Z 26 Project Management CMMI Project Planning Lecture

Z 26 Project Management CMMI Project Planning Lecture 5 b Graham Collins, UCL

Continuous and Staged The concept for continuous improvement, is that aspects of the organisation or projects are of different levels q 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 q 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). q

SG level 1 Establish estimates SP 1. 1 -1 Estimate the scope of the project SP 1. 2 -1 Establish estimates of work product and task attributes Define Project Life Cycle Determine estimates of effort and cost SP 1. 3 - 1 SP 1. 4 - 1 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

SG level 2 Develop a Project Plan SP 2. 1 -1 SP 2. 2 -1 SP 2. 3 - 1 SP 2. 4 - 1 SP 2. 5 - 1 SP 2. 6 -1 SP 2. 7 -1 Establish the Budget and Schedule Identify Project Risks Plan for Data Management Plan for Project Resources Plan for required (needed in CMMI documentation) Knowledge and Skills Plan Stakeholder Involvement 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.

SG level 3 Obtain Commitment to the Plan SP 3. 1 -1 Review Plans that Affect the Project SP 3. 2 -1 SP 3. 3 - 1 Reconcile Work and Resource Levels 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)

GG level 2 Institutionalize a Managed Process GP 2. 1 GP 2. 2 GP 2. 3 GP 2. 4 GP 2. 5 GP 2. 6 GP 2. 7 GP 2. 8 GP 2. 9 GP 2. 10 Establish an Organizational Policy Plan the Process Provide Resources Assign Responsibility Train People Manage Configurations Identify and Involve Relevant Stakeholders Monitor and Control the Process Objectively Evaluate Adherence 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.

GG level 3 Institutionalize a Defined Process GP 3. 1 Establish a Defined Process GP 3. 2 Collect Improvement Information

GG level 4 Institutionalize a Quantitatively Managed Process GP 4. 1 Establish a Defined Process GP 4. 2 Collect Improvement Information

GG level 5 Institutionalize an Optimizing Process GP 5. 1 Ensure Continuous Process Improvement GP 5. 2 Correct Root Causes of Problems

CMM (Capability Maturity Model) q q q 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.

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

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 -32115496 -7) q Ahern, D. M. et al, CMMI Distilled, Addison-Wesley, second edition 2004 q 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. q