Information Technology Reference
In-Depth Information
At GEAR, I learned that the MSG were supposed to be the final approval, but
not the subject matter experts on every process. The intent was for each
department to conduct its own process content review before submitting
processes to the MSG for final approval. I asked people in individual depart-
ments what they were looking for when they were asked to review process
assets. The responses I received were varied.
LESSON 2
Ensure the content requirements for process assets—specifically mini-
mums—are clear, and communicate those requirements to those assigned
to develop and review processes.
The CMMI doesn't dictate answers. It does give us good reminders of things to
consider through its practices. The reason I stress defining “minimums” is not
to drive organizations to only produce the minimum, but rather to know
where the boundaries are so we know when we are not ready to proceed. This
is particularly important for Agile-like organizations at times of project stress.
Lessons 1 and 2 are similar to those learned in the NANO case study. Recall
the common myth exposed at NANO with respect to the belief that it is easy
to write good processes. When I assessed the processes written at GEAR, I
found they were reasonably accurate to the level they were written. The
processes, however, lacked the needed depth to be effective. They were miss-
ing key ingredients, findings quite similar to those at NANO.
To e x p l a i n w h a t I m e a n b y “ l a c k e d t h e n e e d e d d e p t h t o b e e ff e c t i v e ” l e t u s
revisit my recommended process asset structure described in the case study
at BOND. I recommended in that case study that one always package the
“what you must do” separate from the “how you do it.” This simplifies the
“what you must do” process documentation, but does not imply you don't
need significant content in the “how you do it.”
The recommendation to package these separately is made for multiple rea-
sons. One is to clarify what needs to be done as part of your tailoring and
planning activities on each project and what should not be considered
because we have already agreed that everyone does it.
7.5 Criteria and Product Content Templates
An example of what GEAR was lacking was the “how you do it” guidance
for product content requirements. Their “must do” process documentation
Search WWH ::




Custom Search