The document discusses agile program management, highlighting its principles and practices that connect strategy with execution to address traditional project management shortcomings. It outlines five key principles of agile program management that enhance project deliverability by focusing on whole outcomes rather than linear processes. By incorporating elements such as balanced scorecards and capabilities-based planning, the agile approach aims to minimize execution gaps and adapt to changing business environments.

1. Agile Program
Management
Moving from Principles to Practice
Glen B. Alleman
In
Cutter Journal
Agile Project Management 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.”
– The Timeless Way of Building, Christopher Alexander, Oxford University Press, 1979.

2. Agile Program Management: Moving from Principles to Practice .................................................................. 3
Agile Program Management Principles ...................................................................................................... 4
Where Does the Problem Start with Traditional Program Management? .............................................. 4
Closing the Execution Gap with Agile Program Management Principles ............................................. 6
The Five Principles of Agile Program Management .............................................................................. 7
A Layered Approach to Managing IT Programs ......................................................................................... 7
Principles of Agile Program Management .................................................................................................. 8
Vision ...................................................................................................................................................... 8
Value ....................................................................................................................................................... 9
Decision ................................................................................................................................................ 10
People ................................................................................................................................................... 10
Results .................................................................................................................................................. 11
Details of the Agile Program Management Components .............................................................................. 12
Program Offices Deliver Program Management Services ........................................................................ 12
More Difficulties with Traditional Approaches and a Solution ................................................................ 12
The Value Proposition for Agile Program Management .......................................................................... 13
Balanced Scorecard as a Starting Point for Agile Program Management ..................................................... 13
Elements of Balanced Scorecard .......................................................................................................... 14
Objectives and Measures ...................................................................................................................... 15
What is Strategy and Why is it Important to Agile Program Management? ............................................ 15
Alignment with Strategy is a Continuous Process .................................................................................... 16
Four Components of IT Strategy ............................................................................................................... 17
Agile Portfolio Management .......................................................................................................................... 18
Increasing Maturity is an Agile Approach to Deployment ....................................................................... 18
Direct Benefits of Agile Project Portfolio Management ........................................................................... 18
Performance Based Measures for Portfolios of Projects ........................................................................... 19
Three Erroneous Assumptions of Traditional Project Management ......................................................... 19
The Next Phase of Agile Program Management – Planning the Work .................................................... 20
Capabilities Based Planning ........................................................................................................................... 21
Scenarios are one basis of Connecting Business Operations with Strategy .............................................. 22
Augmenting Balanced Scorecard with Capabilities .................................................................................. 23
Program Maturity Assessment Events are the Next Step .......................................................................... 23
Integrated Master Scheduling in Agile Programs .......................................................................................... 24
Addressing Uncertainty with Event Based Scheduling ............................................................................ 24
Evaluation of Program Maturity ............................................................................................................... 25
Learning to Speak in the Language of Integrated Master Schedule and Capabilities ............................... 25
Success Criteria Defined in the Event Structure .................................................................................. 25
Using Integrated Master Schedule Vocabulary for Dealing with Change ................................................ 26
Opportunity Based Processes Built Into The Master Plan ................................................................... 27
Uncertainty in an Agile Program Management Environment ........................................................................ 27
The Contingent Approach to Program Management ................................................................................ 28
Putting it All Together ................................................................................................................................... 28
Bibliography ................................................................................................................................................... 29
Acknowledgements ........................................................................................................................................ 30
Biography ....................................................................................................................................................... 30
Cutter – Agile Program Management 2/30

3. Agile Program Management: Moving from Principles to Practice
Every segment of industry and government is
under pressure to reduce cost, increase quality,
Agile Program Management joins strategy
and execution to deliver value through
and deliver value to owners, customers and
testable outcomes, measures of increasing
constituents. The IT community is no
maturity, and continuous feedback
exception. CIO’s, product managers and
! Business strategy provides the starting point
operational leaders are expected to provide
for selecting portfolios of projects and
solutions that address these improvement
defining their beneficial outcomes.
initiatives in the presence of a constant, rapid
! Defining the capabilities identified in the
and unpredictably changing environment.
strategy lays the foundation defining the
These initiatives result in a mandate to deliver
delivered value to the enterprise.
the best value IT products and services, on
! Event based scheduling provides the needed
time / on cost, that meet emerging business,
project performance management process to
regulatory, and technology requirements. The
assess the increasing maturity of the program
processes used to place IT systems into
in delivering value needed for a successful
strategy.
operation must meet or exceed the strategic
objectives of the enterprise, while addressing
One of the most dangerous forms of human
this effort in the presence of every increasing
error is forgetting what one is trying to achieve
– Paul Nitze
uncertainty. Research shows that that most IT
project problems are related to management, organizational and cultural issues, not
technical problems. [23], [22]
Agile Program Management provides the connection between strategy and execution.
Over the last ten years IT projects have grown in number, larger and complexity. As a
result, a gap has developed between strategic decisions of the corporation and 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 management
position. Much of the gap between strategy and execution didn’t exist because intimate
knowledge of the business problem was a
key requirement for the project manager.
With project managers regarded as
“generic technical professionals,” having
Project
Portfolio
the skills and experience needed to make
Balanced
Scorecard
Management
Capabilities
Based
trade–offs on the road to success has
Business
Planning
Mission
Event
become difficult. This report completes
And
Vision
Tasks
Based
the final piece of the hierarchy for efficient
“Demand” “Done”
management of IT. Donna Fitzgerald’s
Figure 1 – Agile Program Management contains five
“Principle–Centered Agile Project
major elements, each supporting and enhancing the
Portfolio Management,” [10] and Jim
others to deliver beneficial business outcomes derived
Highsmith’s “Agile for the Enterprise,”
from connecting strategy to execution.
[13] complete this series on agile IT management processes.
Cutter – Agile Program Management 3/30

4. The case for Agile Program Management can be stated as …
For CIO’s and internal IT managers who develop and deploy enterprise applications
using Commercial Off The Shelf (COTS) or internally developed solutions;
agile program management provides 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 managing performance variation, and addressing foreseen and
unforeseen unknowns;
Agile Program Management Principles
Agile Program Management contains practices found in traditional program management,
delivered through the principles of agile. For the traditional program manager this
description is likely meaningless. 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 Program Management practices.
“Only those general principles and attitudes that result from clear and deep understanding can provide a
comprehensive guide to action.” [9]
There are several official descriptions of agile. 1 These descriptions fall short for the
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 As well the distinction
between project management, program management and software development
management is not clearly drawn in these approaches. Add to this the variety of different
drivers for the development 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 disciplines start with a retrospective approach that measures
variance against plan, rather than providing performance forecasting information that can
be used to guide projects in a chaotic environment. [25] These traditional systems
measure work accomplished 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.
1 The current definitions of agile are strongly influenced by the software development paradigm. While this
is useful to those writing software, for the Program Manager of development projects or the procurement
and integration of COTS products, the software centric paradigm has limits. The Agile Alliance,
http://www.agilealliance.org/home; Declaration of Interdependence,
http://www.pmdeclarationofinterdependence.org/; Agile Project Managers Leadership Network,
http://www.agileprojectmgt.org/ and David Anderson’s Agile Management site,
http://www.agilemanagement.net/index.html
2 Extreme Programming, SCRUM, Crystal, DSDM
3 In 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.
Cutter – Agile Program Management 4/30

5. Plans made in this way and adjusted by linear feedback methods cannot cope with the
multiple interacting and continuously changing technology and market forces.
The success rate of applying traditional methods to complex software development
projects over the years has been underwhelming. There are a number of critical issues
with IT projects that suggest better attention to implementation procedures and
management processes to deal with change is needed. These approaches start by avoiding
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. Avoiding or controlling change is the primary
activity. In this traditional model, “change” is undesirable; when in fact change in the
world of business systems is natural as well as desirable. A gap arises when the
difference between managing in the presence of change and managing change is not
understood. Agile Project Management uses risk and opportunity management to create a
set of practices that proactively and explicitly manage in the presence of change. [14]
Issues identified in several studies that increase the likelihood of failure for IT projects
shown in Table 1: [7]
Failure Modes for IT Projects Traditional Approach Agile Approach
Absence of a clear vision and
A statement of work, work
statement of program’s
breakdown structure or
requirements
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
Work breakdown structures
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.
4 Linear project management models are sometimes referred to as waterfall models.
Cutter – Agile Program Management 5/30

6. Agile Program Management establishes a culture and framework to deal with these and
other issues. Connecting strategy with execution identifies capabilities that are required to
fulfill the strategy, significant accomplishments that must be performed along the way to
delivering these capabilities, and the criteria by which these accomplishments can be
assessed to assure that the increasing maturity of the capabilities fulfills the enterprise
strategy.
Closing the Execution Gap with Agile
Traditional Methods Agile methods
Program Management Principles
Planning drives results Results drive planning
A study of 72 IT firms revealed several
Delivery focused on
Delivery focused on
attributes of project management critical
planned results
assessable results
to connecting strategy with execution
Defined process steps Self–organizing process
[3], [7]:
steps
Progress measured by
Progress measured by
! Scope, Time and Quality – continuous
the passage of time
increasing maturity
assessment and evaluation of scope
Quality measured at the
Quality measured on
and quality through fine grained
point of delivery
continuous fine grained
feedback allows intervention before
boundaries
budget or time overruns appear.
Table 2 – From the attributes of project management,
differences between Traditional and Agile program
! Cost, Quality and Human Resource
management emerge.
Management determine the adherence
to a project budget at a specific point in time. Uncontrolled budget and poor budget
forecasts result.
! Scope, Quality and Cost management determines the project’s adherence to time
delivery. Scope could be seen as a significant factor in affecting the ability of the
project to deliver on time. Scope creep is a common reason for late delivery.
! Time and Cost management determines a project’s adherence to scope delivery. Time
and Cost management lead to a project completion on–scope, this due to the extra cost
associated with producing more features in a project.
From these research results, differences between traditional and agile Project and
Program Management emerge are shown in Table 2. These differences appear trivial at
first, but they are critical to understanding how agile program 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.
From the differences between traditional and agile program management methods, five
principles of Agile Program Management emerge. The practices associated with these
principles are general purpose project management methods found in a variety of
industries and are not by themselves unique to Agile Program Management.
Cutter – Agile Program Management 6/30

7. The Five Principles of Agile Program
Management
These five principles are both obvious 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 constraints of command and control
and replaces it with the mechanisms needed to turn constant change into opportunity. [20]
A Layered Approach to Managing IT Programs
Four components of Agile Program
Management – strategy, portfolios,
capabilities, 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 take place
through of the processes of Agile Program
Management:
! Balanced Scorecard informs Portfolio
Management about the needed
initiatives for strategy fulfillment.
! Portfolio Management informs
Vision What does the future hold?
Value Why are we doing this?
Decision How do we decide what to do?
People Who is going to do the work?
Results 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.
Agile Program Management is composed of four
core process that operate in harmony to deliver
increased value to IT stakeholders
! Balanced Scorecard provides the starting point
for measurable outcomes in support of mission,
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 assure it meets the strategic goals.
Capabilities Based Planning about what capabilities needed to fulfill the strategy.
! Integrated Master Scheduling informs the program of the increasing maturity goals
for each capabilities 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.
Cutter – Agile Program Management 7/30

8. 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 Score defines the strategic
business outcomes – objectives – to be
delivered by a portfolio of operational
projects
2. Value 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?
Capabilities create value through the
Balanced Scorecard objectives.
Portfolios of projects Delivery these
capabilities. Business value is assigned in
units of measure meaningful to the business
3. Decision 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?
Capabilities based planning is used to
decipher the intent of the scorecard
initiative, selecting projects by their
contribution to the strategic objectives
4. People Who are the people and skills needed to
assure success?
! How are we organized to deal with
change and uncertainty?
! What processes are in place to manage in
the presence of change?
Define the skills and experience needed to
deliver the Significant Accomplishments.
5. Results 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 of this value supportive of strategy?
Assure 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.
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
Strategy is derived from Vision. Famous vision
statements include President Kennedy’s May
25th, 1961 challenge to reach and return from
the moon … before the decade is out [17] and
President Thomas Jefferson’s vision … of a
great nation that would stretch from sea to sea.
[2]
Figure 2 – The Five principles of Agile Program
Management can be arranged to convey the feeling
of continuous motion, interaction, support of a
vision.
Cutter – Agile Program Management 8/30

9. IT programs are unlikely to be launched with such grand visions. There is still need for a
vision, otherwise tools like Balanced Scorecard will have no source for their initiatives,
portfolios, and programs.
“If you tell people where to go, but not how to get there, you’ll be amazed at the results” —
General George S. Patton
It is important to separate vision from mission. [5] The Mission Statement describes the
business and its relationships with customers. The mission statement moves the strategic
planning process from the present into the future. Not only must the mission statement
work today but it 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 actionable. The mission statement must be treated as a
tool not a solution, since it rarely does anything tangible for the organization. Mission
statements should be crafted to focus on the day–to–day accomplishments of work.
The Vision Statement is about the future. The vision statement is a dream, an aspiration, a
statement about what is hoped to be accomplished. The vision should convey a
compelling story about the future.
Steve Jobs’ vision is, “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 its still a great vision
Agile Program Management starts with a Vision for the IT programs. Crafting this
statements requires care and concern for the message conveyed since the vision lays the
ground work for strategy, capabilities, and ultimately the reason for execution and the
resulting operational processes.
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 the organization wants to become
! What are the results of our actions?
! If we achieve our mission what will
the future look like?
From a Vision Statement value, decisions, the right people, results and ultimately the
closure between strategy and execution can be derived. The Vision statement is the
source of what done looks like – it is the purpose of the portfolio of projects, the defined
capabilities, the accomplishments 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 collection of projects through the
gauntlet of corporate management.
Turning principles into practice starts with the definition of value. The first bullet of the
Declaration of Interdependence 5 says – “We increase return on investment by making
continuous flow of value our focus.”
5 www.pmdeclarationofinterdependence.org
Cutter – Agile Program Management 9/30

10. 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, 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 trade offs, hedges risk, selects from the
available options and discovers new options to add to the portfolio. Integrated Master
Scheduling 6 makes continuous decisions based on project performance. Significant
accomplishments are assessed for completion. The accomplishment criteria are assessed
for compliance to the increasing maturity goals. Capabilities Based Planning selects the
needed capabilities, their order of deployment, and assesses their contribution to the
strategic objectives – closing the loop between strategy and execution.
People
People are the raw material for teams, for not only 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 lost when discussing agile processes. No matter the
approach, success comes to those with skill and daring and a bounding framework. 7
There are two schools of thought on how to improve execution 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 problems and incent
them to perform. [9] Another approach improves the average employee and the whole
organization will improve.
A second school emphasizes process and starts with the assumption that firms don’t
intentionally “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
6 The 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 needed capabilities emerge from the portfolio of projects to
match the strategic initiatives selected to fulfill the strategic objectives of the Balanced Scorecard.
7 In 1992, Honeywell’s defense avionics division in Albuquerque New Mexico reorganized their entire 1800 person
business unit into multifunctional teams. Division management searched among their supervisors for people who could
facilitate loyalty, communication and decision making 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 their 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].
Cutter – Agile Program Management 10/30

11. underlying issues from the missing element. The approach for increasing the performance
of people outside the small group level includes:
1. Develop a model for execution that fits culture, skills, needs, and capabilities of
the participants of the initiatives being managed by the program.
2. Choose the right metrics for the program and projects. Metrics that connect
strategy with execution and measure the increasing maturity of the identified
capabilities.
3. 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 treat the plan as a
complex situation, adapting to an emerging solution. 8
4. Continuous performance assessment by measuring the right thing. “Real time”
performance measurement as a natural artifact of agile processes.
5. Communicate the elements of the strategy, initiatives, capabilities, programs and
projects up and down the execution chain.
You cannot have an execution 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.
... from Execution: The Discipline of Getting Things Done, Larry Bossidy.
Results
In many principle–centered approaches to agile, results are implicit and at times left to
the 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 percent or 100 percent completion. No partial
deliveries, no partial done.
There is nothing more difficult 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
8 This idea comes from a colleague Mike Dwyer, IT Program Manager, American Healthways,
Westborough, MA.. It is used with permission.
Cutter – Agile Program Management 11/30

12. 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 Management are
applicable to the agile management
approach described here:
1. The coordinated management of a
portfolio of projects to achieve a
set of business objectives.
Agile Program Management transforms IT
strategy into portfolios of projects that
implement initiatives that deliver the required
capabilities in support of the strategy.
! 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.
The directing of a portfolio of projects
which benefit from a consolidated management approach.
The management of a portfolio of projects towards 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 – managing a portfolio of
projects through articulated programs, and managing 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:
2. Strategic level planning and program development – this activity provides long–
range planning and road map 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.
3. 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, Decision, People, and Results. This is not enough
though, since specific practices to deliver these principles must be in place before they
can be considered operational principles.
More Difficulties with Traditional Approaches and a Solution
Traditional approaches to managing IT projects start with identifying the tasks and
milestones that need to be performed, assignment of resources and budget, and
monitoring the performance of the work for compliance within the error bounds of cost,
quality and schedule.
Cutter – Agile Program Management 12/30

13. Agile Program Management connects 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 delivery of Significant Accomplishments and assessment of
Accomplishment Criteria are the units of measure for this increasing maturity rather than
the passage of time, arrival at a milestone, or consumption of resources or budget.
The Value Proposition for Agile Program Management
Agile Program Management closes the gap between strategy and execution through the
following value propositions.
! Agile Program Management connects each strategic objective to a project or program
deliverable. This connects project performance to strategy fulfillment and measures
progress through accomplishments rather than the passage of time. This approach
connects deliverables to strategy fulfillment closing the loop on the returns from IT
investments, providing a business strategy connection with technical management.
! Agile Program Management focuses on a risk and opportunity management paradigm
using portfolio management processes to address uncertainty by making explicit the
potential losses (risks) and potential gains (opportunities). These Risk and Opportunity
management processes are integrated into a single management process – Agile
Program Management.
! Agile Program Management provides a clear and actionable path between strategy and
execution. This ensures the connection between strategy and execution can adapt to the
changing needs of the enterprise. It defines and maintains a performance baseline of all
IT development and deployment efforts. Key Decision Points – on fine grained
boundaries – assess progress, alter execution, 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 activities, their increasing maturity and measurable
connection to strategy.
Balanced Scorecard as a Starting Point for Agile Program Management
Traditional measures are insufficient to
gauge performance and guide organizations
in an enterprises’ rapidly changing, complex
economic landscape. Organizations must
link performance 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 measurement system. [7] It is a
comprehensive strategic performance
management system and methodology. It is
a framework for defining, refining and communicating strategy, for translating strategy
into operational terms, and for measuring the effectiveness of strategy implementation.
Balanced Scorecard defines the objectives and
initiatives needed to fulfill the business mission
and vision.
! 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 starts with
strategy but includes assessments of progress
based on increasing maturity, not just the
passage time.
Cutter – Agile Program Management 13/30

14. Elements of Balanced Scorecard
The Balanced Scorecard describes and communicates the strategies of the organization.
Selecting the performance metrics that drive strategy. Dr. Norton describes the Balanced
Scorecard as: [15]
“A balanced scorecard is a system of linked objectives, measures, targets and initiatives 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.”
Balanced Scorecard describes strategy and performance management from four
perspectives:
Balanced
Scorecard
Perspective Key Question Connection to Agile Program Management
Financial To succeed financially, how
should we appear to our
stakeholders?
! IT budget performance describes the value delivered for
the investment
! Utilization of resources for invested cost
Customer To achieve our vision, how
should we appear to our
customers?
! What so the customers need to fulfill their strategy?
! How will the customers recognize that IT is fulfilling
their strategy?
! What are the units of measure?
Process To satisfy our customers
and shareholders, at what
business processes must we
excel?
! How can these processes be deployed with the least
impact on performance?
! For each process, when does to pay back its
investment?
Learning’s
and Growth
To achieve our vision, how
will we sustain our ability to
change and improve?
! How can we manage the people side of programs while
increasing the value to the customers?
Each strategy perspective asks and answers a key question about objectives. Performance
is judged by the progress in achieving these objectives. There is a causal relationship
between the perspectives: good performance in the Learning’s and Growth objectives 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 actionable 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 further 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 portfolio and their individual projects flow backward to the
Key Performance Indicators (KPI) of the strategy. These provide an unambiguous view
of the overall performance of the short term and long term strategies. The KPI’s should
support the targets for success that clearly quantify the desired level of performance
necessary for success of the organization.
! Connecting the Balanced Scorecard KPI’s with increasing maturity of the projects in
the portfolio closes the gap between strategy and execution.
Cutter – Agile Program Management 14/30

15. Objectives and Measures
Objectives are desired outcomes. They must to be specific, they must be measurable in
terms meaningful to the stakeholders, they must to be achievable and realistic, and they
must to 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
measures and increasing maturity.
! Success objectives – in units of accomplishment: capabilities delivered in support of a
strategic objective.
Progress toward attaining an objective is gauged by one or more measures. As with
perspectives, there are causal relationships between objectives. A causal relationship is
defined by dependencies among objectives. It is critical to set measurable, strategically
relevant, consistent, time–delineated objectives.
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 depends on
many uncertainty factors.” – Swanson's Unwritten Rules of Management, 2005, William H.
Swanson, Raytheon Company
Measures are the indicators of how a business is performing relative to its strategic
objectives. Measures, or metrics, are quantifiable performance statements. 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 well – not just a few.
The things that are done well must operate within a close nit 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 performance of the organization. [24], [26]
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 trade–offs.
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 functional units is one of the oldest ideas in strategy. It has been
supplanted with new concepts of core competencies, critical resources and key success
Cutter – Agile Program Management 15/30

16. factors. 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 execution starts with identifying which objectives are used to
construct a collection of projects in a portfolio. 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 provides the glue between strategy and execution. Starting
with 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 business leadership team with a capability to:
! Build consensus and commitment 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 stewardship from all stakeholders.
Before IT projects can be identified 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 one means of integrating these needs:
! 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.
! This “value creation” process is more than just “keeping on schedule.” It is about
understanding the business needs.
! This understanding comes from “knowing” the business beyond specifying the
technical details of a software system.
! The IT leader must be an integral part of the process development process.
Cutter – Agile Program Management 16/30

17. Four Components of IT Strategy
Connecting strategy with execution means discovering the hypothesis of a strategy – the
business strategies that must be tested – and constructing business systems to implement
these strategies and the associated tests. Some sample strategy testing hypothesis might
be:
! If a firm provides training to the customer service staff, it will install the skills needed
to develop an “up selling” opportunity with its customers;
! If a firm delivers products faster to the market place than its competitors then it would
expect an in crease 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 must be considered in Agile Program Management. Each
strategy element must be addressed in the following processes – (a) Capabilities Based
Planning, (b) Integrated Master Scheduling, and (c) 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 participants in each organization and the
informal behind the scenes participants.
2. Information System Strategy – the behavioral aspects of the system which support,
promote, or enhance the business activities.
3. Information Technology Strategy – the actual computing systems, their
architectures, operation and maintenance. Although focused on the physical
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 database contents and the
work processes built around them.
These IT Strategy components are based on the physical and logical technologies of the
IT Infrastructure, the value of the data managed by the infrastructure and the
consumption of this data. These components describe: how, what, when, and where the
technology of the IT Strategy is to be deployed. In order to complete the IT Strategy, the
influences of these technologies on the organizational aspects of the business must be
understood. The questions asked and answered while developing the strategy include:
! What IT applications should be deployed to provide a needed capability?
! What technological opportunities 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?
Cutter – Agile Program Management 17/30

18. Agile Portfolio Management
Portfolio Management is the means of
aligning implementation projects that deliver
The management of portfolios of projects
business value with strategy.
provides the glue between strategy and the
operational benefits to the organization.
Several gaps appear between the formation
! Selection, assessment, and performance
of strategy and the eventual delivery of
management of portfolios is the starting process
systems to the users. In traditional IT
for connecting strategy with execution.
management, technology and business are
! Membership in a portfolio requires a project be
readily visible to senior management.
directly traceable to a strategic objective.
What’s missing is visibility into the activities in the “white space” between technology
and business. Managing these gaps is the role of IT Governance.
! An alignment gap appears when IT investments are not traceable to business strategy.
! An execution gap appears when those tasked with delivering IT products and services
don’t have a clear “line of sight” to the corporate strategy.
! An innovation gap appears when IT leadership and staff are not connected to the needs
of the market, emerging technologies and the investment strategies for future needs.
Increasing Maturity is an Agile Approach to Deployment
Rarely does a collection of projects provide its solution in a big bang manner –
everything is available in one day. A set of capabilities that increase in maturity provides
an adaptive, incremental, and iterative manner.
The first approach assumes that these capabilities mature as time passes. A more mature
approach is to measure the increasing maturity of the capabilities through the delivery of
technical performance from the efforts of the project. These Technical Performance
Measures provide a quantifiable means to measure progress, rather than just the passage
of time. 9
Direct Benefits of Agile Project Portfolio Management
1. Serve clients better by monitoring and reporting on projects.
2. Establish credible project screening and selection processes, to provide
decision support for the Portfolio Management Team
3. Raise visibility of projects and their progress by creating an easily
accessible repository for project and program information
4. Institute simple, repeatable and sustainable processes to better manage the
delivery of valuable solutions on behalf of clients
5. Provide long–range planning for a stream of projects, enabling IT to better
plan its staffing, resources and schedule
9 Projects where the passage of time is the measure of progress are called Level of Effort. The fundamental
problem with Level of Effort management is it does not measure performance of the project, just the
passage of time.
Cutter – Agile Program Management 18/30

19. 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 performance 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 dealt with. Using the traditional linear phase–
centric approach to project management these assumptions emerge and negatively impact
a portfolio’s ability to deliver value:
1. Planning – it 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
predefined order. In fact planning is a continuous process whose changes are
driven by the delivery of software into the hands of the users.
2. Change – it 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 solutions in the software
development domains. 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
commit. In fact by making this commitment, they give up the ability to take
advantage of fortuitous developments in the business and technology
environment.
The traditional project management 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 knowledge. They are independent of any
specific application of this knowledge – that is they are domain independent. Finally they
assume the underlying processes are stable 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: [3], [4]
! Clear–cut investment opportunities exist with an explicit purpose, 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 acceptable project attributes can be identified early in its
lifecycle.
! Accurate predictions of project 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, suitability, or acceptability of the solution.
Cutter – Agile Program Management 19/30

20. The Next Phase of Agile Program Management – Planning the Work
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 software 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
origins in economics as popularized by Michael Porter’s Competitive Advantage, The
Free Press, 1985.
There are problems with this transformational approach to project 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 stakeholder’s requirements. Defining value-creating activities is
not provided by normative methods. The normative approach provides very little
direction in defining what NOT to do during the work process, preventing the
minimization of time and resources.
Plans are nothing, planning is everything – D. W. Eisenhower, quoting 19th century Prussian
General Helmuth von Moltke
Another approach is to see project management as a flow process. In this paradigm the
goal is to eliminate waste, lead time reduction, make versus buy, simplification,
variability reduction are all activities found in this paradigm. Just–in–time manufacturing
is one example of flow based project 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” processes 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 integrates four concurrent processes to deliver address the
gaps in the traditional approach to program management and IT project deployment.
Principle Outcome of the Principle Practice to Implement the Principle
Strategies define the desired outcome Balanced Scorecard
Portfolios manage the delivery of capabilities Project Portfolio Management
Capabilities enable the strategy Capabilities Based Planning
Plans manage the delivery effort Event Based Scheduling
10 One side bar discussion among the normative body of knowledge adherents is that software development
methods like RUP, DSDM, SCRUM, and XP are not PM 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.
Cutter – Agile Program Management 20/30

21. The theme here is to build a connection between each process paradigm for delivering IT
projects to the stakeholders, not just imposed 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 Scorecard Strategy,
The capabilities needed to deliver value in
support of a strategy replaces the simple delivery
Business Process Improvement, and Agile
of features and functions
Program Management. Capabilities
provide a defined outcome that is not a
! Tracing value to strategy requires that features
and functions be replaced by capabilities.
final conclusion; but lays the ground work
! Capabilities lay the ground work for adapting to
for the continued delivery of value. [26]
change.
Objectives are reached and the operational
! Features and functions fulfill the stated
value delivered when a defined capability
requirements from the past.
is available for use. Features and
! Capabilities fulfill the unstated requirements of
Functions describe the static and dynamic
the future.
behaviors of a system, but they are not directly connected to the business strategy.
Milestones indicate that a position in a timeline has been reached. Capabilities provide
the answer to the question – in order to achieve our objectives what capability must be
possess?
Capabilities Based Planning transforms the delivery of features and functions into
delivery processes that support strategy in the presence 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 flexibility, 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
without explicit specification of the solution. A capability is the ability to affect an
outcome, react to an input, or change an effect. An example of a before and after
statement is of a need:
! Before (features and functions): We will install the General 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 $100M 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.
Cutter – Agile Program Management 21/30

22. 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:
1. Identify a needed
Figure 3 – Capabilities Based Planning starts with business
scenarios, the tasks needed to implement the scenarios and the
testable capability outcomes
capability in operational terms;
2. Using the set of capability options to;
3. Assess the effectiveness in a operations paradigm, and;
4. Make choices about requirements and the ways to achieve the capability using an
integrated portfolio framework;
5. To produce of output set of options based on these operational paradigms.
Putting Capabilities Based Planning 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 objectives in a Balanced
Scorecard. While popular in decision making processes, we must distinguish between
two situations:
! Finding alternatives
! 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 parameters 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 understanding of the relations and impact on other scenarios. Capabilities provide
a collection point to consolidate scenarios by systematically defining operational
Cutter – Agile Program Management 22/30

23. concepts and their relationships, with each capability defining the compelling rationale
for decisions found in a portfolio of projects.
Augmenting Balanced Scorecard with Capabilities
Balanced Scorecard is augmented through a capabilities based planning process by
mapping strategies to assessment 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 strategy. Planning under uncertainty, provides
capabilities suitable for a wide range of challenges and circumstances while working
within an economic framework that necessitates choice where the focus is on “possible
uses” rather than specified features and functions:
! “What features do we need to achieve the desired capabilities?”
! “How much of each capability to we need at this point in time?”
! “How robust, flexible, and capable should we be at a point time to provide the needed
capability?”
The difference between a capability and function is the difference between the delivery of
a solution and the creation of the foundation responding to a variety of uncertain
demands.
! Focus on the outcomes rather than the features of an IT system.
! Focus on the underlying tasks that produce outcomes.
! Define the needed maturity and assess its presence to provide feedback to the business
strategy in ways simple Balanced Scorecard KPI’s can not.
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 capabilities 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 the 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 Opportunities along the path to maturity:
! Significant accomplishments enable a new capability to support a strategy.
! The maturity of the derived effects are assured through the assessment of the
Significant Accomplishment
Cutter – Agile Program Management 23/30

24. Integrated Master Scheduling (IMS) 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.
IMS is a systematic approach to connecting
strategy with execution through measurable
progress in units of “maturity” rather than
the passage of time. The agile program
manager and the constituents can ask and
answer the critical question – “are the
capabilities planned to be delivered actually
being delivered in a form that supports the strategic objectives?”
Addressing Uncertainty with Event Based Scheduling
Uncertainty is in inevitable outcome 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, layout sequential iterations to assure everyone on the project is
on the same page before proceeding to the next step.
The Program Events and their supporting Accomplishments and Criteria define the path
to increasing levels of maturity to the fulfillment of an Enterprise’s Strategic Objectives.
Connecting these objectives to portfolios of projects is done through three (3) individual
elements of the Integrated Master Schedule (IMS):
The IMS Element The Purpose of the IMP Element
State of the
Program
Integrated Master Scheduling provides the
means to measure progress as a function of
increasing maturity rather than the simple
passage of time.
! 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 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.
Program Event – is 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: at what level of maturity must the
program reach to provide the desired set of capabilities in support of an
Enterprise Strategic Objective?
State of the
Product
Significant Accomplishment – is the specified results, substantiating an Event,
which indicates the maturity (or progress) level for ach product or process.
Generally these discrete steps in the progress of the development 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?
State of the
Process
Accomplishment Criteria – are 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 5 – The Integrated Master Schedule defines the framework for the program 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.
Cutter – Agile Program Management 24/30

25. Evaluation of Program Maturity
The concept of evolving the maturity of a program is likely new to the IT community
applying Project Portfolio Management. The maturity discussed here is not the same
maturity found in the Capability Maturity Model of the Software Engineering Institute.
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 consumption 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 demonstrate the
quality and completion of the Significant
Accomplishments at each release cycle.
! Progress is measures by the successful
completion of a series of iterations that produce
value
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 Schedule approach
starts at the end and works backward to the
beginning of the project. At each step
backward 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 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 Planning 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.
Success Criteria Defined in the Event Structure
Events measure the increasing maturity of the program. This maturity describes how the
capabilities defined in the strategy and objectives are being developed over time. Each
capability should be connected to a strategy or objective statement.
With the capability of closing the month end books in 3 working days, we will be able to
acquire a $100M business and have their books integrated in 30 days.
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.
Cutter – Agile Program Management 25/30

26. 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 measurement:
! The passage of time is a poor measure of progress. Delivery of tangible evidence of
progress through physical maturity connects progress with strategy assessment.
! Defined accomplishments provide measurable outcomes. The measure of progress is
through a 100% or 0% assessment – either the delivery was made or it was not.
! The accomplishments should be fine grained enough to be described as 0% or 100%
complete. By fine grained it means short duration (10 to 40 working days – 2 to 8
week calendar time) effort. This approach reinforces the core tenants of any agile
process – continuous feedback of progress, value and compliance with strategy.
! Accomplishment Criteria are used to define the “exit criteria” for each
accomplishment.
! The Exit Criteria are 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 portfolio of projects, and assess both risk and opportunities.
Using Integrated Master Schedule Vocabulary for Dealing with Change
The discovery of the
unpredictable and
Product
Maturity
Action
Product
State
undeterministic
introduces variance. This
variance introduces
Adjective
Verb
Noun
Verb
change in plans. Change
Demonstrates
Closure
Maturity Step in the Process
End Item
Perform
State
Work
in plans means
Preliminary Design
Bus Structure
Completed
“managing in the
presence of change.”
““A01B02a: Preliminary Design Review of Bus Structure Completed””
The concept of managing
in the presence of this
variance is preferable to
Figure 5 – Integrated Master Schedule states the increasing maturity of
trying to control the
the program through the Program Events, Significant Accomplishments,
variance. This is a critical
and Accomplishment Criteria.
attribute of Agile Program Management.
Adapting to change is critical to any program or project management process, whether it
is considered agile or not. In a program management environment changes to the plan
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 deliverables. By testing each decision against the
strategy, the project stays focused on significant accomplishments in support of a
program event.
Cutter – Agile Program Management 26/30

27. 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 opportunities is enabled through a strategy focused assessment
process. At each Significant Accomplishment an assessment of new opportunities
must be taken. This is the way to provide the adaptability needed at the program
level.
! When change agents are encountered – market forces, technology impacts,
programmatic performance shortfalls – new opportunities present themselves in the
form of reassessment of the strategy, 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. [11] Attempting to control
uncertainty and the risks that result from this uncertainty creates a major disconnect
between expectations and reality. The erroneous assumption is that risk and uncertainty
can be managed in ways that allow predictive schedules to be built.
Type of
Uncertainty Characteristics Agile Processes
Normal
Variation
! 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
! 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
Foreseen
Uncertainty
! Uncertainties that are identified but
have uncertain influences.
! Contingent paths forward
! Decision tree based on alternative
plans
! Proactive risk management
Unforeseen
Uncertainty
! Events that can not be identified during
the planning process
! New problem solving required to
develop an appropriate response
Chaos ! The basic structure of the project is
unstable, with no ability to forecast the
occurrence of these uncertainties
! 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 6 – Uncertainties are present in all projects. Agile Program Management processes are capable of
dealing with each the uncertainty type through specific practices derived from the four principles.
Cutter – Agile Program Management 27/30

28. The Contingent Approach to Program Management
There is more value to categorizing uncertainty than would appear at first. Each
uncertainty type needs a different management approach, to deal with not only the
uncertainty, but the risks that emerge when the uncertainty becomes operational. [11]
Putting it All Together
With this brief overview of Agile Program Management, IT organizations can make
changes in how programs and projects are connected to strategy. First let’s review the
components of Agile Program Management:
Principle Outcome of the Principle Practice to Implement the Principle
Strategies define the desired outcome Balanced Scorecard
Portfolios manage the delivery of capabilities Project Portfolio Management
Capabilities enable the strategy Capabilities Based Planning
Plans manage the delivery effort Event Based Scheduling
Each agile principle results in a practice. There are several critical concepts in putting
these practices to work:
1. Agile practices must be kept close to principles. Interpretation of the practices in
ways not implied by the principle leads to poor results. A clear and concise
understanding of the principles is need in addition to the skills of putting the
practice to work.
2. 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 decision is a starting point. There may be other units of measure but “money”
seems to be the most acceptable one.
3. 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]
4. Nimble, dexterous, and swift,
5. adaptive and responsive to new, sometimes unexpected, information that becomes
available during the projects lifecycle,
6. 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 Scorecard, Project Portfolio
Management, Capabilities Based Planning, and Integrated Master Scheduling to create
these characteristics in support of the principles of Vision, Value, Decision, People and
Results.
Agile Program Management Connects Practices to Principles
Cutter – Agile Program Management 28/30

29. Bibliography
1. Allen, Thomas, Deborah Nightingale and Earl Muman, “Engineering Systems: An
Enterprise Perspective,” Engineering Systems Monograph, MIT Engineering
Systems Division, March, 2004.
2. Ambrose, Stephen, Undaunted Courage: Meriwether Lewis, Thomas Jefferson
and the Opening of the West, Simon & Schuster, 1997.
3. Austin, Robert D. and Richard L. Nolan, “How to Manage ERP Initiatives,”
Working Paper 99–024, 1998.
4. Armour, Phillip, “Ten Unmyths of Project Estimation,” Communications of the
Associated of Computing Machinery, Vol. 45, No. 11., November 2002, pp. 15–
18.
5. Birnbaum, William, Strategic Thinking: A Four Part Puzzle, Douglas Mountain
Publishing, 2004
6. Bossidy, Larry, Execution: The Discipline of Getting Things Done, Crown
Business, 2002.
7. Brock, Susan, Danyal Hendricks, Stephen Linell, and Derek Smith, “A Balanced
Approach to IT Management,” Proceedings of SAICSIT 2003, pp. 2–10.
8. Caminiti, S. 1995. “What team leaders need to know,” Fortune, Feb 20: 94, 100.
9. Collins, Jim, Good to Great: Why Some Companies Make the Leap…and Other’s
Don’t, Harper Collins, 2001.
10. Fitzgearld, Donna, “Principle – Centered Agile Project Portfolio Management,”
Cutter Consortium, Vol. 6, No. 5.
11. de Meyer, Arnoud, Christoph Loch and Michael Pich, “Uncertainty and Project
Management: Beyond the Critical Path Mentality,” INSEAD Working Papers,
2001/04/TM.
12. Haberfellner, Reinhard and Olivier de Weck, “Agile SYSTEMS ENGINEERING
versus AGILE SYSTEMS engineering,” Fifteenth Annual International
Symposium of the International Council of Systems Engineering (INCOSE), 10
July to 15 July 2005.
13. Highsmith, Jim, “Agile for Enterprise: From Agile Teams to Agile
Organizations,” Cutter Executive Report, Volume 6, Number 1.
14. Jabagehourian, Harry and Robert Cvetko, “Risk & Opportunity Management:
Program & Project Management Success Factors,” Fourth International
Symposium on Space Risk Management, May 21–24, 2002, McLean Virginia.
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, May/June 2005, pp. 43–49.
17. Kennedy, John Fitzgearld, Special message to Congress on urgent national needs,
May 25, 1961, www.jfklibrary.org/j052561.htm
Cutter – Agile Program Management 29/30

30. 18. Koffi, Atiogbe Dider, “A Model for the Evolution of Software and Systems
Engineering Project Cultures Throughout Their Lifecycles,” Systems Engineering
Journal, Vol. 8, No. 2, 2005.
19. Koskela, Lauri, “An exploration towards a production theory and its application
to construction,” Espoo, VTT Building Technology. 296 p. VTT Publications;
408. http://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. Person and Kimberly A. Furomo, “IS Project
Management: Size, Complexity, Practices and the Project Management Office,”
Proceedings of the 38th Hawaii International Conference on System Sciences,
2005.
23. McFarlan, F. W., “Portfolio Approach to Information Systems,” Harvard
Business Review, 59(5), pp. 142–150, 1981
24. Porter, M. E., “What is Strategy,” Harvard Business Review, Volume 74, Number
6, pp. 61–78.
25. “Three Reasons Why Good Strategies Fail: Execution, Execution, …, Wharton
Strategic Management, August 10, 2005, Knowledge @ Warton,
http://knowledge.wharton.upenn.edu/
26. “Guide to Capabilities Based Planning, The Technical Cooperation Program,”
Joint Systems and Analysis Group, Technical Panel 3.
27. Welch, J. and J. C. Lowe, Jack Welch Speaks: Wisdom from the World’s Greatest
Business Leader, John Wiley & Sons, 1998.
Acknowledgements
Donna Fitzgerald of Knowth Consulting worked diligently on the themes, framework and
major structure of this paper. The success of this material is due in part to her efforts.
Mike Dwyer is an IT Program Manager at American Healthways, Westborough, MA.
Mike provided valuable input for small typos to major concepts about performance
management.
Biography
Glen B. Alleman consults as a Program Management process Architect (Integrated
Master Plan / Integrated Master Schedule) in a Denver defense and aerospace firm. Over
the past 25 years Glen has led Program Management Offices, software product
development organizations, and ERP deployment projects. His current interests include
Integrated Product Team (IPT) deployments of Microsoft Project Server, integration of
schedule and cost for enterprise programs and probabilistic risk assessment integration.
As well Glen consults in the system architecture, business process improvement, and
Program Management Office deployment fields.
Cutter – Agile Program Management 30/30