Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Estimating Updates

No replies
Patrick Weaver
User offline. Last seen 9 hours 39 min ago. Offline
Joined: 18 Jan 2001
Posts: 373
Groups: None

Over the last couple of weeks, we have been updating the estimating pages on our website, partly in response to the #NoEstimating idiocy. There is no way an organization that intends to survive will undertake future work without an idea of the required resources, time, and cost needed to achieve the objective and an understanding of the anticipated benefits – this is an elementary aspect of governance, which requires estimating! BUT there are two distinctly different approaches to estimating software development and maintenance:

 

1.  Where the objective is to maintain and enhance an existing capability the estimate is part of the forward budgeting cycle and focuses on the size of the team needed to keep the system functioning appropriately.  Management’s objective is to create a stable team that ‘owns’ the application. Methodologies such as Scrum and Kanban work well, and the validity of the estimate is measured by metrics such as trends in the size of the backlog.  For more on this see De-Projectizing IT Maintenance at: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1

 

2.  Where the objective is to create a new capability, project management cuts in.  Projects need an approved scope and budget which requires an estimate! The degree of detail in the estimate needs to be based on the level of detail in the scope documents. If the scope, or objectives, are only defined at the overall level, there is no point in trying to second guess future developments and create an artificially detailed estimate. But, with appropriate data high level estimates can be remarkably useful. Then, once the project is approved, normal PM processes work well. Some of the sources of useful benchmarking data are included in our update estimating software list at: https://mosaicprojects.com.au/PMKI-SCH-030.php#Cost

 

In summary #NoEstimating is stupid, but trying to produce a fully detailed estimate based on limited information is nearly as bad.  Prudent estimating requires a balance between what is known about the project at the time, a proper assessment of risk, and the effective use of historical benchmarking data to produce a usable estimate which can be improved and updated as better information becomes available. 

For more on cost estimating see: https://mosaicprojects.com.au/PMKI-PBK-025.php#Process1