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 management practices.

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?

Similarly, 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.

Watch Webinar

PDF [435 KB]

PRESENTATION