Recursion occurs when a process is applied to successive levels
within a structure. When we talk about engineering practices in CMMI,
we expect recursion (e.g., requirements must be managed for the
product, product component, subcomponents, etc). Although not directly
stated in the model, the same expectation should be made of project
In spite of the
reputation of CMMI-DEV as a product development model, there is a
distinct project focus to CMMI-DEV. There are process areas that use
the word “project” explicitly in their title (project planning, project
monitoring and control, integrated project management). So, would you
expect everyone’s definition of a project to be the same? Let’s say you
were a large defense contractor, building an integrated aircraft. How
would you define the scope of this project? In a project of this
magnitude, we find that there are actually a lot of smaller projects
being executed, with an integrating project at the highest level. So,
how do we define project management practice instantiations at the
highest level, and how do we apply it at lower levels? Should we expect
to find full instantiations of project planning, project monitoring and
control, integrated project management at an integrated project team
level or in a functional organization? When we appraise this
organization, should we expect to gain affirmations from integrated
project team leads or software leads regarding PM PAs?
project management practices are expected to be iterative. For example,
project planning is performed throughout the life of the project, not
just at the beginning.
This presentation will examine
the project management practices from the perspective of both recursion
and iteration. We will identify those practices where recursion and
iteration are expected, and discuss implementation tactics and options.
Finally, implications for appraising these practices and for preparing
appraisal evidence will be noted.