COMPGZ07 Project Management CMMI Project Planning Lecture 5b Graham Collins, UCL

1. COMPGZ07 Project Management CMMIProject PlanningLecture 5bGraham Collins, UCL

2. Continuous and Staged • The concept for continuous improvement, is that aspects of the organisation or projects are of different levels • For the purposes of small computing/research projects the staged model is appropriate, as it can be clearly seen which practices would be most beneficial to incorporate next. Only apply the most appropriate areas, otherwise an imbalance of work is spent on planning, rather than research or project development • The following slides are the Practice-to-Goal Relationship tables, with associated SG (Specific Goals), SP (Specific Practices), GG (Generic Goals) and GP (Generic Practices).

3. SG level 1 Establish estimates SP1.1-1 Estimate the scope of the project SP 1.2-1 Establish estimates of work product and task attributes SP 1.3- 1 Define Project Life Cycle SP 1.4- 1 Determine estimates of effort and cost The technical approach needs to be considered, as well as the appropriate project life-cycle, (e.g., iterative and incremental approach). Attributes of the work products and task (e.g., size and complexity) Schedule Models or historical data for converting the attributes of the work products and tasks into labour hours (and cost where applicable) Methodology (e.g., models, data, algorithms) used to determine required resources of materials, skills and labour hours

4. SG level 2 Develop a Project Plan SP 2.1-1 Establish the Budget and Schedule SP 2.2-1 Identify Project Risks SP 2.3- 1 Plan for Data Management SP 2.4- 1 Plan for Project Resources SP 2.5- 1 Plan for required (needed in CMMI documentation) Knowledge and Skills SP 2.6-1 Plan Stakeholder Involvement SP 2.7-1 Establish the Project Plan For your projects the significance of budget is limited typically to development hours. The emphasis on risk management is not just identifying risks but involving others and updating this regularly. Apart from identification of risks, they should be analysed to determine impact, probability of occurrence and the time frame (or proximity) in which the problems are likely to occur.

5. SG level 3 Obtain Commitment to the Plan SP 3.1-1 Review Plans that Affect the Project SP 3.2-1 Reconcile Work and Resource Levels SP 3.3- 1 Obtain Plan Commitment ‘For software engineering the determination of project phases for software typically includes selection and refinement of a software development model to address interdependencies and appropriate sequencing of software project activities’ Chrissis, CMMI Guidelines (see references)

6. GG level 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Manage Configurations GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management Of particular significance here is planning and having both responsibility charts and communication plans, so that it is clear who is in charge of tasks and communicating with other stakeholders. For software engineering both a software development plan and a software project plan are appropriate on larger projects. The idea of the planning is to gain a mutual understanding of what each person or group is required to achieve. The plan must bring together in ‘ a logical manner: project life-cycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction’ ibid.

7. GG level 3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Improvement Information

8. GG level 4 Institutionalize a Quantitatively Managed Process GP 4.1 Establish a Defined Process GP 4.2 Collect Improvement Information

9. GG level 5 Institutionalize an Optimizing Process GP 5.1 Ensure Continuous Process Improvement GP 5.2 Correct Root Causes of Problems

10. CMM (Capability Maturity Model) • Level 1: Initial, ad hoc development, organized practices for project management absent. • Level 2: Repeatable, development process is intuitive, rather that codified, procedures for project management SCM (software configuration management) • Level 3: Learning and leverage of experience is an important aspect of this level. • Level 4: The organisation’s ability to monitor the success of the project is greatly enhanced if the project goals are set in quantitative terms, and quantitative data is available about the progress of the project. Quantitatively managing the process is the focus of level 4. • Level 5: Process Change Management and Technology Change Management. Defect prevention.

11. Maturity Levels in the CMM Process Change Management Technology Change Management Defect prevention Level 5: Optimizing Software Quality Management Quantitative Process Management Level 4: Managed Integrated Software Management Peer Reviews Level 3: Defined Requirements Management Software Configuration Management Software Project Planning Level 2: Repeatable

12. Further reading • Chrissis, M.B., et al, CMMI Guidelines for Process Integration and Product Improvement, Addison-Wesley (SEI series in software engineering) 2003 (ISBN 0-321-15496-7) • Ahern, D.M. et al, CMMI Distilled, Addison-Wesley, second edition 2004 • Jalote, P., CMM in Practice, Addison-Wesley (SEI series in software engineering) 2000. Pankaj carefully distinguishes between the project management and engineering aspects of projects at Infosys.