How to Manage Complex Programs: High-Impact Techniques for Handling Project Workflow, Deliverables, and Teams

ISBN-13: 9781400245628

Media Type: Paperback

Publisher: AMACOM

Publication Date: 05-02-2023

Pages: 336

Product Dimensions: 6.00(w) x 9.00(h) x (d)

Tom Kendrick the former Program Director for the project management curriculum at UC Berkeley Extension, and lives in the Bay area near San Francisco, California. He is a past award recipient of the Project Management Institute (PMI) David I. Cleland Project Management Literature Award in October 2010 for "Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project" (now in its fourth edition). Tom is also a certified PMP and serves as a volunteer for both the PMI Silicon Valley Chapter and PMI.org.

Read an Excerpt

How to Manage Complex Programs

High-Impact Techniques for Handling Project Workflow, Deliverables, and Teams

AMACOM

Program Management

Make everything as simple as possible, but not simpler. — Albert Einstein

The size and scale of programs makes them complex and difficult to manage. As with any undertaking, the prospects for success diminish and uncertainty increases significantly with the magnitude of the work. Where small projects are almost always successful and carry low risk, long-duration programs with large staffs of contributors have a high probability of falling short of their goals, and many fail.

Program management techniques strive to simplify the work by breaking it down into more manageable pieces. By converting large undertakings into collections of smaller projects, we move the work into a context where things are more easily understood and project management methods can be effective. That's the good news.

Unfortunately, decomposing a major effort into a coherent set of projects that can be independently planned and managed is easier said than done. The act of converting a large program into a collection of smaller projects does not make the complexity go away. Overall program complexity affects the deliverables, the workflow, and organizing the people who will do the work. Creating a program plan that will serve as an effective foundation for execution can succeed only if it is done carefully and with an understanding that what remains, even using the best program management methods, will still be challenging. Simplicity is a worthy goal, but there are limits.

This chapter explores the organizational context for programs, describes a range of program types and sizes, discusses program origins and challenges, and explores the dimensions of complexity that programs must face.

PROJECTS, PROGRAMS, AND PORTFOLIOS

Projects are undertakings that are of finite duration and seek to deliver a specific result using limited assigned resources. Typical organizations have many projects underway in parallel, with a wide variety of goals. Some of these projects are autonomous, with little connection to other work, while others are chartered as a part of something larger, encompassing several or even many projects.

Program is a term that means different things in different contexts, but the Project Management Institute (PMI) defines a program as "a group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually." Subprograms may be part of larger programs, also containing multiple projects. Programs require a leader and generally a program staff, sometimes referred to as a program (or project) management office (PMO). Program activities often involve effort in the "white space" outside specific defined projects and subprograms, effort provided by support, marketing, legal, manufacturing, or other operational functions. Programs are generally larger than projects, but there may be some overlap in scale between large projects and small programs.

At any given time an organization may have multiple programs executing alongside independent projects. All of these undertakings taken together represent a portfolio of endeavors comprising projects, subprograms, programs, and other work. Graphically, such a portfolio might look something like Figure 1-1.

The relationship between portfolio management and project and program management is explored in some detail in Chapter 2.

PROGRAM DEFINITION

Programs are made up of related efforts, most of which will be projects staffed by a project leader and a team of contributors. Some clusters of projects may be complex enough to justify treatment as a program within a program, and the presence of these subprograms will result in a multiple-level program hierarchy.

The 20th-century NASA space program provides a good example of a multiple-level program hierarchy. Once President John F. Kennedy set the goal in 1961 of "landing a man on the moon and returning him safely to Earth," a massive manned space program took shape. Within the overall space program, three subprograms were outlined: the Mercury program with its one-astronaut missions, the subsequent Gemini program containing more complex two-astronaut launches, and finally the Apollo program supporting the three-astronaut flights capable of reaching and exploring the moon. Within these major subprograms, each was further subdivided into missions with specific goals to be achieved in order to support the objectives of later phases of the program. Further subprograms within each mission provided the systems, support, functions, and other needs for each launch. These were further broken down into increasingly detailed and specific efforts, ultimately delegated to project teams. Thousands of contributors worked on the projects that made the program successful. Without a clear division of the program into phases, missions, functions, and detailed projects (not to mention an enormous amount of talent and money), none of what was accomplished would have been even remotely possible.

Program management, as defined in the third edition of the Project Management Institute's Standard for Program Management, is made up of several domains:

• Program strategy alignment

• Program stakeholder engagement

• Program benefits management

• Program governance

• Program life-cycle management

Supporting these domains are the processes of program management. One way to look at these broad aspects of program management is shown in Figure 1-2. Program processes serve to support all five domains, and are a major focus throughout this book. The five domains are major topics in specific chapters of this book, with strategy alignment a major part of Chapter 2, and program governance addressed in both Chapters 2 and 5. Stakeholder engagement is central to Chapters 3, 5, and 6, and program benefits and results are a focus in Chapters 3 and 6. Details of the program life cycle are based on both the specifics of the work to be done and the outputs from the other program management domains. Adopting and using an appropriate program life cycle is explored later in this chapter as well as in Chapter 4.

Ultimately programs are about getting results, generally results with substantial expected benefits and value. Program management requires a deep understanding of the synergies and strategies that underlie the objectives. Programs often carry long-term objectives that require a persistent, high-level focus on the main strategic priorities. These must be balanced with shorter-term tactical goals, but not so much that the things that are truly important can be undermined by what seems urgent at the moment. Program leaders must understand the overall organizational strategies and strive to remain aligned with them. The conflicting needs of dealing with detail-level complexity and high-level longer-term objectives are what make program management challenging.

HOW DO PROGRAMS ORIGINATE?

Successful programs generally require a lot of staff, money, time, and resources, so they tend to arise from the higher levels of an organization where there is sufficient authority to get them going. Some programs are aimed at solving significant problems, such as the following:

• Major customer or user difficulties

• Mandated legal, regulatory, or compliance changes

• Gaps and deficiencies in current offerings

• Significant competitive or external shifts

• Inefficient or expensive procedures

• Evolving organization needs

• Emerging risks

In addition to resolving shortfalls in the organization, programs also address strategic opportunities, including objectives such as these:

• Development of new products, platforms, solutions, or services

• Acquisitions of other companies or organizations

• Strategic partnerships, alliances, or collaborations

• New markets, users, or growth

• Long-term strategic plans

• Reorganization

• Executive fiat or initiatives

However programs arise, there is nearly always a lot of energy and enthusiasm, at least initially, because the program objectives tend to be important and come from people who have significant clout.

WHY ARE PROGRAMS DIFFICULT?

Programs are difficult to manage for quite a few reasons, most of them related to the scale and complexity of what is expected. Their size means that in most cases there are many diverse stakeholders. The deliverables (and there are almost always at least several) are generally complicated systems of interrelated components. Programs are also usually lengthy, far longer in duration than can be planned with much precision. The staffing for a large program involves more people than can be effectively coordinated as a single team, and the funding required is often both substantial and must cover future periods well beyond what is presently committed. The techniques of program management can help in each of these areas, but control of the work is never straightforward.

Stakeholders: The community of people involved with a large program can be both unruly and crowded. It is exceedingly unlikely that all those who can affect a program or will be affected by it will be in complete agreement on program objectives. Perspectives will differ and conflicts are common. Even when there is initial harmony, differences can arise in future program phases. Keeping a fix on expectations, desires, needs, and priorities, even among the most significant stakeholders, can be a full-time effort. Some ideas for establishing effective governance and managing stakeholder conflicts are explored in Chapters 2 and 3.

Deliverables: Program deliverables often involve complex hierarchies of interrelated systems and integrated components. To further complicate matters, definition of what is needed often lacks clarity, especially at the beginning. On lengthy programs, changes are inevitable. Controlling program scope effectively is never easy but can be made more tractable using systems analysis, iterative techniques, effective change control processes, and other tactics discussed in Chapter 3.

Planning: Programs often have long durations, and some (such as those aimed at long-term process improvement) may be initiated without a defined termination date. All project and program planning has a finite planning horizon, beyond which precise forecasts and estimates are not possible. The limits vary for different kinds of work, but very rarely will you be able to accurately plan for more than about 6 months of work (and for programs involving complex technology it will be considerably shorter). Program planning also must anticipate and manage workflow dependencies between the projects making up the program and external inputs and linkages. Developing credible, workable plans for program work and conducting periodic in-depth plan reviews are the focus of Chapters 4 and 6.

Leadership and staffing: The scale of programs involves many leadership, staffing, and financial challenges. The number of people involved is often very large, and coordinating their efforts is made even more difficult because of matrixed reporting relationships (where the connection to the program is "dotted line" for a significant number of program contributors). The effective authority and power of the program leader and staff is often weak, especially when dealing with distant, contract, or part-time program contributors. Programs with large staffs also must manage across a hierarchical organization chart having multiple levels, further diminishing relationships and teamwork. Across the program, projects and teams will rarely share common perspectives and backgrounds, so conflicts may be common and motivation may be low. Access to resources and budgets pose problems for many programs, particularly for major undertakings that will require renewal of funding each year to continue the work. Tactics that can help in these areas are explored in Chapter 5.

PROJECT/PROGRAM SIZE BOUNDARIES

As mentioned earlier, there may be some overlap in scale between a large project and a small program. In general, the size at which projects of a given type start to fail more often than not provides a reasonable limit for the utility of project management processes, and represents a good starting point for adopting program management techniques. Exactly where this threshold falls varies by program type, with predictable, routine projects having higher limits and "bleeding edge," novel, more uncertain projects having lower boundaries. That said, there are some general guidelines that broadly apply when determining when project management principles can be expected to falter.

Project leaders generally find that about 10 percent of their time is spent on activities associated with each contributor on a project team. This effort primarily involves communication (verbal and written, face to face, and electronic) and meetings, but also factors in general oversight, portions of work devoted to the team as a whole, and occasional interactions that are not strictly project oriented. Based on this, a project team should have roughly a dozen or so members. Teams of twenty or more people tend to interact too little, which interferes with teamwork and project progress.

Another perspective comes from the rough guidelines generally recommended for project planning. If a project plan has 100 to 200 lowest-level activities, it becomes difficult to understand and manage. At these levels, the utility of project scheduling tools decreases, and the logical workflow and interactions between parallel efforts become more difficult to see and control. Typical activity estimate guidelines fall into the range of 80 hours of effort or 2 to 20 workdays in duration (with an average of about 2 weeks). Both of these guidelines for work breakdown provide tasks that are small enough for fairly accurate estimating. This granularity also ensures a planned frequency for activity completion that will enable project leaders to detect problems quickly and respond to slippage while recovery remains straightforward.

If a hundred or so of these activities are scattered among about a dozen contributors, the project leader will have a manageable ten to twenty tasks ongoing at any one time, with five to ten completing in a typical weekly status interval. The overall project duration suggested by all of this (assuming all contributors are devoted to the work full-time) is about a half year, or perhaps a bit longer. This corresponds to the general guidelines for a maximum planning horizon, and tends to be about as far out as a project team will be able to schedule and to plan for risks.

An analysis from the cost perspective converges on similar numbers, with a project budget guideline of roughly $1 million (covering about 100 effort-months or so) being a typical maximum for normal projects. Once again, a project falls into the range of about a dozen people, with an approximate duration of a half year.

Simple projects can exceed these limits (although if they are truly simple, they rarely need to) and still be adequately controlled. For complicated projects, work that is not well defined, or environments anticipating a lot of change, much shorter, smaller, or less aggressive limits are more appropriate. Many such projects adopt agile methods, where iterations deliver results approximately monthly. They use feedback to adjust for future cycles and manage the unknowns, evolving requirements, and novelty.

Project management methods do work well, but only up to a point. Exactly where the threshold lies varies somewhat with the type of work, but the following are useful general limits for project parameters:

• Approximately ten to twelve full-time contributors

• Roughly 6 to 8 months of overall project duration

• About 100 to 200 lowest-level activities in the project work breakdown structure

• Around 100 effort-months of estimated work

• A budget nearing $1 million

Going beyond these limits creates project management challenges and difficulties. Program management techniques extend the usefulness of project management processes by breaking down larger undertakings into smaller projects. This can be effective, but only if the breakdown is done logically and the program leader applies program management techniques to understand and coordinate the resulting aggregation of projects.

---

Excerpted from How to Manage Complex Programs by TOM KENDRICK. Copyright © 2016 Tom Kendrick. Excerpted by permission of AMACOM.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

<