Thursday, January 29, 2009
Wednesday, January 28, 2009
Tuesday, January 27, 2009
The CMMI is an integrated process model with +-350 distinct practices that define what a “great company” does, at least within it's engineering, product, software, or services organization. Consider them a list of requirements for your process. So, your first step is to become smart about the model.
Thursday, January 22, 2009
Wednesday, January 21, 2009
Monday, January 19, 2009
- What is the latest time to conduct a SCAMPI ?
- What is the minimum number of projects to present in the appraisals?
- Is there any significant change brought by the release of CMMI version 1.2?
The Generic Practices are foundational to the success of any or all of the process you deploy, and GP 2.1, "Establish and Maintain an Organizational Policy for planning and performing the
GP2.1 is intended to set the expectation, for all practitioners, that they are to plan for AND perform the process that has been established, and that management wants them to do just that. It is an unambiguous request to plan and perform the process as intended.
Now, this set of policies should mirror your process, not the CMMI, and should clearly let everyone know what management's expectations related to performing the process are.
Not every policy is called "a policy" and some may not even exist in a "policy manual."
I have one client that created such a manual, a 100 page document with a detailed policy (bordering on process) and signatures for all the relevant stakeholders contained within its pages. Did this meet the CMMI requirements? Sure, and then some. The problem with this approach is that a) it's too much work to establish and maintain; b) it's not that valuable and c) no one will read it.
Policies can often be effectively communicated in training materials, on posters, in emails, and via word of mouth. In fact, a combination of all of these is often required to get everyone on the same page!