At every company or organization I have visited over the last three years, there has been a similar problem. I like to play a game with teams called “count the bosses.” People believe that they can work on five, eight, even sixteen projects at once. If you can count more than three bosses that are actively asking you for something every day, you are highly unlikely to be productive.The Zeigarnik effect has a nasty side effect. When people take on too much work – they go looking for more work.One team I worked with was seriously overloaded. All their projects were months behind schedule. Yet, everyone on the team regularly took on little 20-minute “favors” for other parts of the company.Why? Why would any sane person do this?It was because they wanted to complete something. The 20 minute favor could be done and they could go home knowing that they were actually able to get some kind of value out the door. Otherwise, they had only their bogged-down projects to look forward to.Despite this, middle-management frequently throws up its hands. With an exasperated cry they say, “O! Verily, I am smited by internal politics’ steely hand! Have pity on my wretched soul!”In short, they feel that they cannot tell those above them, "Hey, you know, actually completing work is preferable to doing tons of unproductive work."This is because no knowledge worker, in the entire history of 20th century business, has ever actually understood their work. Neither do their bosses, nor do their boss’ bosses. We simply don’t understand the cost of non-completion.So let me state categorically: Your company right now is wasting time and money by not completing things.And not a little … a lot.Oddly enough – when business completes things, it can use those completed things (efficiency!). Business can make money from them (profit!). And, perhaps most importantly, business can move on to new projects (growth!).Stop me when I get too radical.
Why Do We Not Understand Our Work?
People feel that we are able to predict the future. We create plans, absent of any appreciation for the role of variation in our work. These plans, in reality, are someone’s best guess – or even wish – as to what should happen. They mostly always run afoul of what really happens.We’ll discuss the count the bosses exercise more in the context switching post, but for now, let’s focus on the disconnect between plans and product.We’ve discussed the Planning Fallacy before. The Planning Fallacy is a well documented cognitive bias that shows that people routinely underestimate the length of tasks. Further, we’ve posited that a large part of this is our inherent lack of understanding about the role of variation in our work.So, let’s look quickly at how we plan:
You approach me with a project and ask for a plan
I write down what I think, with my years of experience, will be involved to make that plan happen
We talk about that list
You tell me what the budget and deadlines are
I make that list fit into the budget and deadlines
We argue about the results until someone “wins”
We now have a plan
Do you notice anything about that plan?First, we never asked how long it might really take.Second, we assume that I, the project manager, can make these judgments alone.Third, we made the plan fit into a budget that was set before the plan was written.Fourth, we assume that I , the project manager, will be able to see into the future and know which of those tasks will go horribly wrong.Fifth, there is extreme political pressures to conform to the budget and deadline.Sixth, there is absolutely zero provision for changes to the plan.Seventh, there is no guarantee that personnel I have on my project will remain dedicated to my project.Eighth ... Ninth ... Tenth ... the list could possibly be endless.Now I, the project manager, must make this plan happen – despite all this.And … this is a best case scenario.
Plans and People Collide
Our plans assume that certain people will work a certain percentage of their time on a certain project. Let’s say, we have our mythical man and his name is Eldred. Now, Eldred is a great worker. Everyone loves him. He is the best worker ever.Eldred is slated to work on Project A, which is managed by Glenn. Glenn has put into his plan that he needs 10% of Eldred’s time.So Eldred starts to work on Project A – but he has lots of time for other projects.Eldred then gets pulled into Project B, managed by Iggy. That will take 15% of his time. So, now he’s up to 25% of his time. He, and everyone else, is worried he’ll be laid off at such low utilization, so we put him on to help with the very large Project C, managed by Crazy Larry. Crazy Larry says he’ll take 30% of his time.We’re at a good 55%, which still isn’t enough so Lucy’s Project D and Armin’s Project E can both do another 10% each. Now Eldred is at a comfortable 75% utilization. Everyone agrees that’s okay, and leave well enough alone.So Eldred is very busy suddenly. He’s staying late, not completing anything. And people are getting annoyed. He’s only at 75% utilization. Some people are doing much better at 100% utilization on one or two projects.Why has Eldred’s performance suffered? He has a 25% buffer, even! He has "slack"!
What don’t we understand?
The main problem here is that we don’t understand what we don’t understand.
We feel, after years of seeing project plans, Gantt charts, and professional experience that we can adequately foresee the future. And the truth is, we can, we just don’t understand what we’re seeing.
So, when we look through that list of seven issues with our plan, we find a long list of mitigatable, but also unavoidable issues. The project will more than likely take longer, elements of the project will change, there will be surprises in task duration, there will be unforeseen difficulties, and there will be time-consuming contractual change orders.
On the personal level, we don’t know which of the tasks the project is introducing into our personal work are going to have more complexity than originally anticipated. We have no way of communicating that complexity once it is noticed. And we have very limited skills to even notice when that complexity occurs.
If we have one project, on which we are focused, then we may have more insight into the problems (because the work has coherence) and can quickly communicate one of these work pitfalls. But if we are on two, three, or four … then we progressively lack that coherence and are unlikely to even spot problems as they arise.
We spin more and more cycles on trying to complete complex tasks because we cannot focus on them due to the natural interruptions of being distracted.
So, if I have a complex task that takes, say, 20 hours to complete, but is interrupted by other projects and expectations, it may have only taken me 20 hours (one half a week), but those 20 hours are spread over months. By the time I am done with the task, I have no idea how long it really took and the cost of delay can be massive. What should have taken 2.5 days to deliver now took 2 months!
The real pain points for traditionally managed projects come from everyone being so busy, with no WIP limits. So when something gets complex – we switch to something else. Complex tasks get buried under the pile of other work you are doing. I have seen many projects suffer long delays and, when doing (considerable) forensic research, there end up being 2 or 3 tasks that the culprits. These tasks would have been expediently dispatched with simple WIP limits because people would have been forced to deal with them immediately.
Limiting WIP and Completion
When we limit work-in-progress, we not only limit the number of projects we are working on, but also the number of tasks. This helps us complete tasks efficiently and effectively. When we are done, we understand what we did. While we are doing the tasks we are fully aware of how long they are taking.When we limit work-in-progress, we have a set number of tasks an individual or a team can be working on at one time. When a particular task spends too much time in progress, people notice.This is post 2 of a 10 part series on Why Limit Your WIP. Read post 3 Multitasking and Bottlenecks: Why Limit Your WIP III in the Why Limit Your WIP Series. Also, see the index for a list of all of them.
