Friday, December 4, 2009

The CMMI IS Right for You; However . . .

As more organizations adopt the CMMI, the breadth of adopters is moving from large DoD/Aerospace companies to more midsize and smaller organizations in a much wider variety of market sectors. Additionally, these adopters from different market sectors don’t all have the same safety-of-life critical applications that the original DoD/Aerospace folks had.

This begs the question; if I’m not a large organization with safety-of-life critical applications, how can I best use the CMMI without overly burdening my organization with many potentially great but often unnecessarily cumbersome practices, or rearchitecting my entire process set?

Finally, some common sense solutions.

Follow the Intent of the Model.  You don’t have to re-architect your entire process set to comply with the CMMI, nor do you have to adopt CMMI specific language. In fact, you can be CMMI compliant without even knowing the CMMI exists (not likely, but possible). If you’re running your software business as a business, you’ve probably got most of the basics covered already. Your challenge is to: map your processes onto the CMMI to ensure you’ve addressed all the best practices, create or enhance processes where they are missing or weak, implement those new or newly enhanced processes, and follow them long enough to demonstrate that they are working better than the previous ones.

Go Slowly. We know you’ve got the task of achieving CMMI MLX by Tuesday, regardless of what all the industry data show. The SEI is beginning to take a very serious look at organizations that show Maturity Level Progress that is out of alignment with what the statistics show as a reasonable time to improve. Go Slowly. Conduct a baseline appraisal to show what your real starting point is. Plot a path from that point to your target. Defend the plan as reasonable, based on the available data.

Start Small. Don’t bite of more than you can chew. People, in general, fear the unknown, and are resistant to change. Carefully explain what your are attempting and why you are attempting it.  Don't overburden them with too many new ideas at once. We frequently find that the most successful strategy is to start off with only a couple of improvements. I like to tackle the most significant challenge, and an easy challenge. The most significant challenge must be addressed due to its potential for great positive impact. The easy challenge will demonstrate the validity of process improvement at making things better, and it will typically do so, quickly.

Run the Process Improvement Initiative as a Project. The Process Improvement Project needs Sponsorship, Support, a Plan, Resources, Schedules, Deliverables, Quality Checkpoints, Measures, etc. just like any other project. To not give it the benefit of all of these project characteristics, is to all but doom it to failure.

Availability is NOT a skill. If you are considering allocating 5% - 7% (typical) of your software development budget to achieving CMMI compliance to be both more successful, and to be able to bid on future work, don’t just take whoever is available on the bench to staff this activity. Software Process Engineering is a discipline with required skills and qualifications just like any other engineering discipline. The biggest challenge in software process improvement projects is that it is a people challenge in a technical environment. Make sure the resources assigned have both the technical and soft skills required to make the project a success.

No comments:

Post a Comment