amazon highlights: The CIO's Guide to Breakthrough PPP

The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile, and Lean by Michael Hannan, Wolfram Müller, Hilbert Robinson , Last annotated on May 15, 2015

 

Chapter 1: The Three Most Important Objectives

The three most important objectives for any project portfolio are

1)  Selecting the right projects.

2)  Maximizing the portfolio’s throughput of project completions.

3)  Optimizing the portfolio’s reliability of project completions.

 

Project selection: Only 42 percent of projects were classified as having “high alignment” to organizational strategy.   

Portfolio throughput: Only 9 percent of respondents consider their organizations “excellent” at executing their highest-priority projects

Portfolio reliability: Only 17 percent of respondents believe that their organizations are able to realize envisioned project benefits with “high maturity.”

 

Chapter 2: How to Select the Right Projects

1)   Project Identification

2)   Project Validation

3)   Project Prioritization

4)   Project Selection

5)   Portfolio Politicking

 

One way to think of T/CU is in terms of “effective throughput,” as it represents what we actually expect to achieve, given what we know about how our system constraint limits throughput.

We now have a somewhat improved project-selection metric that we’ll call “Effective ROI,” as it calculates the actual ROI expected when taking into account the system constraint:

Throughput per Constraint Unit, per Investment (T/CU/I)

To be even more accurate, we would need to refine the metric further by factoring in how long those investment dollars are tied up in project work, and incorporating the time value of money for the entire model.

Typically, the first few IT projects that go into production operation can take full advantage of available CUs, especially as the organization learns to expose hidden capacity by focusing all efforts on maximizing throughput at the constraint.

For many organizations, IT has become so critical to so many facets of the organization, that IT itself has become the system constraint.

1) Keep IT focused.

2) Subordinate all other resources to IT.

3) Generate more ITs.

If you can find a way to get more projects done without adding resources, you will have a greater ability both to expand capacity at the constraint, and to use that additional capacity to drive up throughput.

 

Chapter 3: How to Maximize Portfolio Throughput

We can boost highway throughput in a number of ways—here are some common ones:

• We can keep the road free of impediments and in good working order.
• We can increase traffic density (e.g., carpooling).
• We can meter the on-ramps whenever their inflow slows the main flow of traffic.
• We can recruit underutilized resources elsewhere (such as lanes usually devoted to opposing traffic).
• We can try and make the cars go faster.
• We can build an additional a lane or two.

 

Project Staggering

We also see that staggering gives us the ability to deliver four projects in less time than delivering three using a simultaneous execution approach. For CIOs, IT Project Portfolio Managers, and other senior executives looking for a more practical, hybrid approach for improving the throughput of project completions, project staggering is your first step.

 

 

Focused, Single-Task Execution

most military commanders would not characterize the real-world experience of fighting a battle as interruption-free; on the contrary, they emphasize the importance of “adapting and improvising,” which sounds to us more like task switching than single-task execution.

Assuming that most or all of our projects suffer from pervasive task-switching, we would expect an average productivity benefit of 40 percent from focused, single-task execution.

a 35-percent gain in productivity from focused, single-task execution would jack up throughput to seven project completions, compared to our original metric of just three.

 

Elimination of Task- or Sprint-level Commitments

The aggregated risk approach frees everyone from the need to have the “how aggressively can you commit?” conversation, and allows all team members to focus instead on how to be a high-performing team.

Taking a lesson from the insurance industry, the more that risk can be aggregated, the easier it is to manage. Applied to projects, this will nearly always mean that it’s better to aggregate risk at the project level.

By combining project staggering, single-task execution, and elimination of task/sprint-level commitments, we see that we can now more than triple portfolio throughput—and none of these techniques is complex or difficult to learn and apply.

 

Lean Process Value Stream Analysis (VSA)

In order to satisfy Lean’s definition of a “value-added” step, that step must meet three conditions:

1)  Change the object being moved through the process.

2)  Deliver a result that’s done right the first time.

3)  Deliver value—as defined by the customer of that process.

 

To be conservative, let’s assume that the total net benefit from applying the Lean Process VSA for our software-development projects is only half of the 70-90 percent metric, or a 40-percent improvement. Let’s further assume that only half of our IT project portfolio is comprised of software-development projects, and that no other type of IT project (e.g., infrastructure modernization) can benefit from a Process VSA. So our 40-percent improvement estimate is cut in half, to 20 percent—a very achievable estimate, in our experience. By using these first four techniques in combination, we can now more than quadruple our portfolio’s throughput of project completions—from three to thirteen in our simple portfolio example.

 

Ultimate Scrum

In addition to subscribing to many Agile/Scrum tenets, Ultimate Scrum takes its three flow-improving pillars from Lean and TOC:

1)  Lean’s “pull system,” which drives flow more effectively than a “push system.” In Ultimate Scrum, software developers pull their tasks from the backlog, as opposed to managers assigning (pushing) tasks.

2)  Lean’s “single-piece flow” as the ideal unit of flow in a high-performing process. In Ultimate Scrum, single-piece flow manifests as a rule that developers may pull only one task at a time, and that no developer may start a new task until finishing the one in progress.

3)  TOC’s tenet that the throughput of a system is maximized only when governed by the pace of that system’s constraint. In Ultimate Scrum, the software developers are the constraint, and their velocity of task completion sets the pace for all supporting aspects of task flow.

adopting Ultimate Scrum will result in an additional 20-percent productivity improvement at the project level, even when taking into account that we’ve already eliminated multi-tasking and sprint-level commitments (and sprints, for that matter). Assuming that at least half of the typical project portfolio is comprised of software-development projects, this translates into an additional 10-percent throughput improvement across the portfolio.

 

Chapter 4: How to Optimize Portfolio Reliability

In traditional project management, buffering has often been introduced as the “triple constraint rule,” which holds that we must have some flexibility in schedule, budget, and/or scope in order to deliver with any hope of reliability. If all three are fixed, then the project is likely doomed to failure, and even the most naïve PM would be a fool to take on such a project.

Traditionally, schedule buffers have been the buffers of choice, as significant emphasis has been placed on defining scope and keeping it stable. In contrast, Agile defaults to scope buffers, under the premise that it’s better to get started early in the scope-definition and refinement process, and use rapid iterations to tighten up scope as you go.

In some circumstances, budget buffers will be preferable to schedule buffers.

This fever-chart portfolio view plotting each project’s percent complete vs. percent buffer used is called the “buffer protection index,” or BPI, and comes from Critical Chain Project Management (CCPM).

 

Chapter 5: Fight the Zealotry

We embrace this “best-tool-for-the-job” mindset as a practical matter, in our attempts to help pragmatic executives deliver the most impressive, real-world results possible.

 

Chapter 6: The Best of Both Worlds

We see three fundamental similarities between CCPM and Agile, however:

1)  Both subscribe to the foundational PM principle of buffering to improve project reliability.

2)  Both place emphasis on focused execution to improve flow and speed.

3)  Both understand the importance of aggregating risk in order to improve speed and reliability.

We have identified three fundamental similarities between Agile and CCPM: Buffering, Focused Execution, and Risk Aggregation. By representing all project buffers as time-based, we can balance them across the project portfolio when desirable, thus boosting portfolio reliability while maintaining flexibility in whichever project delivery method we choose. By establishing single-tasking as the norm, all approaches will see productivity jump. And by aggregating risk at the project level on all projects, and at the task level using scrum-team approaches when it makes sense, you will achieve improvements in both speed and reliability. Such improvements simply would not have been possible with just a single delivery method, but integrated together harmoniously, you can harness the best of both worlds.

 

Chapter 7: Putting It All Together

1)  Project selection is best governed by Effective ROI.

2)  At the task level, Single Tasking is the best way to maximize improvements in speed and reliability, followed by the Elimination of Commitments.

3)  At the project level, Project Staggering is essential for maximizing the throughput of project completions, while monitoring time-based buffers is the best way to boost reliability.

4)  At the portfolio level, Buffer Balancing using the Buffer Protection Index (BPI) is the best way to optimize reliability.

Project selection is a portfolio-level responsibility that governs the introduction of new projects, which are visible at the portfolio level and executed in a staggered manner at the project level. Staggering projects effectively requires identification of task-level dependencies, resource-loading and resource-leveling.

 

Chapter 8: Overcoming Obstacles

Obstacle #1: Convincing stakeholders that staggering their project for a late start will actually result in an earlier finish.    

Obstacle #2: Adopting single-tasking as the norm

Obstacle #3: Convincing PMs and Scrum Masters to abandon task-level deadlines

Obstacle #4: Convincing process owners and participants to let go of their non-value-added steps.

Obstacle #5: Convincing scrum-team members to abandon sprints in favor of Ultimate Scrum’s continuous flow   

Obstacle #6: Convincing executive stakeholders to avoid cutting buffers

Obstacle #7: Convincing PMs and Scrum Masters to lend their project resources to at-risk projects.

Obstacle #8: Project portfolios comprised mostly of fixed-price contracts.

 

Chapter 9: How to Get Started

If you’re not sure you’re ready for such an enterprise approach, and would strongly prefer some kind of pilot, we advise a large-scale one, such as for an entire business unit’s IT project portfolio. The reason is that small pilots typically yield small results, while introducing conflicting value systems across the organization.

While we do recommend organization-wide rollouts, we do not advise attempting to adopt all techniques all at once. Here is the logical progression that we recommend:

 

1)  Project Staggering: A great way to begin focusing attention on organizational capacity for projects, to expose resource bottlenecks, and to get some near-term portfolio throughput benefits.

2)  Project Buffering: You are likely doing some type of project buffering already, but in our experience, most organizations can get a lot of benefit by focusing on how to use the three buffer types with greater discipline and maturity.

3)  Portfolio Buffer Balancing: Once you have projects staggered and buffered, and have experience monitoring buffer consumption with the fever chart, it will be a straightforward next step to try balancing buffers across the portfolio.

4)  Project Selection Using Effective ROI: Once you have projects staggered and buffered, and some experience managing buffers across the portfolio, you will then have a clearer sense of how to apply the Effective ROI thinking, and can also begin to enjoy the benefits of being able to put more projects into the queue.    

5)  Eliminating Task-level Commitments: Most practitioners advise doing this step in concert with Project Buffering, as it is very beneficial to expose hidden task-level buffers while trying to establish and protect a generous project-level buffer.

6)  Single-tasking: This is where you will begin to achieve breakthrough levels of performance improvement, but it is also the technique that may require the biggest shift in organizational culture.

7)  Ultimate Scrum: For software-development projects, this technique builds on #5 and #6 very effectively, driving speed and flow of task execution up another 20-30 percent.

8)  Showing all Buffers as Time-Based: This technique can be done as early as #4, and if your portfolio is a hybridized mix of Agile and traditional projects, you may want to start this as soon as possible, so that you can harmonize your portfolio under a single PPM framework.

9)  Lean Process VSAs: This can be a very high-powered technique, and we save it for last only because we think it’s more important to get good at the other techniques first.

 

The ideal large-scale pilot:

1) Has the unwavering support of the entire executive team.

2) Has at least ten projects in the initiation and planning stages.

3) Already shares a common resource pool of at least 100 staff.

4) Already shares a common set of project stakeholders.

5) Has project stakeholders and staff who are eager to see improvements, and willing to support improvement efforts.     

6) Has a competent consultant to coach and mentor along the way.

That should be enough to get you started. For additional information and tools, check out www.FortezzaConsulting.com and www.Reliable-Scrum.info.

 

Appendix: When to Use Agile, and When Not to

1) Does the scope include software-enablement of business processes?

2) Does the scope include significant custom software development?

3) Is the scope lacking in specificity, and unlikely to remain stable?

4) Is the customer willing and able to offer flexibility on scope?

 

If all four of these questions can be answered affirmatively, then Agile—and especially Ultimate Scrum—will likely be your most effective choice of project delivery methodology.