In my last article on estimation, I talked about creating consistent estimates by establishing a scale, where for every type of work you do, and for a range of complexity levels (i.e. low – medium – high), you record pre-set values that can be plugged in to your estimates. What I was in fact describing was a complexity model. In this article I will describe how as a team you can build your own complexity model for your development organization to govern your estimates. › Continue reading…
Tag: planning estimates
In my last article, “Is it bigger than a breadbox”, I talked about the three points in a project when estimates are usually delivered. The topic of that article was the rough order of magnitude (or ROM) estimates generally given during the project selection process or at project initiation. Those estimates can have +- 50% margin of error in them due to lack of information. Once the project is approved, the team begins working on scope definition artifacts, developing first a high level, then a detailed scope statement, and a work breakdown structure to establish a scope baseline. What I want to discuss in this article is a method to derive a planning estimate at a point where the high level scope statement is created, but before the detailed scope definition or WBS artifacts are finalized. › Continue reading…
One of the most perplexing dilemmas of any project portfolio process, a catch 22 really, is how to estimate the size of the potential candidates being submitted before the selection board. The catch 22 is that the selection committee wants an estimate of how much the project will cost before they can make a decision on whether to approve of it. However, no work has been done on the project yet to define the scope or requirements to know what work would be necessary. In fact the team that could even do the estimating has not yet been assembled. No one wants to even invest the time to do any discovery until they understand the overall cost of the project. So, if you are a program manager, you argue, it is impossible to determine a reasonable cost. The decision makers counter-argue that they cannot make a decision without some kind of budgetary number to consider. So you assemble a technical team and ask them to give you some kind of ballpark estimate based on the very sketchy facts you have at such an early point in the project. They of course protest, suspicious that they will be held to the number when requirements balloon later in the project. And round and round you go … › Continue reading…