PMI Virtual Library

© 2007 Project Management Institute

Program Management—
Overcoming Obstacles to Success
Real-life experiences which can contribute to a better
understanding of how programs can be successfully managed
By Diane Haubner, PMP

Executive Summary
Formal program management is becoming a more widespread initiative to help better improve
concurrent project management processes. Although the management of multiple projects
under one roof has been around for a long time, program management has become more recog-
nized for the effective consistency it brings to the process. Recognizing it officially as a struc-
tured process provides project and program managers with a set of standards and controls that
contribute to success.
This article is not about what program management is. The published authority of that
process is documented in PMI's The Standard for Program Management. This article is, instead,
a piece about real-life experiences that can contribute to a better understanding of how programs
can be successfully managed. While this article implies that formal program offices with well
communicated and monitored processes help avoid typical program challenges, it intends to
describe general challenges and appropriate solutions that often exist in an organization without
strong program office controls.

rograms are composed of several individ- just that - individual.

P ual projects, each with a project manager

and team that is accountable for deliver-
ing a product according to standard project
This “individual” view of projects is a natural
phenomenon. Each project manager is account-
able for ensuring the deliverable for which he or
management guidelines. Projects are grouped she is assigned. There is often little interest or
together in a program because an organization time spent in worrying about the other projects
perceives that each of those projects exist to in the program. That is not because each project
achieve the same strategic objective for overall manager isn't conscionable or aware of the other
organizational benefits. projects. In most cases, it's simply because pro-
Any and all projects that are part of a pro- gram management hasn't been formalized, docu-
gram can be very successful in and of them- mented and communicated to the project teams
selves. Yet, the overall program as a whole can sufficiently to allow for each team to understand
fail. The most recurring reason for this failure is how they fit into the overall program.
not viewing the program as a project in itself
and not building a strong process for integrating Relating Project Management to Management
each of the sub-projects within it. of Programs
It is very easy to combine multiple projects on Processes from A Guide to the Project Management
a single project schedule, identify the cross-proj- Body of Knowledge (PMBOK® Guide) have been
ect dependencies, manage that one schedule as a historically well applied to projects. Programs and
program schedule, and still fail. That is because their respective management teams, on the other
a program is not simply a set of projects that are hand, often suffer from a lack of the same process-
combined for a single goal. A program is chal- es. Project teams are frequently thought of as
lenged by the fact that each of the independent administrative functional units, watchdogs or audi-
projects are generally viewed and managed as tors. These teams generally are not considered to
have the detailed kinds of structures and processes their organization at the same time they are
in place as projects do. They are often viewed as doing project work, it becomes increasingly diffi-
managers managing and not producing. cult to do so when they are assigned as equal
PMI's The Standard for Program participants on many projects within a program,
Management describes how those assumptions all vying for the one individual's contribution.
are not the case. It explains programs as having Second, organizationally team members have
three themes—benefits management, stakeholder reporting relationships that may have several
management and program governance—which supervisors, including project managers and
are implied background to this paper's objective. organizational management team members who
The first two themes are generally easier to have their own departmental interests to consid-
achieve and often follow processes for benefits er. The cross relationships and impacts of multi-
and stakeholder management in a similar way ple project teams vying and/or competing for
to how projects manage these processes. management's attention and buy-in becomes
Program governance, however, generally more complex.

“
Within an organization, it is often difficult for personnel to dedicate
their time to a project, even if assigned full-time, and still not be
side-tracked by their “day jobs.” Within a program, it is even more
complicated when the same individual is required to perform on
“
multiple projects at the same time.
becomes a challenge because of the tendency for Third, team interactions are often more chal-
separate projects to prefer to govern themselves. lenging. Project teams within programs some-
They particularly become more difficult to man- times tend to silo themselves. They do this to
age when it comes to the knowledge area “protect their turf” from overall program con-
processes of Human Resource Management, trols. They also do it to form closer team rela-
Quality Management, Communications tionships that are simply easier to manage than
Management and Risk Management. relationships that cross over to other project
While several, if not all, of the nine project teams. Often, other project teams have com-
management knowledge areas apply to program pletely different objectives, products, timelines,
management, this article focuses on principals budgets and attention than another project
and techniques relevant to the four specific knowl- team. That often leads to this isolationist stance.
edge areas noted above, as they lend to overall At a program level then, it becomes necessary
improved program management and specifically to pay greater attention to the Human Resource
in relationship to program governance. process assets that form the program plan.
These actions will help bring success:
Human Resource Management—Challenges  Formalizing and validating individual project
and Solutions organization charts as part of the overall pro-
One of the biggest challenges to program man- gram chart is important. This organizational
agement is the managing of resources. This chal- representation also needs to include manage-
lenge is generally related to time management, ment teams and external entities.
reporting relationships, and team interaction.
 Creating detailed position descriptions that
Within an organization, it is often difficult for
personnel to dedicate their time to a project, describe program as well as project activities
even if assigned full-time, and still not be side- needs to be included. The positions must be
tracked by their “day jobs.” Within a program, it described in a way that allows the individual
is even more complicated when the same indi- to understand that their role and commit-
vidual is required to perform on multiple proj- ment may be different based upon how they
ects at the same time. For example, an organiza- interact on the various projects.
tion may have only one database administrator,  Accountability (RACI) diagrams that include
or one security officer, one change control spe- a dimension for the program as aligned with
cialist, one department manager, etc. And while a project responsibility should be applied. An
these individuals can often more easily support

PMI Virtual Library | www.PMI.org |© 2007 Project Management Institute

2
 example is shown in Figure 1. meetings should not be limited to just the
project managers, but include all levels of
project participants when beneficial.

Quality Management—Challenges and

Solutions
Project teams, especially when deliver-
ing different products using different
tools, often consider themselves free to
ignore program guidelines or rules. The
isolationist stance described under the
challenges of Human Resource manage-
ment often contributes to this view. In
many cases project teams, especially if
composed of vendor third parties, are
quite comfortable with their own way of
running a project and have no interest
in going along with the “program way.”
Teams that have a history together,
either as performing groups within the
Figure 1: Program/Project RACI Diagram. R=Responsible; organization or as product teams, see
A=Accountable; C=Consult; I=Inform. themselves as experts in their own
process. While all of this may be true in
a way, when viewed from a program per-
 Ground rules need to be documented at the spective, deliverable and process quality can be
program level and become part of the quality at risk.
review process from an organizational asset Quality standards, especially when related to
perspective. A good way to ensure uniformity project processes and deliverables, need to be
in this technique is to staff the program with more highly standardized on programs.
a full-time organizational process or change Recognizing that all the projects contribute to
management resource. This role is crucial in the overall benefits expectations of the program,
not just resource management, but in terms quality standards need to be consistent across
projects so that those benefits can be equally
of communication within and external to the delivered. Deliverables that look different can
program team. create confusion to the end user. Processes such
 The organizational process/change manage- as testing, user manuals, etc., that are devel-
ment resource can also be instrumental in oped with different templates, content, approach
ensuring that teams “meet and greet” on a and tone create different levels of quality.
regular basis through planned activities, both To ensure success, quality standards need to
professional and personal. A rewards pro- be designed and documented at a high enough
gram as part of this process is also effective, level so that they can be easily mapped to deliv-
given that every team member is aware of erables and processes that contribute to expect-
how the program operates and what behav- ed benefits. A program quality plan should be
written during the Program Initiation process
iors and deliverables are expected. that identifies what quality standards will be
 Early and repeated communication of pro- applied, how they will be applied and monitored,
gram-level expectations and the relation to and how they link to the expected benefits. This
project benefits is crucial. Every team mem- plan should serve as input into each project's
ber must be continually reminded that they Planning Process Group activities (see Figure 2).
are part of a larger organizational effort. In addition to the quality plan, it is often con-
 Fully documented mapping of individuals and venient to set up a library of templates and
their outputs to project/program benefits real- process descriptions that are designed in such a
ization must be shared. Program resources way that they can be used by any project team
without having to redesign the tool. For exam-
need to participate in program meetings or
ple, a testing plan template can be created that
events to help further this objective. These defines the expected testing processes to be

PMI Virtual Library | www.PMI.org |© 2007 Project Management Institute

3
 Project teams tend to document
their own meetings, create their
own issue lists, and send e-mails to
their own team members. These
activities all have a place. But miss-
ing from that approach is the need
to understand and communicate
how a single issue on one team may
impact another. Or how a resource
need on one team is assumed as
just fine, without communicating to
other teams if there are schedule
conflicts for that same resource.
In some instances, public com-
munications in newsletters, compa-
ny websites, payroll stuffers, lunch-
Figure 2: Linking quality between organization, program and project goals. and-learns, broadcast messages and
elsewhere can sometimes negative-
ly impact another project within the
applied to all projects and how those testing
program without the initiators realizing it. A par-
processes are rolled up into program testing.
ticular communication may send the exact oppo-
The use of standards, templates, instructions,
site message that a different team is trying to
resources, software and other components
communicate, creating confusion to the reader.
should be considered.
From a program perspective, communications
The library should also serve as the program
must be very deliberately formalized and recog-
repository for all work in process and final deliv-
nized as the single source for key messages. A
erables. It should be organized in a way that
specific resource on the program team needs to
allows both project specific documentation as
be assigned a communication role. That individ-
well as program level standards to be easily
ual needs to develop the communication plan
accessed, stored and applied. Figure 3 shows
just one example of how such a library
can be designed. This approach assumes
a high-level structure based upon the
overall program. Within the Execution
Process Group, each project has its indi-
vidual project set of documents and
deliverables.
Communications Management—
Challenges and Solutions
Project communications are not often
given the attention they require since most
project teams focus on getting the “task
list” done first. Communication, therefore,
tends to be centered around team meet-
ings, steering committee updates and occa-
sional newsletters. While that in itself is a
typically limiting approach for communica-
tions, it is compounded on a program level
when multiple projects within the program
not only operate that way but exclude
other program participants from even
those processes. This communication is
related not simply to stakeholder commu-
nication, but program/project communica-
tion related to issues, status and other
communications. Figure 3: Sample project within program document library.

PMI Virtual Library | www.PMI.org |© 2007 Project Management Institute

4
from a program perspective and include specific tion versus less will ultimately reduce miscom-
project communications within that plan. munications in the end.
The program communication plan needs to be Finally, while each project team will still bear
designed to ultimately focus on the communica- its own responsibility to communicate within the
tion related to the original program benefits. It team for the majority of project-related informa-
needs to strategically relate each project's contri- tion, standards for those communications should
butions and their statuses in a way that commu- still be applied. For example, all team meetings
nicates those benefits to all stakeholders. should have published agendas and published
Approaching it this way allows the listener or meeting and to-do notes. The list of actual-ver-
reader to hear a consistent message. sus-planned attendees should be included.
Additionally, those messages should be sent Meetings should be posted to a shared program
with a consistent tone, style and language that team site with the intent of allowing any pro-
the listener will more easily recognize over time. gram member to attend as a “listener.” It is key
This will contribute to less confusion and misin- here that non-project attendees understand
terpretation by the listener. their role as listener versus participant in order
Program focused communication further to make the meetings more efficient and not get
tends to be perceived as more “official” within bogged down with unrelated questions.
organizations. These communications are often Lastly, regular status reports (weekly, bi-
aligned with an organization's formal communi- weekly) should be published by each project team
cations office, which contributes to a more using a consistent format and consolidated by
prominent position overall. Using this advan- the program team for program-wide distribution.
tage effectively however, means that the pro- This allows team members to quickly get “up to
gram communications lead must work very inti- speed” on the program without having to attend
mately with each of the project teams to fully meetings or read through other deliverables.
understand their role, their objectives and their
outcomes. That will allow each of the project Risk Management—Challenges and Solutions
teams to successfully communicate what is nec- Program risk can have impacts across the pro-
essary without feeling left out. gram, including scheduling, deliverables quality,
All project teams need to be coached to con- design considerations, testing, and other areas.
sider communications a critical and sometimes Scheduling risks typically start during project
sensitive process along the path to project com- planning. In many cases, projects within pro-
pletion. Team orientation sessions should grams often have different start and stop sched-
include specific instruction for how project com- ules. This is generally done to reduce the risk of a
munications will be handled within the pro- big bang, to spread out resources more evenly,
gram. A copy of the program communication spread out the program budget over a longer time
plan should be given to each project team mem- period and simply account for the actual length of
the individual projects. While this approach

“
ber as they roll on to the program.
makes sense overall, there are risks associated
Regular status reports (weekly, with it that need to be carefully managed.
One of the significant risks associated with
bi-weekly) should be published this approach is integration of cross-over fea-
by each project team using a consis- tures or cross-project design. In a system imple-

tent format and consolidated by the

program team for program-
“ mentation, for example, the separate projects,
each with separate products, are often intended
to be integrated to some degree. For example, a
customer service system may integrate billing
wide distribution. information into a separate, non-integrated
financial system. Design decisions made within
Additionally, while some program communi- one project may have a significant design impact
cations may simply reflect information from only on the other. Further, if two projects are work-
one of the projects within the program, it should ing from different schedules, and more signifi-
still be shared with each of the other project cantly, if one project finishes before another
team members. Although it is possible that starts, then there is potential for risk. Even
many individuals will ignore communications though separate project teams within a program
that they do not perceive as relevant to what may communicate status to each other via pro-
they have been assigned to do, more communica- gram reports or program meetings, that form of
communication does not always mitigate design

PMI Virtual Library | www.PMI.org |© 2007 Project Management Institute

5
impact risks because of a lack of participation of tracting and other components. The agreed-upon
teams at the detail level. conclusions from this phase then become the
Another risk relates to integration testing. A starting point for all projects going forward. At
fully, complete system integration test for all this juncture, it is not necessary for all project
projects in a scenario such as the example above teams to proceed together. A new start-stop plan
is necessary to ensure that all components work can be applied with reduced risk and rework.
together. While separate project testing events
are obligatory, programs often limit cross-project Integrated Program Testing
integration testing to “interfaces.” As cited While the “single start-multiple continuation”
above, when different projects have different go- approach works well for reducing initial cross
live dates, it's often impossible to conduct cross- project design risks, this integrated testing
project integration test. While regression testing cannot easily be applied later on in a program
certainly is an option to use to mitigate such a if the separate projects have already started
risk, it often is too late in the program to make but end at different times. This then becomes a
changes to design if the go-live is already past significant risk to quality and rework. It
on the first project and regression testing expos- becomes especially difficult if the end dates for
es a significant error or design change. some projects are near to each other. The tim-
Programs often attempt to address this risk ing for integrated testing will ultimately
by scheduling all projects to end at the same impact one team's schedule and cost.
time, even though there may still be staggered The only strategy to eliminate this risk is to
starts. The impact here, however, is that a slip- view each project similar to a new “release” and
page in any one of the multiple projects will perform exceptional system, regression and per-
impact the delivery of all the other projects with- formance testing as part of the second team's objec-
in the program. That creates cost and schedule tives. This will likely eliminate a program benefit
overruns for on-time projects unnecessarily. but in the long run, create a more quality result.

Integrated Design Risks Conclusion

Solutions to address integrated design risks In conclusion, program management is a solid,
typically are often ignored in actual programs, beneficial way for organizations to manage
simply because there is a perception that any groups of projects. When consistent and inte-
alternative to a project's normal start and stop grated processes are applied to each of the proj-
costs more and takes longer. Often teams ects within a program, risk can be reduced and
employ a cross-project subject matter expert as quality improved that contributes to the overall
the eyes and ears for the program. However, in objectives of the initiative. The sample controls
terms of risk mitigation, a more unusual noted within this article are the start for any
approach may actually cost less in the long run consideration of program management, and
and provide a more thorough validation result. when applied to other program characteristics,
An effective way to plan programs to reduce can be considered a success for all.
design risks is with a “single start-multiple con-
tinuation” approach. At the beginning of the pro- About the Author
gram, all project teams start at the same time. Diane Haubner, CISA, PMP, is a veteran man-
They conduct analysis and design sessions con- agement consultant with over 19 years experience
currently, validating As-Is processes, functional in the design, development, implementation and
and technical requirements, and To-Be visions support of strategic business initiatives and infor-
simultaneously. Deliverables from this starting mation systems in a variety of industries and
point then become input into a unique program environments. She has over 15 years experience
phase-cross-project comparison. What this as a project manager. She also has experience in
implies is a formal process that compares the strategic planning, technology assessment, best
results of each project and specifically looks at practice implementations, business process re-
design or build situations that could negatively engineering, portfolio-program-project manage-
impact each other. The program teams then pro- ment office design, application development,
ceed to resolve the exceptions and agree on the information system audit and controls and IT
final approach for integration. organization. Her consulting experience has
This unique phase is not limited to system or ranged from Fortune 500 companies to start-up
process design. It also can be applied to other companies across multiple industries, including
processes with projects such as training, post go- manufacturing, health care, insurance, the public
live controls, communications, licensing, con- sector, higher education and professional services.

PMI Virtual Library | www.PMI.org |© 2007 Project Management Institute

6