Government IT Projects: Opportunity For More Success
I heard of a wonderful blog on Zdnet regarding additional oversight and transparency in Government IT projects costs, schedule: S.920 the Information Technology (IT) Investment Oversight Enhancement and Waste Prevention Act of 2009.
The bill is targeted to prevent issues:
1. cost overruns and schedule slippage from the estimates established at the time the program is initially approved
2. Number of requirements and business objectives at the time the program is approved that are not met by the delivered products
3. Number of critical defects and serious defects in delivered information technology.
The bill requires specific items be available on project performance including:
-
Cost, schedule, and performance using Earned value (ANSI-EIA-748-B)
-
Project Trends
-
commencement of the project;
-
Variance from cost, schedule or performance & rationale
-
Number of times projects are re-baselined
This can really help, if done correctly. ” When Performance Is Measured Performance Improves, When Performance Is Measured and Reported the Rate of Performance Increases”
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Final Version of the GAO Cost Guide
It appears that this is the final version of the GAO cost estimating guide which provides guidance on preparing viable cost estimates both early in the process and throughout the life cycle. Congratulations to the team. This is a great contribution to the industry and can, if used as intended create more successful projects. I especially appreciate the focus on preparing a viable estimate of cost, schedule, etc. then applying earned value management (EVM) to that. So often, in the past we have seen a chasm between those that generated estimates and the EVM people. These are two sides of the same coin. The introduction follows:
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
CMMI Challenges Being Addressed: Process Is As Process Does
SEI people are battling the “Process for process sake” syndrome. CMMI is really trying to invoke a set of best practices. The level is not the goal.
When CMM (CMMI’s predecessor) was first developed the Government promised that the CMM level would not be used to judge organization in contract award. This was forgotten almost immediately.
DCMA released a study in 2007 that found for ACAT-1 (Really big programs) CMMI level was:
- About 83% mostly adhere to CMMI processes
- About 44% somewhat adhere to processes
Another study found that the 6 major reasons for program failure were:
- Business practices
- Culture
- External influences: I what it now
- Enabling Infrastructure
- Joint Integrated Processes
- Acquisition Reform (loss of system engineering capability within government)
NOTE engineering processes were not a root cause of program failure
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Many Observed Incorrect Implementations of CMMI High Maturity
At the CMMI conference a number of difficulties with high maturity, CMMI levels 4 & 5 quantified management. Some included incorrect use of standard statistical techniques for example:
- Too few data points
- Updating control charts too infrequently
- Bad formulas in control level calculations
- Trying to statistically manage inappropriately
- Using aggregated data
- Presenting baselines as stable when they were not
- Lack of quantification of quality and process performance objectives
- Lack of management use of information
- Using trivial cases to show CMMI levels 4 & 5
They also discussed how many organizations just wanted a number.. that they didnt really have a commitment to process. And how that is (finally) changing.
I was thrilled to hear that practice is changing. Over the years we have been disturbed by the trend to get a small project or organization certified, then do business as usual throughout the company.. that is process not being used.
This is the reason SEER for Software provides approximate CMMI level as an output rather than an input. When CMM first came out people asked for knowledge bases or parameters the woudl change the estimate just based on the CMM level. We actually built some draft knowledge bases based on the characteristics of organizations with higher maturity but never released them because we realized that organization CMM or CMMI level does not generally impact the individual projects on a per sey basis. We realized that people, process and technology inputs to SEER actually predict the effort, schedule and effective CMMI level best.
SEER estimates any CMMI level well. It used the root causes of improvement (people, process, technology, reuse, etc.) to generate such estimates. The other reason this is so powerful is because management and other stakeholders can see and understand the specifics of why their estimates change.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Development Teams Using Note Cards: 20th Century Here Today
Lee Fischman, Galorath Guru attended the PMI conference last week. He sent an email during the conference concerned about note cards as a project management approach. Lee sent the following for publication:
“These Agile teams that use note cards claim all sorts of wonderful
benefits from them, like seeing the entire project’s status on a wall,
and solid ownership of tasks. In fact, case tracking systems like JIRA
and Fogbugz do all that too, plus lots more such as sorting, metrics,
etc. I guess one reason people like note cards is that they are so
tangible. But using them reminds me of people who print out their
emails – soooo 19th century. Note cards are even worse, because they
are hand-written. Agile proponent Alistair Cockburn called these
“Information Radiators” but there doesn’t seem to be strong theoretical
support for the idea of using note cards over online systems. It’s not
that the entire Agile community feels like they have to do these things
by hand, because Rally, VersionOne, XPlanner and other vendors do offer popular tools to automate project management. Apparently other people agree with the notion that note cards are, uh, not optimal”
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Improving Productivity By Reducing Rework
Bob Longhorn of CAI gave a masterful talk describing how the cost of rework can be killing software projects and how reducing rework could be the quickest way to improved productivity. Bob defined rework not as I normally do (redesign, reimplementation, retest of existing software to add functionality) but as the amount of churn, the rework of fixing things that were not done properly the first time in a development project. I believe Bob said many organizations have 30% of this rework and he saw at least 1 organization with 70% rework.
That says that improved processes and reviews could improve productivity by 30% just about all by themselves.
Even at Galorath I see rework at times that could have been avoided by reviews and verification that review changes were made. We all know it is many times less expensive to fix a problem up front than when the software is in test. Yes, we have processes, but sometimes that extra review just doesn’t happen due to perceived time constraints.
It is a shame so many organizations think they don’t have time for reviews. They don’t have time not to have them.
Bob says (correctly) that experimentation and prototyping are NOT rework. and that every deliverable should be inspected before declaring it complete. Quoting Bob “”Nothing Will Provide A More Significant Improvement in productivity Than Improved Quality”
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
SEER Estimate By Comparison Professional Released To All Users
The SEER Estimate By Comparison (formerly SEER-AccuScope) comes in two flavors, the core and the professional. The professional version allows estimation of anything, such as
- total system cost
- software size
- hardware weight
- system value
- server capacity
- best choice from a set of alternatives
This new feature incorporates sophisticated mathematics for uncertainty and estimation.
For the first year Galorath is providing the professional version to all SEER users. Beginning the second year the professional functionality will be available as an upgrade.
Galorath recommends using an industrial strength database for an enterprise but will allow Microsoft Access for simple desktop installations.
This feature began shipping with the release of SEER for Software 7.3, in October, 2008.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
7 Characteristics of Dysfunctional Software Projects
From Mike Evans, Coauthor of my book on Software Sizing, and Risk Management while studying over 350 projects:
- Failure to Apply Essential Project Management Practices
- Unwarranted Optimism and Unrealistic Management Expectations
- Failure to Implement Effective Software Processes
- Premature Victory Declarations
- Lack of Program Management Leadership
- Untimely Decision-Making
- Lack of Proactive Risk Management
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Development Intelligence
How I love that phrase “Development Intelligence”, patterned after business intelligence. Unfortunately it appears Borland has got a lock on that phrase.
But the concept of continuous measurement and the ability to use metrics to proactively manage and monitor a software development project is so valuable.
I was recently discussing an automated QA tool with someone who had looked at it. It had several hundred rules for quality software. It even used McCabe’s complexity metric. Those were good things. Only problem is they run it at the end of a project, not during, for example when a single programmer’s work is being checked in or even before when something can still be done be done about quality issues. Congratulations, the 4000 function point application you just took ownership of violates 117 quality rules. What do I do with that except negotiate in an outsource environment.
But continuous Development Intelligence. Imagine, a developer skips a standard, or whose code is on immediately understandable… And to getting flagged before check-in. The vast majority of developers want to do a good job and a tool that helps them find and catch quality errors sounds like a significant total ownership cost improvement.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Barriers 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
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Project Prediction Infographic
