 | Level: Introductory Michael F. Hanford, Chief Methodologist, SUMMIT Ascendant Methodologies
14 May 2004 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.
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.
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.
About the author | 
| | Michael 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. |
Rate this page
| |
