In a previous blog post, I mentioned how electronic lean/agile/kanban visual project management tools have a bigger impact on schedule that any previous solution that I can think of. And I mentioned a case study where a customer cut their development time by 85% over their industry average as represented in this graph.
When I discuss these results I always tell people not to expect the same thing—not every company gets the same impact! But I also realize that metrics like this sound impossible. How in the world could someone cut that much time off their projects when it’s so hard just to make them end on time?
Read our complete guide to Lean Project Management here.
Well, it’s actually not that hard to explain…
I consider Managing the Design Factory, to be the seminal book on Lean Product Development. It was for me, anyway. In it, Don Reinertsen explained various methods for increasing project velocity, and their various tradeoffs. Without going into detail on each one, each of them ultimately deal with how to manage or eliminate queues in the development process. If you’re not familiar with the English definition of “queue,” it means, “A line or sequence of people or vehicles awaiting their turn to be attended to or to proceed.”
Obviously, we’re not talking about people or cars, but instead are talking about any of the work that needs to be done during the course of a project. And “waiting to be attended or to proceed” is the key phrase.
The reason queues are important is because they are usually the biggest cause of schedule delays.
But most companies don’t even know this!
If you ask a project team what caused their last project to be late, you will usually hear about the things that caused large delays like a test failure, or long lead times. But no one recognizes the 135 days that were lost because team members had incorrect priorities and were working on the wrong things at the wrong time!
Why is that?
Two reasons: they didn’t know their priorities were wrong, and they think it “only” causes a one-day delay each time it happens...
But let’s dig into this a bit.
When you look at the cycle time for any item of work, you have to measure from the time the work arrived in the queue, until the time it left or was completed. That’s the total cycle time as shown in this image.
But that total amount of time is made up of two parts. One is the “server time,” or how long it took to do the work. And the other is “queue time,” or how long the work sat idle waiting to be worked on. And as the image below shows, the queue time is often many times greater than the amount of time it takes to actually do the work…!
Why is that?
There are several reasons. The first problem is that most of the work in hardware product development projects is invisible. We can’t see it piling up anywhere, so we can’t see the size of the queues and how far behind we’re getting. (More pressure!)
And the second problem is that when we do pick something to work on, we’re normally guessing at its priority. And not only are we normally wrong, but people don’t realize how serious the cumulative impact really is.
Think of it this way. If a person is only working on three projects, and they can make a list of ten things they could do on each project, they would have thirty things to pick from. Pure chance would say they would only be correct one out of thirty times. But most people have some sense of what’s important so could probably narrow the list down to the five most likely important tasks. So they might be right about 20% of the time.
Those are much better odds, but they are still costly beyond what people recognize.
Every day you don’t work on the correct priority, the project gets one day longer.
That’s an easy concept to grasp, but people don’t realize how much that adds up over time.
The graph below shows how much the end date slides on a twelve-month project based on how many days per week you work on the correct priorities.
The top bar shows that if you have the correct priority every day, your project would not extend a single day. (At least not because you worked on the wrong thing.)
The second bar shows that if you were able to guess the right priorities four out of five days, the project would “only” increase by 25%.
But if you only guessed the correct priority two days per week, your twelve-month project would literally be eighteen months late!
Now do you see what I mean when I said that people don’t realize how serious the cumulative impact of daily slips really is?
Since PLAYBOOK ensures that everyone on the team has not only clear priorities, but correct ones as well—and does so every single day—the project never slides a single day because people worked on the wrong thing.
Now that we understand this, let's go back and look at the case study graph. If the Industry Average companies were guessing the correct priorities slightly less than 20% of the time, they could cut their project times by 85% just by having the correct priority each day…!
Granted, we know the case study company very well and I can tell you that it is run by extremely competent senior leaders, project managers and team members. So they deserve a lot of the credit because they do a lot of things really well besides just using PLAYBOOK.
But at least now it should be apparent that serious gains can be made in project schedules just by making sure people have not only clear priorities, but correct ones as well…!
If you would like to see how PLAYBOOK does this, simply request a Free Trial. As SensorLink found out in this case study, you will get a lot more than just a download of software. We will train your team on some key lean and agile principles for hardware product development, and use one of your live projects as the example!
Want to learn more about the cause of project delays. Watch this 9-minute video. If you find it useful, please share it!