Program management: Different from project management

From the Rational Edge: Mike Hanford asks some basic questions about program management and discusses practices associated with this discipline. He explains relationships between project management and program management roles and techniques, noting significant differences.

Michael F. Hanford, Chief Methodologist, SUMMIT Ascendant Methodologies

Michael F. HanfordMichael F. Hanford is the chief methodologist for the IBM SUMMIT Ascendant methodologies and a member of the IBM Rational commercial methods content team. He has also worked as a methodology author, a manager for large consulting engagements, and a leader of enterprise process assessment and transformation efforts for IBM Rational and PriceWaterhouseCoopers Consulting (PWCC). Prior to joining PWCC, he was director of software engineering practices for Fidelity Investments Systems Company.



14 May 2004

Also available in Chinese

Illustration
Many enterprise IT organizations are tackling large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers are finding that "traditional" project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects.

This article considers five major aspects of program management:

  • Governance: Defining roles and responsibilities, and providing oversight
  • Management: Planning and administering both projects and the overall program
  • Financial management: Implementation of specific fiscal practices and controls
  • Infrastructure: The program office, technology, and other factors in the work environment supporting the program effort
  • Planning: Activities that take place at multiple levels, with different goals. The program plan is not a traditional plan

We will take a closer look at each of these aspects, contrast them with similar aspects of project management, and outline for each the effort and results required to achieve success.

Program governance

Program governance is the aspect of the discipline that creates both the structure and practices to guide the program and provide senior-level leadership, oversight, and control. Strategically, it encompasses the relationship between the oversight effort and the enterprise's overall business direction. It also encompasses all the decision-making roles and responsibilities involved in executing the program effort.

Projects are typically governed by a simple management structure. The project manager is responsible for day-to-day direction, a senior IT executive integrates technology with business interests, and a business sponsor is accountable for ensuring that the deliverables align with business strategy.

Programs require a more complex governing structure because they involve fundamental business change and expenditures with significant bottom-line impact. In fact, in some instances their outcomes determine whether the enterprise will survive as a viable commercial/governmental entity.

Figure 1 shows a sample governance structure for a complex program.

image

Figure 1: Sample program governance structure

As we can see in Figure 1, unlike most projects, programs usually have a steering committee or other group that represents diverse interests and provides executive-level oversight. As the program evolves, this governing body ensures that it continues to align with the enterprise's strategic direction and makes decisions that may eventually filter up to the board of directors. Defining the role and decision-making powers of the steering committee is a significant part of the program governance effort and should be done with an eye toward facilitating rapid decisions and promoting a clear, unified direction.

Figure 1 also illustrates a typical program management structure, which is more complex than that of a project. Creating this structure involves defining specific roles with specific decision-making authority, and making clear to all who "owns" certain program functions.

Good governance is critical to program success. A poorly articulated management structure, overlapping roles and decision-making authority, and roles filled by the wrong people (or not filled at all) can prevent a program from achieving sustained momentum or bog it down with endless attempts to achieve consensus on every decision.


Program management

What is program management? Is it really management at all?

To answer these questions, let's begin by looking at an accepted definition of project management:

Project management is the planning, organizing, directing, and controlling of company resources... for a relatively short-term objective.1

It is clear from this definition that project management is concerned with the dynamic allocation, utilization, and direction of resources (both human and technical), with time -- in relation to both individual efforts and product delivery schedule -- and with costs, relating to both the acquisition and consumption of funding. As a corollary, it is safe to say that without the direction project management provides, work would have to proceed via a series of negotiations, and/or it would not align with the goals, value proposition, or needs of the enterprise.

Within a program, these same responsibilities (i.e., allocation, utilization, and direction) are assigned to people at three levels in the management hierarchy; the higher the level, the more general the responsibilities. For example, at the bottom of the management hierarchy, project managers are assigned to the various projects within the overall program. Each manager carries out the management responsibilities we described above.

At the middle of the hierarchy is the program manager/director,2 whose major responsibility is to ensure that the work effort achieves the outcome specified in the business and IT strategies. This involves setting and reviewing objectives, coordinating activities across projects, and overseeing the integration and reuse of interim work products and results. This person spends more time and effort on integration activities, negotiating changes in plans, and communicating than on the other project management activities we described (e.g., allocating resources, ensuring adherence to schedule, budget, etc.).

Responsibilities of a program manager/director

  • Accountable to executive sponsors for schedule, budget, and quality of all program elements.
  • Leads high-level sessions for program plan and schedule development.
  • Reviews/approves project plans for conformance to program strategy and program plan and schedule.
  • Acts as the communications conduit to executive sponsors and program steering committee and conducts periodic briefings/status updates.
  • Escalates decisions to executive sponsors as necessary.

At the top of the program management hierarchy are the program sponsor(s) and the program steering committee. Their major responsibility is to own and oversee the implementation of the program's underlying business and IT strategies, and to define the program's connection to the enterprise's overall business plan(s) and direction. Their management activities include providing and interpreting policy, creating an environment that fosters sustainable momentum for the program (i.e., removing barriers both inside and outside the enterprise), and periodically reviewing program progress and interim results to ensure alignment with the overall strategic vision.

These individuals receive periodic summary reports and briefings on funding consumption, resources and their utilization, and delivery of interim work products and results. Typically, they will focus on these reports only if there is significant deviation from the plan.

So, let's return to the questions we posed at the start of this section: What is program management? Is it really management at all?

If you think of management activities strictly as those we defined for project management, then the answer to the second question is "No," or maybe "Partly." At the project level, managers do still perform these activities, but the program manager/director addresses a different set of program goals or needs, which requires a different "bag of tricks" as well as a different view of what is happening and what needs to get done. And at the top of the hierarchy, the executive leaders who set goals and oversee the program certainly do not perform the same detailed activities as project managers.


Program financial management

The financial aspect of a program includes the need to conform to internal (and sometimes external) policies and/or regulations for significant expenditures. It also includes development and use of program-specific procedures for making and reporting expenditures.

Overall costs for programs are typically significantly greater than those for projects. For example, projects that consume one to five man-years of effort might have an internal cost range of $250,000 to $1,000,000, assuming the resources are employees (not contractors) with an hourly charge-back rate of $100 to $150 per hour. A program to upgrade and rewrite the core software applications of a large financial services company might require between 750,000 and 1,000,000 work hours, a staff of 175 consultants and 225 employees, and expenses ranging between $160,000,000 and $200,000,000.

The costs are greater not only because the program is larger, but also because it entails more types of expenditures. In a project of the size we just described, most -- if not all -- the expenditures are for labor, from an accountancy perspective. The program costs would include labor (both internal chargeback and consulting fees, and travel and living expenses, including short-term apartment leases), hardware, packaged software applications (which may be capitialized and depreciated), work space (perhaps construction, too), and furnishings/equipment, such as computers, servers, printers, desks, chairs, cubicles, and so on. Enterprises have different ways to treat these expenditures, outlined in financial policies and procedures. Government agencies and regulated industries may also have laws or regulations regarding spending and expense reporting.

From an administrative point of view, the responsibilties associated with authorizing, recording, and reporting program expenditures go well beyond those typically exercised by an individual project manager. Typically, the office of the Chief Financial Officer (CFO) will be involved during the strategic definition and financial justification phases of a program. Financial analysts will construct and/or use complex financial models, see that the enterprise's financial policies are interpreted and applied correctly, and ensure that the program's financial impact is accurately represented to executives at key decision points.

The CFO's engagement will continue, with different responsibilities, throughout the program's lifecycle. The program office will typically include a role for a budget administrator who assists the program manager/director in ensuring conformance to financial policies and guidelines. A best practice requires the CFO to fill this role with a full-time or part-time financial analyst.

Early in the program, you should plan and conduct a checkpoint review of the financial management apparatus and identify needs and requirements that are specific to the program.

Implementing the program's financial practices may require nothing more than educating people about how to apply them. However, in some instances you may need to tailor and adopt policies, create new cost centers and/or a chart of accounts, and outline financial procedures and assign decision authority unique to the specific program.

In any case, the skills required to create and ensure program-wide application of sound financial practices are typically not required for a project effort. To succeed, program financial management demands early and active engagement on the part of the CFO and his or her staff.


Program infrastructure

Infrastructure is a useful term to describe collections of roles, tools, and practices that organizations assemble and integrate in order to provide services and support for software development. To understand the infrastructure required for a successful program, let's first explore the management and administrative roles, tools, and practices that constitute the Program Management Office, or PMO. Then we will look at requirements for the technical environment and tools.

Administrative infrastructure

Of course, simply creating and operating a PMO -- which can assume many forms -- differentiates programs from projects. Our discussion will focus primarily on PMOs that support a single program -- one that will be disbanded at the close of the program effort. However, we should keep in mind that in some IT organizations, an Enterprise PMO is a permanent fixture, providing services to multiple (and changing) programs.

PMO roles

  • Program office management
  • Resources coordination
  • Budget administration and procurement
  • Risk assessment
  • Work products tracking and review
  • Facilities administration
  • Contracts administration
  • Technical support liaison
  • Training coordination
  • Methodology and process support
  • Issues management
  • Communications management
  • Status reporting management

The PMO provides administrative and management support to the program manager/director and all other program participants. It also provides specialized staff expertise for specific work areas.

The PMO involves many roles covering numerous areas and activities (see sidebar). In addition to serving the program manager/director, the staff members, a group of senior specialists, fill essential program roles. For large, complex programs, the PMO helps establish and maintain appropriate work processes, controls, and reporting functions to keep management apprised of the program's progress. It also defines, plans, and completes various work efforts.

As an example, let's examine just one role in the PMO -- facilities administration -- and how it contributes to program success. Whoever takes on this role must identify, plan, and deliver all necessary facilities for either a program-specific or permanent PMO. To do this, the facilities administrator must:

  • Work with the PMO manager and program manager to define what should be included in facilities and define and prioritize facility needs.
  • Develop and gain approval for a facilities plan.
  • Manage execution of the facilities plan and associated deliveries, construction, and installation.
  • Collaborate closely with the infrastructure and technical environment coordinator.

Let's compare the value of this role within a project versus a program. For a single, small project with a maximum of seven employees on the construction team, this role would add little value. The team members would likely have offices or cubicles and the ability to reserve meeting rooms through a reservation system.

But suppose you have a program for which mobilization will take four weeks. Over this period, 200 consultants are to become resident at the principal office campus, 260 IT staff will be assigned to the program, and the three project managers insist that their project teams be co-located for efficiency. There is a need for twelve dedicated photocopiers, five dedicated conference rooms, a space for the program office, and so forth. The daily billing rate for all 200 consultants is $360,000. So if the operation of these facilities is delayed by five days and the consultants cannot work on site -- well, you can do the math. Clearly, someone must "own" the responsibility to set up the proper space and tools to get the job done.

In truth, we could devote an entire article to the work performed by the PMO -- and that office does not even cover every responsibility. For now, let us just say that the infrastructure the PMO provides enables all the project teams involved in the program to be productive.

Technical environment and tools

A program infrastructure also includes both hardware -- for desktop and network devices for storage and communication -- and software, including desktop software and shared platforms with development tools, modeling software, planning tools, communication tools (email, Internet browser, virtual meeting /collaboration programs, telecommunications programs), and software for document retention and reproduction.

An individual project, especially a pioneering effort, may introduce new tools or hardware partly in order to understand their capabilities and limitations. The project manager may become involved in technical support or infrastructure functions, to acquire, install, and/or "tune" the hardware and software. Typically, this will involve a small number of installations for a small number of IT staff. Periodic changes and/or additions to the development environment will affect larger numbers of IT staff, but these are typically defined and managed as separate projects.

Program technical activities, in contrast, usually include large numbers of staff from a variety of sources (internal and external) and various technology backgrounds. As managers identify and staff component projects in the program, they must also specify, acquire, and install technology environments and tools for each project, which collectively form the program's technical infrastructure. This effort might encompass creating a new, remote development site or integrating two companies' technologies following a merger, for example.

This infrastructure effort should be treated as an internal program project (as opposed to an external project, which delivers components or results to clients). Managers should plan a well-defined, rapid, and brief lifecycle for creating the technology environment. The effort should include defining needs and requirements, setting a scope, and installing, testing, and implementing all technologies. If some tools will be new to some portion of the program staff, it may also be necessary to define a rapid-delivery training effort.

Managers should also consider how the infrastructure's hardware and tools will be used beyond the program's boundaries. If they felt compelled to select technologies different than those in the current enterprise IT architecture, then supporting and maintaining new software applications built with those technologies may require additional personnel, software, and training. Managers should always carefully evaluate the potential impact of their program technology selections upon existing IT architecture and resources (and perhaps future direction) before actually making the acquisitions.


Program planning

For program planning, most managers will typically use a bottom-up approach that identifies and executes planning iterations for the program's individual component projects. First, each project manager constructs a plan that estimates and allocates resources required to deliver the project's products or results, using the same techniques and practices they would employ in planning a standalone project.

Then, in the next planning iteration, managers identify connections and dependencies among the program's projects, and refine and rework their project plans to integrate them with others. Often this integration effort requires adjustments to the products planned for each project, the numbers and types of resources required, and -- naturally -- the schedule. The managers' ability to continuously manage and adjust to inter-project dependencies is a significant determinant of program success. This ability is also a major differentiator between the requirements of project planning and program planning.

The program plan

Once the individual project plans are integrated, it is time to initiate the program planning effort. What exactly is a program plan? American Heritage Dictionary defines a plan as "A scheme, program, or method worked out beforehand for the accomplishment of an objective: a plan of attack." But when we look at how we develop and use program plans, we discover that they do not fit neatly into this definition.

First of all, in contrast to the planning for the program's projects, the program plan typically is not developed through a series of iterations. Instead, the planning effort involves conducting a series of reviews of the individual project plans, and then creating a digest of their contents. During this process, conflicts between projects may become apparent and require resolution. A goal of the digest effort is to produce a concise, usable view of all program work, timeframes, and required results. A program plan describing 10,000 activities, for example, would not have these qualities.

You don't use the program plan to direct work and allocate resources. That is the purpose of the individual project plans. It may be helpful to think of the program plan as a seismograph that seeks to detect and measure the potential impact of any trembling in the ground underneath the program effort. As component projects proceed and individual project plans record completion percentages, expenditure of resources, and interim (or final) dates for work activities, the program plan integrates these measures and shows their collective impact. This enables managers to assess the program's progress against plan and detect potential problems. For example, if a client asks for additional functionality in a component that one project is building, that may delay the component's delivery to other projects and slow them down as well.

In short, the program plan's integrated representation of significant planned activities and results of individual projects provides managers with a window into the cumulative work effort of the program. Managers use it to verify that the program is moving in the right direction to meet business goals, identify where unplanned changes may be occurring and assess their potential impact, and to model and/or test the impact of possible adjustments and corrections.


Conclusion

In this article we have just begun to explore the differences between project and program management. We have seen that programs require capabilities and resources that are not generally required in the project management space, and which correlate directly with the program's success.

In general, program efforts have a larger scale and impact than most project efforts. The outcome(s) of a program effort can have a significant impact upon business and product viability. These efforts can also consume significant amounts of funding -- which can translate into hard choices about whether to continue or discontinue programs or certain aspects of them. For example, although the US space program of the 1960s put a man on the moon and created significant new products and engineering capabilities within the American economy, it cost taxpayers tens of billions of dollars, and precluded other government initiatives. Funding for this program was the result of many hard choices.

Program efforts, with their large staffs, typically develop greater momentum than standalone projects. This momentum helps programs accomplish major amounts of work (a good thing), but it can also make programs resistant to changes in direction. Lack of vision, changes in vision, and poor direction can lead a program to consume enormous amounts of money in relatively short time periods without providing real value or useful results.

Fortunately, applying sound techniques and practices specific to program management can enhance an effort's chances of success and reduce risk. For enterprise-scale work efforts, these practices can enable an organization to pursue its business strategy and remain competitive.


References

IBM Rational SUMMIT Ascendant, "The Program Management Method." Version 8.1, February 2004.

Office of Government Commerce (OGC): HMSO, "Managing Successful Programmes." Copyright 2003.

Deborah Kezsbom, et al., Dynamic Project Management. John Wiley & Sons, 1989.


Notes

1 Deborah Kezsbom, et al., Dynamic Project Management. John Wiley & Sons, 1989.

2 In the UK, the Office Of Government Commerce (OGC) calls this role Senior Responsible Owner in its publication, "Managing Successful Programmes," explaining that this role is charged with : "... providing overall direction and leadership for the delivery and implementation of the programme, with personal accountability for its outcome." See References in this article for more information.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=87440
ArticleTitle=Program management: Different from project management
publish-date=05142004