Delivering projects and demystifying the never-ending process of improvement
Every project involves a process, and every process can lend itself to improvement, but have you considered taking the theories behind process-improvement and applying them to the way you implement and deliver projects? (Tongue-tied, yet?)
That sounds confusing, so let’s back up a step. What do I mean when I say “process work for implementing projects”? First, consider the difference between the two types of work. Projects have a beginning, middle, and end. Process work is continuous and never ends; for instance, every month the controller closes the books, does payroll, etc., a pattern that repeats in perpetuity. Understanding the distinction between “project” and “process” work is the first step in improving your ability to deliver projects on time and within budget—and what business person isn’t interested in that?
Is your job to deliver project-based work? Then your process work is just that: to deliver the projects. In other words, while projects may have a discreet, distinct beginning and end point, the job of delivering projects doesn’t. After one project is delivered, another should be in the queue, ready to start. It might be a lens you haven’t previously applied, but considering the implications of shifting your mindset to this process-of-project-delivery framework can have drastic implications for your productivity.
To increase the throughput of your projects, first consider mapping out a flow. Break the project down into its basic components—not necessarily individual tasks, but the major steps. For instance, a standard project at SUCCESS generally follows this flow:
scoping > quoting > procurement > delivery > migration > support > release > production
The major steps of your project may vary from ours, but you get the idea. Once you map that flow, the next step is to find out where you’re getting tripped up with delays. Delay can happen at many points, but most people have an intuition about where to start looking. In the Theory of Constraints, they call this step “identifying the constraint,” and it’s step one in our improvement efforts.
Step 1: Identify the bottleneck
The constraint is the point in the process which, for better or for worse, controls the workflow. For the SUCCESS example above, this might be ordering equipment. Generally (but not always) it’s the point in the project process that has an excessive amount of work in front of it, like inventory or work in progress. It’s the bottleneck of the entire workflow. Some would say this is a bad thing and we need to improve the “efficiencies” of that area. I argue that this is actually a golden opportunity, and you should do whatever you can to forget the word “efficiencies” when it comes to optimizing workflow. Making all areas of a workflow “efficient” tends to decrease production. I know that sounds counterintuitive, but I’m here to tell you it’s true. A balanced system in which we have just enough resources to do the work will never produce the desired throughput.
Step 2 and 3: Exploit the constraint, then subordinate
Once you have identified your constraint, you want to exploit the constraint, which means keeping the constraint busy doing what it should. Next, you subordinate to the constraint, which means offloading any other work the constraint is doing that isn’t critical to project completion. We refer to this part of the process-improvement analysis as “drum, buffer, rope.”
“Drum” means you want a consistent workflow to and from the constraint; “buffer” means to keep the constraint busy by ensuring there is always work for the constraint to do. In the aforementioned SUCCESS example, that may mean that we need some inventory in front of the constraint, thereby creating a buffer of work that’s ready to go when the constraint becomes available to work on the next project. “Rope” refers to releasing the next project into the workflow only when the constraint is ready to work on it. Releasing work/projects too early simply clogs the system and increases lead times on all open projects.
For instance, in our SUCCESS project-flow example, if equipment ordering is our constraint to increase throughput, we might keep inventory on hand to allow for quicker release of product into our project process. If we have equipment on hand so the setup process can be completed anytime, our engineers would be able to stay busy on projects that were ready to go, versus waiting for shipping times and backorders.
Step 4: Elevate the constraint
The fourth step is to elevate the constraint, which means adding more capacity to our constraint. Once we have identified the constraint, kept it busy doing what it’s supposed to be doing, and offloaded the remaining work to other resources, our throughput will be at its highest level. To drive more throughput then requires additional capacity at our constraint, thus step four suggests adding more capacity.
Step 5: Repeat
The example I used above, of a SUCCESS project flow, is a pretty simple example, and honestly, the first constraint you identify is rarely the last one. Once you go through this process, you might even find the constraint shifts. That’s why the fifth step is—you guessed it—to go back to the beginning, and run through the process again.
The promise of continuous process improvement is significant, and can be be measured in terms of the speed of delivery, the predictability of outcome, and within project budgets. In addition, there will be reduced stress, errors, and wasted time.
Think about these concepts in relation to your organization. Have you recognized the difference between project and process work? Do you provide sufficient resources to complete the project work? Are the right resources dedicated to doing the work they are best suited for? To become better at delivering on projects, continuously, consider the following five steps, and watch your throughput flourish.
Our 5 Steps for Improving Your Project-Delivery Processes:
- Identify the Constraint (Bottleneck)
- Exploit the Constraint (Keep the Constraint Busy doing only constraint related work)
- Subordinate to the Constraint (Offload all other work from the constraint)
- Elevate the Constraint (add more constraint capacity)
- Avoid Inertia (Continued Improvement – go back to step one)