Contents

Program management: Different from project management

Michael F. HanfordPublished on May 14, 2004

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.

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: 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.

Notes

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.