• CMMI (Capability Maturity Model Integration) focuses on improving the underlying processes required for successful IT project delivery.
• PMBOK (Project Management Body of Knowledge) provides a set of foundational and “generally recognized good practices” that it reinforces via its certifications.

There is significant emphasis on what we would consider “input metrics”—such as repeatable processes and practices—without corresponding outcome metrics to assess whether this repeatability actually helps improve throughput or reliability.

The Theory Of Constraints (TOC) says that in any system, there is one function, resource, process area, or process step that constrains the entire system’s ability to deliver on its mission.

Once an organization has identified its system constraint, it knows that any improvement anywhere other than at the constraint will have little or no impact on overall organizational effectiveness. Putting this concept into practice helps provide much-needed clarity on where to focus improvement efforts.

One way to think of Throughput per Constraint Unit (T/CU) is in terms of “effective throughput,” as it represents what is actually expected to achieve, given what is known about how the system constraint limits throughput.

One simply needs to get defensible estimates of T/CU for each project candidate and fund the highest-scoring ones for which one has a budget and available CUs to support.

A somewhat improved project-selection metric is called “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).

At some point, however, most or all of this hidden capacity will get used up, such that any further projects delivering new capabilities into operation will only serve to overload the constraint, degrading throughput. As a result, the only projects that make sense at that point are those that can actually expand capacity at the constraint.

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.

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.
• We can try and make the cars go faster.
• We can build an additional lane or two.

PPM works in the same way, but we tend to be concerned only with the speed.

In PPM, we tend to focus mostly on trying to make the cars go faster—even when the highway is all jammed up, sometimes causing accidents, and usually frustrating everyone on the highway who can’t get where they want to go. We also tend to jump right to trying to add a lane or two—which is rarely quick, easy, or inexpensive, if it’s a feasible option at all.

While speed is important and adding capacity may well be in order, let’s start by getting traffic to flow.

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 the first step.

It is important to note that task switching is slowing us down a lot—by a whopping 40 percent, according to many studies. If all we do is stagger our projects and execute them with a single-task focus, we can more than double portfolio throughput.

It turns out that this is higher than normal, but not by much—seasoned process engineers will tell you that the typical business process contains 70-90 percent bloat. The challenge is to devote time, energy, and the right talent into improving processes before software-enabling them.

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.

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, with results satisfying three conditions:

• Change the object being moved through the process.
• Deliver a result that’s done right the first time.
• Deliver value—as defined by the customer of that process.

The goal here is to make sure that the developers always have something to work on. Everything is steered by the volume of planned tasks in the task buffer. So if there are just two tasks left, then one of the developers takes the next story from the product backlog and breaks it into tasks.

If buffer holes persist, then keep increasing the buffer size by one, until no buffer holes occur anymore. If your buffer rises to the point at which you have more than one task in the buffer for every two developers, the problem most likely lies in how long it takes you to break stories into tasks.

Ask all team members to block six hours every day on their calendars for focused task work, leaving the rest of the time to respond to messages etc.

Effective ROI is essential for selecting high-impact projects.

• At the task level, Single Tasking and Elimination of Task-level Commitments are essential for maximizing improvements in speed and reliability.
• At the project level, Project Staggering is indispensable for maximizing the throughput of project completions.
• At the portfolio level, Buffer Balancing using the Buffer Protection Index (BPI) is required for optimizing reliability.

If we can set up our task-execution environments to more closely resemble a relay race, the behaviours will follow—as will the speed and reliability benefits.

The logical progression can be:

• Project Staggering
• Project Buffering
• Portfolio Buffer Balancing
• Project Selection Using Effective ROI
• Eliminating Task-level Commitments
• Single-Tasking
• Ultimate Scrum
• Showing all Buffers as Time-Based
• Lean Process VSAs.