Maturity level 2 in the CMMI is called "Managed," but even maturity level 1 organizations "manage" their projects. For instance, many maturity level 1 projects manage to target project completion on the earliest date with a nonzero probability of success. The thinking is that if everyone works 60+ hours per week, and nobody gets sick or takes weekends or holidays off, the project might just manage to finish on time.
And now your senior management has proclaimed that the overarching goal of the process improvement program is to reduce cycle time. They are not being unreasonable ”it's hard to deny that for many software- intensive products the primary competitive dimension is time to market. Customers, whether internal or external, are always clambering to get new products and features in an ever- decreasing time frame. But as a member of the SEPG you fear that this edict simply gives the project teams an excuse to circumvent existing processes and standards in order to get the job done any way they see fit.
Customers apply schedule pressure as part of a "ritualistic dance ." They get project managers to commit to delivering in twelve months in the desperate hope that they will receive the full product in fifteen months, or alternatively, that they will get 60% of the core functionality by the committed date. The project manager knows it, the customer knows it, and yet the charade plays out release after release. It's just like budgeting's ritualistic dance ”if you need $5M for your project you request $7.5M, knowing that one-third of the budget will be cut back during the approval cycle. We all know the tune and the dance continues!
So what do the customers really want? They want to believe! Customers want to know that when you commit to delivering a product on March 31 that it will be available for implementation on April 1 (an appropriate date?). Although they claim they want the software faster, they really want it more reliably.
As much as the customers want to believe, the software development staff wants to be believed. They would like their managers to leave their professional integrity intact by accepting and even defending their estimates. They would like senior management to understand and mitigate the devastating effects of golf course commitments and uncontrolled scope creep. They would like their customers to realize that it is in their mutual best interest to plan and execute projects in a disciplined manner. Finally, they would like to see their spouses and children more often than Sunday evenings!
Rather than establish a goal of finishing projects faster, the organization would be better served initially with the goal of estimating and executing projects more reliably. To achieve this goal, the organization must
Disciplined planning and execution significantly reduce the variability of project results. They also establish a solid foundation for getting projects done faster, the organization's ultimate goal. Since you are unlikely to achieve sustainable cycle time reductions without first achieving reasonably reliable results, follow Steven Covey's advice and "put first things first." The SEPG's challenge is to convince senior management that generating more reliable estimates is a necessary prerequisite to reducing cycle time ”and that once customers believe and estimation credibility has been established, the tune of the ritualistic dance will be altered forever.
What Is Software Quality?
Software Development Process Models
Fundamentals of Measurement Theory
Software Quality Metrics Overview
Applying the Seven Basic Quality Tools in Software Development
Defect Removal Effectiveness
The Rayleigh Model
Exponential Distribution and Reliability Growth Models
Quality Management Models
In-Process Metrics for Software Testing
Complexity Metrics and Models
Metrics and Lessons Learned for Object-Oriented Projects
Availability Metrics
Measuring and Analyzing Customer Satisfaction
Conducting In-Process Quality Assessments
Conducting Software Project Assessments
Dos and Donts of Software Process Improvement
Using Function Point Metrics to Measure Software Process Improvements
Concluding Remarks
A Project Assessment Questionnaire