Project Management Institute

Boosting program manager effectiveness--nine factors for success


Programs are not projects. That’s a simple fact. However, many organizations around the world continue to manage programs the same way they manage projects only to be ultimately disappointed by the results. The problem is that these organizations simply do not understand the fundamental differences between projects and programs, and, more importantly, they lack the proven practices and support factors needed to bolster program success. Unlike project managers, program managers are, in fact, business managers. To be an effective business manager, one needs a set of skills and competencies that are equal to that of an experienced general manager.

In this paper I will explore the key differences between projects and programs and how those differences manifest themselves in terms of management technique. Moreover, I will present nine critical support factors that are keys to a successful program. Each of the nine factors has been used in organizations such as Motorola, Toyota, and Siemens Medical with positive, demonstrated outcomes. As you read each one, please note how your organization’s practice of program management compares to the practices discussed.

Program Management

A program is defined as a “group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in the program” (Project Management Institute [PMI], 2008, p. 5). Given this definition, we can see that programs can vary from large annual construction programs, to the implementation of an enterprise resource program such as SAP, to building complex defense systems such as a nuclear submarine. The need for competent program managers who are able to handle a vast range of initiatives has never been greater, and all organizations with whom I work are always looking for ways to do things better in this regard. Many are now underway with a wide range of initiatives, including the development of program management methodologies. On a recent trip to London, I conversed with the head of program management for one of the United Kingdom’s largest wireless telecommunications providers. He described how using the U.K’s Office of Government Compliance’s publications publication Managing Successful Programmes, (OGC, 2003) and PMI’s recently revised The Standard for Program Management (PMI, 2008) helped him to develop a practical and pragmatic program management methodology.

Programs differ from projects in a myriad number of ways as illustrated in Exhibit 1. Note that the differences tend to be along a continuum and do not manifest themselves in black and white terms.

Project vs programs

Exhibit 1: Project vs programs

Nine Steps to Successful Program Management

In the United States, the U.S. Department of Defense (DOD) has long-established program management as a key competency; and, it has every reason to do so. For example, between 2005 and 2009, DOD is planning to spend upwards of $1.3 trillion dollars on various programs. In 2005 the General Accountability Office (GAO), a part of the Legislative Branch of the U.S. government and a “watch dog” for Congress, conducted a study to determine the extent to which DOD’s program management performance was sufficiently mature to be able to deliver the intended benefits from such a large allocation of funds (GAO, 2005). In an interesting exercise, GAO compared the program management practices of various large for-profit corporations to those of DOD. Corporations visited included Motorola, Siemens Medical, Wells Fargo, Coors, and Toyota. Interestingly enough, several of these organizations are ESI’s clients. In its report, GAO identified nine environmental factors that it observed in the companies it surveyed that contributed to program management success, suggesting, of course, that DOD adopt these in its practices.

Each of the nine factors for success and a short description of each follows.

Use Investment Strategies

In most organizations, it is generally true that there are more program ideas to fund than funds or resources available. As such, it is important for the organization to develop an investment strategy to pick the “best” programs consistent and aligned to the organization’s strategic plan or direction. The criteria to be used in the selection process are unique to each organization as it relates to its business objectives. The resulting portfolio will inevitably include a mix of the most profitable programs based on customer needs and available technology and resources. The investment strategy is then used as a basis of prioritization and tradeoffs against competing programs. For example, Siemens researched their customers’ technical needs as well as its own technical readiness and produced a one year investment plan, as well as a 3 to 5 year plan.

Use Evolutionary Development

Today’s hot topic is agile development. While this management approach has been applied to software development projects for many years, which is where it got its start in the product development arena (Takeuchi & Nonaka, 1986). Underlying agile development is the notion that an organization should not try to satisfy all needs at once. In fact, an organization should try to get “something out the door” early and often. This approach allows the program manager to focus on design and development. Setting exceedingly high technology enhancement goals as part of the program only spells trouble. For example, Toyota does not use a particular program as a technology laboratory. They constantly upgrade their technology, and then when ready, launch a program for a new car to use the technology developed “in the laboratory.” Too many organizations attempt to develop new technology as part of an overall program. In far too many cases, this simply results in increased costs, protracted schedules, and dissatisfied clients.

Match Requirements to Resources

When bringing a new product or service to market, we need to make sure that the intended customers want it and will pay for it. Building new products and services based on prospective user input is called market-driven research. We also need to determine if what we want to offer the market can be produced within the extant cost, time, and other constraints. In many organizations there is often a requirements gap that needs to be closed before starting the program; otherwise, the program will suffer through requirements scope creep simply because it was not really known at the outset what the end result should be, or what features it should have. The discipline of systems engineering can be very helpful in closing such gaps as it is designed to help the customer translate “wants” into specific project features for which the requisite technology, software, engineering, and production capabilities can be identified.

Match the Right People to the Program

Too many it is obvious that this statement means how many programs have you worked on where you didn’t have the right people “on the bus?” They may have been too junior, lacking in required expertise, had a substandard work ethic, or similar and related issues that prevented the team from executing the portfolio of projects that comprised the overall program. We need the right people with the right level of knowledge, skills, and abilities to accomplish program objectives; and, we need to constantly and continuously develop our team members once they join our program team. In my view, enlightened organizations believe that such development is not a “one-off event.” They constantly have a competency development program underway. By doing so, the “right” people are almost always within the organization to work on programs. One example of an enlightened organization is Cisco Systems, a long-time client of ESI’s. Cisco has thought through the entire universe of project and program delivery and has established training and development programs in project management, program management, portfolio management, and strategy management. It is available to all Cisco employees worldwide. Of particular note, Cisco recognizes, in particular, the need for program managers to have the requisite business skills by incorporating courses such as ESI’s Establishing a Business Mindset and Financial Mastery for Projects in its curriculum. This is consistent with the knowledge and skills identified in the Program Management Professional Examination Specification (PMI, 2007).

Use Knowledge-driven Development Decisions

Successful program managers follow a disciplined, knowledge-based process for accomplishing program objectives. The process is characterized by gates and milestone decision points that require everyone to agree whether or not the program is ready to move to the next phase. However, the organizations mentioned in this paper are also flexible as it relates to the processes they use; for example, if a milestone is not needed it is dropped. Motorola has a 16-gate process with the first five aimed at ensuring that the product concept and business case is sound. Toyota has eight with the first being lessons learned and making sure that the lessons of past programs are applied to the current one. At Toyota, the chief engineer derives the business case, but it is the chief production engineer who executes it, thus instituting a check and balance in the system. Inherent in the Toyota approach is the concept of shared accountability, a hallmark of which is that everyone must agree that the program is ready to move forward. Furthermore, if there are problems, all are held accountable, not only the program manager.

Empower Program Managers

We are probably all a little weary of the word “empower.” It’s one of these business buzzwords that have been overused, misused, and abused through the years. Nonetheless, the concept is sound. If we place someone in a role and do not give them the requisite authority, we have doomed them to doing a less than adequate job at best and irrelevance at worst. If we feel the need to micromanage them, either we have the wrong person in the role, or we have a control problem ourselves. A solid training and development program should produce program managers, who can make the necessary trade-off decisions among schedule, cost, and performance consistent with our business case; who have the refined interpersonal skills to lead a group of people towards a common objective; and in whom we can place trust. As we think about who should lead our programs, we should be selecting those professionals with a stellar track record in our organization, a proven entity if you will. We should be selecting senior professionals, ones who have a sterling reputation and who are highly respected within the group. Moreover, we should establish a governance model that includes a steering committee or senior program sponsor who can oversee and assist the program manager when necessary to navigate the political mine fields found in most organizations.

Demand Accountability

Once we select the right person for the role, he or she must be held accountable for program outcomes. As stated previously, accountability is shared in Toyota; in many organizations it falls squarely on the shoulders of the program manager. Regardless of the way it is accomplished, there should be no confusion as to the decision-making authority of the program manager. For example, he or she should make the difficult decisions related to cost, schedule, performance, and other goals and metrics. The value of clear accountability is that it generally accelerates decision making. I have personally observed and experienced that, where confusion exists as to who is responsible for making what decision, decision making is cumbersome, slow, and subject to reversal or modification. It’s the old “two steps forward and one step back” syndrome. Organizations today, many of whom are fighting for their lives, do not have the luxury of revisiting every decision made on a program.

Require Tenure

A best practice in program management as observed in the companies mentioned in this paper is to have the program manager assigned early in the life cycle, and to make sure the program manager stays until the program is completed. This is difficult in certain organizations, such as the military where program managers are often reassigned every two years; however, the organizations with the greatest success not only select the right people at the outset and keep them engaged through the end of the program but also incent them financially to do so. They provide substantial bonuses, salary increases, or awards (or a combination of all three) to keep them motivated to deliver the program benefits to the organization. Does your organization do this? When was the last time you received a bonus for going “above and beyond” or for simply staying put and getting the job done? Additionally, many of the companies that GAO surveyed did not immediately withdraw or replace the program manager when things were not going well. Rather, they carefully assessed the situation to determine and identify what specific help the program manager needed to improve performance. For example, perhaps performance issues are related to a lack of resources, or the right mix of resources. Clearly, help in this regard can aid in returning the program to its planned schedule. That said, they will replace a program manager if, upon investigation of the issues, it is abundantly clear that the program manager is simply not up to the task.

Continued Senior Leadership Support

When I speak of senior leadership support, I am not talking about oversight and second guessing. I am talking about demonstrating that senior leadership trusts the program manager. Let’s look at how trust manifests itself in the workplace. First, let me ask “what’s worse than getting bad news?” Of course, it is getting bad news late. But, how many program managers feel comfortable in bringing bad news forward? That’s a function of how such news is received. If you want the truth from your program managers, you cannot brow beat them when they bring news that you would rather not hear. In this business everyone has to pull together in the same direction. We need to collaborate and communicate, and that means senior executives as well. It’s not enough to be a cheerleader for the program manager; active involvement at the right level is required. This means that senior executives need to participate in the program management process; they need to sit in hot, stuffy conference rooms for hours on end to assess program status to ensure its ready to move forward to the next milestone. It means setting time aside to talk to the program manager on a regular basis and to provide “air cover” when necessary. And, it means anticipating and removing obstacles to success, whatever they may be. Your program manager is depending on it.


There is not one company or organization that has a perfect track record in program management; not even those mentioned in this paper that were surveyed by GAO. It’s too difficult a business, and, quite frankly, perfection is not required to deliver intended benefits and ensure lasting results. The nine environmental factors discussed here, when practiced within the culture of your organization, will provide the necessary support for the right program manager to get the job done. But who is the “right” program manager? This question will be addressed in future papers and presentations.

Office of Government Commerce. (2003). Managing successful programmes. London: Office of Government Commerce.

Project Management Institute. (2008). The standard for program management (2nd ed.). Newtown Square, PA: Project Management Institute.

Project Management Institute. (2007). Program management professional examination specification. Newtown Square, PA: Project Management Institute.

Takeuchi, H., & Nonaka, I. (1986). The new product development game. Harvard Business Review, Jan-Feb.

United States Government Accountability Office. (2005). Better support of weapon systems program managers needed to improve outcomes. Washington, DC: United States Government Accountability Office.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2009, J. LeRoy Ward
Originally published as a part of the 2009 PMI Global Congress Proceedings – Amsterdam, Netherlands



Related Content