Understanding Programs and Projects—Oh, There's a Difference!

Introduction

The difference between projects and programs has been ignored or confused by many people for too long. A project is chartered to create a specified “deliverable” as efficiently as possible (Project Management Institute [PMI], 2008a). Programs focus on the coordination of a number of related projects and other activities, over time, to deliver benefits to the organization (PMI, 2008b). While it is absolutely possible and often desirable to contract a project to an independent third party (e.g., the developer of a shopping complex can easily contract the building of the center to a construction company), it is virtually impossible to effectively contract out the program management role. The program manager must be an integral part of the organization's strategic business.

Unfortunately, from the very beginnings of modern project management, the terms have often been used interchangeably—for example, the Manhattan Project to create two completely different atom bombs involved numerous major elements such as the construction of factories and the operation of those plants. The Manhattan Project was by all modern definitions a full-blown program of work. Despite the best efforts of the Project Management Institute (PMI), the Office of Government Commerce (OGC), and a range of other organizations, the confusion between projects and programs continues in many quarters to the current day. Most disaster relief efforts are described as “projects,” when in fact they are an ongoing program of work to realize a benefit (i.e., a return to normality). Disaster relief programs include projects and elements of operational work and adapt to changes in the times and circumstances. Program management is about maximizing the benefits realized with constrained resources in a changing environment. Project management is focused on the efficient creation of a defined deliverable (e.g., rebuilding a school).

A more worrying recent trend has been for organizations to start classifying quite simple projects as “programs” in an apparent attempt to avoid the necessity of defining the specific “product, service, or result” that they need. While the degree of difficulty in determining the deliverable may alter the project's strategy and approach, a project remains a project! If the performing organization/client cannot tell the project manager what they want, the project is unlikely to succeed, and changing its name to a “program” won't help.

The boundary that needs to be drawn much more sharply, and the focus of this paper, is between projects that are initiated to create a known deliverable and then shut down and programs that are initiated to create a change and/or realize benefit(s) for the host organization, adapting to circumstances as conditions change and using projects to create individual deliverables within the overall matrix of the program.

Defining the Differences – Project or Program

The Defining Standards

Both PMI and the OGC in the United Kingdom seem to agree that organizations have one or more portfolios of projects and that each portfolio contains a number of programs and projects. Portfolio management focuses on selecting the optimum mix of projects and programs that the organization should undertake based on its available funding and resources. Program management focuses on the coordination of a number of related projects over time to deliver outcomes that benefit the organization, and projects are undertaken for the efficient delivery of a defined output.

PMI Standards

According to the PMBOK^® Guide—Fourth edition (PMI, 2008a, p. 434) the definition of a project is “a temporary endeavor undertaken to create a unique project service or result.” Projects are temporary and close down on the completion of the work they were chartered to deliver.

The definition of a program given in The Standard for Program Management—Second edition (PMI, 2008b, p. 312) is “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may contain elements of work outside of the scope of the discrete projects in the program.”

OGC Standards

The OGC has very similar views embedded in its methodologies. PRINCE2 defines the management of projects and the Managing Successful Programmes (MSP) methodology defines a program as “a portfolio of projects and activities that are coordinated and managed as a unit such that they achieve outcomes and realise benefits” (OGC, 2003, p. 126).

Standardization

As can be seen from the above, the definition of a program is consistent. Programs involve the coordinated management of two or more projects to achieve benefits that would otherwise not be obtained. A program's objective of realizing benefits is a very different one than that of a project or of project management, which, according to their standard definitions, focus on the efficient delivery of products, services, or results—i.e., deliverables. A regularly used short description of the difference is that projects are focused on the efficient creation of outputs; programs are focused on delivering outcomes.

The Four Dimensions of a Project or Program

Every project or program has four basic dimensions:

• Its inherent size, usually measured in terms of value;
• The degree of technical difficulty in creating the output;
• The complexity of the relationships (“small p” politics) with the stakeholders; and
• The degree of uncertainty involved in the work.

The difference between how complicated the work is and its complexity is that managing complicated work (i.e., work with a high level of technical difficulty) is achievable by implementing appropriate systems such as quality management and configuration management. The consequences of technical difficulty are definable, predictable, and manageable with the right people. The essence of complexity, on the other hand, is that the future is inherently unpredictable and the reactions of people to each other within the project or program's network of relationships are nonlinear. The responses/reactions of stakeholders to the work and the consequences of any interaction or communication are not predictable on a linear scale.

Project Size

The size of the project or program will impact the degree of difficulty in achieving its objectives, but large projects are not necessarily complicated or complex. There are projects in Australia to shift millions of cubic meters of “overburden” from mine sites, with expenditures rising to several million of dollars (US) per day, but the work is inherently simple (excavating, trucking, and dumping dirt), and the relationships in and around the project are relatively straightforward. The management challenges are essentially in the area of logistics. One only has to contrast this type of megaproject with the difficulties of successfully delivering a small program to initiate a culture change within an established bureaucracy (say, a new timesheet system with supporting software) to appreciate size is only one dimension of a project or program.

Technical Difficulty (Degree of Complication)

Complicated high-tech projects and programs are inherently more difficult to manage than technically simple projects and programs. The nature of the technical difficulties and the degree of certainty largely depend on how well-understood the work is. Bleeding-edge research has a far higher level of uncertainty associated with every aspect of its management than work of similar technical difficulty that has been undertaken several times before. The degree of understanding of both the work's characteristics and the way it will be accomplished on the part of the client is as important to the success of the endeavor as the understanding of the team. The lower the levels of knowledge and understanding, the more difficult it is to achieve a successful result.

Complexity = Stakeholder Relationships

Complexity theory has become a broad platform for the investigation of complex interdisciplinary situations and helps understand the social behaviors of teams and the networks of people involved in and around a project. These ideas apply equally to small in-house projects and to large complicated programs. In this regard, complexity is not a synonym for complicated or large.

Complexity theory has developed from and includes the earlier field of study known as chaos theory. Complexity theory can be defined as the study of how order and patterns arise from apparently chaotic systems and, conversely, how complex behavior and structures emerge from simple underlying rules (Cooke-Davies, Cicmil, Crawford, & Richardson, 2007). Some of these ideas appear directly relevant to understanding project and program management from a stakeholder relationship perspective and are generally more important in program management.

Uncertainty

The degree of uncertainty associated with the desired output from the team's endeavors has a major impact on the management of the project or program. This is different from the issues around bleeding-edge projects, as discussed earlier. When a bleeding-edge project has a clearly defined endpoint, you are on a quest in which the challenge is finding the optimum route to the end. When the endpoint is unclear, you are either “making a movie” (the processes are well-known but the outcome is uncertain) or “on a walk in the fog,” where neither the route nor the outcome are defined.

The less certain the client is of the requirements, the greater the uncertainty associated with delivering a successful project or program, and the greater the effort required from the team to work with the client to evolve a clear understanding of what's required for success. This is not a problem as long as all of the stakeholders appreciate that they are on a journey to initially determine what success looks like, and then deliver the required results. Problems occur if expectations are couched in terms of achieving an “on time, on budget” delivery when the requirements are not defined and the expected benefits are unclear.

Source: Obeng E (1994) The Project Leader's Secret Handbook Financial Times Prentice Hall

Exhibit 1: Project typology. Note. From All Change!: Project Leader's Secret Handbook (Financial Times Series). By E. Obeng, 1995, London: Prentice Hall. Copyright 1995.

Project Typology

One of the more established ways of describing projects is a typology that maps the interaction of uncertainty and technical difficulty (Figure 1). Managing projects involves knowing both “what to do” and “how to do it,” or, more importantly, knowing how much you know about these two elements. The typology describes four types of projects based on these criteria: “painting by numbers,” “going on a quest,” “making a movie,” and “lost in the fog.” It was developed by Eddie Obeng (1995) in the Project Leader's Secret Handbook, and it asks two questions:

• Are you clear about what to do (the outcome to be achieved)?
• Do you know how to do it (processes, methods, experience)?

Painting by Numbers

Traditional project management works well when both “what's to be done” and “how to do it” are well understood by all key stakeholders including the client and the project team. Closed projects (“painting by numbers”) can be fully defined, estimated, and planned. There are low levels of uncertainty and ambiguity; risks are largely known and manageable. Value is largely achieved by delivering the requirements on time and on budget.

A typical software program of this type would be installing a standard software upgrade across a large organization based in several different cities and with several operating divisions.

Going on a Quest

With these projects and programs, the objective is clear but the way to achieve the objective is uncertain. At the end of the day, success or failure is clear-cut; the objective has been achieved (or not). The challenge is optimizing the way forward. Process and system improvements tend to fall into this category. The objective is to reduce processing time by 20%; this is easily measured at completion. The difficulty is knowing what is the best way to achieve the objective.

Before committing major resources to the main part of the work, adequate time needs to be allowed for prototyping solutions and testing options before a final design solution can be determined and then implemented. The project or program needs to be developed in phases with go/no-go gateways as the design is firmed up. There are risks associated with any creative design process, and most software developments are “quests” requiring creative solutions to identified problems to achieve the desired objective.

Making a Movie

With these projects, the tools and techniques are well-known but the final outcome is uncertain. Only after completion can the results be measured and success or failure be determined. Most culture changes and marketing initiatives (and, of course, actually making movies) are in this category. The tools to be used, including training, communicating, and advertising, are well known, and the traditional (if not optimal) mix of techniques is understood for most situations. What no one can predict is whether the “public” will acclaim the final result, merely accept the final result, or dump the final result.

Traditional project management is not enough in these projects; there is a continual need to measure results, provide feedback information, and adapt the mix of activities to optimize the likelihood of success. The key value measurement is attempting to answer the question “is it worth spending more or should we cut and run?” Efficient stakeholder communication and relationship management is crucial. While there will be some outstanding successes (“blockbusters’) and some total flops, most projects and programs in this “making a movie” category finish somewhere in the middle. There is an art to spending just enough effort to achieve an acceptable outcome—dealing with shades of gray.

Lost in the Fog

I actually prefer Professor Rodney Turner's expression “a walk in the fog,” rather than “lost in the fog.” Managing this type of project involves a journey towards a desired new state. No one is sure of the optimum outcome or how best to achieve it. The only option is to proceed carefully, stop at regular intervals to check exactly where you are, and replan the way forward. This is exactly the way you would navigate through a thick fog. Both ambiguity and uncertainty are high.

Effective management requires making sure that at each “stop point” the value achieved to date is locked in and then refocusing on the next increment. Management is both easy and difficult. It is easy because it is pointless to set fixed plans (you have no idea what to plan), while it is difficult because decisions regarding value and whether to stop or continue are subjective and need to be made in a collaborative environment of trust.

Traditional measures of success such as on-time and on-budget are largely meaningless; typically there are no statistics on which to base this type of measure. Consequently these projects are within the realm of cost-reimbursable contracts and partnerships; stakeholder relationship management and a clear understanding of value are the only effective tools for building to a successful outcome. Agile software development is ideal for this type of project. Each iteration builds new capability and value, and the learning provides a platform for the next iteration of development.

The Dimensional Overview

None of these “dimensional factors” differentiate projects from programs. While most programs are likely to be larger, more complex, and less certain than most projects, the key differentiator between a program and a project is, as described earlier, their objective. Programs are focused on realizing benefits; projects are focused on delivering defined outputs. One of the major roles of a program manager is to initiate projects to create the outputs the program needs to deliver its intended outcomes.

Key Differences Between Projects and Program

Determining if the work to be undertaken is a project or a program is important because it will determine what management approach to use. Attempting to manage a program as a project can lead to failure, or at best, to suboptimal outcomes.

Programs generally have a multiplicity of requirements, deliverables, customers, stakeholders, departments, and interfacing organizations interacting with the work. The following checklist can help determine the difference (Duggal, 2009):

1. Is the associated change wide-ranging and designed to achieve a strategic business objective?
2. Are there multiple deliverables staggered over a period of time?
3. Is the timescale loose and flexible, focused on achievement of benefits rather than on meeting strict deadlines alone?
4. Is the scope fluid and are dynamic changes expected?
5. Is there a good deal of ambiguity and uncertainty?
6. Is it at a departmental or higher level?
7. Are benefits expected to be delivered incrementally during the lifespan of the initiative?

The first question is the key: projects are best if there is one primary goal for the project to focus on delivering; multiple goals are best dealt with by way of a program, with a series of projects each focusing on a particular goal. The remaining questions are secondary, and not all need to be answered with a “yes” to qualify the work as a program rather than as a project.

The Differences Between Managing Projects and Programs

In many respects, the management of projects and programs appears similar. Both are selected via the portfolio management processes on the basis that they support or enable one or more of the organization's key strategic initiatives. Both are initiated, planned, executed, and closed with ongoing monitoring and controlling during their life cycles. In addition, both apply common processes such as time, risk, and communication management.

However, managing projects and programs have distinctly different themes and focuses, which have major consequences on the style of management:

• A successful project is delivered “on time and on budget,” whereas a program should be focused on the overall benefits being created, taking more time, or spending more money to deliver increased benefits to achieve a good outcome. With programs, “value” is the driver rather than budget.
• Project managers focus on producing the optimum deliverable. Program managers focus on integrating the deliverables into the organization's operations to reap the maximum benefit from using the deliverables.
• Stakeholder management is a far more complex and important issue for program managers, as most benefits can be realized only in the future. Project managers should be working within a more constrained framework.
• The risk management framework of a project should be largely definable. The risk management profile of a program is open-ended and heavily influenced by external factors.

The three key management themes that form the framework for PMI's The Standard for Program Management (Project Management Institute [PMI], 2006) are Benefits Management, Program Governance, and Stakeholders Management. Projects, on the other hand, are managed in line with project management good practice as defined in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)—Fourth edition (PMI, 2008a) and focus on minimizing unnecessary change.

A few of the key differences are highlighted below:

Managing uncertainty

• The project view – seek certainty before commencing execution.
• The program view – expect uncertainty, as the world changes and impacts on the organization.

Managing change

• The project view – seek to minimize unnecessary change.
• The program view – embrace change to future works to maximize the benefits delivered to the organization.

Managing risk

• The project view – seek to minimize undefined risks by locking in benefits and mitigating threats.
• The program view – expect undefined risks to occur. Maintain adequate contingencies for future occurrences and seek new opportunities to create value.

Managing stakeholders and communication

• The project view – seek to align stakeholders with the project's objective.
• The program view – engage with stakeholders and use relationships to map future possibilities focused on maximizing long-term value to the organization.

Managing the schedule

• The project view – seek to encompass 100% of the work within the schedule.
• The program view – incorporate the project schedules at a summary level and manage the gaps and interfaces between the projects.

Setting and Managing Senior Management's Expectations

A key challenge facing project and program management professionals is managing the expectation of senior managers. Unrealistic expectations are unlikely to be realized, and creating realistic expectations in senior management thinking requires a sustained process of education and communication.

Realistic expectations of a project should include reasonably high levels of certainty in terms of time, cost, scope, risk, and quality. Importantly, the level of certainty should progressively increase as the project moves through its life cycle. The skill of a project manager lies in identifying ambiguity and uncertainty and then seeking to remove or resolve the causes. The more uncertain the work, the more likely program management approaches will deliver better outcomes for the organization.

Realistic expectations of a program are based on achieving the maximum value from the overall endeavor. The program manager should be expected to balance the relatively short-term stability and certainty needed for the current projects with flexibility and value management to optimize longer-term outcomes. In this sense, value management is not a cost-cutting exercise; rather, it is the balancing of any value proposition through “the eye of the stakeholder”—and this is rarely constrained solely by either time or cost.

Value Management

Effective value management is a key part of effective program management and requires an understanding of what is valuable to the organization. To realize a benefit, the outcomes from the program need to support a strategic objective of the organization. Therefore, the processes to initiate a project within the program should have as a basic consideration its alignment with the organization's strategic objectives.

While the value chain starts with a project being initiated to create a new product, service, or result, the new output by itself cannot deliver a benefit to the organization. The program's management, in collaboration with the organization's management, needs to make effective use of the output to realize a benefit. It is the organization's management that manages the organization, and these people need to change the way that the organization works to use the new capability to realize the intended benefit.

Assuming strategic alignment is achieved, the realized benefits should translate into real value. The challenge is often quantifying value—the concept of “value drivers” helps. Value drivers allow the benefit to be quantified either financially or by other less tangible means.

In the current economic climate, organizations are finding operating capital in short supply. Therefore the value of a new process to accelerate the organization's billing cycle can be measured at several levels:

• The output from the activity to develop the new billing process is simply the new process—this has no value.
• Once the organization's management starts using the new process, the measurable outcome is a reduction in the billing cycle from, say, 45 days to 32 days.
• The benefit of this reduction in the billing cycle could be a reduction in operating capital needs of $500,000.
• The value of this reduction is $500,000 at 12% interest = $60,000 per annum.

The above example may also trigger additional value by allowing the capital to be redeployed into another profitgenerating activity, improving customer relationships, and potentially reducing bad debts.

The challenge of program management is identifying and communicating the value drivers to all levels of the organization's management involved in the activity so that valuable decisions are made in preference to knee-jerk, gut reactions focused on short-term, easy-to-measure metrics. Value is created by meeting the strategic needs of the organization's stakeholders; this requires careful analysis and understanding of who they are and what are their real requirements—i.e., effective stakeholder management.

Program Management and the PgMP Qualification Framework

From the above discussions, it should be apparent that program management is not a natural extension of project management; for most project managers it is a career change. Program managers are part of the organization's senior management team focused on the strategic delivery of value. Project managers manage technicians and subcontractors. Program managers manage project managers and collaborate with other senior managers.

These basic differences are recognized in the PMI certification structure:

• The Project Management Professional (PMP)^® credential is focused on project management knowledge and some general management knowledge. While the credential requires 3 years' experience directing and leading project activities, this is the extent of the threshold to be achieved.
• The Program Management Professional (PgMP)^® credential has a much stronger focus on experience and the ability of the candidate to manage relationships with key stakeholders. A sound knowledge of program management is required, but this is only one third of the overall requirements that are assessed. The candidate needs to demonstrate a strong background in program management and receive a favorable assessment from a range of people in a multirater assessment.

The natural career progression for a project manager is to bigger, more complicated, and more critical projects. Becoming a program manager is a significant career change that needs to be recognized as such and properly managed by the individual making the change and supported by the organization.

Conclusion

Programs are not merely big projects, they are different! The key difference is in the focus of the management effort; project management is focused on creating a deliverable as efficiently as possible, program management is focused on maximizing the benefits realized by the organization.

The key difference between a project and a program of works can be described as follows:

1. Projects involve delivering a product to meet stakeholder needs and expectations with unnecessary change minimized. The key element in project management is efficiency.
2. Programs are about delivering benefits to the organization within defined constraints and in alignment with its strategic objectives. Changing the elements within a program to maximize benefits actually realized and maintaining alignment with changing strategic objectives are essential. The key focus of program management is in the delivery of value, working in concert with the operational and strategic elements of the organization.

The processes, skills, and competencies needed to manage a program to deliver benefits are now well-understood and described in standards published by PMI and OGC, and knowledgeable program managers can seek formal accreditation as PgMP credential holders from PMI or MSP Practitioners from OGC.

What is needed now is for organizational management to recognize the differences and make effective use of both program and project management to create a strategic advantage for their organization. Using project management processes to deliver a program generally will not work despite many of the tools being superficially similar.