Software project estimation is a sensitive subject, but is integral to the task of the technology or engineering manager. Underestimate a firm fixed price contract and your company may lose significant money (and reputation) on the project. Overestimate the effort and your bid will be too high and you many never get the project to begin with. You may also personally get labelled as a pessimist.
Estimation is a big part of planning a project. The larger the project, the more complicated and the more critical the estimation process can become. In many cases the estimation challenge increases exponentially with complexity. For that reason, the cardinal rule of estimation is to break the estimate down into its component pieces/elements on the assumption that the components are easier to estimate than the whole and systems projects are at a minimum equal to the sum of the parts. Those with prior systems experience know that there is something called integration and systems testing and validation that are very difficult to estimate and prove that systems projects are indeed worth much more than the mere sum of the parts.
There are many other cardinal rules, some of which are embraced explicitly by agile (such as the rule noted above). Here is but a sampling of the things to consider when developing an estimate:
- How familiar is your team with this kind of project and this particular market/user?
- How compressed is the timing of the project and duration compared to normal cycle times?
- How stable are the project requirements?
- How many new people will need to join the team to accomplish the project? What is the normal learning curve of a new person to assimilate the technology and product line and market needs?
- How much new code versus modified code do you expect to generate in this project? How solid is the code base (from a quality perspective) that you are building upon?
- What are the quality expectations and how willing is the customer to participate in the development process?
- What are the working constraints? How many other projects are being juggled in parallel with this one?
- Where is the development platform and where is the test (target) platform and how accessible are they?
- What is the mission criticality of the project and what is the fallback plan if the new product needs to be withdrawn from the “production” setting?
It helps dramatically if prior project planning and tracking data are available to help with the estimation process. The systems engineers and project managers should keep detailed historical records of past integration cycles and their time and labor intensity as well as defect discovery rates and densities. This data, though cumbersome to maintain will pay off nicely in the future for achieving more accurate plans and estimates. We call this the project historical data files and they will, over time, become not just a valuable resource but potentially a competitive advantage.
There are many other tools used to estimate the size and duration of a software intensive project, COCOMO and FPA are just two examples, we will explore those in future articles.