Process Compliance Saves 15% of Development or Maintenance Costs
I had the opportunity to hear a brief on Computer Aid’s Tracer software and methodology. Tracer, when applied as recommended by CAI details all the process steps needed to accomplish every task and allows software personnel to entry time directly into the system as well as check off tasks completed. Tracer then show them what it takes to be compliant with processes. I believe if people started using something like Tracer they could actually get their CMMI type processes working and could achieve the 15 or more percent savings that Computer Aid themselves achieve. Amazing…. Simply by doing processes rather than giving them lip service: big savings and more successful projects. Applying Tracer to software projects can mitigate the issues of CMMI compliance. Of course CAI points out this doesn’t have to be CMMI.
Step Ten: Track Project throughout Development
Refining Estimates throughout Project
Estimating software size, cost, and schedule should be an ongoing process. Preliminary estimates may be required to bid a job or to initiate the development process, or you may need to conduct a cost-benefit or return-on-investment (ROI) analysis to evaluate a project’s feasibility.
Preliminary estimates are the hardest to develop and are the least accurate because of the incomplete nature of the information available and the other factors discussed.
You can improve the accuracy of a preliminary estimate by using the sizing methodology identified in Step 4 or by using two different estimation techniques and having your analysts normalize the differences. There will still be a significant risk in using the preliminary estimate to structure a project or to evaluate risk in the early stages of a project life cycle.
Once a project has started, you will need to complete more detailed estimates to accurately plan the project and throughout the conduct of the project you will need to monitor the actual effort and duration of tasks and/or phases against planned values to ensure you have the project under control.
Summary
Software cost estimation is a difficult process but a necessary part of a successful software development. You can help ensure useful results by adopting a process that is standardized and repeatable. Several of the steps we have discussed, particularly those that do not result directly in the production of the estimate (Steps 1, 6, and 7) are often deferred or, worse still, not performed at all, often for what appear to be good reasons such as a lack of adequate time or resources or a reluctance to face the need to devise a plan if a problem is detected. Sometimes you simply have more work than you can handle and such steps don’t seem absolutely necessary. Sometimes management is reluctant to take these steps, not because the resources are not available, but because managers do not want to really know what they may learn as a result of scoping their estimates, quantifying and analyzing risks, or validating their estimates. This can be a costly attitude, because in reality every shortcut results in dramatic increases in project risks.
Previous:
Step Nine: Document Estimate and Lessons Learned
Step Nine: Document Estimate and Lessons Learned
Each time you complete an estimate and again at the end of the software development, you should document the pertinent information that constitutes the estimate and record the lessons you learned. By doing so, you will have evidence that your process was valid and that you generated the estimate in good faith, and you will have actual results with which to calibrate your estimation models. Be sure to document any missing or incomplete information and the risks, issues, and problems that the process addressed and any complications that arose. Also document all the key decisions made during the conduct of the estimate and their results and the effects of the actions you took. Finally, describe and document the dynamics that occurred during the process, such as the interactions of your estimation team, the interfaces with your clients, and trade-offs you had to make to address issues identified during the process. Cost models, which are based on the actual costs of past projects, can be calibrated and their accuracy can be demonstrated by comparing the costs of your current estimates with both past project data and the actual costs of your completed project, thereby adjusting the model input parameters to improve future accuracy.
Step One: Establish Estimate Scope and Purpose
Establish Estimate Scope and Purpose
Define and document expectations. When all participants understand the scope and purpose of the estimate, you’ll not only have a baseline against which to gauge the effect of future changes; you’ll also head off misunderstandings among the project group and clear up contradictory assumptions about what is expected.
Documenting the application specifications, including technical details, external dependencies and business requirements, will provide valuable input for estimating the resources required to complete the project. The more detailed the specs, the better. Only when these requirements are known and understood can you establish realistic development costs.
An estimate should be considered a living document; as data changes or new information becomes available, it must be documented and factored into the estimate in order to maintain the project’s integrity.
Previous:
Ten-Step Project Estimation Process Introduction
Coming Next:
Step Two: Establish Technical Baseline, Ground Rules, and Assumptions
Total Cost of Ownership: Development is (only) Job One
Planning software development projects is never an easy undertaking. Customer and competitive requirements, time-to-market, architectural and quality considerations, staffing levels and expertise, potential risks, and many other factors must be carefully weighed and considered. What can make software planning even more complicated, however, is that software development costs only comprise a portion - often the smaller portion - of the total cost of software ownership. In fact, the development process, itself, invariably has a significant impact on total cost of ownership as tradeoffs are evaluated and compromises made which impact software sustainability and maintainability of software over time.
Because software doesn’t wear out like car tires do, software planners may underestimate how much a code stream can degrade over time with the accumulation of patches, system and configuration changes, provisioning and re-provisioning, integrations, and ongoing development. Further, the rigorous standards applied during initial software development may end up being compromised as maintenance personnel are diverted to emerging or mission-critical software issues. Over time, accumulation of poorly managed changes almost always generates software instability and a significant increase in the cost of software maintenance - up to four times the cost of initial development, according to some estimates.
This session will provide a systematic approach to addressing total cost of ownership across the software lifecycle, including design for maintainability, development of measurement criteria, collection of metrics, and industry standards, guidelines, and best practice options. Parametric modeling will be discussed using the SEER platform as a specific example of this approach. Estimating block changes and their potential interdependencies and impacts will also be covered.
Click here to see the slides.
