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.
Make or Break: Why Accurate Cost Estimation Is Key
A recent article from executivebrief.com sent to me By Dr. Ricardo Valerdi of MIT discusses how the accuracy of the cost estimation process can make or break a project’s success.
“When it comes to controlling costs, it is a critical first step to make appropriate estimations at the outset of a project. Being able to control costs is largely a matter of adhering to established guidelines, oftentimes by learning from previous projects and reacting to current circumstances efficiently and effectively.”
It is amazing to me how simple this concept is, yet how many CEO’s don’t even know it is possible. Accurate estimates (of course with risk and uncertainty factored in) yield viable project plans which can then be successfully monitored and controlled. In fact the application of techniques such as earned value management, as powerful as they are, crumble when the baseline plan is unachievable.
Software Estimation Much More Complicated Than Some Perceive
How many times have we been asked to submit a 5 minute or off the cuff estimate to stakeholders… Then be held to that estimate even though we missed the complexity in our haste.. Of course if we didn’t prepare an estimate until everything was known the estimate would be of little value. That is why uncertainty must be part of the process and off the cuff, manual estimations should be avoided when possible.
I thought these diagrams showing the perceived simplicity of the software estimation process versus complexities in the software cost estimation process were very interesting.
Automated Versus Manual Estimating
Having been in the industry for decades I have seen a lot of projects get into trouble with inadequate estimating. Watching the estimation methodologies (or lack therein) I have seen a variety of techniques. Over the years, analyzing these I have made several observations:
Developers are not too bad at estimating what it will take to make the software do what it should (the go path)… They are not so good at estimating what it will take to make the software not do what it shouldn’t.
- Manual estimates can very greatly even from the same person, depending on their current frame of mind.
- People have poor memories as to what it really takes to build and deliver acceptable software.
- Estimating effort directly (e.g. that take should take 3 months) rarely produces an optimized plan.. And without repeatability no one can figure what went wrong.
- Manual estimates at the lowest (1-2 week) level can actually make projects take longer since tendencies are to estimate those tasks at a higher probability and use all the time, even when things go well.
- Parametric estimating provides a language, methodology, and repeatability to the process.
- When people don’t want to take the time to estimate their project is already in trouble.
- Agile projects don’t eliminate the need to estimate. Stakeholders are not comfortable with “we will be done when we are done” answers.
The folllowing table summarizes some of the estimating methods:
Effectiveness Measurement At Galorath Still Focusing On the Positive
I was in an ISO review today at Galorath Inc. I saw customer satisfaction scores that were through the roof (in a good way.) I saw compliments (from the ISO compliments file) that were flattering. I asked about the complaints file (also an ISO requirement) I was told we had no complaints since the past review. I personally appreciate the compliments but learn more from complaints. When pressed I found nothing was reported as complaints. But there certainly had been some areas where we could have done better.
Process improvement is about finding where things could be better, not about painting rosy pictures. We are in the business and even we like to concentrate on the good and minimize the bad.
We are probably better than most in this regard. Process improvement and improvements in customer satisfaction is important. And to achieve these we have to identify and stress where we can do better.
Step Eight: Generate A Project Plan
The process of generating a project plan includes taking the estimate and allocating the cost and schedule to a function and task-oriented work breakdown structure. Models such as SEER Client for Microsoft perform this function automatically. The eight major software development phases
are: (1) concept, (2) acquisition, (3) requirements, (4) design, (5) code and unit test, (6) integration, (7) acceptance, and (8) post deployment.
Determining Costs from Effort Estimates
At this point in the estimation process, you should have a reasonably accurate projection of your project’s size and required effort, that is, an estimate of the number of person-hours by component and a sum of these projections, and you can now begin to price the estimate. As software estimation models generally account only for costs related directly to development, you may need to translate the required effort to a cost and finalize the estimate by adding in essential nonlabor costs. You can do so by answering the following questions:
What types of individuals do I need and when do I need them?
Identify the specific personnel requirements by task area (direct software management, software systems engineering, design, programming, configuration management, quality assurance, etc.). Develop a strawman schedule from the work breakdown structure or a staffing plan such as the one produced by SEER-SEM.
How experienced do they have to be? Assign specific staff levels to the task requirements and identify the level of experience required to satisfy the task. Some of the automated cost models will identify the tasks and develop a task-based schedule, which will minimize but not eliminate all of the work required to produce the software development plan.
Step Seven: Estimate Validation and Review
Step Seven: Estimate Validation and Review
At this point in the process, your estimate should already be reasonably good-but it may not be as good as you think. It is important to verify your methods and your results in a step called validation, which is simply a systematic confirmation of the integrity of an estimate. By validating the estimate, you can be more confident that your data is sound, your methods are effective, your results are accurate, and your focus is properly directed.
It may be tempting to skip this review due to a lack of time, personnel or budget, and there is the unappealing possibility that a close examination may reveal faults in the logic of your process. Nevertheless, the costs involved in performing a proper validation will be dramatically less than the cost overruns that are likely to develop during a poorly managed software project.
There are many ways to validate an estimate. Both the process used to build the estimate and the estimate itself must be evaluated. Ideally, the validation should be performed by someone who was not involved in generating the estimate itself, who can view it objectively. The analyst validating an estimate should employ different methods, tools and separately collected data than were used in the estimate under review.
Ten-step Project Estimation Process
Software Estimation Concepts
Many project managers and project management offices have unrealistic expectations about estimates. The definition of the verb estimate is to produce a statement of the approximate value of some quantity. Estimates are based upon incomplete, imperfect knowledge and assumptions about the future. For these reasons, many estimates of software costs tend to be too low due to omissions of important product functions and project activities. Most importantly, however, all estimates have uncertainty. There is no such thing as a precise, single-value estimate. Managers should always ask how large the uncertainty of an estimate is! A manager can use the size of this uncertainty in conjunction with other factors such as perceived risks, funding constraints, and business objectives to make decisions about a project.
How can projects address the uncertainty of poor estimates? How can the risks associated with initial estimates be identified, managed, and controlled? The answer is straightforward: by defining, establishing, planning, and applying a consistent, repeatable, and effective estimation process.
A software estimation process that is integrated with the software development process can help projects establish realistic and credible plans to implement the project requirements and satisfy commitments. It also can support other management activities by providing accurate and timely planning information. Realistic plans will also describe how the resources that are required to undertake the initiative in accordance with the schedule will be secured. The planning process, as critical as it is, is difficult and takes time to perform correctly. Managers often truncate the planning process by using “easily available” information that is often inadequate; by employing whoever has the time, even if those individuals are not qualified to perform the estimate; and by using only one estimation method to save time.
Successful software engineering requires the application of engineering principles guided by informed management. The principles must them-selves be rooted in sound theory. While it is tempting to search for miracles and panaceas, it is unlikely that they will appear. The best course of action is to stick to age-old engineering principles. There simply are no silver bullets.
Cost estimates are projections of required effort, time, and staffing levels. Because all estimates, particularly those made at the beginning of a project, are based on assumptions, they should be considered probabilistic. Cost estimates in particular should provide a range with an indication of accuracy, i.e., least, probable, and most, with the least and most values representing the upper and lower bounds of the projected cost.
Project Estimation Process
Ideally an estimate should be produced using the ten-step process.
During October we will cover each step on this blog.
Figure 1 Ten-step project estimation process
- Establish estimate scope
- Establish technical baseline, ground rules & assumptions
- Collect data
- Size software
- Prepare baseline estimates
- Quantify risks & risk analysis
- Review, verify, validate estimate
- Generate a project plan
- Document estimate & lessons learned
- Track project throughout development
Barriors to Adopting Estimation Technology & Applications
A reader requested I chime in on The biggest barriers I see to adopting estimation technologies and tools. So here goes the first draft.
- Not Invented Here: Some people think that their environment is so unique that it cant be estimated… or that estimation applications like SEER can’t handle their unique scenarios. I have never seen a case where this was true once the organization tried. Or sometimes an expert has their own spreadsheet and they don’t want to let go of that control.
- Don’t Want To Know: Sometimes the answers from estimation technology are longer or more costly than stakeholders want to hear. Read more
How Hard Is A Hardware Model
August 21, 2008 · Filed Under Estimating, General, Hardware Electronics Systems Estimating · CommentEstimating the effort, schedule, labor & materials, operations & support for hardware type systems is fundamentally different than estimating software. Software, while difficult and a major risk item, is much more homogeneous than hardware, electronics, and systems.While there are some similarities in development, estimating production is an entirely different problem. Some of the most important drivers in hardware and electronics systems include certification, tolerances, technology, circuitry types, integration levels and a host of other specifics. Of course material costs, prototypes, operating issues, support costs, spares, etc. are all critical for inclusion as well.Galorath’s SEER for Hardware (SEER-H) has hundreds of person years invested in estimation of hardware, electronics and systems, including knowledge bases; everything from mechanical, structural, hydraulics, electronics to custom IC’s to EO Sensors.We caution organizations with trying to accomplish this challenging endeavor with spreadsheets or simple CER type models as those approaches can be wrought with risk. And a poor estimate is worse than none at all.
