I've finally received buy-off to take a baby step in the direction of implementing some project management.
The people I'll be relying on for data have never had to estimate (read as: commit to) task durations. I get blank stares and shoulder shrugging when I try and walk them through a process.
Without any historical data to fall back on, and *knowing* that there will be buffer time up the wazoo added... are there any effective approaches to creating realistic estimates from which to baseline a project by?
Yes, I believe in Parkinson's Law... but right now I'm getting ranges, instead of estimates. For instance -- I ask a developer how long it'll take to code xyz and he gives me a range of "a couple of hours to a month."
Any tips on this would be great. I have a wee bit of authority to enforce some guidelines if I watch my p's and q's and can justify the added value.
Am going through exactly the same thing here - suggest talk to the people and get them to rate their estimates on the 50% & 90% marks - plan accordingly with suitable buffers.
Also make sure senior management know that these estimates are not based upon factual evidence, but the results of which will drive future estimates - that will get them into line behind you and then it is a case of tracking estimate v actual to work out if those 50% estimates you were given are really 50%... each project you get through, repeat the process, each time you will have a little more historical evidence to go through... I have found no other way... Saving Changes...
I am currently leading our IS department through this minefield as well. In reading some of Frank's articles on Critical Chain theory, a lot of it makes sense as to estimation. Bottom line to me as lead PM; if I can keep task estimation as close to minimum as possible, add in buffer zones at strategic points in the project, and have the authority, (either implicit or explicitly) to designate that worker bees only work one task at a time, (until completion) then alot of the fudge factor could actually go away. So I think maybe one way to address the question is, "IF you need to code xyz, and your time can be uninterrupted to produce the code, THEN how long does it take to produce the code?" The myth of multi-tasking actually dimishes everyone's time, because you have to put down one task to gear up for another. Getting buy-in to this way of thinking is rough, (and I'm experiencing back-lash at this now) but I think the overall gain in productivity and deliverables on or before the due date shows enough promise as to be a worthwhile endeavor. Frank, care to expound further? Saving Changes...
Just kidding. But you and David are giving good advice. Briana should accept the range estimates, with the understanding that the larger one is a "commitment level" estimate and the smaller one is "in the realm of possibility" -- stay away from confidence percentages like 90% and 50%; they only muddy the water.
If you can get the right behaviors going, use these estimates to pull together a critical chain schedule. If that culture change is too daunting without outside expert assistance, then promise the project based on the bigger estimates and manage it against the aggressive ones (like two sets of books).
Just make sure that the PM and the Resource Managers do every thing they can to make that "realm of possibility" possible, if not probable. This includes careful network building with detailed task completion criteria, enough iterations (or some added time to the promise) to cover what is needed when iterations are likely, and most important, keeping the resources tied to their current tasks without multitasking other projects or activities.
One other thing -- don't let management overload the pipeline -- that'll only drive the multitasking.
I have done a lot with estimates and estimating ?methodology/process?. As a consultant estimates can be our bread and butter.
If the people have never had to estimate before and you have no historical data, then you have almost no chance of getting an accurate estimate. Experience in the problem domain (business and technical) and historical data are the two most important estimating inputs. Seems you have neither.
If a developer is actually giving you that large a range, then one you need some one else on the task or two you are not far enough along to give accurate ranges. You are probably in the order of magnitude level estimate as opposed to a design level estimate. Ranges themselves and presenting ranges are OK. The larger the range, the more risk in determining cost and schedule accurately at this point.
If the people have never had to estimate before and you have no historical data, then you have almost no chance of getting an accurate estimate. Experience in the problem domain (business and technical) and historical data are the two most important estimating inputs. Seems you have neither.
Dave? right? you need to start sometime or you?ll never have history. You also may want to track and review est vs actual with each person so they know where they need to improve their estimating. Why was my estimate good or bad?
It does not really matter what point you are at or even how accurate the estimates are except that it determines how you deliver the estimate. How the estimate is delivered can be more important than the estimate itself. Don?t get me wrong accurate estimates are great! They make life easier.
Communication is key PM process. Managing the risk and presentation of estimates is just a part of that. You can?t always control the quality of estimates, you can control the communication.
Depending on YOUR environment don?t set a hard date. At this point don?t try to set a date like December 15. Say it will be in December. If you can?t really predict it, then why try? We have had some success with this. There is nothing wrong with setting December xx when you hit November and actually have an idea.
I do like Frank?s idea of promise the project based on the bigger estimates and manage it against the aggressive ones (like two sets of books) is one very good approach in this case. Under promise and over deliver trick; an oldie, but a goodie.
Am I the only PERT fan left? I suggest asking for the best case estimate, the worst case estimate and the most likely for each task. Have each estimate expressed as effort duration. Then take 1/6 of the best case + 1/6 of the worst case + 2/3 of the most likely. In addition to factoring in the inherent uncertainty, this will also draw out the assumptions and issues upon which the estimates are based. It is those influencing factors that you really need to track, mitigate, and manage to get the work done. Saving Changes...
Ok, that was a fascinating thread, but I got pulled up when I saw you equating "estimate" with "commitment". This is dangerous talk. estimates and commitments are two different things and it is best not to confuse them. if people know that when they are being asked for "estimates" it will be interpreted as a commitment and used against them, you will not get good estimates and people will not learn to do it. Stephen Devaux in his book Total Project Control sums this up better than I can. Saving Changes...
I'd like to just throw a spanner in the "estimation by formula" works. A theme that always comes back is the fact that developers are human and if they have never estimated work that they have delivered before then you cannot rely on these estimates. What I find is by working with developers that I have worked with in the past, I have tracked estimation against actual and each developer is different. One will be better than the other and most will build in their own contingency (subconsiously or not). I strongly believe in the dual schedules discussed in this topic - an agressive one, based on developer estimates with some of your own additional contingency (developers won't factor in illness, IT environments being unavailable, holiday etc..), then add some leeway before presenting to the business (altough for external customers, this time may not be chargeable). 4 times out of 5, this leeway will be eaten up before you know it - so the chance of delivering on time (the larger estimate) is greatly increased and it will be possible to deliver early (which must be almost unheard of!). Saving Changes...
One other suggestion I've tried is to have 2 different developers estimate the same work. If that's not feasible, then we do a team estimate review where everyone contributes to try and analyze the work required and help solidify the estimate.
