CL02 Notes On Project-Program Typologies

PM World Today February 2011 (Vol XIII, Issue II)
PM WORLD TODAY FEATURED PAPER FEBRUARY 2011
Notes on project/program typologies

By Alan Stretton, PhD
ABSTRACT In an earlier paper in this journal I presented a listing of 14 program management application areas, and 38 sub-areas. I noted that there was little cross-referencing between these very diverse application areas, and indeed a dearth of materials that aggregate and/or summarise program processes and/or practices relating to individual application areas. Whilst I suggested that everyone would benefit if there was more documented experience of others working in different application areas, I also acknowledged that there were several hurdles to be overcome to progress such documentation, not the least of which is the sheer diversity of application areas. One way of helping overcome this particular hurdle is to identify common elements, or dimensions (as Shenhar calls them) covering these diverse application areas. This paper moves to the broader field of projects as well as programs (projects/programs), and discusses five different sets of project/program dimensions identified in the literature, plus two from my own experience, under the following headings: Dimension of initial project/program uncertainty (2-type & 4-type) Dimension of project/program complexity/scope (3-type) Dimension of project/program pace (4-type) Dimension of product novelty (3-type) Dimensions of strategic goals and customers (2-type x 2-type) Dimension of project/program customer-or-provider-perspective (3-type) Dimension of perceived primary program purpose (2-type)
INTRODUCTION As noted in the Abstract, I came to this discussion of project/program typologies via a concern about the great diversity of program management applications, and the dearth of materials that aggregate and/or summarise program processes and/or practices relating to individual application areas. This led to the thought that one way of facilitating cross-fertilisation across application areas would be to identify and classify elements (or dimensions) common to most of these diverse areas. In this paper I have broadened the context of this discussion to include projects as well as programs (projects/programs), because distinguishing between the two is not
Alan Stretton 2011 PM World Today is a free monthly eJournal - Subscriptions available at http://www.pmworldtoday.net Page 1
relevant to these discussions. With regard to classification of dimensions, the best work I have come across is that of Shenhar and his colleagues, who have published extensively on this since the mid-1990s. For some reason, their work has not received the attention I believe it deserves. I will first discuss each of the four sets of project/program dimensions developed by Shenhar and colleagues, with relevant contributions from various other sources. This will be followed by discussion of further dimensions, including two deriving two from my own experience. DIMENSION OF INITIAL PROJECT/PROGRAM UNCERTAINTY Shenhar 1995 first proposed A two-dimensional taxonomy of engineering projects and systems. These two dimensions were Technological Uncertainty and System Scope. The following discussion is concerned with the former. Shenhars four levels of Technological Uncertainty were labelled as Low Tech, Medium Tech, High Tech and Super High Tech, as shown in Figure 1.
SYSTEM SCOPE
Array
System
Assembly
Low Tech Medium Tech High Tech Super High Tech TECHNOLOGICAL UNCERTAINTY
Figure 1: Shenhar 1995, Figure1. A two-dimensional taxonomy of engineering projects and systems
Later, as for example in Shenhar & Dvir 2004, Figure 50.1, the descriptor Technical was dropped from the title of this dimension, which was retitled simply Uncertainty, with a note that it applied to uncertainty at the moment of project initiation. I will adopt this more generalised understanding of Uncertainty in the following discussions. A good deal of the project/program literature has tended to assume (either explicitly, or implicitly) conditions of low initial uncertainty. However, more writers are now discussing projects/programs with high initial uncertainty, and several are critical of low initial uncertainty assumptions (e.g. Lycett et al 2004, Thiry 2004 and Pellegrinelli et al 2007).
However, such criticism would become irrelevant if it were recognised that, in practice, there are two basic contextual situations i.e. low initial uncertainty, and high initial uncertainty and if it were clearly stipulated which of these two contexts applied. Admittedly a clear distinction between the two cannot always be made, but a note about the nature of any uncertainty would help clarify the situation. Many types of potential uncertainties Atkinson et al 2006 discuss the management of uncertainty in the project context in some detail, as is indicated in the following quote from their abstract.
The management of uncertainty is seen as a necessary condition for effective project management. Sources of uncertainty are wide ranging and have a fundamental effect on projects and project management. These sources are not confined to potential events, and include lack of information, ambiguity, characteristics of project parties, tradeoffs between trust and control mechanisms, and varying agendas in different stages of the project life cycle. Common project management practice does not follow many fundamental sources of uncertainty, particularly in soft projects where flexibility and tolerance of ambiguity are necessary. More sophisticated efforts to recognise and manage important sources of uncertainty are needed.
This is a very wide range of uncertainties. Following the last sentence of this quotation, we will discuss some types of uncertainty which various contributors to the project management literature have evidently regarded as important. Goals and/or methods uncertainties The earliest contribution to initial project uncertainties I know of is that of Turner & Cochrane 1993, who developed a matrix involving two types of uncertainty, namely in relation to goals and methods, which gives a four-type project typology, as follows.
No Methods Well Defined Yes Type 2 Project
e.g. Product Development
Type 4 Project
e.g. Research; Organisational Change
Type 2: Methods for achieving project goals are initially uncertain Type 4: Both methods and goals initially uncertain
Type 1 Project
e.g. Engineering
Type 3 Project
e.g. Applications Software Development
Type 1: Both goals and methods initially known Type 3: Goals of the project are initially uncertain
Yes
No Goals Well Defined
Figure 2: Adapted from Turner & Cochranes Figure 1. Goals-and-methods matrix
Turner & Cochrane go on to develop themes of start-up techniques and implementation techniques appropriate to each of their four project types. Obeng 1994 identified similar
initial uncertainties about the project (but with rather more colourful descriptors of the project types). Japans P2M 2008 identifies two types of programs in the context of degrees of initial uncertainty:
(a) (b) Creative-type program where the concept is ambiguous - i.e. high initial uncertainty e.g. R&D programs Operation-type program where the initial concept is shared with stakeholders - i.e. relatively low initial uncertainty e.g. programs to modify/improve existing systems.
In the terminology of Turner & Cochrane, P2Ms creative-type program would appear to be akin to their Type 4 project, and operation-type programs to Type 1. We now look at each of Turner & Cochranes two types of uncertainty in more detail. Project methods uncertainties In discussing their Type 2 projects, Turner & Cochrane say
In these projects, the goals are well defined, but the methods of achieving them are not. They are typified by product-development projects. Many of the early projects, through which modern project management was developed, e.g. Atlas, Polaris and Apollo, were of this type.
As already noted, Shenhar & Dvir 2004 focus on technological uncertainty. They say:
The major source of task uncertainty is technological uncertainty. (Other types may involve team experience or tight budget constraints)..We found four distinct levels of technological uncertainty associated with different project categories: .. Type A: Low-Tech Projects. These projects rely on existing and well-established technologies. [e.g.] rebuilding an existing product. . Type B: Medium-Tech Projects: These use mainly existing or base technology, yet incorporate some new technology or a new feature that did not exist in previous products. Type C: High-Tech Projects: These projects represent situations in which most of the technologies employed are new but nevertheless exist when the project is initiated. .. [e.g.] defense development. Type D: Super High-Tech Projects. These projects are based on new technologies that do not exist at project initiation. While the mission is clear, the solution is not[e.g.] Apollo moon-landing program.
Shenhar & Dvir are concerned with levels of uncertainty of technological methods. If this classification were interpreted flexibly, these four levels of methods uncertainty would appear to be applicable in many, if not most, project contexts, Project goals uncertainties In discussing their Type 3 projects, Turner & Cochrane say
In these projects, the goals are not well defined, but the methods are. They are typified by software-development projects, in which it is notoriously difficult to specify the users requirements. The goals are known to exist, but cannot be specified precisely until users begin to see what can be produced, often during the testing stages.
I have not seen a breakdown of goals uncertainties into levels which are in any way equivalent to the above levels of methods uncertainties. Uncertainties typologies As noted in the preamble to this section on project/program uncertainty, some writers have criticised assumptions of low initial uncertainty, but such criticism would become irrelevant if it were recognised, and stipulated, whether low initial uncertainty, or high initial uncertainty, applied, and the nature of the initial uncertainty, if high. A minimum uncertainty typology Therefore, a minimum basic typology would be to categorise the initial uncertainty context for programs into two levels (using the identifier U for initial uncertainty). I have used P2Ms descriptors for these (but do not particularly care for creative-type as a descriptor, and would welcome alternative suggestions).
U1: Operation-type projects/programs, which have relatively low initial uncertainty in most areas relevant to the program. U2: Creative-type projects/programs, which have relatively high initial uncertainty in one or more key areas relevant to the program.
A more detailed project methods uncertainly typology In cases where there is significant uncertainty regarding the methods to be used to progress the project, the addition of Shenhar & Dvirs typology would appear to be appropriate (using the prefix T for Technological uncertainty, but it could be appropriate for other forms of uncertainty).
T1: Low-Tech projects/programs, which rely on existing and well-established technologies. T2: Medium-Tech projects/programs, which use mainly existing technology, but include some new technology or a new feature that did not exist in previous products. T3: High-Tech projects/programs, in which most of the technologies employed are new but nevertheless exist when the project is initiated. T4: Super High-Tech projects/programs , which are based on new technologies that do DIMENSION OF PROJECT/PROGRAM COMPLEXITY/SCOPE not exist at project initiation.
DIMENSION OF PROJECT/PROGRAM COMPLEXITY/SCOPE As shown in Figure 1 above, Shenhar originally labelled the second of his project dimensions as System Scope. In his 1996 paper, Shenhar changed this to the System Complexity (Scope) dimension. Before discussing his three levels in this dimension, I will look at other contributions relating to project/program complexity/scope. In the following I distinguish between the various literatures specifically concerned with major projects/programs (i.e. mega-projects and the like), which I will simply call the major project/ program literature, and the mainstream project management literature, which I will call the non-major project/program literature. Major project/program literature The literature on major projects/programs gives extensive and detailed attention indeed to size and complexity, and to processes for managing complexity. For example, in his book on the management of weapons systems projects, Bennett 1990 devotes a chapter (No. 7) to The Forest of Complexity. In the context of very large engineering projects, Stringer 1982:9 says
The scale, duration, and complexity [of large projects] are such that the work is beyond the detailed understanding of any of those involved.
Jaafari 2004 says that complexity stems from two sources: the projects external environment and the complex makeup of the project itself. In its course notes on Managing Major Programs, UMT 2007 gives substantial attention to program complexity, and identifies four types of complexity which apply to typical major programs, namely complexity associated with sheer scale, with variety, with difficulty, and with change. It also makes the following comments on size/complexity.
A software project whose budget is one-fifth the size of a construction project may entail more management effort than the construction project, because a large portion of the budget of construction projects is tied up with the cost of materials.. In general, knowledge-based tasks/projects with smaller budgets and labor allocations may require more program management effort than much larger tasks/projects dealing with routine, physical production (e.g. construction, development of hardware).
As noted in Stretton 2009b, there have been recent moves to isolate complex projects from the mainstream, as is evidenced by the formation of an International Centre for Complex Project Management (ICCPM) in 2008, and of a College of Complex Project Managers in Australia.
Non-major project literature Issues relating to program complexity are being more frequently discussed in the nonmajor program literature e.g. Alderman et al 2005, Crawford et al 2006, Frame 1994:Ch2 but do not have the prominence that these issues command in the major project literature. Covering both major and non-major projects/programs Shenhar & Dvir 2004 discuss complexity issues that straddle both major and non-major projects/programs. Their primary context is evidently product development programs/projects, but their levels of complexity appear to cover many other contexts. They say:
Project complexity depends upon product scope, number and variety of elements, and the interconnection between them. But it also depends on the complexity of the organisation and the connections amongst its parties.
It will be noted that this perception of project complexity is concerned with the makeup of the project itself, and not with the complexity of the projects environment (referring to the above note by Jaafari 1994). We continue with considering the former. Later, under the heading Project Complexity (System Scope), Shenhar & Dvir (2004) say:
.a simple way to define and distinguish among different levels of complexity is to use a hierarchical framework of systems. Project management practices,, can be distinguished by three typical levels, as follows. Level 1: Assembly Projects. Assembly projects involve creating a collection of elements, components, and modules combined into a single unit or entity that is performing a single function. Assembly projects are relatively simple; they may produce a stand-alone product such as a CD player or a coffee machine, or create a subsystem of a larger systems such as a computer hard drive or a radar receiver. They may also involve restructuring a functional organisation or building a standalone service.. Level 2: System Projects. System-type projects involve a complex collection of interactive elements and subsystems, jointly dedicated to a wide range of functions to meet a specific operational need. System projects may produce aircraft, cars, computers, or buildings, but they may also involve reengineering efforts of entire businesses. .. Level 3: Array Projects. Array-type projects deal with large, widely dispersed collections of systems that function together to achieve a common purpose, such as city public transportation systems, national air defense systems, or interstate telecommunication infrastructures. Arrays are clearly large-scale projects.
Shenhar & Dvirs complexity/scope typology Shenhar & Dvirs complexity/scope typology appears to be the only systematically detailed one in the literature, and there appears to be no reason not to adopt it, recognising always that it is concerned with the makeup of the project itself, and not directly with external complexities. This typology uses the prefix C for Complexity.
C1: Assembly projects/programs, which consist of a collection of elements, components, and modules combined into a single unit or entity that is performing a single function. C2: System projects/ programs, which are a complex collection of interactive elements and subsystems, jointly dedicated to a wide range of functions to meet a specific operational need. C3: Array projects/programs, which are large, widely dispersed collections of systems that function together to achieve a common purpose
DIMENSION OF PROJECT/PROGRAM PACE The only writers to discuss this dimension are Shenhar and colleagues, as is illustrated in the following figure from Shenhar & Dvir 2004.
COMPLEXITY
Array System Assembly
NOVELTY
Breakthrough Platform Derivative Low-Tech Regular Fast/Competitive MediumTech HighTech
TECHNOLOGY
Super HighTech
PACE
Blitz/Critical
Figure 3: Shenhar & Dvir 2004, Figure 50.3: The NCTP Framework
As this is the only reference to pace that I could find in the literature, these three levels are adopted (when they are relevant) as follows (with the prefix Pace),
Pace 1: Regular projects/programs, whose timing is not critical to achieving success. Pace 2: Fast-competitive projects/programs, which are typically conceived to address market opportunities, create a strategic positioning, or form new business lines. Pace 3: Critical-blitz projects/programs, for which meeting schedule is critical to success, and project delay means failure.
DIMENSION OF PRODUCT NOVELTY This is the most recent of the four dimensions developed by Shenhar and his colleagues, as illustrated in Figure 3 above. It is specifically concerned with product development projects/programs. Product novelty is defined by how new the product is to its potential users. Shenhar & Dvir 2004 nominate three levels of product novelty.
Derivative products are extensions and improvements of existing products. Platform products are new generations in existing product families. Breakthrough products are new-to-the-world products.
These could be useful typologies in relevant circumstances. However, they are rather specialised, and do not appear to me to be general enough to warrant inclusion in a general project/ program typology. None-the-less, they do appear to have a link with Shenhar & Dvirs strategic goal dimension, to which we now turn. DIMENSIONS OF STRATEGIC GOALS AND CUSTOMERS The project/program strategic goal dimension Shenhar & Dvir 2004 discuss a strategic goal dimension, in which they distinguish between what they call strategic projects and operational projects as follows.
Strategic projects relate to new business. These are prime efforts that are made to create or sustain strategic positions in markets and businesses. Typically, strategic projects are initiated with a long-term perspective in mind. Operational projects deal with existing businesses. They involve improvements in products, line extension, and cash cow projects, to gain more revenue from existing businesses.
As just noted, there does appear to be a link between the three levels of the product novelty dimension and the project/program strategic goal dimension. There are evidently connections between derivative products and operational projects on the one hand, and between platform and breakthrough products and strategic projects on the other. The project/program customer dimension Shenhar & Dvir also discuss a customer dimension, which involves external and internal customers, as follows.
External projects are made for external customers, contracted or non-contracted Internal projects are done within the organisation, for internal departments or units
Combining the strategic goal and customer dimensions Shenhar & Dvir combine the strategic goal and customer dimensions to give four major groups of projects, as exampled in the following table.
Operational External Internal
Product improvement Maintenance Improvement Problem solving
Strategic
New product development Utility and infrastructure Research
Figure 4: Combining strategic goal and customer dimensions. (Shenhar & Dvir 2004 Table 50.2: Strategic portfolio classification)
DIMENSION OF PROJECT/PROGRAM CUSTOMER-OR-PROVIDER-PERSPECTIVE In the context of external projects/programs, it is often important to identify whether we are talking about the perspective of the organisation providing the project/program assets/services, or about the perspective of the customer/owner of these project/program assets/services. The perspectives of these two parties on the same project/program will often be very different. There is substantial variation in the literature about whose perspective is being considered. In the major project/program literatures, the perspective is generally on project/program management by the customer/recipient organisation. One of the few exceptions I found where the focus was on the providing organisation was in engineering and construction, where Prieto 2008b discusses using the project/program approach to help the recipient organisation prepare for utilising the delivered assets. In the literature on non-major projects, the focus is generally on the provider of project management assets/services (e.g. the PMBOK Guide), whether to external or internal customers. A particular case of the latter arises in discussions of program management in this literature, which is primarily concerned with organisational change/betterment programs undertaken by the organisation itself. Such projects/programs are internal (as defined above), and the perspective is of both provider and customer/owner. The above suggests that the following three-type typology may be useful for describing the perspective that is relevant to particular projects/programs (P for perspective)
P1: Perspective of customer of projects/programs delivered by external provider P2: Perspective of provider of projects/programs, delivered to external customers P3: Perspective of provider-and-owner/customer of internally delivered projects/ programs
DIMENSION OF PERCEIVED PRIMARY PROJECT/PROGRAM PURPOSE Undoubtedly, the ultimate reason for undertaking any project/program is to provide benefit(s) of some sort. However, in my experience, all too often responsibility for the realisation of the benefits is not in the hands of the project/program team, but is explicitly retained by the customer. Sometimes there is partial, but limited involvement by the project team, with the real decision-making remaining with the customer. The assumption that the project team has real powers in benefits realisation is probably applicable mainly to internal projects/programs, where it can be easily arranged or mandated. If the situation is that the customer assumes the responsibility for realising the benefits, then the purpose of the project/program is simply delivery of the assets to the specified quality etc. This appears to be the case in very many major projects/programs. For example, in the context of defence acquisition programs (e.g. weapons systems) Delano 1998 says that one of the significant elements contributing to program success is that the procured item (e.g. a weapons system) works well when fielded. Clearly, in such cases the customer organisation takes the responsibility for ensuring that the project/program deliverables are marshalled to realise the longer-term benefits. In such cases, we clearly have assets-delivery-focused projects/programs. In contrast with the major project/program literature, the program management contributions in the non-major project management literature, which are primarily concerned with organisational change/betterment programs, tend to emphasise realisation of benefits to the organisation, rather than the delivery of assets which facilitate such benefits realisation. This restricted perception of the nature of programs has led to such myopic assertions as Programmes deal with outcomes; projects deal with outputs (OGC 2007:4). The reality is that, if the circumstances are such that the project/program management team is contracted to include the benefits realisation, then we can classify such project/programs as benefits-realisation-focused. Therefore the following two-type program classification is proposed in the context of the focus of project/program purpose (F for focus).
F1: Assets-delivery-focused projects/programs F2: Benefits-realisation-focused projects/programs
SUMMARISING THESE PROJECT/PROGRAM MANAGEMENT TYPOLOGIES There appears to be little doubt that the degree of initial uncertainty is one of the most important of these typologies. In this case we have two levels, the general, and the
methods-specific, which here is related specifically to uncertainty in the technological context, but is evidently transferable to other forms of methods uncertainty. The other dimensions are a little more straightforward, as is indicated in the following summary table of the typologies discussed above.
4
Initial General
U1: Operation-type projects - low initial uncertainty of the uncertainties clearly identified and articulated
SUMMARISING Uncertainty; THESE PROJECT/PROGRAM TYPOLOGIES U2: Creative-type projects -MANAGEMENT high initial uncertainty, with the nature(s) Dimension of initial project/program uncertainty
Initial T1: Low-Tech projects - using existing established technologies. Uncertainty; T2: Medium-Tech projects mostly existing, but some new techs Dimension of project/program complexity/scope re Methods T3: High-Tech projects - mostly new techs, but existing at initiation T4: Super High-Tech projects - completely new technologies
Shenhar & Dvirs complexity/scope typology appears to be the only systematically detailed literature, and was adopted, as follows. Project one in theC1: Assembly projects - a collection of elements combined into a
Complexity/ single unit or single function entity. C1: Assembly which consist of of a interactive collection of elements, Scope C2: projects/programs System projects , - complex collection elements components, and modules combined into a single unit or entity that is performing dimension C3: Array projects - large, widely dispersed collections of systems that a single function. function together to achieve a common purpose C2: System projects/ programs, which are a complex collection of interactive subsystems, jointly dedicated to is a not wide rangefor of success. functions to meet Projectelements and Pace 1: Regular projects - timing critical need. Pace a specific operational Pace 2: Fast-competitive projects to address market opportunities, C3: Array projects/programs, which are large, positioning, widely dispersed collections of dimension create strategic or form new business systems that function together to achieve a common purpose Pace 3: Critical-blitz projects - meeting schedule is critical to success,
Dimension of project/program pace

Product
and project delay means failure.
Derivative products extensions/improvements of existing products.
Here again Shenhar & Dvirs typology appears to be the only one on offer, as follows. Novelty Platform products - new generations in existing product families.
Breakthrough products - new-to-the-world products. Pace 1: Regular projects/programs, whose timing is not critical to achieving success. Strategic goal Operational Strategic Pace 2: Fast-competitive projects/programs conceived to /customer External Product improvement , which are Newtypically product development market opportunities, positioning, or form new dimension address Internal Maintenancecreate a strategicUtility and infrastructure business lines. Improvement Research Problem solving, for which meeting schedule is critical to Pace 3: Critical-blitz projects/programs success, and project delay means failure. P1: Of customer of projects delivered by external provider Customer-orP2: Of provider of projects delivered to external customers provider P3: Of provider-and-owner/customer, re internally delivered projects perspective Perceived primary focus F1: Assets-delivery-focused projects/programs F2: Benefits-realisation-focused projects/programs
This is a substantial list of project/program typologies. Not all of them will be relevant all the time, but this summary does constitute a substantial checklist.
REFERENCES
ALDERMAN Neil, Chris IVORY, Ian McLOUGHLIN & Roger VAUGHAN 2005. Sense-making as a process within complex service-led projects. International Journal of Project Management, Vol 23, pp 380-385. ATKINSON, Roger, Lynn CRAWFORD & Stephen WARD, 2006. Fundamental uncertainties in projects and the scope of project management. International Journal of Project Management, Vol 24, pp 687-698. BENNETT F N 1990. The amateur managers: A study of the management of weapons system projects. Canberra Papers on Strategy and Defence No 67, Canberra, Strategic and Defence Studies Centre, Research School of Pacific Studies, Australian National University. CRAWFORD, L.H., HOBBS, J.B. & TURNER, J.R. 2006 Aligning capability with strategy: categorizing projects to do the right projects and to do them right. Project Management Journal 37 (2):38-51. DELANO, Kenneth J 1998. Identifying Factors that Contribute to Program Success. Acquisition Review Quarterly, Winter. FRAME, J Davidson 1994. The new project management. San Francisco CA, Jossey-Bass JAAFARI, Ali 2004. Modeling of large projects. In The Wiley Guide to Managing Projects, Eds Peter W G Morris & Jeffrey K Pinto, Hoboken, NJ; John Wiley & Sons. Chapter 12, pp 288-320. LYCETT Mark, Andreas RASSAU & John DANSON 2004. Programme management: A critical review. International Journal of Project Management, Vol 22, pp 289-299. OBENG, Eddie 1994. All change! The project leaders secret handbook. London, Pitman Publishing. OGC (OFFICE OF GOVERNMENT COMMERCE) 2007. Managing successful programmes. 3rd Edition, London, The Stationary Office. PELLEGRINELLI, Sergio, David PARTINGTON, Chris HEMINGWAY, Zaher MOHDZAIN & Mahmood SHAR 2007. The importance of context in programme management: An empirical review of programme practices. International Journal of Project Management, Vol 25, pp 41-55. PMI (PROGRAM MANAGEMENT INSTITUTE) 2008. A Guide to the Project Management Body of Knowledge. 4th Edition, Newtown Square, PA; Project Management Institute PRIETO, Robert 2008b. Foundations, frameworks & lessons learned in program management. PM World Today, VolX, Issue V, May. P2M 2008. Project and program management for enterprise innovation: Guidebook. Tokyo, Japan; Project Management Association of Japan (PMAJ).
SHENHAR, Aaron J 1996. Project Management Theory: The Road to Better Practice. Proceedings of the 27th Annual Project Management Institute Seminars & Symposium. Boston, MA; October 7-9. SHENHAR, Aaron J 1995. A project is not a project is not a project: a contingent project management framework. Proceedings of the 26th Annual Project Management Institute Seminars & Symposium. New Orleans, LA; October 16-18. SHENHAR Aaron J & Dov DVIR 2004. How projects differ, and what to do about it. In The Wiley Guide to Managing Projects, Eds Peter W G Morris & Jeffrey K Pinto, Hoboken, NJ; John Wiley & Sons. Chapter 50, pp 1265-1286. STRETTON, Alan 2009b. Program management diversity Problem or opportunity. PM World Today, Vol XI, Issue VI, June. STRINGER, John 1982. Towards a theory for the management of large engineering projects. Working Paper No. 82-006. Kensington, NSW, Australian Graduate School of Management, University of New South Wales (mimeo) THIRY, Michel 2004a Program management: A strategic decision management process. In The Wiley Guide to Managing Projects, Eds Peter W G Morris & Jeffrey K Pinto, Hoboken, NJ; John Wiley & Sons. Chapter 12, pp 257-287. TURNER, J R & R A COCHRANE 1993. Goals-and methods matrix: coping with projects with ill defined goals and/or methods of achieving them. International Journal of Project Management, Vol 11, No 2, May, pp 93-102. UMT 2007. Management of major programs. Course notes, UMT PM-279. Arlington, VA; University of Management and Technology.
About the Author:
Alan Stretton, PhD

Author
Alan Stretton is currently a member of the Faculty Corps of the University of Management and Technology, Arlington, Virginia, USA. In 2006 he retired from a position as Adjunct Professor of Project Management in the Faculty of Design, Architecture and Building at the University of Technology, Sydney (UTS), Australia, which he joined in 1988 to develop and deliver a Master of Project Management program. Prior to joining UTS, Mr. Stretton worked in the building and construction industries in Australia, New Zealand and the USA for some 38 years, which included the project management of construction, R&D, introduction of information and control systems, internal management education programs and organizational change projects. He has degrees in Civil Engineering (BE, Tasmania) and Mathematics (MA, Oxford), and an honorary PhD in strategy, programme and project management (ESC, Lille, France). Alan was Chairman of the Standards (PMBOK) Committee of the Project Management Institute from late 1989 to early 1992. He held a similar position with the Australian Institute of Project Management (AIPM), and was elected a Life Fellow of AIPM in 1996. He was a member of the Core Working Group in the development of the Australian National Competency Standards for Project Management. He has published over ninety professional articles. Alan can be contacted at alanailene@bigpond.com.au.

CL02 Notes On Project-Program Typologies

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CL02 Notes On Project-Program Typologies

Uploaded by

Copyright:

Available Formats

PM World Today February 2011 (Vol XIII, Issue II)

PM WORLD TODAY FEATURED PAPER FEBRUARY 2011

Notes on project/program typologies

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

No Goals Well Defined

Figure 2: Adapted from Turner & Cochranes Figure 1. Goals-and-methods matrix

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

Dimension of project/program pace

and project delay means failure.

Derivative products extensions/improvements of existing products.

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

PM World Today February 2011 (Vol XIII, Issue II)

About the Author:

Alan Stretton, PhD

You might also like