Why program management is essential for IT projects
Program management offers a unique benefit for information technology and other programs where the interdependencies among projects have significant technical, as well as management dimensions. Most discussions of program management to date have focussed exclusively on the management dimensions (cost, schedule, risk, and quality). For technology-intensive programs, however, the technical dimensions are also critical and often have management consequences as well. Using the example of the North Atlantic Treaty Organization's (NATO) information technology program office, this paper will show how program management can enable effective integration through management of architecture, interfaces, requirements, testing, and other aspects of project planning and execution. This paper offers a model for Program Management Offices (PMOs) that need to address both management and technical program support needs.
Depending on which survey from the last twenty years you refer to, the exact percentage of unsuccessful information technology (IT) projects varies, but one message remains constant: IT projects have a high rate of failure. To cite just one example (Standish Group, 2013), less than 40% of IT projects surveyed were considered successful—the rest were “challenged” or outright failures.
A consistent characteristic of failed IT projects is their inability to deliver the expected value to the sponsoring business or organization. Whether due to cost overruns, schedule delays, ineffective project management, poor stakeholder engagement, or the loss of alignment with strategic concerns, IT projects have an unfortunate tendency to deliver outputs that don't meet organizational expectations.
Root of problem is the tension between conventional project management principles and the nature of IT projects. According to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, (PMI, 2013)--the leading illustration of conventional project management, the meaning of the conventions of project management (the ways in which project management is usually practiced), clearly states the need to keep projects aligned with changing organizational objectives. But many of the practices of project management—particularly after the project plan has been baselined—act as barriers against externally-driven changes and controls. There are many good reasons to maintain a strong focus on a project's own outputs and objectives and avoid dependencies on external activities, but the paradox of IT projects is that these dependencies are, very often, essential to achieving its ultimate benefits to the organization.
Program management offers an effective approach to manage this tension, leveraging the advantages of a project management approach while maintaining alignment with organizational interests. The construct of a program aims to coordinate a group of related projects to obtain benefits and control not available from managing them individually. In the case of IT projects, these relationships include numerous aspects, such as IT infrastructure standards and organizational practices, that are relevant to multiple projects and that operate on longer timescales and at larger “scope-scales” than those of the projects. The significant advantages, in terms of both improved IT project performance and better achievement of expected organizational benefits, make program management essential to IT project success.
In 2007, NATO launched an initiative specifically designed to address the problems of delivering multiple, related IT projects. Known as the Program Management and Integration Capability (PMIC), it built upon best practices of project and program management, but also incorporated numerous technical aspects, such as architecture, interface control, and test management, to improve the quality and effectiveness of its projects’ deliverables. PMIC represents a model of IT program management that can be adopted by other organizations to better coordinate the planning and execution of IT projects with their changing strategic and operational objectives.
The Challenges of IT Projects
The dismal performance of IT projects reflects challenges that have plagued IT itself for decades. Forty years ago, in a book tellingly titled Why Information Systems Fail, Lucas (1975) observed that, “Because of our concern over technology we seem to have ignored the fact that almost all information systems exist within the context of an organization.” Concerns over the alignment between IT and organizational objectives have led to the development of such practice frameworks as the Control Objectives for Information and Related Technology (COBIT) from Information Systems Audit and Control Association (ISACA).
In a 2008 survey (ISACA, 2008), ISACA found that the five leading reasons that organizations cancelled IT projects were:
- The organizational needs changed.
- The project did not deliver as expected.
- The project was no longer an organizational priority.
- The project exceeded its budget.
- The project did not support the organizational strategy.
All five of these reasons relate to disconnects between what was happening at project level and what was going on at a larger organizational level. Whether projects were well or poorly managed is irrelevant, in retrospect. What matters, for the purpose of this discussion, is that one or more aspect(s) of each project diverged sufficiently from the needs of its sponsoring organization to invalidate the business case behind the project's initiation.
This fate could befall any project, regardless of its nature. Projects are often what Managing Successful Programmes (OGC, 2011) calls “mechanisms for delivering change.” They act as the linchpin between the organization's strategy—where it wants to go—and its on-going activities—what the PMBOK® Guide (PMI, 2013) refers to as operations. With a railroad engine and the train of cars it pulls, the difference in forces between the pull of engine and the inertia of the cars places significant stress on each linchpin. In the same way, the fixed resources and constrained scope of a conventional project can be severely strained in trying to apply the force of strategically-driven change to the inertia of existing organizations, people, and practices.
In the case of IT projects, there are additional forces at play that significantly increase the stress on each project and, hence, its risk of failure. The essence of an IT project is to deliver organizational change through a combination of technical (hardware, software, and networks) and non-technical (procedures, training, and support) elements. No matter how well or poorly the organization manages those factors within its control, the fact is that IT is subject to continual evolution and change due to market and technological forces beyond its control. Factors such as the introduction of a new operating system, the phase-out of a hardware line, or the failure of a key vendor have torpedoed more than a few projects as they were steaming along an otherwise well-charted course.
And the number and scale of these forces have increased over the decades that organizations have been implementing IT projects. In the 1960s and 1970s, few information systems were networked. Usually the only applicable technical standards were the operating system or programming language of the mainframe computer(s) involved. In the 1980s, networking standards were mostly proprietary to a company or community and interfaces and interdependencies were few. In the 1990s, the rise of Internet and web standards led to an explosion in the number of interconnections and information exchanges between systems, and the last decade has seen this number continue to increase rapidly with the use of mobile devices.
At the same time, the nature of how organizations use IT has grown in its range, depth, and complexity. IT is pervasive in most organizations. Processes and functions that were linked through paper in the 1980s and 1990s—for example, travel, finance, and HR—now rely on interlinked applications, common data elements, workflows, and other aspects that act as constraints on both IT and the organization it supports. Major IT projects, such as the introduction of an Enterprise Resource Planning (ERP) system, now routinely find themselves working with dozens of different organizational functions and locations and an equal or larger number of interfaces and information exchange requirements.
Some organizations have adopted the discipline of enterprise architecture (EA) to deal with these challenges, but, as was observed in a recent article in Forbes magazine (Bloomberg, 2014), “the practice of EA has become all about documentation rather than effecting business change.” This same tendency can be observed in what one might call “conventional” project management.
Why Conventional Project Management Doesn't Work for IT Projects
A quick look into the PMBOK® Guide – Fifth edition (PMI, 2013) shows that, on the surface, conventional project management takes an open, or at least a neutral, view of externally-driven change. “Project management activities should be aligned with top-level business direction, and if there is a change, then project objectives need to be realigned,” it states in the introduction.
In reality, though, there is much in the conventional project management approach that acts as a barrier to ward off external control and externally-driven change. A baselined project plan, with its target milestones and (usually) fixed budget, becomes seen as the asset to be protected—rather than what it is fundamentally: a forecasted set of activities rooted in certain assumptions about what is likely to happen during its execution. Hodgson (2004) observed this effect in a study of the introduction of project management practices in a large IT company: “The main experience of project management as reported by many…employees was one of intensified bureaucratic surveillance.”
One can see this reflected in statements about planning in the PMBOK® Guide – Fifth Edition (PMI, 2013). While it acknowledges that “the project management plan is iterative,” it characterized the iterations as “progressive elaboration”—meaning “detailing a plan as more detailed and specific information and more accurate estimates become available.” But that assumes that more accurate estimates do become available, and often the reason a new iteration of a project plan has to be developed is because something occurs that wasn't anticipated in the baseline plan.
It's also evident in statements about change management. Although the PMBOK® Guide – Fifth Edition (PMI, 2013) places Integrated Change Control at the core of a project's control processes, the language it uses to address project change requests is overwhelmingly negative. As examples of project change requests, it offers “corrective action,” “preventive action” (“an intentional activity undertaken to avoid an event”), “defect repair,” and “updates” (which it qualifies as “changes to formally controlled documentation”).
But the fact is that change is actually more likely to come from some factor outside the project. There is, after all, more of the world outside the project's scope than within it. And the longer a project lasts, the more likely it is that such a need will arise. This is certainly the case for IT projects if they last more than a few months, because it is virtually unknown for there not to be externally-driven changes in the form of changes in the configuration of one or more elements of the IT infrastructure into which its products will be implemented.
Most project managers would say that one of the best ways to minimize the risk of changes to a project plan is to minimize its external dependencies. Yet, for the reasons described above, IT projects tend to be rich in external dependencies. Minimizing these dependencies might keep a project on schedule but ensure that its products are incompatible with IT infrastructure or organizational processes or both. On the other hand, the converse approach—maximizing external dependencies—seems a guaranteed way to ensure a project burns through its resources without delivering anything.
How Program Management Can Help: The Theory
Ironically, the PMBOK® Guide – Fifth Edition (PMI, 2013) provides the answer: program management. “Program management,” it states, “focuses on project interdependencies and helps to determine the optimal approach for managing and realizing the desired benefits.” Programs are groups of related projects (and sometimes, other activities) organized and managed in a coordinated way, usually to ensure alignment with strategic objectives. Program management, according to The Standard for Program Management – Third Edition (PMI, 2013), aims “to obtain benefits and control not available by managing projects individually.”
As described in Managing Successful Programmes (OGC, 2011), program management aligns three critical organizational elements: strategy; projects; and the business-as-usual environment. This description provides a clue to where program management can be most useful in improving the success of IT projects. When a single project acts as the linchpin between strategy and business-as-usual, it can be subject to tremendous external forces—forces it is often too weak and small to manage itself.
When a project is carried out as an element of a program, however, the program can act as a buffer, both spreading the energy of these forces across multiple activities and projects and controlling the flow of change from external sources to the project. The authority of the program manager and his weight in the organization is likely to be greater than that of any of the individual project managers, and hence, can put him in a better position to work with stakeholders on strategic issues.
Properly arranged, the capabilities of program management and project management can be not just complementary but reinforcing. Program management can focus on outcomes and other strategic concerns while providing projects with the freedom to focus on delivery of outputs. As outlined in The Standard for Program Management – Third Edition (PMI, 2013), program management deals with domains that go well beyond the scope of individual projects: Strategy Alignment, Benefits Management, Stakeholder Engagement, Governance, and Life Cycle Management.
Each of these domains acts as a mechanism to coordinate and manage the interactions between strategy, business-as-usual, and projects. Strategy Alignment, for example, can assess changes in organizational strategy and identify how they may affect individual projects. Stakeholder Engagement can establish and maintain a variety of communication tools to take status information from projects and report this in a coherent and aggregated way to sponsors and users. And Benefits Management can ensure that projects don't become too fixated on protecting the project plan over the interests of the organization.
How Program Management Can Help: The Practice
A tangible example of the advantages of a program management approach to IT projects can been found in NATO's experience with IT program management. In a report presented to the NATO Investment Committee in 2005 (NATO, 2005), the NATO Office of Resources noted that IT projects intended to support NATO military commands over the previous decade had consistently been subject to cost overruns and schedule delays averaging well over one year, and that there had been little achievement of the strategic objectives of an integrated and coherent set of operational capabilities. The report also advised that the most important characteristic of these projects was that NATO's IT environment “…is and will continue to be in a state of constant evolution,” and that “the evolution of the underlying technology” was the predominant influence upon these changes.
The PMIC Framework
In response, NATO initiated a project to implement a program management framework to coordinate and manage a portfolio of over 60 separate IT projects with a total value exceeding €400 million. Known as the Program Management and Integration Capability (PMIC), this framework drew heavily upon a number of best practice sources: the PMBOK® Guide – Fifth Edition (PMI, 2013), The Standard for Program Management (PMI, 2008), Managing Successful Projects with PRINCE2 (OGC, 2007), Managing Successful Programmes (OGC, 2011), and the International Council on Systems Engineering (INCOSE) Systems Engineering Handbook, v. 3 (INCOSE, 2006).
Given the technical challenges inherent in implementing IT projects, the PMIC framework was designed from the very beginning to incorporate both management and technical functions. The rationale was that technical issues in IT projects very often have direct consequences for such management considerations as cost, schedule, and risk. A focus exclusively on management aspects neglects the importance of maintain consistency in project deliverables through coordinated technical controls.
After assimilating the most useful elements of best practice and incorporating considerations unique to NATO's organizational practices and policies, the PMIC framework was established around the following set of functions:
- Program Governance
- Change Management
- Communications Management
- Risk Management
- Schedule Management
- Cost Management
- Configuration Management
- Quality Management
- Security Management
- Systems Integration
- Requirements Management
- Architecture Management
- Test Management
- Verification and Validation
- Transition Management
For each function, a set of program-project interactions were defined according to project lifecycle stages: initiation, planning, procurement, implementation, and closure. The program office, for example, takes a strong role in project initiation, providing the project team with a brief, outlining not just the scope and expectations for the project, but also the key interdependencies with other projects and the controls required to ensure effective oversight.
To implement this framework, NATO established a core program office team of four NATO staff supported by a team of approximately 16 contractors. Given limitations of manpower and the number of projects involved, the PMIC team had to select the most essential of the above functions to achieve an effective initial level of capability.
Change Management: The Key Enabler
Change management was seen as the most critical function of all. This was based on lessons identified in numerous projects, where the inability to perform effective change management was found to be the most persistent weakness in NATO IT project execution. The root of the problem can easily be seen from Exhibit 1.
Exhibit 1: Inter-project change management.
As the number of projects increases, so do the possibilities of inter-project changes. And when changes tied to changes in strategy or changes in business-as-usual are added to the picture, the complexity of the situation quickly becomes unmanageable.
For this reason, PMIC quickly implemented a program-level change management function. Its task was to provide an easy (and safe) process by which project managers could elevate issues for program-level assessment, while at the same time maintaining a constant scan of possible sources of externally-driven change. The basic interactions are illustrated in Exhibit 2.
Exhibit 2: PMIC program-level change management function.
Each week, the PMIC team met to review and action the new entries on the program's issue log, as well as to monitor progress on actions agreed in previous weeks. This review soon evolved from a reactive to a pro-active stance, reflected in a change in terminology. Instead of “issues,” the team began to track “blips”—a term coming from air defense radars—which could be anything from a decision by a NATO resource committee or a formal requirements letter from a NATO command to a hallway conversation between a project manager and a member of the team.
To support this weekly review, the team had to put a number of valuable program tools in place. One was a set of common external information feeds and a central repository of documentation. Another was a practice of maintaining regular communications between each of the support project managers—regardless of whether there were issues or “blips” of program concern. Another was a program data model that made it easy to organize the rapidly-growing archive of data and documentation on projects in a manner that enabled visualization and analysis from multiple perspectives.
Support to Projects
Of course, the obvious danger in introducing a program management framework into an existing project management environment is that the result will be twice the overhead and half the output. As with any other project, implementation of PMIC ran a significant risk of encountering resistance from project managers perceiving a loss of control and a burden of additional oversight and reporting. Recognizing this, the PMIC team considered it essential to make gaining acceptance by project managers a high priority in the early stages.
One of the easiest ways this was done was through the program's Systems Engineering function. The IT projects supported by PMIC often involve the development and testing of a dozen or more interfaces with other information systems. As illustrated in Exhibit 3, each of these interfaces is, in project management terms, an external dependency that has to be monitored and managed by the project team.
Exhibit 3: IT project interfaces.
In a manner similar to establishing the change management function, the PMIC team surveyed all the known project interfaces, identified those associated with any type of interface specification or standard, and established a repository of this information. They then took on the responsibility for managing the coordination of interface specifications—and changes to them—on behalf of the supported projects. What the program did, in effect, as illustrated in Exhibit 4, was to abstract a whole set of project interfaces into a single one, managed by the program.
Exhibit 4: Program-project interface management.
The PMIC Systems Engineering function was complemented by the program's Test Management function, which established a centrally-managed test bed, accessible from any project facility over the Internet, in which all the systems associated with these interfaces were made available, with test data, to enable projects to develop and test new applications.
A final means by which the program was able to quickly establish an effective working relationship with projects was through its Verification and Validation (V&V) function. Prior to PMIC, individual project teams had the responsibility for establishing effective quality controls, particularly in the critical product testing and acceptance phases. Given that these activities tend to occur late in a project's lifecycle, when resources are scarce and schedule slack limited, it was not unusual to find that key tests were omitted or performed in a cursory manner.
The PMIC team created a pool of V&V experts, supplemented by other members of the team, which could be allocated and managed by the program manager against the demands of projects. Because V&V as a function tends to be performed in short periods of intensive activity, this approach maximized the productivity of the V&V staff and enabled a small team to support a larger number of projects. Project managers were receptive to this support because it offloaded this burden from their own resources. The V&V staff also provided the program manager with visibility into project issues independent of the project manager.
Support for Stakeholders
The purpose of creating PMIC was not just to support project teams, however. Engagement with stakeholders and improving strategic alignment was an equal priority. Following an analysis of stakeholder roles, interactions, and interests, the PMIC team created an Internet portal on which it began providing weekly updates to a variety of program report views tailored for different stakeholders. This portal has since been expanded to support collaboration spaces for project teams, and is being used on a regular basis by several hundred stakeholders.
The creation of the program office established the relatively senior-level position of program manager, who gained access to equivalent levels of management in key NATO staffs and the military commands. This access enabled the program manager to provide early and informal engagement with senior stakeholders, and not only improved their sense of involvement in governance but also helped with the early identification and resolution of issues.
The technical functions of PMIC also supported external engagement. Although the full portfolio of NATO IT projects was large, it was not self-contained. There were numerous interfaces between the program as a whole and other major programs such as those building NATO air and missile defense systems. In the case of the missile defense program, collaboration between technical staff led to the adoption of a common requirements data model and protocols for organizing tests involving both programs. Such practical measures significantly reduced the risk of running into problems with operational tests and acceptance very late in project schedules, with the consequent costs, delays, and losses in operational capability.
PMIC has been broadly recognized by its stakeholders as a major improvement in IT project delivery compared to the results achieved prior to its introduction. As a consequence, NATO committed in 2014 to keep the PMIC functions in place for at least six more years.
A Model for IT Program Management
PMIC represents an approach to IT program management that can be adopted by other organizations to better coordinate the planning and execution of IT projects with their changing strategic and operational objectives. However, before attempting to abstract PMIC into a generic model for IT program management, one key consideration must be noted: the expected degree of integration.
Organizations can take a variety of approaches to how they implement IT systems, but, in general terms, these approaches can be characterized as either tightly-coupled or loosely-coupled. In tightly-coupled systems, the interfaces, specifications, standards, practices, and other supporting elements between two or more components of the system are fixed or can only be changed through a carefully-orchestrated modification of these components. In loosely-coupled systems, individual components can be changed more or less independently of the others.
Few systems are absolutely one or the other. The Internet is the best example of this. While the millions of websites and other applications attached to the Internet are managed independently, they all conform to a basic set of protocols and standards, most of which are implemented in their operating systems, hardware, and networking equipment.
However, for the purpose of IT program management, the expected degree of integration should guide the level of control—and hence, the scope—of the program management framework. In a loosely-coupled system, there are fewer constraints upon the design and implementation of the deliverables of the individual projects. In a tightly-coupled system, the number of constraints increase, as do the negative consequences of not conforming to them. In the same manner, the required level of program-level control is much higher for a tightly-coupled system than for a loosely-coupled one.
Understanding the systems perspective of a program is essential in establishing effective IT program management, and the lesson illustrated by the example of PMIC is that effective IT program management requires a combination of management and technical support and control functions.
Keeping aligned with business objectives is one of the biggest challenges for IT projects and, in too many cases, the basis of their ultimate failure. While project management is, in theory, an effective approach for introducing change into an organization, conventional project management tends to act as a barrier against the type of externally-driven changes often associated with maintaining a project's business value. Given the fact that IT projects are often characterized by both a large number of external dependencies and the need to cope with frequent change, a program management approach offers considerable advantages for organizations interested in ensuring that their IT projects deliver strategic value.
NATO has put this into practice with its Program Management and Integration Capability (PMIC). In particular, it integrated technical, as well as management functions in its PMIC framework enable change management to be addressed on as broad a range of external sources of change as possible. PMIC developed this framework to provide support to projects throughout their lifecycles and across a variety of management and technical functions. At the same time, however, it also worked to improve stakeholder engagement and foster mechanisms to ensure continual strategic alignment. For those organizations trying to implement complex information systems—particularly, tightly-coupled ones—PMIC offers a model of IT program management deserving of careful consideration.
Bloomberg, J. (2014, July 11). Is enterprise architecture completely broken? Forbes. Retrieved on 8 January 2015 from http://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/
Hodgson, D. E. (2004). Project work: The legacy of bureaucratic control in the post-bureaucratic organisation. Organisation, 11, 81—100.
International Council on Systems Engineering. (2006). INCOSE systems engineering handbook, version 3. Seattle, WA: International Council on Systems Engineering.
Information Systems Audit and Control Association. (2008, September 8). Survey finds that unmet expectations and changing business needs are leading causes of technology project failure. Retrieved on 8 January 2015 from http://www.isaca.org/About-ISACA/Press-room/News-Releases/2008/Pages/Survey-Finds-That-Unmet-Expectations-and-Changing-Business-Needs-Are-Leading-Causes-of-Technology-Pr.aspx.
Lucas, H. (1975). Why information systems fail. New York, NY: Columbia University Press.
Marchewka, J. (2002). Information technology project management: Providing measurable organizational value. Hoboken, NJ: John Wiley & Sons, Inc.
North Atlantic Treaty Organization. (2005). A status report on the Bi-SC AIS, AC/4(PP)N(2005)0135. Brussels, BE: NATO Office of Resources.
Office of Government Commerce. (2007). Managing Successful Projects with PRINCE2. London, UK: Office of Government Commerce.
Office of government Commerce. (2011). Managing successful programmes. London, UK: Office of Government Commerce.
Project Management Institute. (2008). The standard for program management – Second edition. Newtown Square, PA: Author.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® Guide) – Fifth edition. Newtown Square, PA: Author.
Project Management Institute. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.
Standish Group. (2013). CHAOS Manifesto. Boston, MA: Standish Group International.
© 2015, Brad Bigelow
Originally published as a part of the 2015 PMI Global Congress Proceedings – London, UK
Federal Project and Program Management Community of Practice (FedPM CoP) – How Sharing Best Practices Can Lead to Success
Recognizing the value of a community focused on project practice capability and how such a community could help improve the performance of departments across the U.S. federal government, the leaders…