But I Need to Know When the Project Will Be Done

February 2, 2011 | Author: PM Hut | Filed under: Agile Project Management

But I Need to Know When the Project Will Be Done
By Johanna Rothman

I was talking with a new-to-agile project manager, who said he needed take the first iteration to do design and estimation. I asked why. “Because our management needs to know exactly when the project will be done.”

“Do you think your iteration of design and estimation will provide you a perfect estimate?”

“Uh.” He paused. “From your question, I’m guessing you don’t think it will.”

“I have never found that spending two weeks will provide a perfect estimation for anything larger than a 2-week project. But I could be wrong. Have you been able to before?”

“No.”

“Oh. Do you think you can get a perfect estimate this time?”

“No.”

“Then why would you spend your time doing an estimate instead of producing something, learning from that and bettering your gross estimate?”

“Because my manager needs to know when the project will be done!”

I feel for this guy. I do. I understand why his management wants an estimate that’s better than a swag (scientific wild tush guess). But you can’t always give your managers what they want. You might be able to give your managers what they need (with apologies to the Rolling Stones).

If you are starting a project and you are using iterations, you can do a gross estimate of the entire backlog, do one iteration, see what your velocity, and guess at how many more iterations you will need. Your guess is dependent on the backlog not changing, on your gross estimate being right, and on your initial velocity being a predictor of future velocity. Put like that, your managers will realize your initial estimate is a guess, and they may well want another estimate in another iteration or two or three. That is a very good thing. You can do that.

If you are not using iterations, you can do a swag, and then know that your estimate is wrong, until you have some delivery of some sort. Until you have some part of your product working, you have no idea how far off your estimate is.

If you prefer to use kanban, that’s fine, as long as your features are minimum marketable features. If your MMFs are maximum marketable features, you have no idea when you can be done because you are not limiting work in progress. Kanban is great for limiting work in progress for the entire team, and for not piling up work where people can’t finish it. The team can’t proceed until the team finishes work.

Once you have data, you can see when the project will be done. If that’s after several timeboxes, great. If that’s after some number of minimum marketable features, great. But you can’t really provide an estimate without data. Otherwise, it’s just a swag. And if you want a swag, I can give you any swag at all. It won’t mean anything, but I can give you one.

The original article can be found at: http://www.jrothman.com/blog/mpd/2011/01/but-i-need-to-know-when-the-project-will-be-done.html

Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

4 people have left comments

*sigh* As far as we’ve come in the profession, questions like that in your example continue to flourish. Your techniques are very effective, and helpful, and will provide management with the best information possible to help their decision-making. But the underlying issue in this scenario is a management looking for reassurance that there’s no risk in the project. It just doesn’t work that way. If you expect to take on a project and not have any risk, that’s having your cake and eating it too.

“But I Need to Know When the Project Will Be Done” is a source of much head-banging on tables by project managers, simply because the correct answer is, “you can have a best estimate but no guarantees–stop asking!” LOL

Thanks for a great article, Johanna! Sorry for my little rant. :-D

Geoff Crane wrote on February 2, 2011 - 3:11 pm | Visit Link

Geoff,

Then respond with a “best estimate.” But that estimate must have some basis of estimate. SWAG are rarely credible when you spending someone else’s money.

Imagine you’re hiring someone to do something in your house. We just had our kitchen backslash installed after 3 years of waiting. The contractor is a friend who built our house, upgraded the kitchen three years and has done other things over the 18 years we lived there.

Imagine Doug (his real) responding to my question “Doug how many days to install the stone, the under counter lights we forgot in the first round, move power to inside the side board, put the feet on the bottom cabinets, and some other stuff.

Doug would have a estimate. He’d speak in terms of estimates. But that estimate would have an upper and lower bound. Some assessment of the variance. Something around the confidence in those upper and lower bounds.

He’s not give a best estimate, because that best estimate has no variance. Point estimate - even if they are labeled BEST - are pretty much a SWAG.

When you’re spending someone else’s money SWAGs are that useful. Same for spending my own money.

What’s troubling here is we don’t speak in confidence intervals, upper and lower bounds, probabilities of completing “on or before” a date or completing “at or below” a cost. We send the message that the manager is somehow not entitled to ask the question in the first place. That the developer gets to decide what the manager “needs” instead of what the manager “wants.” This bottoms up decision making is indicative of an agile person complete misunderstanding about where her pay check comes from - not from the Bank of America, but from the customer (internal or external). When this person “new to agile” gets to management, with a budget, and time frame for performance, and with managers above her, maybe she’ll start to do her homework and have a credible, risk adjusted, probabilistic estimate before her manager comes and asks.

Glen B Alleman wrote on February 2, 2011 - 7:04 pm | Visit Link

Even multiple probabilistic estimates with varying degrees of confidence carry risk, though, don’t they Glen? I fully get that management needs and wants to have their estimates; I even grant that they’re entitled to them. But they’re still estimates. The keyword in Joanna’s article for me was “exact”. It implies a management seeking a guarantee that can’t exist, thereby attempting to eschew the risk of taking the project on in the first place. Paycheques notwithstanding, I don’t think that’s 100% responsible, and I find it a little Teflon-esque.

I see your point, though. I think there’s a give and take that needs to happen. Management does have the right to demand estimates, and hold their resources accountable. But they also have to be understanding and prepared to replan if the estimates don’t hold up due to unforeseen circumstances (yes, there are ways for dealing with that I know–but management still needs to be prepared). The key is adaptability on both sides, I think.

Geoff Crane wrote on February 2, 2011 - 7:38 pm | Visit Link

I’d be interested in an article or perspective on budgeting for agile projects. If I understand correctly, we use agile because there are so many unknowns in the project, requirements are not clearly specified, technical specifications are incomplete, customer doesn’t really know what the want until they see it, too many unknown unknowns…. On the other hand, we need to give the customer an idea of budget to establish the business case. So, in order to win the business, we need to agree a budget and scope and flesh out the details iteratively. This creates risk in terms of cost overrun if the project does not meet the unknown customer requirements after the budgeted number of iterations. Now we could start out with an indicative budget with 25% confidence, and revise the estimate after each iteration slowly increasing confidence to 40, 60, 80% confidence. But will customers agree to this commerical approach? Will they accept the risk at outset that budget might be off by a factor of 4 or more? How much will they be willing to spend to reduce that risk? Indicative budget £500,000 @ 25% (ie 0.5 to 2m). Spend £50,000 to increase confidence to 65%. Spend another £50,000 to reach 90% (ie cost is now £100k plus remaining budget of £550k @ 90% = £650 to 705k). Are customers agile?

Tim Morgan wrote on May 27, 2011 - 9:20 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories