|
||||||||||||||||||||||||||||||
Article 1
Article 2
Article 3
Article 4
Article 5
Article 6
Article 7
Article 8
Article 9
Article 10
Do’s and Don’ts of Process Improvement
Pat O'Toole
#7: DO Establish Organizational Policies, Not CMMI Policies
The VP of Engineering is trying to establish a process-disciplined culture in her software development organization. As a consultant, you have encouraged her to think about employing policies as a means to demonstrate her commitment to establishing, following, and improving the project management process.
You look across all of the projects and see a bit of consistency in that each project has:
- An appointed project manager;
- A schedule based on four major project phases (Requirements, Design, Code, and Test); and
- A weekly project team meeting.
As a consultant to the VP, what 3 points would you recommend be documented in her organization’s initial Project Management policy?
“But wait,” you hear the EPG protest, “this would not be CMMI-compliant!” However, unless it’s trying to fool itself, or an appraisal team, why would this maturity level 1 organization have maturity level 2-compliant policies? Remind the EPG that the CMMI does not say that the organization merely has policies, but that the projects actually follow them. As a consultant, you stand your ground by recommending that your client write policies that reflect current organizational commitments rather than “CMMI-compliance.”
You might also point out that, just like other process assets, policies should evolve with increasing process maturity. Policy updates can serve as the final act of institutionalizing a major process improvement – declaring that the modified behavior is now required and is therefore expected to endure. The projects should feel empowered and protected, not constrained or demeaned, by such changes in policy.
Undoubtedly the EPG’s CMMI bible-thumpers also caught the blasphemous phrase “Project Management policy” – a clear deviation from the passage that proclaims, “Thou shalt have a policy for Project Planning, a policy for Project Monitoring and Control, and a policy for Integrated Project Management.” But why is it necessary to split project management responsibilities across three policies, yet it was OK – whoops, I mean required to lump requirements engineering, design engineering, development engineering and test engineering into a single unified “CMM Software Product Engineering” policy – at least until you migrated to the CMMI and then you had to tease them apart.)
Models and consultants are just like any other tools – use them when they provide value and use something else when they don’t. You have provided the VP of Engineering with your best advice regarding her organization’s software policies; the authors of the CMMI have also provided their advice about what policies should be in place (25 policies – good grief!). Now it’s time for the VP to take ownership of the situation and craft policies that reflect her organization’s commitment to process. After all, models and consultants can provide guidance, but only people can provide leadership! The next article is entitled "Separate Process and Training." The next article is "Separate Process Documentation from Training Material."