How should standards and process improvements be introduced to an organization without them?

Question

I've been tasked with improving the software development process through the implementation of process improvements, of which we will most likely be using CMMI for Development, Version 1.3 as a guideline and adopting the best practices in whole or in part. What is the best way to introduce standards and process improvements so that the degree of push back and resistance from developers is minimized?

Answer 1

1. Start software process improvement (SPI) project. Define its scope and goals. It will definitely help if standardization has its own goals and measure applicable to your organization.
2. Assign person responsible for adopting standards. It also might be several people or even department in the case of large organization. Important thing is that all those responsible for the standardization would be:
   • professional enough to see the whole picture
   • influential enough in order to deal with teams and help them to adopt/negotiate changes
3. Develop trainings covering both standard you want to adopt and its specifics applied to your organization. And its really important as long as all people who were not trained are potentially resistant to changes. For example, when I worked in a large company, I instructed all newcomer employees about QA processes, CMMI, ISO and Quality Management System. Such training was obligatory. It helped to improve knowledge about the quality management processes and raise employees awareness regarding the important issue of software quality.
4. Negotiate changes and tailor generally accepted practices for your specific needs. It will help to avoid bureaucracy and implementation of heavy-weight processes nobody really need.
5. Establish monitoring of how implemented process improvements are being supported and whether they are effective enough in your organization.

It will also help if you will find all the people within your organization who are truly concerned about the quality. Most probably, those would be the most important resource helping you to promote changes and establish mature practices.

Answer 2

A couple thoughts from the school of hard knocks:

1) Most process improvement initiatives spend 80% of their time on process design and 20% on education and socialization. Flip these percentages. A mediocre standard that's followed beats a perfect one that isn't.

2) Identify clear reasons why you're asking people to change how they work. What's the business case? Ideally it benefits every team individually. Sometimes it's just systemic improvement. Either way, make the case visible.

3) Simplify, then standardize, not the other way around.

4) You can't fully delegate this to a PMO. Direct managers need to be bought in, and the head of the business unit will need to break ties when complaints come in.

5) Find friendly early adopters. People will complain about how much time it all takes. You need someone you can point to and say, "it only took them 15 minutes"

6) For metrics, push hard for quantitative over qualitative. Otherwise you have projects that are Green until a day before Go Live, when everything slips by a month.

7) Emphasize techniques over tools. Good planning is more important than MS Project.

8) Put in a level of process relative to the needs. Every restaurant needs process, but Nobu and the French Laundry need a different kind than McDonalds. Same with software firms.

Good luck!

Answer 3

Basing your efforts on the CMMI is probably a good idea, even if you don't undergo the appraisals and get formally audited and rated. There's plenty of literature available about the CMMI, CMMI and other process improvement techniques such as Lean and Six Sigma, and CMMI and agile software development. The SEI has an entire collection of resources, some available for free, about different aspects of CMMI and guidance for different types of organizations.

I'd recommend looking in great depth at the continuous approach to implementing CMMI, rather than the staged approach. It strikes me as a much more efficient way to determine exactly where your organization stands now and improve in areas that add the most business value. This will allow you to not only align your improvement efforts with business objectives, but quickly achieve progress milestones and demonstrate the effects of improvement, increasing buy-in from all levels.

Something to keep in mind, though, is that process improvement is generally more successful when it's a grassroots effort. When process changes are dictated from above - by people the developers "in the trenches" might see as being out of touch with how things are done in the trenches - there is probably going to be pushback, even if the idea is a good one. Be prepared for this.

Some type of engineering process group might also be beneficial. Bring together representatives of the various organizational components and teams impacted by the improvement so that everyone's voice is heard. This would include not just representatives of each role, but perhaps various product development teams. Without knowing how your organization is structured, I can't say exactly who you might want to look at, but include people from every level of the organization in the group. Also, make the discussions and decisions made by this group available to the organization for comments and raising of any problems.

Answer 4

For each change:

• Call out the 1 change and how it will improve development.
• Implement the change.
• Demonstrate improvement
• Remove changes that did not demonstrate improvement

Obviously the analysis needs to happen over time, but no change should be accepted until it's demonstrated to be effective. That's also why I would implement no more than 2-3 changes per cycle otherwise you often can't measure if there has been improvement or not.

Nothing irritates me more than blindly following best practices without doing the analysis to show that is actually is a best practice for your environment. A best practice that doesn't demonstrate improvement is at best wasteful and at worst damaging.

All steps in your process and all practices in methodology should analyzed and proved to be of benefit. If it isn't it should be removed. This analysis should be done on an on-going basis regardless of adding or removing steps or practices.