Pat O'Toole's Dos and Don'ts of Process Improvement: DO Establish Organizational Policies, Not CMM Policies
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 SEPG protest, "this would not be CMM-compliant!" However, unless it's trying to fool itself, or an assessment team, why would this Level 1 organization have Level 2-compliant policies? Remind the SEPG that the CMM 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 "CMM-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 SEPG's CMM bible-thumpers also caught the blasphemous phrase "Project Management policy" – a clear deviation from the passage that proclaims, "Thou shalt have a policy for Software Project Planning, a policy for Software Project Tracking, and a policy for Integrated Software Management." But why is it necessary to split project management responsibilities across three policies, yet it is OK – whoops, I mean REQUIRED to lump requirements engineering, design engineering, development engineering and test engineering into a single unified "Software Product Engineering" policy? (At least until you migrate to CMMI and then you'll have 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 CMM have also provided their advice about what is "typically stated" in the 18 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!
Copyright © Process Assessment, Consulting & Training 2002