What's your bottleneck?

Who’s your Michael?

Every project has one. It’s your job to identify him or her ASAP.

Let me explain…

I recently did a project performance workshop with a new client. They came as well prepared as I’ve ever seen.

They shared their project plan. They walked me through their Asana setup. They showed me their documents, sent a meeting recording, and came up with a 2-page document full of assumptions, ideas, and questions.

The problem? They couldn’t make the boat go faster.

You see, this is an internal IT project. They’ve done a lot of things right in setting it up.

No “big bang” but incremental releases in manageable sprints. A plan and team that most PMs can only dream of. All the tools and executive support they need. Risks under control, adequate budget, the list of things to like is long.

But whatever they’ve tried, they’re not getting close to the release speed they expected and planned.

So they’ve been trying to fix things. More resources. Better processes. Different tools. You name it, they tried it. But so far, nothing seemed to work.

So as we were talking through what they’d tried, I noticed that one name came up a lot. Let’s call him Michael.

Michael is one of their IT operations engineers. He’s been with the company for 7 years and knows the overall architecture better than anyone (hint 1). He builds things, fixes things, and loves helping people. One of those guys that everyone wants on their team (hint 2).

“To be honest, it’s almost impossible to get something into production without Michael” the project sponsor said at some point during the workshop.

That was hint number 3. By now, it’s not a hint anymore. It’s a big fat red flag.

“Is Michael dedicated to this project?” I asked.

“On paper, yes. But I’m sure that he’s working on 20 other things.” said the PM.

OK. So we’ve got a key resource who is needed in almost every project task but is also working on dozens of other things.

Bingo.

“I think we’re on to something here” I said.

“This makes me think of one of the most important books ever written about manufacturing and operations management. It’s called “The Goal” by Eliyahu Goldratt. Have you heard of that?” I continued…

The sponsor had, and was puzzled that I was referencing a 40-year-old book about plant management in a discussion about their agile IT project.

In a nutshell, the book explains the story of plant manager Alex who has 3 months to turn around the productivity of a manufacturing operation. He is pushed to simplify the problem to the ultimate goal of the organization.

Once he understands the the true goal, he identifies the bottlenecks of the operation and improves those, while “ignoring” the productivity of the rest of the process.

And in true Disney fashion, he lives happily ever after.

But when we translate that to this project, you get something like this:

You see… everything they’d tried so far, was trying to increase productivity of the entire process.

But here’s the thing: any improvement in productivity in any other place than the bottleneck is not only a waste of time - it makes things worse.

Let me explain…

If the work before the bottleneck goes faster, that means more work in progress piles up at the bottleneck.

In a factory, that means piles of inventory. In an IT project that means emails, slack messages, and sticky notes on Michael’s desk.

“Can you look at this design for 10 minutes?”

“When can you release this to test?”

“XYZ is not responding - can you have a look?”

And as these things pile up, Michael has to task switch more. And we all know that multitasking kills productivity.

But there’s more…

As things don’t get solved, people start asking when it will be done. Which means even more emails, phone calls, or worse - escalations and angry managers trying to mess with his priorities.

You see where this is going?

It just gets worse, until someone screams, cries, burns out, or all of the above.

And then what? Then you have a pile of work that only one person can do, and no one to take over. Because he was so busy that you agreed “to do documentation after the project is done”…

Reads like a horror story, right?

It’s more common than you think. In fact, I bet you’ve seen it up close at some point in your career.

So what do you do about it?

Here’s the good news: if you’ve done the initiation of your project right, you know the first step. You know the purpose, the value you’re trying to create, and how that’s translated into a measurable definition of success.

With that out of the way, your next job is to identify your Michael.

In this case, the bottleneck was a person. But there are more categories of bottlenecks according to Goldratt:

1. Resource constraints: this is broader than just people. It can also be a tool, a machine, a server, or cash for example. It’s the thing in your main delivery process with the lowest throughput.

2. Policy constraints: rules, policies, metrics, or “best practices” that distort your flow because they lack alignment with the overall system.

3. Permanent constraints: limiting factors that are always present in a business. In the case of projects, think about a lack of management support or cultural issues for example.

So, your bottleneck can be a thing, a person, a process, a tool - heck, it can even be the fact that your team members don’t talk to each other.

The point is to identify what single thing is holding your entire project back, and then do something about it.

How? More on that next week - it’s almost midnight and I have to stop somewhere…

To wrap up, the goal here was not to scare you out of IT projects. The goal is to plant an idea. To make you think.

Zoom out and look at your current project: what’s your bottleneck?

Once you know, I’ll see you next Tuesday for part two of this small series: what you can do about it.

Talk soon,
Jasper

PS: This story was shared with the client's permission, but some details are twisted to ensure confidentiality.

PPS: If you can’t wait for next week, grab the book here: Eliyahu Goldratt - The Goal.