Pragmatic method to check/improve effort calculations

Question

Somebody asked me to look over their cost calculation for an internal IT project in the 1.5 mio € range. They did some eyeballing, and are now asking me to cross-check it for them with a few hours of effort. There is no malice involved, i.e. I am 100% certain that they won't blame me for anything that happens now or later, no matter what my conclusion about their project is.

The project includes software, hardware, and time&material for installing the latter; the hardware and the T&M are special enough that neither I nor anybody else outside of the project know much about it.

Obviously, it makes little sense for me to go number-crunching now, as I know nothing about their project except what they already knew and used for their calculation. I also don't want to simply say "no". So my plan is to teach them a small hands-on method to do the work themselves (maybe with me consulting/moderating).

Do you know of a good way to check such calculations? I know that there are many methods for this kind of work out there, some of them very involved, but I am specifically looking for one which fits on 1-2 slides, can be demonstrated/introduced quickly, and which at least gives some measure of improvement beyond just going by gut-feeling, within a short 1-2 day workshop.

They are not going to base the final go/no-go on this; it is more a "should we go along with this at all" decision right now.

Answer 1

As you mentioned, there are multiple estimation methods out there. You just have to ask your favourite web search engine fore something like project efford estimation. Regarding Software Projects, you find some idea on Wikipedia.

From my point of view, when it comes to estimation one of the biggest mistakes is a forgotten task / activity. So, I would put more effort in identifying all relevant tasks than in the effort estimation itself. And to identify the relative tasks, it's about creativity and you'll find as many methods as for estimation.

My favourite way to deal with your question task looks like follows:

• Set up a small group (< 5) containing at least an expert and a novice
• Collect - structure - review
  • Do a (silent) brainstorming to collect necessary tasks
  • Structure the identified tasks to a WBS
  • Review the identified WBS w.r.t to relevance and completeness
  • Apply iteration using different techniques to detail your wbs
  • Take care to identify products and their definition of done, released design documents, SW-releases, etc. to measure progress and to avoid we-are-almost-finished-solutions.
• Estimate the effort using planning poker
  • The discussion between the cheapest and the most expensive guess will help to understand the tasks and to detail them further. Fore sure, you don't have to estimate each task. Let the team decide the level of detail they are able to estimate.