SlideShare a Scribd company logo
1 of 30
Download to read offline
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

More Related Content

What's hot

What's hot (20)

EVM+Agile the darkside
EVM+Agile the darksideEVM+Agile the darkside
EVM+Agile the darkside
 
Deliverables based planning handbook
Deliverables based planning handbookDeliverables based planning handbook
Deliverables based planning handbook
 
Project portfolio management
Project portfolio managementProject portfolio management
Project portfolio management
 
The 5 Immutable principles of project management
The 5 Immutable principles of project managementThe 5 Immutable principles of project management
The 5 Immutable principles of project management
 
Strategic portfolio management
Strategic portfolio managementStrategic portfolio management
Strategic portfolio management
 
Program Management Office
Program Management OfficeProgram Management Office
Program Management Office
 
Five immutable principles
Five immutable principlesFive immutable principles
Five immutable principles
 
NAVAIR Integrated Master Schedule Guide guide
NAVAIR Integrated Master Schedule Guide guideNAVAIR Integrated Master Schedule Guide guide
NAVAIR Integrated Master Schedule Guide guide
 
CMMI and Agile
CMMI and AgileCMMI and Agile
CMMI and Agile
 
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
A Workshop for Product Owners, Scrum Masters, and Team Members for Improving ...
 
Increasing the Probability of Project Success with Five Principles and Practices
Increasing the Probability of Project Success with Five Principles and PracticesIncreasing the Probability of Project Success with Five Principles and Practices
Increasing the Probability of Project Success with Five Principles and Practices
 
Earned value, XP and government contracts
Earned value, XP and government contractsEarned value, XP and government contracts
Earned value, XP and government contracts
 
Successfully Integrating Agile and Earned Value
Successfully Integrating Agile and Earned ValueSuccessfully Integrating Agile and Earned Value
Successfully Integrating Agile and Earned Value
 
Earned Value Management and Agile
Earned Value Management and AgileEarned Value Management and Agile
Earned Value Management and Agile
 
Agile at scale resources
Agile at scale resourcesAgile at scale resources
Agile at scale resources
 
Improving Project Performance in the DOE
Improving Project Performance in the DOEImproving Project Performance in the DOE
Improving Project Performance in the DOE
 
Capabilities based planning
Capabilities based planningCapabilities based planning
Capabilities based planning
 
Agile in the government
Agile in the government Agile in the government
Agile in the government
 
Building the perfect schedule (v6)
Building the perfect schedule (v6)Building the perfect schedule (v6)
Building the perfect schedule (v6)
 
EDM/PDM Implementation
EDM/PDM ImplementationEDM/PDM Implementation
EDM/PDM Implementation
 

Viewers also liked

Leading on the edge
Leading on the edgeLeading on the edge
Leading on the edge
Glen Alleman
 
Agile project management is systems management
Agile project management is systems managementAgile project management is systems management
Agile project management is systems management
Glen Alleman
 
Leaf litter community
Leaf litter communityLeaf litter community
Leaf litter community
alanpillay79
 
Ev+agile=success (final v2)
Ev+agile=success (final v2)Ev+agile=success (final v2)
Ev+agile=success (final v2)
Glen Alleman
 

Viewers also liked (20)

Measurement News Webinar
Measurement News WebinarMeasurement News Webinar
Measurement News Webinar
 
Managing in the presence of uncertainty
Managing in the presence of uncertaintyManaging in the presence of uncertainty
Managing in the presence of uncertainty
 
Control systems
Control systemsControl systems
Control systems
 
5 immutable principles and 5 processes in 60 seconds
5 immutable principles and 5 processes in 60 seconds5 immutable principles and 5 processes in 60 seconds
5 immutable principles and 5 processes in 60 seconds
 
Leading on the edge
Leading on the edgeLeading on the edge
Leading on the edge
 
Agile project management is systems management
Agile project management is systems managementAgile project management is systems management
Agile project management is systems management
 
Agile Project Management for ERP Projects
Agile Project Management for ERP ProjectsAgile Project Management for ERP Projects
Agile Project Management for ERP Projects
 
Earning value from risk (v4 full charts)
Earning value from risk (v4 full charts)Earning value from risk (v4 full charts)
Earning value from risk (v4 full charts)
 
Subphylum mandibulata (By: J.Q)
Subphylum mandibulata (By: J.Q)Subphylum mandibulata (By: J.Q)
Subphylum mandibulata (By: J.Q)
 
Farmer Al's problem
Farmer Al's problemFarmer Al's problem
Farmer Al's problem
 
Leaf litter community
Leaf litter communityLeaf litter community
Leaf litter community
 
Governance
GovernanceGovernance
Governance
 
Performance based planning in a nut shell (V5)
Performance based planning in a nut shell (V5)Performance based planning in a nut shell (V5)
Performance based planning in a nut shell (V5)
 
Tell a memorable story
Tell a memorable storyTell a memorable story
Tell a memorable story
 
Nine Best Practices
Nine Best PracticesNine Best Practices
Nine Best Practices
 
Introduction to monte-carlo analysis for software development - Troy Magennis...
Introduction to monte-carlo analysis for software development - Troy Magennis...Introduction to monte-carlo analysis for software development - Troy Magennis...
Introduction to monte-carlo analysis for software development - Troy Magennis...
 
Ev+agile=success (final v2)
Ev+agile=success (final v2)Ev+agile=success (final v2)
Ev+agile=success (final v2)
 
Capabilities Based Planning
Capabilities Based PlanningCapabilities Based Planning
Capabilities Based Planning
 
Evm+agile estimating
Evm+agile estimatingEvm+agile estimating
Evm+agile estimating
 
The integrated master plan and integrated master schedule
The integrated master plan and integrated master scheduleThe integrated master plan and integrated master schedule
The integrated master plan and integrated master schedule
 

Similar to Agile Program Management - Moving from Principles to Practices

IT portfolio
IT portfolioIT portfolio
IT portfolio
mkhaled1
 
Whitepaper - Effective Business Analysis
Whitepaper - Effective Business AnalysisWhitepaper - Effective Business Analysis
Whitepaper - Effective Business Analysis
Peter Bricknell
 
UMT_PMI-ATL Governance Agility_Final
UMT_PMI-ATL Governance Agility_FinalUMT_PMI-ATL Governance Agility_Final
UMT_PMI-ATL Governance Agility_Final
Ludvic Baquie
 

Similar to Agile Program Management - Moving from Principles to Practices (20)

Agile Program Management: Moving from Principles to Practice
Agile Program Management: Moving from Principles to PracticeAgile Program Management: Moving from Principles to Practice
Agile Program Management: Moving from Principles to Practice
 
Insights and Trends: Current Portfolio, Programme, and Project Management ...
Insights and Trends:  Current Portfolio,  Programme, and Project  Management ...Insights and Trends:  Current Portfolio,  Programme, and Project  Management ...
Insights and Trends: Current Portfolio, Programme, and Project Management ...
 
IGrafx Performance Management Whitepaper
IGrafx Performance Management WhitepaperIGrafx Performance Management Whitepaper
IGrafx Performance Management Whitepaper
 
I Grafx Performance Management Whitepaper
I Grafx Performance Management WhitepaperI Grafx Performance Management Whitepaper
I Grafx Performance Management Whitepaper
 
IT portfolio
IT portfolioIT portfolio
IT portfolio
 
Whitepaper - Effective Business Analysis
Whitepaper - Effective Business AnalysisWhitepaper - Effective Business Analysis
Whitepaper - Effective Business Analysis
 
The Seven Enablers & Constraints Of IT Service Management - Research Update 2011
The Seven Enablers & Constraints Of IT Service Management - Research Update 2011The Seven Enablers & Constraints Of IT Service Management - Research Update 2011
The Seven Enablers & Constraints Of IT Service Management - Research Update 2011
 
The 7 enablers and constraints of itsm 2011 v1 final
The 7 enablers and constraints of itsm 2011 v1 finalThe 7 enablers and constraints of itsm 2011 v1 final
The 7 enablers and constraints of itsm 2011 v1 final
 
The Road to IT Governance Excellence
The Road to IT Governance ExcellenceThe Road to IT Governance Excellence
The Road to IT Governance Excellence
 
Efficacy of Project Management,
Efficacy of Project Management, Efficacy of Project Management,
Efficacy of Project Management,
 
EFFICACY OF PROJECT MANAGEMENT
EFFICACY OF PROJECT MANAGEMENTEFFICACY OF PROJECT MANAGEMENT
EFFICACY OF PROJECT MANAGEMENT
 
Msc Graduating project : The agile method of management
Msc Graduating project : The agile method of managementMsc Graduating project : The agile method of management
Msc Graduating project : The agile method of management
 
PM Chapter on Agile IT Project Management Methods
PM Chapter on Agile IT Project Management MethodsPM Chapter on Agile IT Project Management Methods
PM Chapter on Agile IT Project Management Methods
 
operatingmodelandorganizationdesigntoolkit-overviewandapproach-211220031125.pdf
operatingmodelandorganizationdesigntoolkit-overviewandapproach-211220031125.pdfoperatingmodelandorganizationdesigntoolkit-overviewandapproach-211220031125.pdf
operatingmodelandorganizationdesigntoolkit-overviewandapproach-211220031125.pdf
 
Operating Model and Organization Design Toolkit
Operating Model and Organization Design Toolkit Operating Model and Organization Design Toolkit
Operating Model and Organization Design Toolkit
 
Holistic data governance frame work whitepaper
Holistic data governance frame work whitepaperHolistic data governance frame work whitepaper
Holistic data governance frame work whitepaper
 
UMT_PMI-ATL Governance Agility_Final
UMT_PMI-ATL Governance Agility_FinalUMT_PMI-ATL Governance Agility_Final
UMT_PMI-ATL Governance Agility_Final
 
The Principles of Effective P3 Governance - AXELOS Webinar
The Principles of Effective P3 Governance - AXELOS WebinarThe Principles of Effective P3 Governance - AXELOS Webinar
The Principles of Effective P3 Governance - AXELOS Webinar
 
he Principles of Effective Project, Programme and Portfolio Management Govern...
he Principles of Effective Project, Programme and Portfolio Management Govern...he Principles of Effective Project, Programme and Portfolio Management Govern...
he Principles of Effective Project, Programme and Portfolio Management Govern...
 
ISO_6
ISO_6ISO_6
ISO_6
 

More from Glen Alleman

More from Glen Alleman (20)

Managing risk with deliverables planning
Managing risk with deliverables planningManaging risk with deliverables planning
Managing risk with deliverables planning
 
A Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMSA Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMS
 
Increasing the Probability of Project Success
Increasing the Probability of Project SuccessIncreasing the Probability of Project Success
Increasing the Probability of Project Success
 
Process Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPMProcess Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPM
 
Practices of risk management
Practices of risk managementPractices of risk management
Practices of risk management
 
Principles of Risk Management
Principles of Risk ManagementPrinciples of Risk Management
Principles of Risk Management
 
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
 
From Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems EngineeringFrom Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems Engineering
 
Building a Credible Performance Measurement Baseline
Building a Credible Performance Measurement BaselineBuilding a Credible Performance Measurement Baseline
Building a Credible Performance Measurement Baseline
 
Integrated master plan methodology (v2)
Integrated master plan methodology (v2)Integrated master plan methodology (v2)
Integrated master plan methodology (v2)
 
IMP / IMS Step by Step
IMP / IMS Step by StepIMP / IMS Step by Step
IMP / IMS Step by Step
 
DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)
 
Making the impossible possible
Making the impossible possibleMaking the impossible possible
Making the impossible possible
 
Process Flow and Narrative for Agile
Process Flow and Narrative for AgileProcess Flow and Narrative for Agile
Process Flow and Narrative for Agile
 
Building the Performance Measurement Baseline
Building the Performance Measurement BaselineBuilding the Performance Measurement Baseline
Building the Performance Measurement Baseline
 
Program Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six SigmaProgram Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six Sigma
 
Policy and Procedure Rollout
Policy and Procedure RolloutPolicy and Procedure Rollout
Policy and Procedure Rollout
 
Integrated Master Plan Development
Integrated Master Plan DevelopmentIntegrated Master Plan Development
Integrated Master Plan Development
 
Project Management Theory
Project Management TheoryProject Management Theory
Project Management Theory
 
Paradigm of agile project management (update)
Paradigm of agile project management (update)Paradigm of agile project management (update)
Paradigm of agile project management (update)
 

Recently uploaded

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 

Recently uploaded (20)

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
 
Exploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with MilvusExploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with Milvus
 
[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf
 
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
 
MS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectorsMS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectors
 
Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfBoost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)
 
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost SavingRepurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
 
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdfRising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistan
 
AWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of TerraformAWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of Terraform
 
MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024
 
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
 
Artificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyArtificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : Uncertainty
 
Strategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherStrategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a Fresher
 
WSO2's API Vision: Unifying Control, Empowering Developers
WSO2's API Vision: Unifying Control, Empowering DevelopersWSO2's API Vision: Unifying Control, Empowering Developers
WSO2's API Vision: Unifying Control, Empowering Developers
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
 
Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
 

Agile Program Management - Moving from Principles to Practices

  • 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