How many times have you heard the phrase “What is the project timeline?” If you were asked this phrase, what was your reaction? Were you waiting with bated breath to speak your thorough analysis and research into an airtight date with milestones? Were you filled with dread as you utter something that you knew was wrong?
I wish I could say that this question belongs in my history, but it doesn’t. It falls out of the mouths of people all the time. Sometimes they ask when they know they shouldn’t. Sometimes they ask when they have nothing else. Sometimes they ask when they are out of options.
Why is this question so hard?
Well, in some spaces it may not be that hard to come up with a reasonable answer with milestones that are more correct than incorrect. How would you know if you’re in that kind of space? There is a manual telling you how to do your job and it has been followed successfully many times before.
Software, by the way, doesn’t fit that model.
In fact, many people have a number of projects that run over their estimates by nearly double. This is quite common. Do we adjust our estimates to take this into account? Not really.
I’ve worked with a few aspiring managers and project managers who looked at this data and then would double the estimates given and present it alongside the original. I’ve never seen this go well.
Sadly, that aspiring manager may have been right. The problem is that the estimate is so huge that it looks lazy, sloppy, and unusable. How can a manager go secure budget for something that is so huge compared to the other projects?
What is there to do? Let’s take the question apart and try to turn it around.
First, they want an end date. They want to know when the project will be complete. I will use several tools in this conversation. I’ll build a Monte Carlo simulation of the project with historical data. I’ll look at estimates and actuals over several projects and derive a percentage we are off and apply it to the estimates.
If you think this sounds exactly like what that ambitious person did, you’re right. Managers will ask dozens of questions about my numbers and methods. They won’t understand them, they may refute them. I don’t give them the original estimates. I exploit this moment.
“If we can’t predictably deliver to this timeline, we need another way to build software so that we have the ability to stop early after we have the essential pieces. We need the ability to alter course so every day spent is a valuable one. This project assumes everything works in the end. It won’t.”
This little speech tends to pause the timeline conversation. It works because I’ve acknowledged the absurdity while maintaining its anchoring in reality while also giving them a solution.
This solution will be described in more detail as agile development.
The next part about milestones that come along with the timeline is a little stranger to tackle. The milestone conversation is about scope. They are asking how much will they get at certain dates.
At this point, we want to move away from the scope question. This is tricky because it’s how people are used to thinking of things. They aren’t sure how to think about it differently.
We want to shift from scope to outcomes or value. Scope is the guess we make pursuing the outcomes or value.
“We can build the scope as defined. It’ll be hard to impossible to get it right. There are too many variables to account for. Instead, we could work towards a measurable outcome or a clear business goal. That way our scope can move as we learn more about the challenges while maintaining, ‘True north’ towards our goal.”
I have limited success with this statement. It makes too much of a leap too quickly.
Honestly, most leaders I’ve met have never had a goal or vision. They use those words, but if you ask specifically for their goal or vision they’ll struggle.
To make the leap smaller, consider having example goals. Bring example metrics with those goals. The metrics are the warm blanket surrounding change. If there is a way to measure progress, we can feel good that we’re doing the right things.
Sounds ridiculous, but this is what I’ve seen time and time again. A measure, no matter how bad or impossible it is to interpret gives a sense of security.
Don’t believe me? How many reports have you seen with velocity in it?
I hope the next time you hear, “What is the project timeline,” you also see an opportunity. Use metrics and historical data to show a timeline that reflects how the organization has delivered in the past. Exploit the opportunity that presents itself when people balk at the numbers to provide an alternative. Shift the conversation from measuring scope to outcomes and goals by providing examples and measures to go with them.
Give it a try, see how it goes.