No related posts.
Once Bitten, Twice Shy
Previous post: Managing Stakeholders Empathetically
Next post: How To Get Ahead Without Killing Yourself
No related posts.
Previous post: Managing Stakeholders Empathetically
Next post: How To Get Ahead Without Killing Yourself
{ 9 comments… read them below or add one }
Great article Josh. I've been a developer and know how estimates get padded when necessary. And in your story, it's no surprise that Mark would double his estimate following the poor handling of the situation with Jack. A group review of estimates and an ongoing budget review as part of internal project status meetings as well as ongoing status meetings involving the customer would help alleviate this issue and certainly bring it to light before everything Mark is doing becomes the critical path. Thanks for sharing.
Excellent comments Brad, thanks!
This is why best engineering estimates are not allow of most DoD programs. A basis of estimate must justify the cost and duration beside some ones opinion. When is IT and other project domains going to figure this and stop behaving in this way.
Hi Josh – good story.
This resonates with me in trying to estimate jobs for clients, as well as the moral – so over the years I have adjusted my model differently to try to allow for more open and shared responsibility, and ultimately better ensure win win results. Perhaps an idea.
In general, I don't really believe in long term project estimates AT ALL anymore without caveats galore (of can't be accountable for unknowns, change notices will stop you at every step likely, etc. etc.).
Of course clients hate the caveats, so instead I have frank conversations with them about their own internal projects (since usually this entire estimation process is before the client is fully on board). When I push the honesty path up front, the clients often acknowledge their challenges in estimating also – yet they of course still need something as a guide for budgeting.
Okay – understood. At least now we can discuss on same page.
The next part of the discussion reaches out to their end date goal, then backs up the calendar. Then milestones each week for momentum to the end goal – and transparent systems (shared collab wiki and issue tracking) between the client and us to ensure that BOTH sides stay honest on the trajectory over time.
From there, we can estimate the “bite-size” chunks with a better level of realism, as well as highlight pts of risks and dependencies. We can mutually discuss the time it will take, and decide a milestone approach with checks allow for both budgeting and satisfaction. And the client buys a block of hours with some expectations of one or two or whatever milestones and best efforts in that time.
I will ack to the client that we will take the lead on deliveries, iteratively (weekly even often) – released within the systems – but this assumes also engagement continually from the client in terms of reviews (UAT) – and if not, then we cannot be held accountable to those delays. Although even in these cases, sure – will try our best regardless.
==
In the case of the discussion above – if Mark had kept Jack continually in the loop on a shared system vs email (even if Mark didn't watch or follow the whole time), that early blaming discussion might have taken a different course. As well as the later subtle bashing by Mark to Sue. Everyone gets what happens and how it goes. when its transparent.
Projects rarely run without hiccups – but with transparent systems between all parties and stakeholders, at least the accountability is also shared and sting less for all – and the team instead can work together to get past the hurdles “as a team” vs more wasted time in the blame game among other. Just an idea on all this.
Ellen
Agreed Glen. Unfortunately, I've seen practices exactly like this for estimation all too often. “Here's a list of stuff, guess how long it will take and get back to us.”
Thanks Ellen! Great points. This is a good reason why range estimates are so valuable, because they communicate clearly and truthfully about the uncertainties and our confidence, and clients can see the +/- range go up as the estimate goes further into the future.
If you can use individual 3-point estimates and use existing knowledge about past projects as a starting point and use a system that accurately represents that as a whole, you have something pretty decent, even years out.
I agree fully with Glen's comment about the need for a true basis of estimates; when I discovered that process after moving into aerospace it opened my eyes. When done right, there is no need for padding estimates because everyone knows the justification and assumptions being made. Then you can have true management reserve for contingency and not as simply “extra padding” (and formulate your amount of reserve based on a justified level of uncertainty that is understood and in plain sight).
-Josh
Based on my experience, the root cause is clear … too many IT project managers are taught that they should let the person who is going to do the work estimate the work. This is just so incredibly wrong on so many levels:
– In IT, the person who is going to do the work seldom has enough knowledge or experience to estimate the work.
– There is no distinction made between estimates and budgets. (In fact, Josh's article implies that there is no difference between an estimate and a budget.)
– Some level of estimating is often required before we know who will be doing the work.
I find it interesting that both Jack and Sue made the SAME MISTAKE.
Thanks for the comment Duncan.
I didn't mean to imply that an estimate and a budget are the same. In my scenario I said the project came in over budget, which is what I meant. I can try to draw a clearer distinction between estimates and the baseline budget in the future, although that wasn't part of my point in this particular post. Of course another angle on this scenario is that insufficient (or non-existent) MR resulted in spending over the agreed budget.
I'd really like to hear more about the point that the person who is doing the work shouldn't estimate it. I prefer group sessions for estimation, but they include the person(s) who may be eventually assigned to the tasks.
You did say that the project came in over budget, but you also talked throughout about Mark's estimates without ever mentioning the vital step of converting an estimate into a budget. If Jack used a single-point estimate from an inexperienced team member for his budget, then Jack was clearly the one at fault.
What are my concerns with having the person doing the work estimate it? As I said in my initial post, my main issue is that the person who will do the work often lacks the ability to develop a reasonable estimate, and is even less able to convert that estimate into a budget.
I also see too many project managers who think this rubric means that they must accept the individual contributor's number without discussion. That is pure abdication of responsibility.
Finally, that concept is pretty much unique to IT and software. Architects and engineers have standards for design work because they track and monitor their performance. Construction folks have professional estimators.