Shipulski On Design

If you want to do a task, but you don’t have what you need, that’s waiting for a support resource. If you need a tool, but you don’t have it, you wait for a tool. If you need someone to do the task, but you don’t have anyone, you wait for people. If you need some information to make a decision, but you don’t have it, you wait for information.

If a tool is expensive, usually you have to wait for it. The thinking goes like this – the tool is expensive, so let’s share the cost over too many projects and too many teams. Sure, less work will get done, but when we run the numbers, the tool will look less expensive because it’s used by many people.  If you see a long line of people (waiting) or a signup list (people waiting at their desks), what they are waiting for is usually an expensive tool or resource. In that way, to find the cause of waiting, stand at the front of the line and look around. What you see is the cause of the waiting.

If the tool isn’t expensive, buy another one and reduce the waiting. If the tool is expensive, calculate the cost of delay.  Cost of delay is commonly used with product development projects. If the project is delayed by a month, the incremental revenue from the product launch is also delayed by a month.  That incremental revenue is the cost of delaying the project by a month. When the cost of delay is larger than the cost of an expensive tool, it makes sense to buy another expensive tool. But, to purchase that expensive tool requires multiple levels of approvals.  So, the waiting caused by the tool results in waiting for approval for the new tool. I guess there’s a cost of delay for the approval process, but let’s not go there.

Most companies have more projects than people, and that’s why projects wait. And when projects wait, projects are late. Adding people is like getting another expensive tool.  They are spread over too many projects, and too little gets done. And like with expensive tools, getting more people doesn’t come easy. New hires can be justified (more waiting in the approval queue), but that takes time to find them, hire them, and train them. Hiring temporary people is a good option, though that can seem too expensive (higher hourly rate), it requires approval, and it takes time to train them.  Moving people from one project to another is often the best way because it’s quick and the training requirement is less.  But, when one project gains a person, another project loses one. And that’s often the rub.

When it’s time to make an important decision and the team has to wait for missing information, the project waits. And when projects wait, projects are late. It’s difficult to see the waiting caused by missing or uncommunicated information, but it can be done. The easiest to see when the information itself is a project deliverable. If a milestone review requires a formal presentation of the information, the review cannot be held without it. The delay of the milestone review (waiting) is objective evidence of missing information.

Information-based waiting is relatively easy to see when the missing information violates a precedent for decision making.  For example, if the decision is always made with a defined set of data or information, and that information is missing, the precedent is violated and everyone knows the decision cannot be made. In this case, everyone’s clear why the decision cannot be made, everyone’s clear on what information is missing, and everyone’s clear on who dropped the ball.

It’s most difficult to recognize information-based waiting when the decision is new or different and requires judgment because there’s no requirement for the data and there’s no precedent to fall back on. If the information was formally requested and linked to the decision, it’s clear the information is missing and the decision will be delayed.  But if it’s a new situation and there’s no agreement on what information is required for the decision, it’s almost impossible to discern if the information is missing. In this situation, it comes down to trust in the decision-maker. If you trust the decision-maker and they say there’s information missing, then there’s information missing. If you trust the decision-maker and they say there’s no information missing, they should make the decision. But if you don’t trust the decision-maker, then all bets are off.

In general, waiting is bad.  And it’s helpful if you can recognize when projects are waiting. Waiting is especially bad went the delayed task is on the critical path because when the project is waiting on a task that’s on the critical path, there’s a day-for-day slip in the completion date.  Hint: it’s important to know which tasks and decisions are on the critical path.

Image credit — Tomasz Baranowski

Comments are closed.