Another Case for IMP/IMS and Capabilities-Based Planning?

Many years ago, a preview of one of Jim Highsmith's books,?The Agile Revolution,?caused me to read it on the web from Addison Wesley.

I was interested in the book and should have been excited about the concepts of Agile Project Management he presents.

But I was troubled by several things:

• The view that project management is a roadblock and an administrative overhead.
• Project managers and project management practices are focused on compliance.
• Predictability versus adaptability is the choice, where agile projects are adaptable, and it is assumed that non-agile projects seek predictable approaches.

I know Jim has specific experiences in mind, and the IT world is full of "bad projects." I've managed a few myself. But I've learned over the past 26 years - by hanging around large construction, environmental remediation, process control systems, and spacecraft development projects - that approaches to managing IT projects are seriously flawed compared to these other environments.

Each construction, environmental remediation, embedded control systems, and spacecraft project had:

• The clearly defined outcome is measured in units of Effectiveness and Performance, which are the Basis of All Project and Product Success. "Done" is envisioned several and sometimes many times over, but it is always shared, communicated, and syndicated down to the lowest level of the organization.
• Clear and concise requirements, or as clear and concise as possible at the beginning of the project. These requirements changed many times. Some because of the customer, some because of an unanticipated discovery, and some because the solution did not actually work.
• Unequivocal measures of success, both monetary, technical, political, and operational. Agile does this well, by the way.
• Risk management processes in depth. 2 or 3 layers deep. For technology, funding, operational, and general unanticipated problems risk management. "Risk Management is How Adults Manage Projects" was a poster hanging in our work area at one Multi-Billion Dollar environmental remediation project.

Capability-Based Planning and IMP/IMS

So what's different between a "poster child" IT project Jim speaks of, where project management is seen as an unnecessary overhead and project managers just get in the way of progress, and my recent experience in project and program management?

• Maturity of the organization? These companies are project-centric. They manage projects for money. "Project Completion Services" was an NPR sponsorship tagline for one of my former employers.
• High Risk / High Reward / High Experience? The three firms I mention engage in high-risk / high-reward projects for the most part. Not all monetary rewards (7% Gross Margin is about the government rate). But managing in this environment brings out the best in people through skill and cunning or natural selection.
• Professional roles? The three firms from my experience and the mentoring firms we used, and neighbor firms all treated project management as a core competency. The technical staff knew this, was involved daily in the project management processes, and was rewarded by the project managers' success and their own. One large construction firm promoted project managers to VP positions (I was one), emphasizing a ladder of business progress starting as associate project manager.

What's interesting from my point of view is that all these examples treated projects as "increasing" maturity assessment opportunities. Planning is done with a "planning horizon." The future is vague, and the present needs to be stable. Exploration of alternatives is good risk management - "risk buy down" is the operative term. Technology insertion, technology, and managerial on-ramps and off-ramps (code words for immediate adaptability to change) are explicitly programmed into the planning process. Explicit (monetary) value measures are mandatory (Earned Value or some equivalent) and are used along with

Technical Performance Measures

A Technical Performance Measurement (TPM) involves predicting the value of a key technical performance parameter of the higher-level end product under development based on current assessments of products lower in the system structure. TPMs track and measure progress toward achieving the specified outcome after development. Continuously comparing the achievement of chosen technical parameters to expectations validates progress and reveals deviations that could jeopardize end product requirements. Values that are assessed and outside the defined tolerances call for management attention and corrective action. At the start of a program, TPMs define the planned progress of selected technical parameters.?

Here are some briefings for applying TPMs to programs we work

• Using Technical Performance Measures to Inform Earned Value Performance, 15 August 2018.
• Knowing What Done Looks Like?- Connecting the Dots Between Technical Performance Measures, Earned Value, and Physical Performance Complete, Patrick Barker and Glen Alleman.
• Implementing Technical Performance Measures, Glen Alleman.
• Integrating Technical Performance Measures, PMI EVM Community of Practice, EVM World 2011.
• Exploring Ways to Inform Earned Value Using Technical Performance Measures, EMV World 2014 Conference.
• Informing Program Performance with Technical Performance Measures and Programmatic and Technical Risks, CPM EVM World 2015
• Informing BCWP (EV) with Technical Performance Measures of Risk, Gordon Kranz, Glen Allemanm, and Dave Walden, EVM World 2015, Office of Performance Assessments and Root Cause Analysis (PARCA).
• Scope and Organizational Management Lesson C: Using Technical Performance Measures to Inform Earned Value Management, Glen Alleman and Thomas Coonce, EVM World 2016.
• Technical Performance Measures?- CPM-200C, College of Performance Management, IPMC 2012.
• Using Technical Performance Measures to Inform Earned Value, College of Performance Management, EVM World 2016.
• Using Technical Performance Measures to Inform Earned Value, Glen Alleman, Thomas Coonce, and Rick Price, College of Performance Management, IPM 2014.

By the way,?the use of the term "customer value" in the Declaration of Interdependence for Agile Project Management has no units of measure, therefore it has no business value in practice. It's a wonderful principle, but in practice is of little use without a unit of measure.

TPMs have monetized units of measure to go along with their technical compliance units (mass of the final product versus cost versus time to market as a function of investment cost and schedule is a common discussion topic in the morning stand-up on my current project).

Program maturity assessment points are mandatory, with significant accomplishments, accomplishment criteria, and supporting tasks. Along with the Program Events that explicitly map to the statement of work, the customer value stream (monetized technical performance measures) and 0%/100% measure of "done" on fine-grained boundaries. These are the "currency" of project managers in construction and aerospace.

What would happen if IT projects adopted some of these measures, processes, maturity assessment approaches, and paradigms for defining "done?" Would the role of a project manager be seen as overhead anymore? "Buy a pizza and stay out of the way?" may become rarer. Would actual bookable value to the firm be made visible to all the participants on the project, raising the esteem of the project manager?

In IT, we're trying to solve the problem incorrectly. Let's look at the successful project management methods in other domains and ask if they know something we don't.

Jim's new book Wild West to Agile: Adventures in Software Development Evolution and Revolution may contain more on the idea that project management is a profession in the Agile world because it certainly is a Profession in our Software Intensive System of Systems Aerospace and Defense domain.

Some Sample Project and Prorgam Management Roles

• Agile in NASA, DoD, and DOE - There is a common misconception that Agile, as we know it today, started with the Agile Manifesto and is best applicable to self-organizing and self-directed teams.
• What makes an Effective NASA Project Manager?
• NASA FAC-P/PM Certification Program
• One Hundred Rules for NASA Project Managers

and of course Agile project management

• Agile PM: The Keys to Getting Started (APPEL-vAgile)

In the end, agile development and management of agile development are well developed in the Federal Government. The Software Engineering Institute is a Federally Funded Research and Development Center.

Here are 6 handbooks from the Software Engineering Institute for applying Agile in the Department of Defense:

• Booklet 1: Agile Development and DoD Acquisitions
• Booklet 2: Agile Culture in the DoD
• Booklet 3: Management and Contracting Practices for Agile Programs
• Booklet 4: Agile Acquisition and Milestone Reviews
• Booklet 5: Estimating in Agile Acquisition
• Booklet 6: Adopting Agile in DoD IT Acquisitions