How to deal with “I want it earlier”

deadlineDo you recognise this dialog?


Senior Executive (SE): “In this plan you’re showing me, you say it will be ready by December?”

Project Manager (PM): “Well that’s the best estimate we have now based on what we know.”

SE: “I want it by end of June”

PM: “Er, OK. Er but the team don’t believe it can be done.”

SE: “Take your black hat off. It’s your job to make it happen.”

PM: “Er…”


I was thinking about how to apply a lean-agile mindset to this imaginary situation. How about something like this:


Senior Executive (SE): “In this plan you’re showing me, you say it will be ready by December?”

Project Manager (PM): “Well that’s the best estimate we have now based on what we know.”

SE: “I want it by end of June”

PM: “Why do you want it by end of June?”

SE: “I consider it important that we get this done quickly and I’m sure you are capable of doing it. It’s top priority!”

PM: “Why is it important to be done quickly?”

SE: “Well, this project affects bottom line. It significantly improves our revenues and decreases our cost.”

PM: “So there is nothing which happens at midnight on 30th June which means that if we deliver a minute later then this really matters. It is more like you’d like this to happen earlier than later?”

SE: “Yes, that’s right.”

PM: “I understand that it’s top priority. It will help if we can characterising what top priority means since there are always other projects who are claiming to be top priority. The business case says that this change will have a benefit of $52m per year which is the same as $1m per week. Does that mean that for every week we are able to get this project done early, the company would realise an extra $1m?”

SE: “Yes, that’s true in this case.”

PM: “Does that mean we’d be willing to spend up to $1m to get the project a week earlier?”

SE: “I never thought of it like that but, yes.”

PM: “Great. Now we can make our case about being top priority. Every time we have to wait in a queue for some bottlenecked resource that is on our critical path, we take the amount we have to wait (in weeks) and multiply by $1m and this is the opportunity cost to the organisation of us not going first!”

SE: “I like the sound of that!”

PM: “Of course, the other projects will calculate the opportunity cost they incur if we go first. We will compare opportunity costs and the biggest will win.”

SE: “Em. I suppost that makes sense. Although I don’t like the idea of waiting.”

PM: “That I can understand. We are trying to to what’s right for the company overall. This calculation (called CD3 = cost-of-delay divided by duration or weighted shortest job first) ensures this.”

SE: “Yes. You’re right.”

PM: “Going back to the $1m per week. If we agree on this figure, and the team identify something they can do to bring the delivery forward by a week that costs less than $1m, do we have the authority to spend the money to make this happen?”

SE: “I’m not sure. They can always escalate to me if necessary.”

PM: “So you agree to make yourself available quickly if we have something we need to escalate.”

SE: “Well I am very busy and important.”

PM: “Yes. If you are unable to make the time and unwilling to delegate then the cost to the company will be $1m per week.”

SE: “Yes. You are right. I will be available.”

PM: “With regards to the delivery dates. Our estimated date was arrived at by harnessing the brainpower of the whole team – the people who are closest to the work. This is the best estimate we can get with the information we have today – there is no better way.

At $1m per week, I understand the urgency of realising value as soon as possible, so we will set up our delivery pipeline in order to break work down into small chunks of value and then realise that value, starting with the most valuable chunks. Using this approach, you will see that the team is delivering value before end of June and you will also have ongoing opportunities to change the priorities as we go and we learn more.

This also allows us to check assumptions about the value of the solution and how to build it.”

SE: “I don’t understand. Can’t you just double the team size and deliver earlier?”

PM: “Both IT industry experience and our own previous project experience suggest that this doesn’t help. Larger teams tend to deliver less.”

SE: “That doesn’t sounds right?”

PM: “In any process, it only makes sense to add resource at the process bottleneck. Adding resource anywhere else will slow the team down. IT development is a complex human intensive process. If there are 10 people on the team and we add one more, then there is an overhead on the original 10 in bringing the 11th up to speed, maintaining communication and alignment etc. This is particularly true when the team processes are new. Until there is a running process that is demonstrably creating value then it doesn’t make sense to scale the process and add lots more people.”

SE: “Can’t we just start a lot of work in parallel and have a lot of different teams?”

PM: “Yes this would be possible if the nature of the work was such that there were no dependencies between the teams but the dependencies we have will create bottlenecks. In any case, the most scarce resource in any organisation is usually management attention. Its better to do a smaller number of activities and work on doing them fast than a large number at once and do them all slow.”

SE: “You said that you want a running process that is demonstrably delivering value. When will that be?”

PM: “We aim to begin realising business value within 30 to 90 days.”

SE: “We’ll that is sooner than I expected and I guess I’ll see whether the approach you propose is working by then. I’m looking forward to that.”

Maybe I’m a dreamer but if only all these conversations went like this…

Leave a Reply