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
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.
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 confernce 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”
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 say 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”
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.
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
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 ti 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.
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
Effectiveness Measurement for Project Managers
It is generally difficult to access project manager’s performance as discussed in a CIO magazine. THey discuss how project managers are sometimes evaluated on soft skills, how well they interact with people, passion for results, ethics, etc. They provide a potential solution…
Start each project manager with a perfect score, 100. for completing a project that meets business objectives.
Then deduct something (like 2 points) for each week a project is late.
Deduct another half point for each defect found in the first 60 days.
And deduct another for each feature originally promised that was not delivered.
I think this is an excellent example of applying effectiveness metrics, ones that measure what we are doing that we shouldn’t be doing and what we are not doing that we should be doing into a clear definition of performance.
Risk On IT Infrastructure Projects
Identifying the risk on IT infrastructure projects is a key to viable cost & schedule analysis. While working on risk identification I ran across this list which is a decent starting point for IT Infrastructure risks. I will post enhancements to this risk list as they are determined:
From http://www.projectmanagement.net.au/infrastructure_risks
Schedule
Unscheduled changes/delays
Personnel turning up without notification
Non-conformance - not starting/failures
Reliance on external sub-contractors/organisations
Technical
Unplanned/unapproved changes
Disasters
New design not working
Version control problems
Hardware failure
Software failure
Incorrect image/version loaded
Integration with existing systems
Personnel
Changes of personnel - CUSTOMER/Vendor
Lack of skills/knowledge
Not aware of policy/procedures
Logistical/Equipment
Supply availability
Physical storage of equipment on arrival - security
Contingency equipment availability
User
Not aware of Vendor schedule/activities
Inability to perform core business activities
Inability to perform non-core business activities
User expectations
Confusion about CUSTOMER/Vendor responsibilities
Loss of data
Data not moved to C:\userid
Project Management
Lack of detailed site information
Lack of reporting
Unaware of Customer site requirements
Absence of quality control/management process built into plan
Absence of issue log/change request log/configuration management log
Role confusion
Lack of issue identification - trends
Inconsistent project documentation
