Agile Program Management: Moving from Principles to Practice

Agile Program
Management:
Moving from Principles
to Practice
by Glen Alleman
Agile program management is the “glue” between IT
strategy and the delivery of business value. Capabilities-based
planning identifies needed features and functions, allowing
the portfolio manager to incrementally measure value through
the assessment of the increasing maturity of significant
accomplishments and exit criteria that represent the
business capabilities.
Agile Project
Management
Vol. 6, No. 9

About Cutter Consortium
Cutter Consortium is a truly unique IT advisory firm, comprising a group of more
than 100 internationally recognized experts who have come together to offer
content, consulting, and training to our clients. These experts are committed to
delivering top-level, critical, and objective advice. They have done, and are doing,
groundbreaking work in organizations worldwide, helping companies deal with
issues in the core areas of software development and agile project management,
enterprise architecture, business technology trends and strategies, enterprise risk
management, metrics, and sourcing.
Cutter offers a different value proposition than other IT research firms: We give you
Access to the Experts. You get practitioners’ points of view, derived from hands-on
experience with the same critical issues you are facing, not the perspective of a
desk-bound analyst who can only make predictions and observations on what’s
happening in the marketplace. With Cutter Consortium, you get the best practices
and lessons learned from the world’s leading experts; experts who are implementing
these techniques at companies like yours right now.
Cutter’s clients are able to tap into its expertise in a variety of formats including
content via online advisory services and journals, mentoring, workshops, training,
and consulting. And by customizing our information products and training/
consulting services, you get the solutions you need, while staying within
your budget.
Cutter Consortium’s philosophy is that there is no single right solution for all
enterprises, or all departments within one enterprise, or even all projects within a
department. Cutter believes that the complexity of the business technology issues
confronting corporations today demands multiple detailed perspectives from which a
company can view its opportunities and risks in order to make the right strategic and
tactical decisions. The simplistic pronouncements other analyst firms make do not
take into account the unique situation of each organization. This is another reason to
present the several sides to each issue: to enable clients to determine the course of
action that best fits their unique situation.
For more information, contact Cutter Consortium at +1 781 648 8700 or
sales@cutter.com.
Cutter Business Technology Council
Access
to the
Experts
Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Lou Mazzucchelli Ed YourdonRob Austin

by Glen Alleman
Agile Program Management:
Moving from Principles to Practice
AGILE PROJECT MANAGEMENT
ADVISORY SERVICE
Executive Report, Vol. 6, No. 9
[Solutions] should always
concentrate on the whole
and not on assembling parts.
All the great principles have
one thing in common. They
are simple. After one realizes
such a simple but profound
principle, one can not stop
wondering how one survived
without its knowledge.
— Christopher Alexander
(The Timeless Way
of Building, Oxford
University Press, 1979)
Every segment of industry and
government is under pressure
to reduce cost, increase quality,
and deliver value to owners, cus-
tomers, and constituents. The IT
community is no exception. CIOs,
product managers, and opera-
tional leaders are expected to
provide solutions that address
these improvement initiatives in
the presence of a constant, rapid,
and unpredictably changing envi-
ronment. These initiatives result
in a mandate to deliver best value
IT products and services — on
time and on cost — that meet
emerging business, regulatory,
and technology requirements. The
processes used to place IT sys-
tems into operation must meet or
exceed the strategic objectives of
the enterprise and must do so in
the presence of ever increasing
uncertainty. Research shows that
most IT project problems are
related to managerial, organi-
zational, and cultural issues not
technical problems [22, 23].
Agile program management pro-
vides the connection between
strategy and execution. During
the past 10 years, IT projects have
Business strategy provides the starting point for selecting portfolios of projects
and defining their beneficial outcomes.
Defining the capabilities identified in the strategy lays the foundation defining
the delivered value to the enterprise.
Event-based scheduling provides the needed project performance management
process to assess the increasing maturity of the program in delivering value
needed for a successful strategy.
One of the most dangerous forms of human error is forgetting what one is trying
to achieve. — Paul Nitze
Agile program management joins strategy and execution to deliver value through
testable outcomes, measures of increasing maturity, and continuous feedback.

grown in number, size, and com-
plexity. As a result, a gap has
developed between the strategic
decisions of the corporation and
the actions of the project teams
tasked with executing their own
interpretation of management’s
desire. In the past, successfully
managing a project was seen as
a stepping-stone to a senior man-
agement position. Much of the
gap between strategy and execu-
tion didn’t exist because intimate
knowledge of the business prob-
lem was a key requirement for
the project manager. However,
today, with project managers
regarded as “generic technical
professionals,” having the skills
and experience needed to
make tradeoffs on the road to
success has become difficult.
This Executive Report completes
the final piece of the hierarchy
for efficient management of IT
and complements the agile IT
management processes presented
in Cutter Consortium Senior
Consultant Donna Fitzgerald’s
“Principle-Centered Agile Project
Portfolio Management” [11] and
Cutter Business Technology
Council Fellow Jim Highsmith’s
“Agile for the Enterprise” [13].
The case for agile program man-
agement, as explored in this
report, can be stated as follows:
For CIOs and internal IT managers
who develop and deploy enter-
prise applications using com-
mercial off-the-shelf (COTS) or
internally developed solutions,
agile program management pro-
vides the principles and practices
needed to successfully manage
a portfolio of projects; measure
their financial and technical
performance through iterative
and incremental deliverables; buy
down risk by continuously manag-
ing performance variation; and
address foreseen and unforeseen
unknowns (see Figure 1.)
TRADITIONAL VERSUS AGILE
PROGRAM MANAGEMENT
Only those general principles
and attitudes that result from
clear and deep understand-
ing can provide a compre-
hensive guide to action.
— Jim Collins,
Good to Great [9]
Agile program management con-
tains practices found in traditional
program management, delivered
through the principles of agile. For
the traditional program manager
this description is likely meaning-
less. Before these principles can
have value to an IT organization
some background on the problem
and the previous approaches is
needed to show how these gaps
are addressed by the agile pro-
gram management practices.
There are several official
descriptions of agile.1 These
descriptions fall short for the
VOL. 6, NO. 9 www.cutter.com
22 AGILE PROJECT MANAGEMENT ADVISORY SERVICE
The Agile Project Management Advisory Service Executive Report is published by the Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA
02474-5552, USA. Client Services: Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America,
+1 800 888 1816; E-mail: service@cutter.com; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: kletourneau@cutter.com.
Managing Editor: Cindy Swain, E-mail: cswain@cutter.com. Production Editor: Pamela Shalit, E-mail: pshalit@cutter.com. ISSN: 1536-2981. ©2005
by Cutter Consortium. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against
the law. Reprints make an excellent training tool. For more information about reprints and/or back issues of Cutter Consortium publications,
call +1 781 648 8700 or e-mail service@cutter.com.
“Demand”
Business
mission
and
vision
Balanced
scorecard
Project
portfolio
management Capabilities-
based
planning
Event-
based
tasks
“Done”
Figure 1 — Agile program management contains five major elements, each
supporting and enhancing the others to deliver beneficial business outcomes
derived from connecting strategy to execution.
1The current definitions of agile are strongly influenced by the software development paradigm. While this is useful for those writing software, for
the program manager of development projects, or for the procurement and integration of COTS products, the software-centric paradigm has limits.
See, the Agile Alliance (www.agilealliance.org), Declaration of Interdependence (www.pmdeclarationofinterdependence.org), Agile Project
Leadership Network (www.agileprojectmgt.org), and David Anderson’s Agile Management site (www.agilemanagement.net/index.html).

traditional program manager, not
because the principles of agile are
lacking, but because the practices
of program management are not
directly addressed using the
software development–focused
methodologies presented by these
authors.2 In addition, the distinc-
tion between project manage-
ment, program management, and
software development manage-
ment is not clearly drawn in these
approaches. Add to this the variety
of different drivers for the devel-
opment or acquisition of software
systems and the practices of agile
program management become
lost in the vocabulary of software
development [18].
Where Does the Problem Start
with Traditional Program
Management?
Traditional management disci-
plines start with a retrospective
approach, which measures vari-
ance against plan rather than pro-
viding performance-forecasting
information that can be used to
guide projects in a chaotic envi-
ronment [26]. These traditional
systems measure work accom-
plished through cost and schedule
variance rather than technical
and business accomplishments.
These principles make use of
linear,3 step-wise refinement
of the project management
processes based on a planning-
as-management paradigm. Plans
made in this way and adjusted by
linear feedback methods cannot
cope with the multiple interacting
and continuously changing tech-
nology and market forces.
The success rate of applying
traditional methods to com-
plex software development proj-
ects over the years has been
underwhelming. There are a num-
ber of critical issues with IT proj-
ects that suggest better attention
to implementation procedures as
well as to management processes
to deal with change is needed.
These approaches start by avoid-
ing the application of linear
processes found lacking from
past experience.4
The impact on a project from
external forces or from problems
within the project is given little
attention in the linear approach
[16]. Avoiding or controlling
change is the primary activity. In
this traditional model, “change” is
undesirable; however, in reality,
change in the world of business
systems is natural as well as desir-
able. A gap arises when the differ-
ence between managing in the
presence of change and managing
change is not understood. Agile
project management uses risk
and opportunity management to
create practices that proactively
and explicitly manage in the
presence of change [1, 14].
Issues identified in several studies
that increase the likelihood of fail-
ure for IT projects are shown in
Table 1 [7]. Agile program man-
agement establishes a culture and
framework to deal with these and
other issues. Connecting strategy
with execution identifies capabili-
ties that are required to fulfill the
strategy, significant accomplish-
ments that must be performed
along the way to delivering these
capabilities, and the criteria by
which these accomplishments
can be assessed to ensure that the
increasing maturity of the capabili-
ties fulfills the enterprise strategy.
Closing the Execution Gap with
Agile Program Management
Principles
A study of 72 IT firms revealed
several attributes of project man-
agement critical to connecting
strategy with execution, as out-
lined below [3, 7]:
Scope, time, and quality —
continuous assessment and
evaluation of scope and quality
through fine-grained feedback
allows intervention before bud-
get or time overruns appear.
Cost, quality, and human
resource management —
determine the adherence to
a project budget at a specific
point in time to maintain the
connection between the plan
and budget.
Scope, quality, and cost
management — determine
the project’s adherence to
time delivery. Scope could be
seen as a significant factor in
©2005 CUTTER CONSORTIUM VOL. 6, NO. 9
EXECUTIVE REPORT 33
2For example, Extreme Programming (XP),
Scrum, Crystal, and Dynamic System
Development Method (DSDM).
3In these models, it is assumed that each
phase of the project is completed in a fixed
sequence, followed by the next logical step
in the sequence.
4Linear project management models are
sometimes referred to as waterfall models.

affecting the ability of the proj-
ect to deliver on time. Scope
creep is a common reason for
late delivery.
Time and cost management
— determine a project’s
adherence to scope delivery.
Time and cost management
lead to a project’s completion
on scope; this is due to the
extra cost associated with
producing more features in
a project.
From these research results, dif-
ferences between traditional and
agile project and program man-
agement emerge, as shown in
Table 2. These differences appear
trivial at first, but they are critical
to understanding how agile pro-
gram management methods
address the identified problem —
the delivery of value to the IT
project management process.
Traditional project management
methods have failed to deliver on
the promise of success as shown
in numerous research, anecdotal,
and experience reports.
Traditional Methods Agile Methods
Planning drives results.
Delivery focused on
planned results.
Defined process steps.
Progress measured by
the passage of time.
Quality measured at the
point of delivery.
Results drive planning.
Delivery focused on
assessable results.
Self-organizing process
steps.
Progress measured by
increasing maturity.
Quality measured on
continuous fine-grained
boundaries.
Table 2 — From the attributes of project management, differences between
traditional and agile program management emerge.
Failure Modes for IT Projects Traditional Approach Agile Approach
Absence of a clear vision and
statement of program’s
requirements.
A statement of work, work
breakdown structure (WBS), or
requirements specification.
Extract initiatives from strategy
through capabilities, followed by
initiatives, then portfolios, then
projects.
Unrealistic expectations due
to estimating difficulties and
organizational politics.
Project plans, organizational
breakdown structure (OBS),
responsibility assignment
matrix (RAM).
Gain consensus on the needed
capabilities, defined through
program events, significant
accomplishment, and
accomplishment criteria.
Lack of program decomposition
to the project level.
WBSs decompose work elements
into a hierarchy of elements.
Incremental capabilities emerge
from the iterative assessment of
customer needs.
Inadequate staffing policies and
team conflict.
Resource allocation is applied to
the work products to create a
staffing plan.
Define skills and experience for
each significant accomplishment
and the collection of tasks needed
to deliver this accomplishment.
Lack of stakeholder involvement
and focus.
Formal specifications, interface
control documents, and “contracts”
are used to control requirements
variance.
Define the stakeholder input
needed to deliver the significant
accomplishments.
Lack of strategic focus and
executive management support.
Features and functions are derived
from specifications.
Capabilities derived from strategic
objectives provide the basis to deal
with changing and emerging
requirements.
Table 1 — IT project failure modes can be addressed in traditional and agile ways. Although the traditional
approaches can lead to success, they have difficulties operating in the presence of changing requirements.

As a result of the differences
between traditional and agile
program management methods,
five principles of agile program
management emerge (vision,
value, decisions, people, and
results — see Table 3). The prac-
tices associated with these princi-
ples are general-purpose project
management methods found in
various industries and are not by
themselves unique to agile pro-
gram management.
These five principles are both obvi-
ous and subtle. Obvious because
they’ve been heard before. Subtle
because the practices that deliver
on the promise of the principles
start with the integrated whole and
work outward to the deliverables,
rather than starting with a set of
constraints — rules — and working
inward. This “principles in place of
rules” approach removes the con-
straints of command and control
and replaces them with the mech-
anisms needed to turn constant
change into opportunity [20].
A LAYERED APPROACH TO
MANAGING IT PROGRAMS
Four components of agile program
management — strategy, portfo-
lios, capabilities, and integrated
master scheduling — interact
through value streams that
“inform” the decisions that must
be made within and between
each “area of concern.”
These informing activities, listed
below, take place through the
processes of agile program
management:
1. Balanced scorecard —
informs portfolio management
about the needed initiatives
for strategy fulfillment
2. Portfolio management —
informs capabilities-based
planning about what capabili-
ties are needed to fulfill the
strategy
3. Integrated master scheduling
— informs the program of the
increasing maturity goals for
each capability that supports
the strategy
These three informing activities
are the core practices and support
the value delivered from agile
program management principles
shown in Table 4.
PRINCIPLES OF AGILE
PROGRAM MANAGEMENT
The role of principles is to provide
a set of balancing forces that
allow a system — in this case a
system of IT projects — to reach
equilibrium. Figure 2 shows the
interaction between the five
principles of agile program
management.
Vision
If you tell people where to
go, but not how to get there,
you’ll be amazed at the
results.
— US General
George S. Patton
Strategy is derived from vision.
Famous vision statements include
US President John F. Kennedy’s 25
EXECUTIVE REPORT 55
What does the future hold?Vision
Value
Decision
People
Results
Why are we doing this?
How do we decide what to do?
Who is going to do the work?
What does “done” look like?
Table 3 — The five principles of agile program management provide a holistic
approach to managing complex projects by connecting products and services
with the processes to produce them.
The balanced scorecard provides the starting point for measurable outcomes
in support of mission and vision.
Project portfolio management provides the collecting point where projects
are assessed for the support of strategy.
Capabilities-based planning defines the capabilities needed to fulfill the
strategic initiatives.
Integrated master schedule defines how the increasing maturity of each
project will be assessed to ensure it meets the strategic goals.
Agile program management is composed of four core processes that operate in
harmony to deliver increased value to IT stakeholders.

May 1961 challenge to reach and
return from the moon “before
this decade is out” [17] and US
President Thomas Jefferson’s
vision “of a great nation that would
stretch from sea to sea” [2].
IT programs are unlikely to
be launched with such grand
visions. A vision is still necessary;
otherwise, tools like the balanced
scorecard will have no source
for their initiatives, portfolios,
and programs.
It is important to separate vision
from mission [5]. The mission
statement describes the business
and its relationships with cus-
tomers. The mission statement
Principle Test Question Agile Practice in Support of Principle
1. Vision What will the system look like when it’s
complete?
What does “done” look like?
How can we measure “done”?
Balanced scorecard defines the strategic
business outcomes — objectives — to be
delivered by a portfolio of operational projects.
5. Result
2. Value
3. Decision
4. People
How will we recognize that our investment
has been returned?
What are the units of measure of “value”?
Who defines these units?
How are they recorded?
What selections and decision must be
made to create the needed capabilities?
What is the trade space for these decisions?
What trades are fixed?
What trades are variable?
Who are the people and skills needed to
ensure success?
How are we organized to deal with change
and uncertainty?
What processes are in place to manage
in the presence of change?
What are the units of measure and their
value that describe success?
How is value defined?
What capabilities are needed to deliver
this value?
How is this value supportive of strategy?
Capabilities create value through the balanced
scorecard objectives. Portfolios of projects
deliver these capabilities. Business value is
assigned in units of measure meaningful to
the business.
Capabilities-based planning is used to
decipher the intent of the scorecard initiative,
selecting projects by their contribution to the
strategic objectives.
Define the skills and experience needed to
deliver the significant accomplishments.
Ensure that increasing capabilities are
delivered by the portfolio initiatives and key
performance indicators of the balanced
scorecard through the delivery of value at
each maturity event.
Table 4 — Principles of agile program management and the associated practice frameworks form the foundation
of a set of methodologies, actionable outcomes, and performance measurement metrics for successfully connecting
strategy with execution.
People
Value
Results
VisionVision
Decision
Figure 2 — The five principles of agile program management can be
arranged to convey the feeling of continuous motion, interaction, and
support of a vision.

moves the strategic planning
process from the present into the
future. Not only must the mission
statement work today but it also
must be capable of evolving over
the life of the strategy.
The mission statement must be
broad enough to allow for the
diversity required by the business
but narrow enough to be action-
able. The mission statement must
be treated as a tool not a solution,
since it rarely does anything tangi-
ble for the organization. Mission
statements should be crafted to
focus on the day-to-day accom-
plishments of work.
In contrast, the vision statement is
about the future. The vision state-
ment is a dream, an aspiration, a
statement about what is hoped
to be accomplished. The vision
should convey a compelling story
about the future.
For example, consider CEO and
Cofounder of Apple Steve Jobs’
vision: “An Apple on every desk.”
At the time there wasn’t then an
Apple on every desk. There will
not likely ever be an Apple on
every desk. But it’s still a great
vision.
Agile program management starts
with a vision for the IT programs.
Crafting this statement requires
care and concern for the message
conveyed since the vision lays
the groundwork for strategy,
capabilities, and ultimately the
reason for execution and the
resulting operational processes.
From a vision statement, value,
decisions, the right people, results,
and ultimately the closure between
strategy and execution can be
derived (see Table 5). The vision
statement is the source of what
done looks like — it is the purpose
of the portfolio of projects, the
defined capabilities, the accom-
plishments, and their criteria.
Value
The term “value” is often used in
the discussion of agile without
a specific context or definition.
While this provides the means to
explore concepts, it is less than
satisfying for a program manager
tasked with shepherding a collec-
tion of projects through the gaunt-
let of corporate management.
Turning principles into practice
starts with the definition of value.
The first bullet of the Declaration
of Interdependence5 says: “We
increase return on investment by
making continuous flow of value
our focus.”
In agile program management,
value has monetary units of
measure: cost of goods sold,
product cost structure, gross
margin, operational efficiency,
earned value, bookable saves,
capital utilization, economic value
added, resource effectiveness,
and brand leverage.
This forces the value discussion to
become concrete for those most
interested in measuring value —
the customers, stakeholders, and
funding agencies.
Decision
Each element of agile program
management involves a decision-
making process. Project portfolio
management makes investment
tradeoffs, hedges risk, selects from
the available options, and discov-
ers new options to add to the port-
folio. Integrated master scheduling6
makes continuous decisions based
on project performance. Significant
accomplishments are assessed for
completion. The accomplishment
criteria are assessed for compli-
ance to the increasing maturity
goals. Capabilities-based planning
selects the needed capabilities,
EXECUTIVE REPORT 77
Mission Action Vision Results of Action
What is the organization about?
• What do we do?
• Who we do it for?
• What is the benefit?
What does the organization want
to become?
• What are the results of our actions?
• If we achieve our mission what will
the future look like?
Table 5 — Mission versus vision.
5www.pmdeclarationofinterdependence.org
6The concept of a master plan is derived from
“event based planning,” where the increasing
maturity of a program is the primary measure
of progress. This approach assures the need-
ed capabilities emerge from the portfolio
of projects to match the strategic initiatives
selected to fulfill the strategic objectives of
the balanced scorecard.

their order of deployment, and
assesses their contribution to
the strategic objectives, thereby
closing the loop between strategy
and execution.
People
You cannot have an execu-
tion culture without robust
dialog — one that brings
reality to the surface
through openness, candor,
and informality. Intense
debate brings up all sides of
an issue, even if it makes
people uncomfortable.
— Larry Bossidy, Execution:
The Discipline of Getting
Things Done [6]
People are the raw material for
teams, not just for agile program
management teams but for almost
every human-based endeavor. But
teams need a framework in which
to work. This is obvious but many
times gets lost when discussing
agile processes. No matter the
approach, success comes to those
with skill, those who are daring,
and a bounding framework.7
There are two schools of thought
on how to improve the execu-
tion of teams. One school
emphasizes people, while the
other emphasizes process. The
people school has two divisions.
Get the best people (“A” players),
put them on the toughest prob-
lems, and incent them to perform
[9]. The other approach believes
if you improve the average
employee, the whole organization
will improve.
The second school emphasizes
process and starts with the
assumption that firms don’t inten-
tionally “hire bad people,” so a
framework in which to work is
needed [6].
At the program level and above,
the choice of a people focus or
a process focus is not between
two competing paradigms. They
are two sides of the same coin.
Research shows firms using both
approaches deliver better results.
Attention to both people and
process produces superior results,
while focus on one or the other
ignores the underlying issues
from the missing element. The
approach for increasing the per-
formance of people outside the
small group level includes:
Developing a model for execu-
tion that fits the culture, skills,
needs, and capabilities of the
participants of the initiatives
being managed by the program
Choosing the right metrics for
the program and projects:
metrics that connect strategy
with execution and measure
the increasing maturity of the
identified capabilities
Planning is not “plan and
forget” but an ongoing dynamic
activity that peers into the
future for indications as to
where a solution may emerge
and treats the plan as a com-
plex situation, adapting to an
emerging solution8
Conducting continuous perfor-
mance assessment by meas-
uring the right thing: “real time”
performance measurement
as a natural artifact of agile
processes
Communicating the elements
of the strategy, initiatives,
capabilities, programs, and
projects up and down the
execution chain
Results
There is nothing more diffi-
cult to take in hand, more
perilous to conduct, or
more uncertain in its success
than to take the lead in the
introduction of a new order
of things.
— Niccolo Machiavelli,
The Prince (1532)
In many principle-centered
approaches to agile, results are
implicit and at times left to the
7In 1992, Honeywell’s defense avionics division in Albuquerque, New Mexico, USA reorganized
its entire 1,800-person business unit into multifunctional teams. Division management searched
among its supervisors for people who could facilitate loyalty, communication, and decision mak-
ing within a group and complete the change in six months. According to the division’s general
manager, senior management “took a ‘burn the bridge’ approach because we wanted people to
know we were serious. If we hadn’t made a big fuss, this would have died a natural death.” One
of the successful teams developed a data storage system for Northrop Grumman’s B-2 bomber.
The team leader managed the group by taking actions that created team loyalty and focused its
effort on the Air Force’s needs. The leader saw his job as helping the team “feel as if they owned
the project by getting whatever information, financial or otherwise, they needed. I knew that if
we could all charge the hill together, we would be successful” [8].
8This idea, used with permission, comes
from my colleague Mike Dwyer, IT
program manager, American Healthways,
Westborough, Massachusetts, USA.

end. The means for reaching
these results are presented first.
Agile program management
starts with the results — what
does done look like?
Putting the principle of value into
practice demands that results be
described in the units of measure
defined by the stakeholders, not
the supplier. A critical aspect of
these units is they must come in
small packages with 0% or 100%
completion. No partial deliveries,
no partial done.
DETAILS OF THE AGILE
PROGRAM MANAGEMENT
COMPONENTS
Agile program management is an
integrated approach that connects
IT strategy with execution. Some
of the definitions of program man-
agement are applicable to the
agile management approach
described here, as listed below:
The coordinated management
of a portfolio of projects to
achieve a set of business
objectives
The directing of a portfolio of
projects that benefit from a
consolidated management
approach
The management of a portfolio
of projects toward one specific
objective
The coordinated support,
planning, prioritization, and
monitoring of projects to meet
changing business needs
The planning and monitoring
of a number of simultaneous
related projects
Program Offices Deliver Program
Management Services
A program management office
has two primary missions: manag-
ing a portfolio of projects through
articulated programs and manag-
ing those individual projects at
their performance interface, not
their technical interface. These
missions are carried out through
two primary activities, governed
by a set of flexible processes,
as follows:
1. Strategic-level planning
and program development —
provides long-range planning
and a roadmap for developing
IT projects that benefit the
organization, its customers,
and shareholders. Program
management activities build
the business case for programs,
including cost estimates
and measurable goals and
objectives.
2. Tactical management
of selected programs —
depending on the size of the
program, either a single project
manager or a team is assigned
to the functional department
through final delivery and post-
project activities.
Agile as a verb describes
maneuverability, quickness, light-
footedness, and adaptation to
change without undesirable
impacts on the performance of
the collection of projects that
make up the program.
Agile program management is
about applying the principles of
agile to the activities of program
management (vision, value, deci-
sion, people, and results). This is
not enough though, since specific
practices to deliver these princi-
ples must be in place before they
can be considered operational
principles.
More Difficulties with Traditional
Approaches and a Solution
Traditional approaches to manag-
ing IT projects start with identify-
ing the tasks and milestones that
need to be performed, assigning
resources and budget, and moni-
toring the performance of the
work for compliance within the
EXECUTIVE REPORT 99
Line-of-sight connection from strategy to execution is the basis of a strategy-
focused organization.
The units of measure for project performance are derived from the balanced
scorecard.
Capabilities needed to implement strategy are identified rather than features
and functions.
Agile program management transforms IT strategy into portfolios of projects
that implement initiatives that deliver the required capabilities in support of
the strategy.

error bounds of cost, quality, and
schedule.
Agile program management con-
nects strategy and execution by
assembling portfolios of projects.
The performance of the projects
and the programs they support is
managed through an integrated
master schedule, where the
increasing maturity of the business
capabilities is assessed. The deliv-
ery of significant accomplishments
and assessment of accomplish-
ment criteria are the units of
measure for this increasing matu-
rity rather than the passage of
time, arrival at a milestone, or con-
sumption of resources or budget.
The Value Proposition for Agile
Program Management
closes the gap between strategy
and execution through the follow-
ing value propositions:
connects each strategic
objective to a project or pro-
gram deliverable. This con-
nects project performance
to strategy fulfillment and
measures progress through
accomplishments rather than
through the passage of time.
This approach connects deliv-
erables to strategy fulfillment,
closing the loop on the returns
from IT investments and pro-
viding a business strategy con-
nection with technical
management.
focuses on a risk and opportu-
nity management paradigm
using portfolio management
processes to address uncer-
tainty by making explicit the
potential losses (risks) and
potential gains (opportunities)
[21]. These risk and opportu-
nity management processes
are integrated into a single
management process — agile
program management.
provides a clear and actionable
path between strategy and exe-
cution. This ensures that the
connection between strategy
and execution can adapt to the
changing needs of the enter-
prise. It defines and maintains
a performance baseline of all IT
development and deployment
efforts. Key decision points —
on fine-grained boundaries —
assess progress, alter execu-
tion, and adapt to changing
needs. It defines a framework
for establishing the program
management functions to
deliver value to the stakeholder
making visible all work activi-
ties, their increasing maturity,
and measurable connection
to strategy.
BALANCED SCORECARD AS
A STARTING POINT FOR AGILE
PROGRAM MANAGEMENT
Traditional measures are insuffi-
cient to gauge performance
and guide organizations in an
enterprise’s rapidly changing,
complex economic landscape.
Organizations must link perfor-
mance measurement to strategy
and measure performance in
ways that both promote positive
future results and reflect past
performance.
The balanced scorecard is a
proven performance meas-
urement system [7]. It is a
comprehensive strategic perfor-
mance management system and
methodology. It is a framework
for defining, refining, and commu-
nicating strategy, for translating
strategy into operational terms,
and for measuring the effective-
ness of strategy implementation.
Elements of the Balanced Scorecard
The balanced scorecard describes
and communicates the strategies
of the organization, selecting the
Aligning IT strategy with execution is not a state but a process that is not
always predictable, rational, or well planned.
Alignment requires procedures but also a continuing process that can hold
the course for long periods of time.
This approach requires a framework and starts with strategy but includes
assessments of progress based on increasing maturity, not just the
passage time.
Balanced scorecard defines the objectives and initiatives needed to fulfill the
business mission and vision.

performance metrics that drive
strategy. David Norton describes
the balanced scorecard as follows:
A balanced scorecard is a
system of linked objectives,
measures, targets, and initia-
tives, which collectively
describe the strategy of an
organization and how the
strategy can be achieved.
It can take something as
complicated and frequently
nebulous as strategy and
translate it into something
that is specific and can be
understood. [15]
The balanced scorecard describes
strategy and performance man-
agement from four perspectives:
financial, customer, process, and
learning and growth (see Table 6).
Each strategy perspective asks
and answers a key question
about objectives. Performance is
judged by the progress in achiev-
ing these objectives. There is a
causal relationship between the
perspectives: good performance
in the learning and growth objec-
tives can drive improvements in
the internal business process
objectives, which should improve
the organization from the view of
the customer, leading to improved
financial objectives.
Connecting strategy with action-
able outcomes means defining a
capability, not just the physical
availability of a feature of the
product or service. A capability
answers the question: What can
be done with these features to fur-
ther the business strategy? This
approach provides the basis of
agility through the following
mechanisms:
The strategic connections
flow through the description
of the needed capabilities of
the business to the portfolios
of projects to the specific
deliverables.
The performance of the portfo-
lio and the individual projects
flow backward to the key per-
formance indicators (KPI) of
the strategy. These provide
an unambiguous view of the
overall performance of the
short- and long-term strategies.
The KPIs should support the
targets for success that clearly
quantify the desired level of
performance necessary for
success of the organization.
Connecting the balanced
scorecard KPIs with increasing
maturity of the projects in
the portfolio closes the gap
between strategy and
execution.
Objectives and Measures
Promises, schedules and
estimates are important
instruments in a well-run
business. You must make
promises — don’t lean on
the often used phrase: “I
can’t estimate it because it
EXECUTIVE REPORT 1111
Balanced
Scorecard
Perspective
Key Question Connection to Agile Program Management
Financial
Customer
Process
Learning
and Growth
To succeed financially, how
should we appear to our
stakeholders?
To achieve our vision, how
should we appear to our
customers?
To satisfy our customers and
shareholders, at what business
processes must we excel?
To achieve our vision, how will
we sustain our ability to change
and improve?
• IT budget performance describe the value delivered
for the investment.
• Utilization of resources for invested cost.
• What do the customers need to fulfill their strategy?
• How will the customers recognize that IT is fulfilling
their strategy?
• What are the units of measure?
• How can these processes be deployed with the least
impact on performance?
• For each process, when does it pay back its investment?
• How can we manage the people side of programs while
increasing the value to the customers?
Table 6 — Balanced scorecard perspectives.

depends on many uncer-
tainty factors.”
—William H. Swanson,
Swanson’s Unwritten Rules
of Management, 2005,
Raytheon Company
Objectives are desired outcomes.
They must be specific; they must
be measurable in terms meaning-
ful to the stakeholders; they
must be achievable and realistic;
and they must be time bound.
Objectives must be deliverables-
based and stated as:
Business objectives — in
units of measure agreed on by
the project manager and the
stakeholder
Project objectives — in units
of scope: features, functions,
technical performance meas-
ures, and increasing maturity
Success objectives — in units
of accomplishment: capabili-
ties delivered in support of a
strategic objective
Progress toward attaining an
objective is gauged by one or
more measures. As with perspec-
tives, there are causal relation-
ships between objectives. A
causal relationship is defined by
dependencies among objectives.
It is critical to set measurable,
strategically relevant, consistent,
time-delineated objectives.
Measures are the indicators
of how a business is perform-
ing relative to its strategic objec-
tives. Measures, or metrics, are
quantifiable performance state-
ments. As such, they must be:
Relevant to the objective and
strategy
Placed in context of a target to
be reached in an identified
time frame
Capable of being trended
Owned by a designated person
or group who has the ability to
impact those measures
What Is Strategy and Why Is It
Important to Agile Program
Management?
Strategy is creating fit among a
company’s activities. IT strategy
creates fit using IT systems. The
success of a strategy depends on
doing many things — not just a
few — well. The things that are
done well must operate within a
close-knit system. If there is no fit
among the activities, there is no
distinctive strategy and little to
sustain the strategic deployment
process. Management then reverts
to the simpler task of overseeing
independent functions. When this
occurs, operational effectiveness
determines the relative perfor-
mance of the organization [24,
25].
Managers must distinguish
between operational effectiveness
and strategy. Both are essential,
but the two agendas are different.
Operational effectiveness involves
the continual improvement of
business processes that have no
associated tradeoffs. Operational
effectiveness is the proper place
for constant change, flexibility,
and relentless efforts to achieve
best practices. The strategic
agenda is the place for making
clear tradeoffs and tightening
the fit between the participating
business components. Strategy
involves the continual search for
ways to reinforce and extend the
company’s position in the market
place and the systems that enable
these improvements.
The concept of fit among func-
tional units is one of the oldest
ideas in strategy. It has been
supplanted with new concepts
of core competencies, critical
resources, and key success fac-
tors. In fact, fit is far more critical
to the success of the IT systems
than is realized. Strategic fit
among the IT system components
and the business processes they
support is fundamental not only
to competitive advantage but
also to the sustainability of that
advantage.
Connecting strategy with execu-
tion starts with identifying which
objectives are used to construct
a collection of projects in a port-
folio. The challenge is to create
fit among the IT components
and their matching business
components traceable to the
performance of the business
processes and the investments
in technology.
Agile project management pro-
vides the “glue” between strategy
and execution. Starting with the
balanced scorecard, it translates a

vision into strategy by focusing on
shareholder, customer, internal,
and learning requirements, which
collectively describe the strategy
of the organization and how this
strategy can be achieved.
Alignment with Strategy Is
a Continuous Process
Getting “aligned” is not an event;
it is a continuous improvement
process. Alignment must be tested
through strategies, objectives, and
portfolio performance metrics.
Alignment starts with a busi-
ness leadership team with a
capability to:
Build consensus and commit-
ment around the strategy
Participate in the strategy
formulation
Understand the benefits of a
strategy-focused organization
Demonstrate the power of an
IT strategy to the stakeholders
Require participation and stew-
ardship from all stakeholders
Before IT projects can be identi-
fied to fulfill the strategic needs
of the firm, an understanding of
their performance measures, their
connection to strategy, and their
past performance is needed.
Project portfolio management is
the means to address needs of
the capabilities required by busi-
ness leadership. These capabili-
ties form the basis of the value
delivery system by ensuring the
following:
Project delivery is more
than schedule and budget
compliance.
Projects must deliver the right
value to the business processes
at the right time for the right
solution — creating “value”
not just benefits.
Value comes from booking the
benefits on a balance sheet.
Value is visible to the market
and customers.
The “value creation” process
is more than just “keeping on
schedule.” It is about under-
standing the business needs.
Understanding comes from
“knowing” the business beyond
specifying the technical details
of a software system.
The IT leader becomes an
integral part of the process
development paradigm.
Four Components of IT Strategy
Connecting strategy with execu-
tion means discovering the
hypothesis of a strategy — the
business strategies that must be
tested — and constructing busi-
ness systems to implement these
strategies and the associated tests.
Sample strategy-testing hypothe-
ses might be:
If a firm provides training to
the customer service staff, then
it will instill the skills needed
to develop an up-selling oppor-
tunity with its customers.
If a firm delivers products faster
to the marketplace than its
competitors, then it would
expect an increase in customer
awareness of these products.
If a firm has identified more
potential customers, then it
can expect increased sales
and a great return on equity.
Four components of IT strategy,
listed below, must be considered
in agile program management.
Each strategy element must
be addressed in the following
processes: capabilities-based
planning; integrated master
scheduling, and uncertainty
management. The four elements
of IT strategy are:
1. Organizational strategy — the
organizational structure of the
various business units, how
they interact, the named partic-
ipants in each organization,
and the informal behind-the-
scenes participants
2. Information system strategy
— the behavioral aspects of
the system that support, pro-
mote, or enhance the business
activities
3. Information technology
strategy — the actual comput-
ing systems, their architectures,
operation, and maintenance;
although focused on the physi-
cal technology, the acquisition,
installation, and deployment of
these technologies is a critical
component of the IT strategy
4. Information management
strategy — the creation,
management, and use of

information; this information
is usually in the form of data-
base contents and the work
processes built around them
These IT strategy components are
based on the physical and logical
technologies of the IT infrastruc-
ture, the value of the data man-
aged by the infrastructure, and
the consumption of this data.
These components describe: how,
what, when, and where the tech-
nology of the IT strategy is to be
deployed. In order to complete
the IT strategy, the influences of
these technologies on the organi-
zational aspects of the business
must be understood. The ques-
tions asked and answered while
developing the strategy include:
What IT applications should be
deployed to provide a needed
capability?
What technological opportuni-
ties should be considered?
What IT platforms should be
deployed, and what IT policies
are needed to manage these
platforms?
Which capabilities should be
nurtured, and which should be
acquired from outside sources?
How should IT activities be
organized, and what is the role
of the IT function?
What is management’s role in
the IT domain, and what IT
capabilities are required for
today’s managers?
AGILE PROJECT PORTFOLIO
MANAGEMENT
Project portfolio management is
the means of aligning implemen-
tation projects that deliver busi-
ness value with strategy.
Several gaps appear between
the formation of strategy and
the eventual delivery of systems
to the users. In traditional IT man-
agement, technology and business
are readily visible to senior man-
agement. What’s missing is visibil-
ity into the activities in the “white
space” between technology and
business. Managing these gaps
is the role of IT governance.
Consider the following types
of gaps:
Alignment gap — appears
when IT investments are not
traceable to business strategy
Execution gap — appears
when those tasked with deliv-
ering IT products and services
don’t have a clear “line of
sight” to the corporate strategy
Innovation gap — appears
when IT leadership and staff
are not connected to the needs
of the market, emerging tech-
nologies, and the investment
strategies for future needs
Increasing Maturity Is an Agile
Approach to Deployment
Rarely does a collection of proj-
ects provide its solution in a big
bang manner — in which the
technology and business value
is available in one day. Instead,
agile projects provide a set of
business capabilities whose matu-
rity increases over time. At each
point along the maturity curve,
these capabilities are assessed
against each of the business
strategy measures.
One approach assumes that as
time passes these capabilities
mature. An approach better
matched to agile program man-
agement measures the increasing
maturity through the technical
performance of each capability
resulting from the efforts of
the project. These technical
performance measures provide
the quantifiable means to meas-
ure progress, rather than just the
passage of time.9
Selection, assessment, and performance management of portfolios is the
starting process for connecting strategy with execution.
Membership in a portfolio requires a project be directly traceable to a
strategic objective.
The management of portfolios of projects provides the “glue” between strategy
and the operational benefits to the organization.
9Projects in which the passage of time is the
measure of progress are called “level of
effort.” The fundamental problem with
level-of-effort management is that it does
not measure performance of the project,
just the passage of time.

Direct Benefits of Agile Project
Portfolio Management
Agile project portfolio manage-
ment allows you to:
Serve clients better by monitor-
ing and reporting on projects
Establish credible project
screening and selection
processes to provide decision
support for the portfolio man-
agement team
Raise visibility of projects and
their progress by creating an
easily accessible repository
for project and program
information
Institute simple, repeatable,
and sustainable processes
to better manage the delivery
of valuable solutions on behalf
of clients
Provide long-range planning for
a stream of projects, enabling
IT to better plan its staffing,
resources, and schedule
Performance-Based Measures
for Portfolios of Projects
Perhaps the most important
reality is that despite what the
statistics say about average
returns on IT investment, each
manager must decide which
projects are worthwhile. There is
no bank where an IT department
can deposit IT investments and
withdraw an average return.
Three Erroneous Assumptions of
Traditional Project Management
In order to connect the perfor-
mance measures of a portfolio
of projects with the actual delivery
of that performance to the firm,
three erroneous assumptions of
project management must be
made visible and must be dealt
with. Using the traditional linear
phase-centric approach to project
management, the following three
assumptions emerge and nega-
tively impact a portfolio’s ability
to deliver value:
1. Planning. It is assumed that it
is possible to produce a plan
so that its implementation is
merely a matter of executing a
defined set of tasks in a prede-
fined order. In fact, planning is
a continuous process whose
changes are driven by the deliv-
ery of software into the hands
of the users.
2. Change. It is assumed that
changes can be stabilized early
in the process. The concept
that change must be avoided
— somehow “controlled”
through management
processes — ignores the
source of most creative solu-
tions in the software develop-
ment domain. Business and
external market forces usually
drive late changes and are a
natural part of the business
cycle.
3. Stability. It is assumed that
management can be given
a plan to which it can com-
mit. In fact, by making this
commitment, management
gives up the ability to take
advantage of fortuitous
developments in the business
and technology environment.
The traditional project manage-
ment approach is based primarily
on “normative” and “rational”
methods that make use of
processes known to work. These
methods can be conveyed through
standards and bodies of knowl-
edge. They are independent of any
specific application of this knowl-
edge — that is, they are domain-
independent. Finally, they assume
the underlying processes are sta-
ble and not impacted by the very
efforts they are trying to manage.
One final aspect of the “normal-
science” project management
method is the overwhelming
emphasis on “planning-as-
management” paradigm. This
paradigm creates several myths,
including the following [3, 4]:
Clear-cut investment opportu-
nities exist with an explicit pur-
pose; the beginning, duration,
and end can be identified early
in the project.
Low opportunity costs for each
business or technical decision
exist, in most instances with a
reversible decision process.
Feasible, suitable, and accept-
able project attributes can be
identified early in its lifecycle.
Accurate predictions of proj-
ect duration and resource
demands are possible once
the requirements have been
defined.

Worst-case consequences can
be determined well in advance,
and clear-cut mitigations can
be created.
The failure of the project was
due to lack of technical and
managerial skills rather than
inappropriate feasibility, suit-
ability, or acceptability of the
solution.
The Next Phase of Agile Program
Management: Planning the Work
Plans are nothing; planning
is everything.
— US President Dwight W.
Eisenhower, quoting 19th
century Prussian General
Helmuth von Moltke
One approach is to broaden
the set of project management
methods in some higher-level
context. One place to start is to
acknowledge that the normative
knowledge in the various bodies
of knowledge has value but by
itself is not sufficient in the soft-
ware development domain.
This kind of knowledge can be
classified as transformational. It
describes how to transform inputs
into outputs; requirements into
requirements specifications; test
plans into testing; progress to plan
data into planning adjustments;
and so on. This view has its ori-
gins in economics as popularized
by Michael Porter’s Competitive
Advantage (Free Press, 1985).
There are problems with this
transformational approach to proj-
ect management, not the least of
which is the fact that it is not the
transformation itself that makes it
valuable, but its conformance to
the stakeholders requirements.
Defining value-creating activities is
not provided by normative meth-
ods. The normative approach
provides very little direction in
defining what not to do during the
work process, preventing the min-
imization of time and resources.
Another approach is to see project
management as a flow process
that eliminates waste and reduces
lead time and variability — all
agile program management activi-
ties. Just-in-time manufacturing is
one example of flow-based proj-
ect management.
A third approach is the value-
generation paradigm. Here,
delivering the best value to the
customer is the focus. In software
development, value is defined by
the customers rather than the
designers of the software. Full
participation of the customer in
this value-defining process is
critical to the success of many
agile development processes.10
This transformation, flow, value
model is based on the work of
Koskela in the domain of lean
construction [19].
Agile program management inte-
grates four concurrent processes
(strategies, portfolios, capabilities,
and plans) to address the gaps in
the traditional approach to pro-
gram management and IT project
deployment, as shown in Table 7.
The theme here is to build a con-
nection between each process
paradigm for delivering IT proj-
ects to the stakeholders, not just
imposing each methodology on
the project during a phase or a
separate step in a program.
This is not a single methodology
but a collection of principles and
practices — each supporting the
others, each necessary for the
success of the program.
CAPABILITIES-BASED
PLANNING
Capabilities-based planning fits
naturally with balanced score-
card strategy, business process
improvement, and agile program
management (see Figure 3).
Capabilities provide a defined out-
come that is not a final conclusion
but lays the groundwork for the
continued delivery of value [25].
Objectives are reached and the
operational value delivered when
a defined capability is available
for use. Features and functions
describe the static and dynamic
behaviors of a system, but they
10One sidebar discussion among the normative body of knowledge adherents is that software
development methods like Rational Unified Process (RUP), DSDM, Scrum, and XP are not proj-
ect management methods, but software development methods. To the software development
manager, this appears to be an artificial and unnecessary distinction. Getting software out the
door that meets the needs of customers is the “management” goal. The “purity” of what is
a method and what is a practice is irrelevant at the level of the software development team.
Where it is important is the next level up in the organization — at the project portfolio, program,
and product level.

are not directly connected to the
business strategy. Milestones
indicate that a position in a time-
line has been reached.
Capabilities provide the answer to
the following question: In order to
achieve our objectives, what
capability must be possessed?
Capabilities-based planning trans-
forms the delivery of features and
functions into delivery processes
that support strategy in the pres-
ence of risk. Capabilities-based
planning is planning, under the
conditions of uncertainty, to
provide capabilities suitable for a
wide range of business challenges
and circumstances, while working
within an economic framework.
This approach emphasizes flexi-
bility, adaptiveness, and robust
capabilities, implying a modular
building-block approach to the
delivery of enterprise applications.
When transformation takes place
it is because new modules have
come into use.
Capabilities are not the same
as features and functions (they
enable demands to be met with-
out explicit specification of the
solution). A capability is the ability
to affect an outcome, react to
an input, or change an effect.
Consider the following example
of a before and after statement:
Before (features and func-
tions). We will install the gen-
eral ledger and operate it in
all financial centers by fall of
2006. With these features
and functions comes a set of
abilities, but they are not made
explicit.
After (capability). We will
be capable of acquiring a
US $100 million business in
less than 90 days. With the
capabilities explicitly stated,
the invested effort and cost
can be directly connected to
the strategic objectives for
mergers and acquisitions.
Principle Outcome of the Principle
Practice to Implement
the Principle
Strategies
Portfolios
Capabilities
Plans
Define the desired outcome.
Manage the delivery of capabilities.
Enable the strategy.
Manage the delivery effort.
Balanced scorecard
Project portfolio management
Capabilities-based planning
Event-based scheduling
Table 7 — Four processes to address gaps in traditional approach to
program management.
Tracing value to strategy requires that features and functions be replaced
by capabilities.
Capabilities lay the groundwork for adapting to change.
Features and functions fulfill the stated requirements from the past.
Capabilities fulfill the unstated requirements of the future.
The capabilities needed to deliver value in support of a strategy replaces the
simple delivery of features and functions.
Scenarios Work tasks Capabilities
The business units
operational needs
in scenario terms:
The individual work
processes needed to
fulfill the scenarios:
The planned capability
of the business units
at each level of maturity:
• Merge a general ledger
from a third-party database
through a data conversation
process
1. Define the data to be
acquired from the
new firm
2. Verify that data
conversation can
take place
3. Verify that business
operations can continue
• Acquire a US $100 million
business unit in 90 days
or less
• Process 100% AP invoices
from Tier 1 vendors, saving
$9 million annually
Business process
improvement
Project management Strategy management
Figure 3 — Capabilities-based planning starts with business scenarios,
the tasks needed to implement the scenarios, and the testable
capability outcomes.

Scenarios Are One Basis of
Connecting Business Operations
with Strategy
A capability provides an outcome
or an effect without an a priori
specification of the outcome or
effect. Features and functions
require an a priori specification in
order to test for their existence or
conformance to the specification.
Capabilities-based planning can
be understood at the execution
level, but it needs to be raised to
the level of enterprise process
analysis: identify a needed capa-
bility in operational terms, using
the set of capability options to
assess the effectiveness in an
operations paradigm, and make
choices about requirements and
the ways to achieve the capability
using an integrated portfolio
framework to produce an output
set of options based on these
operational paradigms.
Putting capabilities-based plan-
ning to work requires a change
in our approach to planning —
a set of business process
improvement activities focused
on assessing increasing maturity
of the capabilities needed to fulfill
the strategic objectives.
Emphasis is placed on operational
capabilities rather than features
and functions. These operational
capabilities become the building
blocks of change. The emphasis
is also placed on evaluating
capabilities under conditions of
uncertainty, which requires the
deployment of robust building
blocks capable of adapting to
these changes. In both cases
analysis illuminates the feasibility
of alternatives.
Scenario-based planning is one
approach to defining the objec-
tives in a balanced scorecard.
While popular in decision-making
processes, we must distinguish
between two situations:
1. Finding alternatives
2. Evaluating existing alternatives
The first use (finding alternatives)
is popular but has problems.
The second use is equivalent to
simulation. One example is the
assumption that a strategy can be
discovered by studying individual
scenarios. This what-if approach
to optimal decision making is
flawed when some of the para-
meters are unknown — as is the
case in most IT projects.
Issues found in scenario-based
planning can be addressed by a
capabilities view of the world.
Scenarios are related to each
other in different contexts;
changes made to one operational
scenario may impact another.
Selection of scenarios must be
based on the proper understand-
ing of the relations and impact on
other scenarios. Capabilities pro-
vide a collection point to consoli-
date scenarios by systematically
defining operational concepts
and their relationships, with each
capability defining the compelling
rationale for decisions found in a
portfolio of projects.
Augmenting Balanced Scorecard
with Capabilities
The balanced scorecard is aug-
mented through a capabilities-
based planning process by
mapping strategies to assess-
ment maturity events for the
emerging capabilities. The focus
of capabilities-based planning
is on assessing the increasing
maturity of functionality defined
by the balanced scorecard strat-
egy. Planning under uncertainty
provides capabilities suitable for a
wide range of challenges and cir-
cumstances while working within
an economic framework that
necessitates choice, where the
focus is on “possible uses” rather
than specified features and func-
tions. For example:
What features do we need
to achieve the desired
capabilities?
How much of each capability
do we need at this point
in time?
How robust, flexible, and capa-
ble should we be at a point in
time to provide the needed
capability?
The difference between a capabil-
ity and a function is the difference
between the delivery of a solution
and the creation of the foundation
responding to various uncertain
demands. Capabilities do the
following:

Focus on the outcomes rather
than the features of an IT
system.
Focus on the delivery of the
effort that produces these
outcomes.
Define the needed maturity and
assess its presence to provide
feedback to the business strat-
egy in ways a set of simple bal-
anced scorecard KPIs cannot.
Capabilities-based planning
replaces features and functions
with business value, traceable to
strategy through a portfolio of
projects and their program events.
It does so by:
Planning the delivery of capa-
bilities rather than the delivery
of features and functions
Identifying the features and
functions that are the raw
materials of capabilities
Making visible the capabilities
that enable the delivery of the
strategy
Program Maturity Assessment
Events Are the Next Step
Program events in integrated
master scheduling are evaluation
points in the project for assessing
the maturity of the capability and
its effect on the business. Program
events are celebratory opportuni-
ties along the path to maturity that
test the delivered business against
a strategic objective. These tests
ensure that:
Significant accomplishments
enable the capability to support
a strategy.
The maturity of the delivered
value of the significant accom-
plishment fulfills the strategy.
INTEGRATED MASTER
SCHEDULING IN AGILE
PROGRAMS
Integrated master scheduling
takes the capabilities extracted
from the strategic initiatives and
constructs a series of evaluation
“events” that assess the increasing
maturity of these capabilities.
Integrated master scheduling
is a systematic approach to con-
necting strategy with execution
through measurable progress in
units of “maturity” rather than
the passage of time. The agile
program manager and the con-
stituents can ask and answer the
critical question: Are the capabili-
ties planned to be delivered actu-
ally being delivered in a form that
supports the strategic objectives?
Addressing Uncertainty with
Event-Based Scheduling
Uncertainty is an inevitable out-
come of any technological or
business venture. When both
technology and business are
combined, uncertainty not only
increases, but the number
of degrees of freedom also
increases. The first impulse is to
define decision milestones, install
risk management, and lay out
sequential iterations to ensure
everyone on the project is on the
same page before proceeding to
the next step.
The program events and their sup-
porting accomplishments and cri-
teria define the path to increasing
levels of maturity to the fulfillment
of an enterprise’s strategic objec-
tives. Connecting these objectives
to portfolios of projects is done
through three individual elements
of integrated master scheduling,
as seen in Table 8.
Evaluation of Program Maturity
The concept of evolving the matu-
rity of a program is likely new to
the IT community applying project
portfolio management. The matu-
rity discussed here is not the same
maturity found in the Capability
Maturity Model® (CMM) of the
Software Engineering Institute
(SEI). (See Table 9.)
Defining maturity assessment points allows stakeholder and planners to concur
that progress is being made toward beneficial outcomes.
The unit of measure for these outcomes starts with the fulfillment of strategic
objectives.
Significant accomplishments and their exit criteria are the raw materials for
assessing maturity of the projects, not the passage of time.
Integrated master dcheduling provides the means to measure progress as a
function of increasing maturity rather than the simple passage of time.

When a portfolio of projects is
viewed through this increasing
maturity assessment, project and
program risk becomes an explicit
measure rather than a hidden
attribute of the collection of
projects.
Learning to Speak in the Language
of Integrated Master Schedule and
Capabilities
The integrated master scheduling
approach starts at the end and
works backward to the beginning
of the project. At each step back-
ward from the finish, there are key
decision points that assess the
increasing maturity of the project.
These points are program events.
They appear to be milestones,
but they are actually assessment
points for the increasing maturity
of the program. This concept of
increasing maturity is unique to
integrated master scheduling and
agile program management.
When the capabilities-based plan-
ning is operational, the increasing
maturity assesses the increasing
capabilities of the program and
the increasing capabilities of the
firm to which the program is
being targeted (see Figure 4).
Success Criteria Defined in the
Event Structure
Events measure the increasing
maturity of the program. This
maturity describes how the capa-
bilities defined in the strategy and
objectives are being developed
over time. Each capability should
be connected to a strategy or
objective statement.
Evaluation of Program Maturity
Traceability of Projects
within the Program
Provides insight in the overall effort
through measures of capability rather
than the passage of time or consump-
tion of resources.
Connects strategy and objectives with the
deliverables of projects.
Provides a level of detail consistent
with the risk and complexity of the
individual projects.
Project granularity is rolled up from
iterations and increments.
Decomposes events into a logical
series of significant accomplishments
supported by incremental deliverables.
The iterative and incremental deliverables
from agile development projects is
connected to the increasing maturity
of capabilities.
Provides measurable criteria to demon-
strate the quality and completion of the
significant accomplishments at each
release cycle.
Progress is measured by the successful
completion of a series of iterations that
produce value
Table 9 — Evaluation of program maturity,
The IMS Element The Purpose of the IMS Element
State of
the Program
State of
the Product
State of
the Process
Program event — the major program milestones,
assessment points, or key decision points used to
substantiate the increasing maturity of the portfolio of
projects. Program events answer the question: What
level of maturity must the program reach to provide the
desired set of capabilities in support of an enterprise
strategic objective?
Significant accomplishment — the specified results,
substantiating an event, which indicate the maturity
(or progress) level for each product or process. Generally
these are discrete steps in the progress of develop-
ment or deployment. The significant accomplishment
answers the question: Where are we along the road to
completion in terms of maturity not just the passage
of time?
Accomplishment criteria — the definitive measures
used to substantiate the maturity level of the significant
accomplishment. These measures need to provide
objective and explicit proof of completion or closure
of the effort. They define the conditions for closing the
significant accomplishment and answer the question:
How do I know when an accomplishment has been
completed?
Table 8 — The integrated master schedule defines the framework for the pro-
gram by establishing key decision points, the significant accomplishments
that must be performed prior to those decision points, and the criteria
by which those accomplishments will be substantiated, providing clear
and concise measure of progress of the program against the strategic
objectives of the enterprise.

Consider this example: with the
capability of closing the month-
end books in three working days,
we will be able to acquire a $100
million business and have its
books integrated in 30 days.
Measurable progress is evidenced
by the significant accomplishments
and their accomplishment criteria.
This approach is different than the
normal Gantt chart approach to
planning and progress meas-
urement. The approach replaces
the passage of time with the
delivery of tangible evidence of
progress, through the physical
maturity connection of progress
with strategy; defines accomplish-
ments as measurable outcomes;
and measures progress through
a 0% or 100% assessment of the
accomplishment. Either the deliv-
ery was made or it was not. In
addition, the accomplishments
should be fine-grained enough to
be described as 0% or 100% com-
plete. By fine-grained it means
short duration (10 to 40 working
days — two-to-eight-week calen-
dar time) effort. This approach
reinforces the core tenants of the
agile program management para-
digm through continuous feedback
of progress, assessment of value,
and compliance with strategy.
Meeting these goals is done by:
Defining the accomplishment
criteria (“exit criteria”) for each
significant accomplishment
Defining the exit criteria as
binary rather than incremental
— either you made the goal or
you didn’t
Using the integrated master
schedule vocabulary, statements
can be constructed that test the
maturity of the program, identify
points where changes can be
made for the benefit of the port-
folio of projects, and assess both
risk and opportunities.
Integrated Master Scheduling
Vocabulary and Change
The discovery of the unpre-
dictable and indeterministic
introduces variance. This vari-
ance introduces changes in plans.
Changes in plans means “manag-
ing in the presence of change”
(see Figure 5).
The concept of managing in
the presence of this variance is
preferable to trying to control the
variance. This is a critical attribute
of agile program management.
Adapting to change is critical
to any program or project man-
agement process, whether it is
considered agile or not. In a pro-
gram management environment,
changes to the plan are provided
through “on ramps” and “off
ramps” in the baseline schedule,
where an adaptive response to
change takes place.
The business strategy defined in
the balanced scorecard provides
guidelines for the entry and exit
processes for the project deliver-
ables. By testing each decision
against the strategy, the project
stays focused on significant
accomplishments in support of
a program event.
Opportunity-Based Processes
Built into the Master Plan
If adaptive management
processes are to be installed
and made operational, then
opportunities for change and
improvement must be identified
and acted on when they appear
or are discovered. The search for
these opportunities takes place
Event (system or product)
Significant accomplishment
Significant accomplishment
Accomplishment criterion
Accomplishment criterion
Detailed task
Detailed task
Figure 4 — The integrated master schedule describes the significant
accomplishments and the accomplishment criteria needed to assess
the increasing maturity of the program.

through a strategy-focused assess-
ment process. At each significant
accomplishment, an assessment
of new opportunities must be
taken. This is the way to provide
the adaptability needed at the pro-
gram level. When change agents
are encountered — market forces,
technology impacts, program-
matic performance shortfalls —
new opportunities present them-
selves in the form of reassessment
of the strategy and reevaluation of
program performance.
UNCERTAINTY IN AN AGILE
PROGRAM MANAGEMENT
ENVIRONMENT
Managing in the presence of
uncertainty is a core capability
of agile program management,
since uncertainty is part of every
project [10]. Attempting to control
uncertainty and the risks that
result from this uncertainty cre-
ates a major disconnect between
expectations and reality. The erro-
neous assumption is that risk and
uncertainty can be managed in
ways that allow predictive sched-
ules to be built (see Table 10).
The Contingent Approach to
Program Management
There is more value to categoriz-
ing uncertainty than would appear
at first. Each uncertainty type
needs a different management
approach to deal with not only the
uncertainty but also the risks that
emerge when the uncertainty
becomes operational [10].
PUTTING IT ALL TOGETHER
With this brief overview of agile
program management, IT organi-
zations can make changes in how
programs and projects are con-
nected to strategy. First let’s
review the components of agile
program management (refer
again to Table 7 [on page 17]):
Each agile principle results in a
practice. There are several critical
concepts in putting these prac-
tices to work:
Agile practices must be
kept close to principles.
Interpretation of the practices
in ways not implied by the prin-
ciple leads to poor results. A
clear and concise understand-
ing of the principles is needed
in addition to the skills of
putting the practice to work.
The “units of measure” of
agile practices are business
value. Business value is almost
always measured in dollars.
“Dollarizing” a process, a
feature or function, or a deci-
sion is a starting point. There
may be other units of measure
but “money” seems to be the
most acceptable one.
Strategy is about testing a
hypothesis through initiatives
that provide the raw material
for decision making about the
business. IT projects provide
the mechanisms to deliver
value in support of this
decision-making process.
Agile can be characterized as [12]:
Nimble, dexterous, and swift
Adaptive and responsive to
new, sometimes unexpected,
information that becomes
available during the project’s
lifecycle
Perform
work
Maturity Action Product
Product
state
Adjective Verb Noun Verb
Preliminary Design
Business
structure
Completed
“A01B02a: Preliminary design review of business structure completed.”
Demonstrates
maturity
Step in the
process
End item
Closure
state
Figure 5 — The integrated master schedule states the increasing maturity
of the program through the program events, significant accomplishments,
and accomplishment criteria.

Opposite of traditional
approaches to project
management that seek to
freeze requirements, design,
and implementation as early
as possible
Agile program management uses
the practices of balanced score-
card, project portfolio manage-
ment, capabilities-based planning,
and integrated master scheduling
to create these characteristics
in support of the principles of
vision, value, decision, people,
and results.
Therefore, agile program man-
agement connects practices to
principles.
REFERENCES
1. Allen, Thomas, Deborah
Nightingale, and Earll Murman.
“Engineering Systems: An
Enterprise Perspective.”
Engineering Systems Monograph,
MIT Engineering Systems Division,
March 2004.
2. Ambrose, Stephen E.
Undaunted Courage: Meriwether
Lewis, Thomas Jefferson, and the
Opening of the American West.
Simon & Schuster, 1996.
3. Austin, Robert and Richard
Nolan. “Managing ERP Initiative
as New Ventures, Not IT Projects.”
Harvard Business School Working
Paper 99-024, 1998.
4. Armour, Phillip. “Ten
Unmyths of Project Estimation.”
Communications of the ACM,
Vol. 45, No. 11., November 2002,
pp. 15-18.
5. Birnbaum, Bill. Strategic
Thinking: A Four Piece Puzzle.
Douglas Mountain Publishing,
2004.
6. Bossidy, Larry. Execution:
The Discipline of Getting Things
Done. Crown Business, 2002.
7. Brock, Susan, Danyal
Hendricks, Stephen Linnell,
and Derek Smith. “A Balanced
Approach to IT Project
Management.” Proceedings
of SAICSIT 2003, pp. 2-10.
Type of
Uncertainty
Characteristics Agile Processes
Normal
Variation
Foreseen
Uncertainty
Unforeseen
Uncertainty
Chaos
Normal variation in the completion of tasks,
costs, and the exact performance level
comes from the accumulation of the small
fluctuations in the execution process.
Uncertainties that are identified but have
uncertain influences.
Events that cannot be identified during the
planning process.
The basic structure of the project is
unstable, with no ability to forecast the
occurrence of these uncertainties.
• Fine-grained assessment points
• 0% or 100% deliverable assessment
• Performance measured on deliverables
rather than the passage of time
• Buffers, schedule margin assigned in
front of critical deliverables, management
reserve
• Statistical process control using key
program variables
• Contingent paths forward
• Decision tree based on alternative plans
• Proactive risk management
• New problem solving required to develop
an appropriate response
• Continuous verification of the programs
strategy through hypothesis testing
• Iterations based on continuous feedback
• Close customer contact to foster an
entrepreneur relationship to deal with
upset conditions
Table 10 — Uncertainties are present in all projects. Agile program management processes are capable of dealing
with each uncertainty type through specific practices derived from the four principles.

8. Caminiti, Susan. “What Team
Leaders Need to Know.” Fortune,
20 February 1995.
9. Collins, Jim. Good to Great:
Why Some Companies Make
the Leap…and Others Don’t.
HarperCollins, 2001.
10. de Meyer, Arnoud,
Christoph Loch, and Michael
Pich. “Uncertainty and Project
Management: Beyond the Critical
Path Mentality.” INSEAD Working
Paper, 2001.
11. Fitzgerald, Donna. “Principle-
Centered Agile Project Portfolio
Management.” Cutter Consortium
Agile Project Management
Executive Report, Vol. 6, No. 5,
2005.
12. Haberfellner, Reinhard and
Olivier de Weck. “Agile SYSTEMS
ENGINEERING versus AGILE
SYSTEMS engineering.” Fifteenth
Annual International Symposium
of the International Council on
Systems Engineering (INCOSE),
10-15 July 2005.
13. Highsmith, Jim. “Agile for
the Enterprise: From Agile
Teams to Agile Organizations.”
Cutter Consortium Agile Project
Management Executive Report,
Vol. 6, No. 1, 2005.
14. Jabagchourian, Harry
and Robert Cvetko. “Risk &
Opportunity Management:
Program & Project Management
Success Factors.” Fourth National
Symposium on Space System Risk
Management, McLean, Virginia,
USA, 21-24 May 2002.
15. Kaplan, Robert S. and David
P. Norton. The Strategy-Focused
Organization: How Balanced
Scorecard Companies Thrive in
the New Business Environment.
Harvard Business School Press,
2000.
16. Karlstrom, Daniel and Per
Runeson. “Combining Agile
Methods with Stage-Gate Project
Management.” IEEE Software,
Vol. 22, No. 3, May/June 2005,
pp. 43-49.
17. Kennedy, John F. Special
Message to the Congress on
Urgent National Needs, 25
May 1961 (www.jfklibrary.org/
j052561.htm).
18. Koffi, Atiogbe Didier. “A Model
for the Evolution of Software and
Systems Engineering Project
Cultures Throughout their Life
Cycles.” Systems Engineering
Journal, Vol. 8, No. 2, 2005.
19. Koskela, Lauri. “An exploration
towards a production theory and
its application to construction.”
Dissertation presented at Helsinki
University of Technology, Espoo,
Finland. VTT Publications,
2000 (www.inf.vtt.fi/pdf/
publications/2000/P408.pdf).
20. Kurtz, Cynthia F. and David J.
Snowden. “The New Dynamics
of Strategy: Sense-Making in
a Complex and Complicated
World.” IBM Systems Journal,
Vol. 42, No. 3, 2003.
21. Loch, Christopher, Michael
Pich, and Arnoud de Meyer.
“Adjusting Project Management
Techniques to Uncertainty.”
European Business Forum 3,
Autumn 2000, pp. 47-51.
22. Martin, Nancy L., John M.
Pearson, and Kimberly A. Furumo.
“IS Project Management: Size,
Complexity, Practices and the
Project Management Office.”
Proceedings of the 38th Annual
Hawaii International Conference
on System Sciences, 2005.
23. McFarlan, F. Warren.
“Portfolio Approach to Information
Systems.” Harvard Business
Review, Vol. 59, No. 5, September
1981, pp. 142-150.
24. Porter, Michael E. “What is
Strategy?” Harvard Business
Review, Vol. 74, No. 6, November
1996, pp. 61-78.
25. The Technical Cooperation
Program (TTCP). “Guide to
Capabilities-Based Planning.”
A paper prepared by the Joint
Systems and Analysis Group,
Technical Panel 3 of TTCP for
the MORS Workshop, Alexandria,
Virginia, USA, 19-21 October 2004.
26. Wharton Strategic
Management. “Three Reasons
Why Good Strategies Fail:
Execution, Execution…” 10 August
2005 (http://knowledge.wharton.
upenn.edu/article/1252.cfm).

ACKNOWLEDGEMENTS
Cutter Consortium Senior
Consultant Donna Fitzgerald
worked diligently on the themes,
framework, and major structure
of this report. The success of
this material is due in part to
her efforts.
Mike Dwyer — IT program
manager at American Healthways,
Westborough, Massachusetts,
USA — provided valuable input
on everything from small typos
to major concepts about perfor-
mance management.
ABOUT THE AUTHOR
Glen B. Alleman consults as a
program management process
architect (integrated master plan/
integrated master schedule) in a
Denver, Colorado, USA, defense
and aerospace firm. Over the past
25 years, Mr. Alleman has led
program management offices,
software product development
organizations, and enterprise
resource planning (ERP) deploy-
ment projects. His current inter-
ests include integrated product
team deployments of Microsoft
Project Server, integration of
schedule and cost for enterprise
programs, and probabilistic
risk assessment integration.
Mr. Alleman also consults
in the system architecture, busi-
ness process improvement, and
program management office
deployment fields.

Agile Project
Management Practice
Cutter Consortium’s Agile Project Management Practice helps companies succeed
under the pressures of this highly turbulent economy. The practice is unique in that
its Senior Consultants — who write the reports and analyses for the information
service component of this practice and do the consulting and mentoring — are the
people who’ve developed the groundbreaking practices of the Agile Methodology
movement. The Agile Project Management Practice also considers the more
traditional processes and methodologies to help companies decide what will
work best for specific projects or teams.
Through the subscription-based publications and the consulting, mentoring, and
training the Agile Project Management Practice offers, clients get insight into Agile
methodologies, including Adaptive Software Development, Extreme Programming,
Dynamic Systems Development Method, and Lean Development; the peopleware
issues of managing high-profile projects; advice on how to elicit adequate
requirements and managing changing requirements; productivity benchmarking;
the conflict that inevitably arises within high-visibility initiatives; issues associated
with globally disbursed software teams; and more.
Products and Services Available from the Agile Project Management
Practice
• The Agile Software Development and Project Management Advisory Service
• Consulting
• Inhouse Workshops
• Mentoring
• Research Reports
Other Cutter Consortium Practices
Cutter Consortium aligns its products and services into the nine practice areas
below. Each of these practices includes a subscription-based periodical service,
plus consulting and training services.
• Agile Software Development and Project Management
• Business Intelligence
• Business-IT Strategies
• Business Technology Trends and Impacts
• Enterprise Architecture
• IT Management
• Measurement and Benchmarking Strategies
• Enterprise Risk Management and Governance
• Sourcing and Vendor Relationships
Senior Consultant
Team
The Cutter Consortium Agile Project
Management Senior Consultant Team
includes many of the trailblazers in the project
management/peopleware field, from those
who’ve written the textbooks that continue
to crystallize the issues of hiring, retaining,
and motivating software professionals, to
those who’ve developed today’s hottest Agile
methodologies. You’ll get sound advice and
cutting-edge tips, as well as case studies and
data analysis from best-in-class experts. This
brain trust includes:
• Jim Highsmith, Director
• Scott W. Ambler
• Christopher M. Avery
• James Bach
• Paul G. Bassett
• Kent Beck
• E.M. Bennatan
• Tom Bragg
• David R. Caruso
• Robert N. Charette
• Alistair Cockburn
• Mike Cohn
• Ken Collier
• Doug DeCarlo
• Tom DeMarco
• Khaled El Emam
• Donna Fitzgerald
• Kerry F. Gentry
• Michael Hill
• David Hussman
• Ron Jeffries
• Joshua Kerievsky
• Bartosz Kiepuszewski
• Brian Lawrence
• Tim Lister
• Michael C. Mah
• Lynne Nix
• Ken Orr
• Mary Poppendieck
• Roger Pressman
• James Robertson
• Suzanne Robertson
• Rob Thomsett
• Colin Tully
• Bob Wysocki
• Richard Zultner

Agile Program Management: Moving from Principles to Practice

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile Program Management: Moving from Principles to Practice

Similar to Agile Program Management: Moving from Principles to Practice (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Agile Program Management: Moving from Principles to Practice