Integrated Project Management (IPM) - SP 2.2

Could you please provide some examples of evidence for IPM Specific Practice 2.2 and some examples of a critical dependency?

Integrated Project Management (IPM) Specific Practice 2.2 states “Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.” This practice is one of many compound practices in the CMMI. Therefore, to completely cover the practice, the organization would have to provide evidence that the project is participating with the relevant stakeholders. And that participation would be to identify critical dependencies, negotiate critical dependencies, and track critical dependencies. So the type of Direct Evidence that I would expect to see as a Lead Appraiser or Appraisal Team Member from the organization would be a list of critical dependencies, issues, and action items that were the result of the participation and for Indirect Evidence I would expect to see the meeting minutes or review/inspection reports that resulted in the list provided as Direct Evidence.

Now, if you read the Tips and Hints in the CMMI for IPM SP 2.2, these will provide insight into what a critical dependency is. Each project will have some constraints such as time, quality, budget, etc. that it must meet. By applying these constraints to the project schedule the Project Manager will be able to define the critical path through the project tasks and activities. The critical path contains all of the tasks and activities that have a direct impact on meeting the scheduled end date for the project. If a task on the critical path slips or runs over, then the end date of the project has a corresponding slip or overrun. Tasks that are not on the critical path can move about a bit before they impact the end date. The project tasks and activities on the critical path define the critical dependencies for the project. For example, if both Task A and Task B are on the critical path and Task B cannot begin before Task A completes, that is one critical dependency. Another example of a critical dependency is an external group is supplying a work product to the project and a Task cannot begin until the work product is received and accepted. This type of critical dependency may also be called a critical deliverable.

Hope this explanation helps.

Selection of Suitable Lifecycle Processes

Selection of a suitable lifecycle for the project/product is more of a technical issue. Then why is it covered in Integrated Project Management (IPM) rather than Technical Solution (TS)?

Selecting a suitable lifecycle is a function of the project requirements and the application domain. The selection is something that should be performed when planning the project activities, not while performing the actual software engineering activities. Selecting a lifecycle model and defining the project’s lifecycle phases are necessary for planning and estimating the project. That is why lifecycles appear in Project Planning (SP 1.3) and Integrated Project Management (sub-practice 1 of SP 1.1) . The selection of the lifecycle is a project management activity.

From another perspective, the purpose of Technical Solution is to design, develop, and implement solutions to requirements. And selecting an appropriate lifecycle model is an activity that needs to be done before you can design, develop, and implement a solution to the requirements.