Yesterday, I was talking to a colleague about a new job he's considering. It's in a regulated industry, and he had some assumptions: that regulated industry auditors assume a waterfall lifecycle and that organizations require process people to improve the process.
Regulated industries do not require a waterfall lifecycle. What they do require is that you show requirements traceability from the beginning of your work through the testing. They want to know you didn't add anything more than what you said would be in the product, and they want to know you tested what you said was going to be in the product. You can do that with any lifecycle. Some of us would say you can do this better with an agile lifecycle 🙂 (There's more that regulated industries want, but requirements traceability is huge piece of their process issues.)
But I found his other question more disconcerting. The more I work with people who try to change things, the more I'm certain that process people who are divorced from the everyday stresses of product development is wrong. The managers have to be responsible for process improvement, or it's just another management fad.
I've seen process people used effectively in organizations when they act as internal auditors, who can explain where the current process isn't working, and as experts who can explain how to make the process better. But the people who own the process are the people who live and work the process — not the process experts. Assigning some percentage of the product development team as full-time process improvement specialists cheats the team out of the domain expertise these people have — domain expertise that would be helpful in product development. And, if you have full-time process people who don't have domain expertise, why do you think they could help you in your product development?
I loaned out my copy, but Capers Jones in Software Assessments, Benchmarks, and Best Practices, (page 133), says that reuse, ability to manage, and ability understand the domain are the three most important factors in software product development. The factors are something like 300 for reuse, 85 for management and 75-80 for domain expertise. Process is down around 30-40 as a factor for successful product development.
If you want a process that will meet regulator's needs, understand how you obtain requirements and how you use them all the way through your projects. Use experts and internal auditors to help you assess how well you do what you say you're going to do. Measure what you do and see if that's where you want to be. Make sure each manager has process improvement goals that benefit the entire organization, not local benefits. That's the way to do real process improvement. Not with an army of process people.