Programs are not projects
boosting program management effectiveness
Programs are not projects. That's a simple fact. However, many organizations around the world continue to manage programs the same way that they manage projects only to be ultimately disappointed by the results. The problem is that these organizations simply don't 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 is 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 program success. Each of the nine has been used in such organizations as Motorola, Toyota, and Siemens Medical, to name a few, with positive, demonstrated outcomes. As you read this paper, please consider how your organization's practice of program management compares to the practices discussed.
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” (PMI, 2009). 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 such a vast range of initiatives has never been greater, and all of the organizations with which 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. In fact, in a recent trip to London, I was conversing with the head of program management for one of the United Kingdom's largest wireless telecommunications providers, and he was describing how, using the United Kingdom's Office of Government Compliance's publication entitled Managing Successful Programmes, (OGC, 2003) and the Project Management Institute's recently revised The Standard for Program Management (Project Management Institute [PMI], 2008), he was developing a practical and pragmatic program management methodology.
Programs differ from projects in myriad ways, as illustrated below in Exhibit 1. Note that the differences tend to be along a continuum and do not manifest themselves in black and white terms.
Exhibit 1: Projects versus 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 US$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.
Following, I will identify each of the nine factors for success and provide a short description of each.
1. 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 with 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 trade-offs against competing programs. For example, Siemens researched their customers' technical needs as well as its own technical readiness and produced a 1-year investment plan, as well as a 3- to 5-year plan.
2. Use Evolutionary Development
Today's hot topic is agile development. While this management approach has been applied to software development projects for many years, in fact, it got its start in the product development arena (Takeuchi & Nonaka, 1986). Underlying agile 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.
3. 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 the program is started; otherwise, the program will suffer through requirements scope creep simply because it was not actually 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.
4. Match the Right People to the Program
Although it is obvious what 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. 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 by the Project Management Institute (PMI, 2007).
5. 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 with regard 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 gates in place to ensure that the product concept and business case is sound. Toyota has eight, with the first being lessons learned, thereby making certain 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 and that if there are problems, all are held accountable, not solely the program manager.
6. Empower Program Managers
We're 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've doomed them to doing a less than adequate job at best, and to 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.
7. Demand Accountability
Once we select the right person for the role, he or she must be held accountable for program outcomes. As stated above, accountability is shared in Toyota; in many organizations, it falls squarely on the shoulders of the program manager. In whatever 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 which are fighting for their lives, do not have the luxury of revisiting every decision made on a program.
8. 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 2 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, they incentivize 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, 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 browbeat 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 that it's 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 one of 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 success 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. (The question of who is the “right” program manager is one that will be addressed in future papers and presentations.)
Office of Government Commerce. (2003). Managing successful programmes. London: Office of Government Commerce.
Project Management Institute. (2006). Program management professional examination specification. Newtown Square, PA: Project Management Institute.
Project Management Institute. (2008). The standard for program management—Second edition. Newtown Square, PA: Project Management Institute..
Takeuchi, H., & Nonaka, I. (1986, January-February). The new new product development game. Harvard Business Review, 137–146.
United States Government Accountability Office. (2005). Better support of weapon systems program managers needed to improve outcomes. Washington, DC: United States Government Accountability Office.
©2009, J. LeRoy Ward
Ppublished as a part of the 2009 PMI Global Congress Proceedings – Orlando, Florida