Agile Program Management Part 5 of 5 - IMP/IMS

Integrated Master Plan (IMP) and Schedule (IMS) on Agile Programs

Integrated Master Planning and Scheduling (IMP/IMS) 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 being delivered in a form that supports the strategic objectives?”

Addressing Uncertainty with Event-Based Scheduling

Uncertainty is an inevitable outcome of any technological or business venture. When technology and business are combined, uncertainty increases and the number of degrees of freedom also increases. The first impulse is to define decision milestones, install risk management, and lay out sequential iterations to 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 maturity levels to fulfilling an Enterprise’s Strategic Objectives. Connecting these objectives to portfolios of projects is done through three (3) individual elements of the Integrated Master Plan and Integrated Master Schedule (IMS):

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.

Learning to Speak in the Language of IMP/IMS and Capabilities-Based Planning

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.

Measurable progress is evidenced by the Significant Accomplishments and their Accomplishment Criteria. This approach is different from 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. Fine-grained, it means short duration (10 to 40 working days – 2 to 8 weeks calendar time) effort. This approach reinforces the core tenants of any agile process – continuous feedback of progress, value, and compliance with strategy.
• Accomplishment criteria 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 program's maturity, 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 indeterministic introduces variance. This variance introduces a 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 are provided through “on-ramps” and “off-ramps” in the baseline schedule, where an adaptive response to change takes place.

The business strategy defined in the Balanced Scorecard provides guidelines for the entry and exit processes for the project deliverables. By testing each decision against the strategy, the project stays focused on significant accomplishments in support of a program event.

Opportunity-Based Processes Built Into The Master Plan

If adaptive management processes are to be installed and made operational, then opportunities for change and improvement must be identified and acted on when they appear or are discovered.

• The search for 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 and reevaluation of program performance.

Uncertainty in an Agile Program Management Environment

Managing in the presence of uncertainty is a core capability of Agile Program Management since uncertainty is part of every project. [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.

The Contingent Approach to Program Management

With this brief overview of Agile Program Management, IT organizations can change how programs and projects are connected to strategy. First, let’s review the components of Agile Program Management:

Each agile principle results in practice. There are several critical concepts in putting these practices to work:

1. Agile practices must be kept close to principles. Interpreting the practices in ways not implied by the principle leads to poor results. A clear and concise understanding of the principles is needed 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.
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 to support this decision-making process.

Agile can be characterized as: [12]

1. Nimble, dexterous, and swift,
2. Adaptive and responsive to new, sometimes unexpected, information that becomes available during the projects lifecycle,
3. 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 a 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.

Previous Content

• Agile Program Management Part 1 of 5 - Moving from Principles to Practice
• Agile Program Management Part 2 of 5 - Details of Agile Program Management
• Agile Program Management Part 3 of 5 - Agile Portfolio Management
• Agile Program Management Part 4 of 5 - Capabilities Based Planning

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. https://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, https://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.

Acknowledgments

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.