Sometimes you inherit undersized projects. It’s not your fault. You weren’t there for the original estimate. But it’s your baby now and you’ve got to set expectations.
I had to do that recently. I suspected the project was bigger than it looked (thankfully we hadn’t started yet). I did an inception deck with the team and all the sponsors, and lo and behold – it was bigger than anyone expected.
I had to deliver some bad news.
Here is a sanitized form of the letter where I explained to the sponsor why the numbers were what they were, and why the team didn’t feel like it would be safe to go with the lower more aggressive numbers.
Hi Mr. Smith,
After sitting down with the team, and going over the estimates, the team’s best guess is that XXX Project is in the neighborhood of:
325 – 490 days with a strong feeling towards the higher number.
I asked the team if there were areas we could simplify, cut back on, or reduce size in, and was cautioned against the lowering the numbers.
The fact that it is:
– A cross cutting project (lots of stakeholders)
– Distributed team (x3 cities)
– There is no in-house expertise
– Many first times (never done x, y, or z, etc)
tilts the team towards believing this project be slow, with a good chance of surprises along the way.
It’s big. And the team feels there is little risk in finishing early ahead of schedule.
Let me know if you’d like to get together to look at options on how best to present this number and how we should proceed with the budget and schedule.
Actual vs Original Estimate
There’s a lot going on here (and a lot of missing context and background behind the project). Don’t worry about that for now. Here is what I wanted to share:
1. Estimates as a range.
Even though the original estimates were in days, I like showing stakeholders than when we first give estimates, we don’t really know upfront how long things are going to take (see Cone of Uncertainty).
By showing the estimates as a range, I convey that sense of uncertainty, and it’s a nice lead into Agile planning where I explain how I will soon be able to tell him the exact date.
2. Why the higher number.
This project was about as risky as they get. It was cross company, brand new work with no inhouse expertise, spread across three cities. Nothing in this project was going to go fast, and I needed to alleviate the fear that by some chance the team might finish early and not need the extra funding.
We owe it to our sponsors to be as transparent and visible with regards to where these guesses come from. So I always try to frame it in ways they understand.
3. Actuals vs Estimate.
This project missed a lot of important stuff first time round. That’s why those boxes are red. They represent new stuff (or scope). I like highlighting this and making it really visible, so people can see and feel the size difference. On some ThoughtWorks projects we would use bubbles to actually represent the size to make it feel even more visceral. But you get the point.
That’s it. I just wanted to share this letter/email. I find when writing these it’s best to be clear, simple, and straight to the point.
It’s never fun. But it needs to be done. Bad news early is the Agile way and the sooner you let your sponsor know their project is in trouble the better.