- The Projectleaders newsletter
- Posts
- How we doubled a project team's productivity
How we doubled a project team's productivity
Without driving them crazy...
“So you’re saying Michael is the problem?”
The sponsor looked at me confused.
“We thought Michael was the solution!” he stammered.
“Yes, and that is the problem.” I said. “Michael is not your problem, but your dependency on Michael is.”
Let’s zoom out for a second. I’m in the middle of a Project Performance Workshop with a client. They can’t get their project to deliver tasks on time, and we’ve just hit the issue. If you missed the first half of the story, check last week’s newsletter here.
Are you with me again?
Great. I hope you thought about it during the week, and that you have an idea of a bottleneck in one of your projects. That’ll make the rest of this newsletter much more practical.
Alright, let’s continue.
So now that we know that Michael is the bottleneck, we can apply the other steps that Eliyahu Goldratt set out in The Goal:
✔️ Identify your bottleneck
Exploit the constraint
Subordinate all other work
Elevate the constraint
Back to step 1
Let’s have a look at how that applies to this situation, so you can use it yourself too.
The second step after identifying your bottleneck is to exploit it. If the output of your system is held back by the output of something, you should increase the output.
Simple, right?
This step always gets people riled up, and this case was no different.
“Wait, you’re telling me to squeeze more out of Michael? He’s already overworked and stressed. What is this, a 1940’s factory?”
“Hear me out…” I said.
Or rather, hear Goldratt out. This has nothing to do with squeezing, and everything to do with flow.
Here are a few starting points:
Banish all kinds of interruptions
Eliminate non-value-adding work
Provide high-quality tools and inputs
Prioritize ruthlessly to reduce task-switching
Even out the workload to a steady, healthy pace
In this case, this meant that we took away a pile of tasks from Michael that someone else could do, and we put someone “in front of him” to test all inputs.
This meant he never started work on something incomplete or untested, because just like with dieting: shit in, shit out.
Which means rework, frustration, and more work in progress.
“So what’s next?” the project manager asked.
Step 3: Subordinate all other work to the bottleneck.
Next up, we let the bottleneck set the pace. In other words: Michael’s pace decided when the team started a new task.
That means that the people around Michael will be idle sometimes.
Idle time may sound scary, but the goal is not to keep people busy. The goal is to generate output that delivers your project’s value. And since the output of the system can never exceed the output of the bottleneck, you optimize for that.
Setting the pace is the easy part. Maintaining is hard, and falls on you as the project manager. You’ll have to shield your bottleneck.
How? Get creative. We moved Michael from an open office to a private space near the leadership team, which eliminated people walking over for a non-urgent question. That’s an hour a day saved right there!
I’ve seen project managers kill phone lines. Set up email autoresponders. Have your sponsor “politely ask” other departments to stop asking directly and make requests via you.
Whatever it takes. Defend their time and attention like your project depends on it, because it does.
Step 4: Elevate the bottleneck.
It’s now time to invest time and resources into improving the performance of the bottleneck. You only do this after you’ve exploited and elevated it, because those steps are both free and fast.
Also, throwing money (or people) at a problem is the easy way out for an executive. Adding people only makes sense after you’ve gotten the process under control.
So what does this mean in practice? Well, in Michael’s case, we invested in training a few internal people around him so they could take over more work that was previously marked as “only Michael can do this”.
We also got Michael an extremely overqualified personal technical assistant. And by extremely overqualified, I don’t mean an overseas VA. I mean a senior developer from a technology firm who knew their infrastructure and systems.
Quick side note: this contracted engineer was sitting on her hands half the time, and the project manager thought she was too expensive for that.
So what did the project manager do? He gave her “a few small tasks”…
Ugh.
Before you know it she’s busy with 10 other things, and no longer relieving the bottleneck. Please, don’t fall for it.
Step 5: Rinse & repeat.
So now what? You’ve successfully eliminated the chokepoint of your entire delivery, and speed is picking up.
Congrats! But guess what…
This means that something (or someone) else is now the bottleneck.
You see, this becomes a game of whack-a-mole. Once you fix your biggest issue, your second biggest problem just got a promotion. So it’s back to start to do it all over again.
I guess that’s where the term “continuous improvement” comes from…
Wrapping up
Or actually… before we wrap up, there’s a 6th step.
You’ll get to a point where you’ve done all this, but there’s still not enough effect. That means you’ll have to change the system. You’ll have to change how you run your project.
Get some fresh perspective from the outside, and start breaking those unwritten rules of your company one by one.
Your new bottleneck is the phrase “That’s how we’ve always done things here”. Time to ruffle some feathers…
OK, let’s wrap up for real.
In this case, working around Michael as the bottleneck cut the average deployment time almost in half. Or in non-technobabbel: the output of the team doubled.
And we did that by slowing down. Crazy, right?
I hear you thinking… “This all sounds expensive”.
A few of the steps we took with Michael cost money. His private technical assistant was an expensive move, and I don’t work for free either.
But look at it this way: this was a multi-6-figure project. Delays were costing them $30K per week in direct expenses, plus a multiple of that in lost potential revenue. So actually, this was a no-brainer.
So there you have it - a 101 in the theory of constraints, applied to project management.
I hope that gave you some fresh perspectives that you can apply to your own projects.
You don’t have to go all-in like we did here. If all it does is give you a different lens to look at a challenge, I’m chalking it up as a win.
If you enjoyed this format and want me to share more client stories in the future, please hit reply and let me know.
And if you have a project where you’d like a second pair of eyes from someone who has seen the movie before, I run a few of these workshops every month. Reply “workshop” if you’d like to know more.
Talk soon,
Jasper