Towards a program management body of knowledge
Associate Professor, ISGI – Lille School of Management
In the last few years, a number of organizations have moved from a “contained” project management perspective to a more strategic one. Program management (PgM) has stemmed from this more strategic approach. This new discipline has required organizations to acquire knowledge outside the scope of the PMBOK® Guide and to explore new areas of knowledge and practice, such as strategic management, value management, supply and value chain management and others.
At the moment, there is still no formalization of program management practice or even a real consensus on its definition, let alone what could be called a body of knowledge. The CCTA's (now OGC-Office of Government Communications) Managing Successful Programmes (2000) probably comes closest to a Program Management Body of Knowledge (PgMBoK), although it remains very much in a project paradigm.
With the PMBOK® Guide 2000 and the PMBOK® Guide Exposure Draft 2004 as a framework and starting point, this paper draws a parallel between project and program management. Five program management process groups and 9 program management knowledge areas are presented for discussion and comparison to the project management process groups and knowledge areas. The intent is for readers to clearly understand the differences between programs and projects and formalize their respective practices.
The PMBOK® Guide (PMI, 2000) defines programs as “consisting of several associated projects [that] will contribute to the achievement of a strategic plan.” It adds: “A program is a group of projects managed in a coordinated way to obtain benefits not available from managing them individually. Many programs also include elements of ongoing operations.”
The APM Body of Knowledge (2000) states: “There is widespread variation in the use of the term Programme Management. […] The most common – and cogent – definition is that a programme is a collection of projects related to some extent to a common objective.” (p.15) The CCTA (2000) has offered the following definition: “Programme management is the co-ordinated management of a portfolio of projects that change organisations to achieve benefits that are of strategic importance” (Sec.1.3). The CCTA (2000) has taken a view of programmes mainly associated with large IT change programmes or, with a ‘portfolio’ application to multi-project management (Ch.11).
In the Gower Project Management Handbook, Murray-Webster and Thiry (2000) have offered the following definition: “A programme is a collection of change actions (projects and operational activities) purposefully grouped together to realise strategic and/or tactical benefits.” (p.48) This definition is more encompassing than the three previous and emphasizes the purposefulness of the grouping of projects as a key concept underlying programs.
Recently Thiry (2004) has linked Program Management to Strategic Decision Management, supporting the PMI view that programs contribute to the achievement of a strategic plan. Here, the dynamic nature of Program Management is emphasized in contrast to Portfolio Management, which is a more static management approach.
Note: In the context of this paper, the definition of benefits is: “The measurable improvement to existing and new business operations and services.” (CCTA, 2000, Section 4.8)
A Program Paradigm
In recent years, a number of authors have recognized the need for a specific program stance (Grundy, 2001; Murray-Webster & Thiry, 2000; Pellegrinelli, Partington & Young, 2003; Reiss & Rayner, 2001). Processes that are applicable to project management cannot be readily applied to PgM, as programs have an uncertain finality and high ambiguity, and are generally longer-term ventures. In previous publications, Thiry (2002a, 2002c) has identified a Project-Based Paradigm, based on uncertainty reduction and performance as well as a Strategy-Based Paradigm based on ambiguity reduction and learning.
By definition the program paradigm is closer to a strategic paradigm than a project paradigm thus, the need to define the framework of a PgMBoK that is different from that of the PMBOK® Guide. Key issues supporting this new paradigm, such as learning versus performance, as well as decision-making and implementation, have been discussed in previous writings (Thiry, 2002a, 2002c).
Recently, Thiry (2002b, 2003, 2004) has defined five program process groups that support the PgM paradigm. The wording of which reflects a strategic discourse, as shown below.
|Initiate: begin, bring into use, get something going||Formulate: express clearly & systematically|
|Plan: arrange beforehand, design, intend||Organize: give an orderly structure, systematize|
|Execute: carry out, perform, follow through, fulfil||Deploy: spread, unfold, bring into effective action|
|Control: restrain, regulate, compare to standard, verify||Appraise: judge, estimate the value, evaluate formally|
|Close: bring to an end, settle, finish||Dissolve (Conclude): disintegrate, decompose, disperse|
|Set, objective, precise||Evolving, subjective, fuzzy|
Source: Webster Dictionary and Oxford Dictionary.
The PMBOK® Guide (PMI, 2000, p.30 & PMI, 2004, Ch.3) defines the five project process groups as:
Initiating: Authorizing the project or phase. (2004 – defines and authorizes the project or phase.)
Planning: Defining and refining objectives and selecting the best of the alternative courses of action to attain the objectives that the project was undertaken to address. (2004 - defines and refines objectives and plans the best alternative courses of action to attain the objectives and scope that the project or phase was undertaken to address.)
Executing: coordinating people and other resources to carry out the plan. (2004 - integrates people and other resources to carry out the project management plan for the project or phase.)
(Monitoring and) Controlling: ensuring that project objectives are met by monitoring and measuring progress regularly to identify variances from plan so that corrective action can be taken when necessary. (2004 - requires that progress is regularly measured and monitored to identify variances from the project management plan, so that corrective action can be taken when necessary to meet project or phase objectives.)
Closing: formalizing acceptance of the project or phase and bringing it to an orderly end. (2004 Draft - formalizes acceptance of the product, service, or result and brings the project or phase to an orderly end.)
Thiry (2002b) has defined five program management groups as:
Formulation is the stage where purpose is defined, stakeholders are identified and their needs and expectations defined; it is also the stage where program benefits are determined.
Contrary to project initiating, it is a complex decision-making process, where ambiguity is high.
Organization is the process of selecting and prioritizing projects and other actions required to deliver benefits and, according to conclusions, set up the program team and structures.
Project planning mainly consists of breaking down the project into manageable units and to reduce uncertainty. The organization process requires a system's view and consists of putting in place learning and ambiguity-reduction processes, not only to achieve agreed objectives, but to identify and exploit emergent opportunities.
Deployment involves the actual implementation of projects and other actions as well as the management of their interdependencies.
Again this process requires a system's view, specifically for the management of interdependencies and resources. It extends beyond the simple delivery of product outputs. Since benefits can only be accounted for when the product is put to use, therefore emphasizing the correlation between programs and product life cycle. Contrary to project execution, and like organization, deployment must identify and exploit emergent opportunities, rather than stick to a baseline.
Appraisal essentially concerns the program level assessment of benefits.
Contrary to project (monitoring and) control, this process relies on a formative, rather than summative approach of control (Guba & Lincoln, 1989). Summative evaluation is based on the definition of a baseline, or standard, (in this case, the project plan) to which progress is compared for evaluation purposes. Formative evaluation is a prospective process, based on the concept of improvement; it delineates what needs to be done to achieve the objectives in regards of what has already been accomplished.
Dissolution happens when the rationale for the program no longer exists. Dissolution is a phasing down process, much more extensive than project closing.
The PgM process groups sequence is represented as follows:
Figure 1: The program life cycle (© Thiry, 2000-2002)
Although program processes have been defined in previous work (Thiry, 2002b, 2002,c, 2003, 2004), program management knowledge areas (KA) have not been identified as such in published work. Reiss and Rayner (2001) have identified “ten key disciplines that contribute significantly to programme success” (p.4), inspired from CCTA (2000), as part of their Program Management Maturity Model, but only two of them, benefits and stakeholder management, can be directly linked to program knowledge areas, the others are mere transpositions of project management KAs into programs.
Some of the PgM KAs described below, like stakeholder, benefits, pacing, or uncertainty management, have already been described in the PgM literature, although not necessarily as program knowledge areas. Others, like marketing and partnership management have emerged from practice, and finally, a few, like value and strategic decision management, have emerged from action research conducted by the author.
Additionally, a direct comparison between Program and Project knowledge areas has not yet been established. This section aims to put in parallel project and PgM knowledge areas, using the PMBOK® Guide (PMI, 2000) structure. This structure, exposed in the table below, may not be the most appropriate for PgM knowledge areas, but will help clarify the differences and similarities between the two bodies of knowledge.
Comparison of Project and Program Knowledge Areas:
|Integration Management||Strategic Decision Management|
|Scope Management||Stakeholder Value Management|
|Time Management||Pace Management|
|Cost Management||Resource Management|
|Quality Management||Benefits Management|
|Human Resources Management||Stakeholder Relationship Management|
|Communications Management||Communication/Marketing Management|
|Risk Management||Uncertainty Management|
|Procurement Management||Partnership Management (Value Chain)|
In the following section project and program management knowledge areas are compared and explained.
Integration Management vs. Strategic Decision Management
PMBOK® Guide View
The PMBOK® Guide 2000 states that: “Project Integration Management includes the processes required to ensure that the various elements of the project are properly coordinated” (PMI, 2000 p7). In the PMBOK® Guide 2004 exposure draft, the scope of integration management is clarified and establishes a transactional (Burns, 1978; Bennis & Nanus, 1985) approach for project integration. “The Project Integration Management knowledge area includes the processes and activities […] within the Project Process Groups. […] Integration, in the context of managing a project, is making choices about where to concentrate resources and effort […]” (PMI, 2004). This view enables project managers to concentrate on what they do best: achieving high performance of clearly defined objectives within set parameters. In summary, project integration management is based on the development and implementation of a project plan-a deliberate strategy (Mintzberg and Waters, 1994)-and a summative approach to change.
Program size and time span make for a more complex environment. Continually changing circumstances require use of configuration strategy (Mintzberg et al., 1998), which combines both deliberate and emergent strategies (Mintzberg & Waters, 1994). PgM takes a formative approach to change; whereas projects require a transactional approach, the emergent nature of PgM requires more of a transformational (Burns, 1978; Bennis & Nanus, 1985) approach. Recently, Thiry (2002c, 2004) has argued that program management should be linked to a strategic decision management process aimed to achieve strategic and or tactical benefits through a series of learning and performance loops. The learning loops focus on a value-based decision process, including change management, whereas the performance loops focus on the delivery of results.
The equivalent knowledge area of integration management in PgM should be Strategic Decision Management, a cyclic, benefits-oriented process capable of dealing with emergent inputs and continually evolving circumstances.
Scope Management vs. (Stakeholders) Value Management
PMBOK® Guide View
The PMBOK® Guide takes for granted that there is a defined scope of work for each project and that it needs to be determined as soon as possible, ideally before, the project starts. The definition of the results expected to satisfy stakeholders needs is clearly in the hands of the project sponsors (PMI, 2004).
Thiry (2002a, 2004) has argued that the PgM process should combine value management and project management, where value management is used to reduce ambiguity to identify and agree stakeholders' needs and expectations and translate them into measurable critical success factors (CSF) that constitute the scope of the program. Value management is then used as a learning framework to address emergent changes and ongoing stakeholders needs management.
The CCTA (2000) states that: “Some stakeholders […] will be a key group for assessing the realisation of the programme's benefits [and that] it is important to recognise their specific interest areas in order to ensure that their expectations can be managed effectively.” (Sec.6.1) The process they advocate in the stakeholder management chapter though, is basic and concerns only their identification and the establishment of communication channels to manage their expectations.
In a PgM framework, the role of initiator or sponsor of a project is clearly that of the program manager. PgM cannot therefore be content with simply “defining and controlling what is and is not included” (PMI, 2004, Ch.5), but must take an evolving, systemic view of the customers and other stakeholders' needs and expectations. Each project, which forms the program, is prioritized on the basis of its value (contribution to benefits (CSFs) vs. achievability); this is what determines the scope of the program.
It can be safely argued that the equivalent of the scope management knowledge area would be Stakeholders' Value Management in programs: the management of the stakeholders' needs and expectations expressed in measurable terms (CSFs) and prioritized, the sum of which constitutes the program's purpose.
Time Management vs. Pace Management
PMBOK® Guide View
One of the key characteristics of projects is that they have a beginning and an end, usually set by the sponsor(s). Activities duration and critical path control are the critical elements of project time management.
Program managers give their attention to major deliverables and interfaces between projects. As part of the program plan, the CCTA (2000) identifies: “a dependency network showing the optimum sequencing of the projects and their dependencies on each other [and] a schedule of all the benefits to be delivered by the projects and when they will be achieved”. (Section 4.3, table 6) In the case of programs, beginning and, more so end, are usually “fuzzy”. Because of the evolving and complex context of programs, program managers need continually re-evaluate project priorities and benefits delivery. Program time management focuses on resource availability and benefits delivery, not on activity dependencies or duration. Pacing includes prioritization of actions based on interdependencies and benefits delivery. It must focus on early benefits, positive cash flow and maintenance of the motivation of stakeholders (Thiry, 2004).
It would be more appropriate to talk about Pace Management, which concerns the management of relative project priorities in accordance with emergent inputs and “optimal” benefits delivery-not shortest delivery time. It is a deterministic and formative approach whereas time management is a probabilistic and summative approach.
Cost Management vs. Resource Management
PMBOK® Guide View
In a project, cost, like time, is usually a preset parameter. “The project charter is issued […] at a level, within the organization authorizing the project, that is appropriate to funding project needs.” (PMI, 2004, Ch.7) For the project manager, “Project Cost Management includes the processes required to ensure that the project is completed within the approved budget.” (PMI, 2000, p.83).
The program manager is involved in setting project budgets and is usually asked to justify, or “rejustify” the budgets on a regular basis. Additionally, a program's budget includes elements of support activities and investment in supporting structures, which go beyond a simple delivery process.
Program managers build long-term relationships and partnerships with their stakeholders, who can be either providers or customers, sometimes both. The management of funding and cash flow is directly related to these “partnerships”, which also involve an aspect of stakeholder relationship management, when securing human resources for the program and negotiating commitments.
Program budgeting is prospective, as opposed to cost management that is retrospective. It includes reliance on a much wider range of resources that cost alone can cover.
It would be more appropriate, instead of cost management, to talk about Resource Management to describe the above concept. It involves the long-term management of all the resources necessary to successfully carry out the program and is closely linked to pacing management.
Quality Management vs. Benefits Management
PMBOK® Guide View
Project Quality Management is concerned with two things: the quality of the project management process and the quality of the product being delivered. It “includes the processes required to ensure that the project will satisfy the needs for which it was undertaken.” (PMI, 2000, p.95)
Benefits are the key success factors of a program, as quality is one of the key success factors of a project. Benefits are tightly linked to the stakeholders' needs and expectations as quality is to scope in projects. “Benefits management provides the programme with a target and a means of monitoring achievement against that target on a regular basis. […] Care should be taken not to shift [the] focus [of benefits management] to the delivery of new capability” (CCTA, 2000, Section 5.1). Benefits emerge from strategic intent, but cannot be evaluated until project deliverables are operated and marketed; it is therefore essential that PgM covers the whole benefits life cycle if it is to be effective.
A number of organizations consider that it is the responsibility of the program manager to deliver benefits to the business, but this requires authority over the resources necessary to do so. Surprisingly, the CCTA takes a view of benefits management that does not put the responsibility of their delivery in the hands of program managers, but rather in those of the business managers. This takes away all accountability from the program manager for the delivery of benefits, which is not desirable.
What is known in projects as quality management becomes Benefits Management in programs: the management of benefits over time so that ultimate impact of project deliverables correspond to expected benefits.
Human Resource Management vs. Stakeholder Management
PMBOK® Guide View
While the PMBOK® Guide 2000 takes a wider view of Human Resource Management, stating that: “[It] includes the processes required to make the most effective use of the people involved with the project. It includes all the project stakeholders—sponsors, customers, partners, individual contributors, and others […]” (p.107); the 2004 PMBOK® Guide Exposure Draft narrows this view to include only the organization and management of the project team. It states that: “The project team is comprised of the people who have assigned roles and responsibilities for completing the project.” (Ch.9)
The PMBOK® Guide 2000 considers stakeholder management a major challenge for project managers (p.18). Stakeholder management and the resolution of their differences to identify expected benefits is one of the key roles of the program manager. Stakeholder management is a two way relation that involves contribution of the stakeholders to the program and, in certain cases, the forming of partnerships, the equivalent of team development in projects, but on a much larger scale and with much less formal power.
While leadership involves formal power on projects – “the project management team [can] use disciplinary action to maintain order” (PMI, 2004, p.163) -, leadership in programs requires more of a facilitating or negotiating approach, since many of the stakeholders have more formal power than the program manager. Human resources in programs encompass much more than the program team, where relationships are based on trust rather than formal power, therefore requiring skills and competences much broader than simple human resource management.
The best name for this knowledge area would be Stakeholder Management: the management of all the stakeholders of a program to maximize their contribution to the ultimate delivery of benefits.
Communications Management vs. Communications & Marketing Management
PMBOK® Guide View
“Project Communications Management includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information” (PMI, 2000 P7).
The CCTA (2000, Annex B) defines communication strategy as “how information about the programme will be disseminated to stakeholders, people directly involved in the programme, the rest of the organisation, and any other external organisations.” This view is consistent with the PMBOK® Guide view, but personal experience and research have demonstrated that well marketed programs are much more successful than those which solely rely on communication management, as described above. Contrarily to project management, information and data management is just one aspect of PgM communications.
Program management practice has seen the emergence of a new and crucial aspect of communications in programs: marketing. Marketing is more than just advertising; good marketing encompasses strategic integration and not only follows strategy but drives it (Schmetterer, 2003) through learning and knowledge management.
Program Communication and Marketing Management could be summarized as: developing an interactive communication system aimed at gaining stakeholders' support in terms of the strategy and delivery of the program benefits.
Risk Management vs. Uncertainty Management
PMBOK® Guide View
Although the PMBOK® Guide (PMI, 2000) defines Risk Management as covering both maximization of positive effects and minimizing of adverse effect on projects, risk management is still mostly practiced as a threat reduction process.
The management of risks in programs is not very different than that of projects, except that a greater emphasis should be put on opportunities, because of the formative nature of programs. The focus of program risks is of a higher and more systemic level than that of projects.
Differences also include the emergence of three distinct levels of risks: program risks, project risks and “aggregated” risks-project level risks that affect more than one project and are better managed at program level. Program risks definitively encompass both threats and opportunities, take into account ambiguity and a scope outside of the simple known unknown of projects. Chapman and Ward (2000) suggest the term “uncertainty management”, which is also in line with the concepts of emergent strategy developed by Mintzberg and Waters (1985).
It would be appropriate to use the term Uncertainty Management for programs: “an iterative, learning approach” covering both threats and opportunities, where “uncertainties are allowed for at organizational level” and that covers uncertainty related to ambiguity (Chapman & Ward, 2000, p.416).
Procurement Management vs. Partnership and Value Chain Management
PMBOK® Guide View
Whereas, in the 2000 PMBOK® Guide, Procurement Management focuses on the acquisition of goods and services from outside the performing organization (PMI, 2000 p7). In the new PMBOK® Guide Exposure Draft, the scope comprises any acquisition “from outside the project team” (PMI, 2004). This new development widens the scope of the goods and services under consideration, but narrows the role of project managers to their project team, leaving out the rest of the organization.
In programs, long-term relationships are built, which are not contractual, but based on mutual needs. Often, the program manager has to deal with stakeholders who have enormous power and clout. Therefore the standard procurement relationship is not appropriate anymore.
In terms of programs it would be more appropriate to talk about partnership management or Value Chain management, which Pinto & Rouhainen (2001) have very well described in their book: “Building Customer-Based Organizations” (pp. 127-142). Value chain management involves much more than managing relationships required to procure goods and services; it is an organizational level process.
The recommendation is to use the term Partnership Management to describe the program knowledge area required to acquire resources and support for the program from parties within or outside the performing organization. Relationships could be subjected to contractual agreement or not.
Project and program management differ from one another by more than just being concerned with different levels of management. Whereas project management is an uncertainty-reduction performance-based process, program management involves ambiguity-reduction learning-based processes. This means that the process groups and knowledge areas that are valid for project cannot be directly transposed to the management of programs. In particular, managing project interdependencies in a complex environment, is not like managing dependencies between activities and requires different approaches. In program management practice, the author has experienced the need to draw from a much wider range of knowledge areas than when managing projects.
This paper suggests the range of process groups and knowledge areas required to support program management, based on existing literature and research as well as emergent practices. Program management is desperately in need of good inductive research to support the development of a specific body of knowledge. Hopefully this paper will trigger thinking in that direction.
APM (2000) The Association for Project Management Body of Knowledge, 4th Ed., High Wycombe, UK: Association for Project Management
Bennis, W. and Nanus, B (1985) Leaders: The Strategies for Taking Charge. NY: Harper & Row, Publishers.
Burns, J. (1978) Leadership. NY: Harper & Row, Publishers.
CCTA (2000) Managing Successful Programmes, Central Computer and Telecommunications Agency (now called OGC-Office of Government Communications), London, UK. CD Rom Version
Chapman, C. and Ward, S. (2000) “Project Risk Management: The Required Transformations to Become Project Uncertainty Management”. The Frontiers of Project Management Research. Slevin, Cleland & Pinto Eds. Project Management Institute, Newton Square, PA
Grundy T (2001) Strategic Project Management London: Thomson International,
Guba, E.G. and Lincoln, Y.S. (1989). Fourth Generation Evaluation. Newbury Park, CA Sage Publications,
Mintzberg, H. and Waters, J.A. (1985). ‘Of strategies, deliberate and emergent’. Strategic Management Journal, 6-(3), 257-272
Mintzberg, H., Ahlstrand, B. and Lampel, J. (1998) Strategy Safary. London: Prentice Hall.
Murray-Webster, R. and Thiry, M. (2000). ‘Managing Programmes of Projects’ Gower Handbook of Project Management, 3rd edition'. Turner & Simister, Eds. Chapter 3. Aldershot, UK: Gower Publishing,
Pellegrinelli, S, Partington, D, and Young M (2003, .May) Understanding and assessing programme management competence Proceedings of the PMI Europe Congress, The Hague
Pinto, J. K. and Rouhiainen, P.J. (2001) Building Customer-Based Organizations, Wiley &Sons, NYC, NY.
PMI (2000) Guide to the Project Management Body of Knowledge (PMBOK® Guide), Newton Square, PA: Project Management Institute,
PMI (2004) Guide to the Project Management Body of Knowledge Exposure Draft, Newton Square, PA: Project Management Institute,
Reiss, G. and Rayner, P. (2001) The Programme Management Maturity Model, Proceedings of the Fourth European Project Management Conference, PMI Europe 2001, London UK
Schmetterer, R. (2003) Leap, A revolution in Creative Business Strategy. Hoboken, NJ: John Wiley & Sons Inc.
Thiry, M (2002a, April) Combining value and project management into an effective programme management model. International Journal of Project Management, 20(3), 221-228. Oxford: Elseveir Science,
Thiry. M. (2002b, June) FOrDAD, A Program Management Life-Cycle Process, Proceedings of the 5th PMI Europe Conference, Cannes, June 2002. Accepted for publication in International Journal of Project Management, Elseveir Science, Oxford. Scheduled date: May 2004
Thiry. M. (2002c, July) The Development of a Strategic Decision Management Model: An Analytic Induction research process based on the combination of project and value management. Proceedings of the 2nd PMI Research Conference, Seattle, July 2002
Thiry, M. (2003) Programme Management Ch.11, Project Management Pathways. High Wycombe, UK: Stevens Ed. Association for Project Management,
Thiry, M. (2004) Program Management: A Strategic Decision Management Process. Ch. 4 The Wiley Project Management Resource Book. New York: Wiley (in press): Morris & Pinto Eds.
© 2004, Michel Thiry
Originally published as a part of the 2004 PMI Global Congress Proceedings – Prague, Czech Republic