agile program management - moving from principles to practices

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.

Cutter – Agile Program Management 2/30

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


Agile Program Management: Moving from Principles to Practice Every segment of industry and government is under pressure to reduce cost, increase quality, and deliver value to owners, customers and constituents. The IT community is no exception. CIO’s, product managers and operational leaders are expected to provide solutions that address these improvement initiatives in the presence of a constant, rapid and unpredictably changing environment. These initiatives result in a mandate to deliver the best value IT products and services, on time / on cost, that meet emerging business, regulatory, and technology requirements. The processes used to place IT systems into operation must meet or exceed the strategic objectives of the enterprise, while addressing this effort in the presence of every increasing 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 the skills and experience needed to make trade–offs on the road to success has become difficult. This report completes the final piece of the hierarchy for efficient management of IT. Donna Fitzgerald’s “Principle–Centered Agile Project Portfolio Management,” [10] and Jim Highsmith’s “Agile for the Enterprise,” [13] complete this series on agile IT management processes.

Agile Program Management joins strategy and execution to deliver value through testable outcomes, measures of increasing maturity, and continuous feedback ! Business strategy provides the starting point

for selecting portfolios of projects and defining their beneficial outcomes.

! Defining the capabilities identified in the strategy lays the foundation defining the delivered value to the enterprise.

! Event based scheduling provides the needed project performance management process to assess the increasing maturity of the program in delivering value needed for a successful strategy.

One of the most dangerous forms of human error is forgetting what one is trying to achieve – Paul Nitze

CapabilitiesBasedPlanning

ProjectPortfolio

ManagementBala

nced

Scoreca

rd

Event

Based

Tasks

Business

Mission

And

Vision

“Done”“Demand” Figure 1 – Agile Program Management contains five major elements, each supporting and enhancing the others to deliver beneficial business outcomes derived from connecting strategy to execution.


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.


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 statement of program’s requirements

A statement of work, work breakdown structure or Requirements Specification

Extract initiatives from strategy through capabilities, followed by initiatives, then portfolios, then projects.

Unrealistic expectations due to estimating difficulties and organizational politics

Project plans, Organizational Breakdown Structure (OBS), Responsibility Assignment Matrix (RAM).

Gain consensus on the needed capabilities, defined through Program Events, Significant Accomplishment and Accomplishment Criteria.

Lack of program decomposition to the project level

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.


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 Program Management Principles

A study of 72 IT firms revealed several attributes of project management critical to connecting strategy with execution [3], [7]:

! Scope, Time and Quality – continuous assessment and evaluation of scope and quality through fine grained feedback allows intervention before budget or time overruns appear.

! Cost, Quality and Human Resource 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.

Traditional Methods Agile methods Planning drives results Results drive planning Delivery focused on planned results

Delivery focused on assessable results

Defined process steps Self–organizing process steps

Progress measured by the passage of time

Progress measured by increasing maturity

Quality measured at the point of delivery

Quality measured on continuous fine grained boundaries

Table 2 – From the attributes of project management, differences between Traditional and Agile program management emerge.


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 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.

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.


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

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]

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.

Figure 2 – The Five principles of Agile Program Management can be arranged to convey the feeling of continuous motion, interaction, support of a vision.


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


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].


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.


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.

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.

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.


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.


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.


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


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.


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?


Agile Portfolio Management Portfolio Management is the means of aligning implementation projects that deliver business value with strategy. Several gaps appear between the formation of strategy and the eventual delivery of systems to the users. In traditional IT management, technology and business are readily visible to senior management. 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.

The management of portfolios of projects provides the glue between strategy and the operational benefits to the organization. ! Selection, assessment, and performance

management of portfolios is the starting process for connecting strategy with execution.

! Membership in a portfolio requires a project be directly traceable to a strategic objective.


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.


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.


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, Business Process Improvement, and Agile Program Management. Capabilities provide a defined outcome that is not a final conclusion; but lays the ground work for the continued delivery of value. [26] Objectives are reached and the operational value delivered when a defined capability is available for use. Features and Functions describe the static and dynamic behaviors of a system, but they 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.

The capabilities needed to deliver value in support of a strategy replaces the simple delivery of features and functions ! Tracing value to strategy requires that features

and functions be replaced by capabilities. ! Capabilities lay the ground work for adapting to

change. ! Features and functions fulfill the stated

requirements from the past. ! Capabilities fulfill the unstated requirements of

the future.


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 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

Figure 3 – Capabilities Based Planning starts with business scenarios, the tasks needed to implement the scenarios and the testable capability outcomes


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


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

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.

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.


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)

Detailed Task

Detailed Task

Detailed Task

Detailed Task

Accomplishment Criterion








Figure 4 – the Integrated Master Schedule describes the Significant Accomplishments and the Accomplishment Criteria needed to assess the increasing maturity of the program.


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 undeterministic introduces variance. This variance introduces change in plans. Change in plans means “managing in the presence of change.”

The concept of managing in the presence of this variance is preferable to trying to control the variance. This is a critical attribute of Agile Program Management.

Adapting to change is critical to any program or project 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.

PerformWork

MaturityMaturity

Adjective

ActionAction

Verb

DesignPreliminary

ProductProduct

Noun

Bus Structure

Demonstrates Maturity End Item

“A01B02a: Preliminary Design Review of Bus Structure Completed”“A01B02a: Preliminary Design Review of Bus Structure Completed”

Step in the Process

ProductState

ProductState

Verb

Completed

Closure State

Figure 5 – Integrated Master Schedule states the increasing maturity of the program through the Program Events, Significant Accomplishments, and Accomplishment Criteria.


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.


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


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


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.