Software Engineering

Critical Chain Project Management | Toptal®


The IT industry exists in a chronic state of staffing shortages. Resources are strained, deadlines are tight, and haphazard solutions like “crunch time” can have a devastating effect on team members. Meanwhile, roughly 12% of the money invested in projects is routinely lost to poor planning. How can project managers stem this loss in an industry where time and labor are already stretched to the limit?

With 86% of software teams adopting Agile practices as of 2021, it may seem like Agile solutions are the only option. But Agile is nothing if not flexible: Applying critical chain project management (CCPM) planning to an Agile workflow is a great way to identify and resolve chokepoints in processes while still keeping the benefits of Agile delivery. The use case in this article will show you how to reap the benefits of a hybrid CCPM/Agile approach.

The Critical Chain Method in Project Management

CCPM is one of the most effective project management tools for optimizing resources. It was first described in Eliyahu M. Goldratt’s 1997 book Critical Chain, and builds on his earlier theory of constraints. In short, CCPM provides a framework to identify and limit project constraints. You’ve probably heard the saying that a chain is only as strong as its weakest link—CCPM seeks to concentrate efforts on the weak links that threaten the whole project.

CCPM handles these weak links with six steps that, taken together, improve the efficiency of available resources while making sure they’re assigned where they’re most needed:

  • Identify the critical chain. In any project, there are a series of tasks that absolutely must be completed for the project to be successful. When identifying the critical chain, the project manager defines the most significant and time-consuming tasks, as well as feeder chains, on which the critical chain is dependent. For instance, “write documentation” might be a task on the critical chain, while “choose documentation software” might be a task on the feeder chain.
  • Identify possible resource constraints. Consider limitations you may face when assigning workers to assignments (e.g., vacations or other planned leaves).
  • Increase focus by eliminating multitasking. Keeping team members focused on specific activities will lead to higher productivity. Multitasking is known to hinder performance, and eliminating it will allow you to assign less time per task.
  • Estimate time by assuming single-task assignments. CCPM operates under the assumption that if a team member is focusing on a single task, the time allotted to that task can be cut in half. For instance, if your initial estimation for a given task is four days, after eliminating multitasking, that time can be cut down to two days.
  • Add buffers. Reintroduce part of the reduced time as a buffer for the critical tasks. Using the same estimation example noted above, if you reduce a four-day task to two days, add one more day to the plan in case the task takes longer than expected.
  • Rewrite your plan. Using your new time frames and buffers, write a new project plan. At this stage, you should level resources, reallocating time, labor, and tools as necessary.

The goal of this process is to add buffers around events and interdependencies that are vital to project outcomes. CCPM uses three kinds of buffers to ensure timely delivery:

  • Project buffer: The pooled time found after the last task and before project completion. This is the contingency that most critical chain activities have.
  • Feeding buffer: The time added to tasks on the feeder chain that ensures that delays on those tasks will not affect the most vital activities.
  • Resource buffer: The reserve of physical resources (i.e., workers or equipment) that can be reallocated as needed if the project calls for it.

Once the steps have been completed and the new plan is written, the difference should be visible. As shown in the sample Gantt chart below, tasks are assigned less time across the board, but buffer and safety margins have been applied to the most vital tasks.

Two sections of a Gantt chart show a sample project plan before and after the application of critical chain project management.

Merging Lanes: Agile and CCPM

CCPM can be considered an optimization of the Waterfall approach, so applying it to Agile may not seem immediately intuitive. But both CCPM and Agile have the same goal: to ensure project efficiency by improving speed and reliability. CCPM makes its changes on the front end through timeline planning, whereas Agile makes its improvements throughout the work process after every sprint. What this means is that it’s not difficult to envision a hybrid framework in which work estimates are done in CCPM, and the work itself is executed in Agile.

Think of it like a small project that many people do multiple times a week: driving to work. In this scenario, you start with a plan and time estimation in mind. There are resources (fuel) and constraints (traffic). There are also critical steps that have to be accounted for if the commute is going to be successful, like finding parking. You probably build buffers into the plan for constraints you know about ahead of time, like leaving 15 minutes early in case of particularly bad rush hour traffic. (This part of the “drive to work” project looks a lot like CCPM planning.)

Once you’re actually on the road, there are critical milestones that determine your ensuing choices. Maybe you hear about an accident on the highway, so you find another on-ramp. Maybe a colleague calls and asks for a ride, so you leave the highway for a while and return back to it before exceeding your time buffer. This is the Agile part of the process. Unexpected events (i.e., requirement variations) lead to another path, but you should make an effort to stick as close as possible to the original plan.

There are several proposals for how Agile can be combined with CCPM, but for our purposes we’ll examine a use case in which CCPM is used to plan a project, and Scrum is used to execute it.

CCPM and Agile: A Hybrid Use Case

A company develops a product that has already penetrated a regulated market. Regulations require that this product meet high standards for reliability (based on code quality), security certification, and license compliance. The company has decided to improve product performance by integrating a new open-source software (OSS) library with a database management system (DBMS).

The management team estimates that the new DBMS will improve key metrics like client retention cost, net promoter score, and first-time acceptance rate; with the new DBMS, the company could outperform the competition, reach its planned revenue goals, and secure the next round of funding by the end of the year. Development is given four months to complete integration and verify product alignment. This integration will need to take place alongside the team’s regular maintenance responsibilities.

A row listing the stages of an OSS integration workload followed by a row listing the stages of regular maintenance.

The Problem

The development team has inferred that the code quality of the OSS library is not sufficient for a highly regulated market. The initial integration steps have uncovered several defects and vulnerabilities, like hardcoded tokens and code duplication. This significantly increases the overall product’s technical debt. Due to the product’s large customer base, the development and test departments are already struggling to keep up with incoming support requests.

The incoming requests for bug fixes and resolution of vulnerabilities increase significantly. Support tickets are filed in a timely manner, but the development team doesn’t have the capacity to handle the extra requests or adequate experience with the newly integrated DBMS. The additional challenge has further taxed an already overburdened team.

The testing team is struggling to implement a test suite that adequately covers the newly integrated software, and the release team lacks the capacity to update documentation and the product’s web presentation. The development team lacks the availability to carefully tackle the newly discovered issues, leading to either patch work or delays, neither of which is a good solution. Both damage the original plan.

The testing team also reports more and more issues in every sprint. Its backlog is getting bigger and the integration’s completion time is getting pushed back. Business pressure leads the project manager to micromanage the completion of each task on the scheduled date, frustrating everybody. Teams begin to isolate themselves, using backfiring as a last resort, which makes everything worse.

The Solution

The development team now faces a situation in which they must complete a major discrete project, but also address new incoming requests and comply with external regulations; it’s not realistic for them to depend solely on Agile or Waterfall in this context. Because the team already uses Scrum for new feature development, and a hybrid Kanban framework for bug fixes and client customization requests, they are reluctant to change either approach. But, pushed by business stakeholders to align the project with their goals (and urgent fundraising needs), the team decides to add CCPM planning to their workflow using the following four steps:

1. Identify the Critical Chain

The project manager determines a critical path consisting of eight tasks:

  • Integrate OSS
  • Align OSS quality (refactor to address defects and vulnerabilities)
  • Eliminate vulnerabilities
  • Implement test suite
  • Update documentation
  • Run tests
  • Release
  • Fix bugs (including customer support)

2. Identify Possible Resource Constraints

The constraints are clear: The development team lacks the required bandwidth for the tasks required; the code’s lack of maturity adds complexity; and extreme multitasking is cutting into the developers’ availability. All team members will be available for the duration of the project, but there is no budget to hire anyone new.

The project manager conducts an initial workload estimation to determine the obligations of the development team. The team had previously estimated the effort that would go into database integration, but because the quality problems were not visible until integration had begun, the estimation did not account for the added effort of refactoring the database’s code.

There are a number of ways the workload can be estimated. For instance, the effort needed to align the OSS quality could be assessed using a combination of software composition analysis tools, code review tools, and security tools such as Mend, SonarQube, Snyk, Coverity Scan, c2m, or Checkmarx. The team could also run a technical debt assessment suite like c2m or CloudZero, or use a source code assessment suite. But the actual method is less important for our purposes than the results:

Task

Days of Effort per Sprint

Integrate OSS

5

Align OSS quality

5

Eliminate vulnerabilities

5

Implement test suite

2

Update documentation

2

Run tests

1

Release

1

Fix bugs

2

3. Eliminate Multitasking, Estimate New Time Frame, Add Buffers

Although these tasks are conceptually separate, in practice a project manager will likely perform them all in one sitting. Operating under CCPM’s assumption that the elimination of multitasking reduces necessary time by half, the project manager writes a new workload estimate. They also assign buffers (typically set to 50% of task effort estimation) to these crucial tasks, in case of unexpected delays.

Task

Days of Effort per Sprint

Buffer

Integrate OSS

2.5

1.25

Align OSS quality

2.5

1.25

Eliminate vulnerabilities

2.5

1.25

Implement test suite

2

1

Write documentation

1

0.5

Run tests

1

0.5

Release

1

0.5

Fix bugs

1

0.5

4. Rewrite the Plan

With the new workload estimates and buffers, the project duration remains about the same but the pressure on bottlenecks in the critical chain is relaxed, making it much more likely that the plan’s goal will be achieved.

At this point, the CCPM plan is complete, and new sprints can be planned that reflect the CCPM plan’s priorities. The development work is still done in Scrum, with two-week sprints that contain both integration and maintenance tasks. But within these sprints, the goals of the CCPM plan inform sprint planning. Effort times are taken from the CCPM estimates, and integration tasks are given priority, with maintenance tasks addressed only when a sprint’s integration tasks are complete. When the team’s sprints are planned with these CCPM-established priorities in mind, team members should be able to achieve the DBMS integration within the allotted time.

Managing Resources to Ensure Delivery

Whether used as a standalone methodology or in conjunction with Agile, CCPM is an effective tool for balancing the pressure between management and development teams, and helping project managers meet their targets while not overwhelming teams or overtaxing resources. When CCPM is combined with Agile’s ability to react in real time to unexpected developments and customer feedback, the result is a powerful framework for delivering projects on time and within budget.


Further Reading on the Toptal Blog: