COMPGZ07 Project Management

CMMI

Project Planning

Lecture 5b

Graham Collins, UCL

Continuous and StagedContinuous 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).

SG level 1 Establish estimatesSG 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

SG level 2 Develop a Project PlanSG level 2 Develop a Project Plan

SP 2.1-1 Establish the Budget and ScheduleSP 2.2-1 Identify Project RisksSP 2.3- 1 Plan for Data ManagementSP 2.4- 1 Plan for Project ResourcesSP 2.5- 1 Plan for required (needed in CMMI

documentation) Knowledge and SkillsSP 2.6-1 Plan Stakeholder InvolvementSP 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.

SG level 3 Obtain Commitment to the PlanSG 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)

GG level 2 Institutionalize a Managed ProcessGG level 2 Institutionalize a Managed Process

GP 2.1 Establish an Organizational PolicyGP 2.2 Plan the ProcessGP 2.3 Provide ResourcesGP 2.4 Assign ResponsibilityGP 2.5 Train PeopleGP 2.6 Manage ConfigurationsGP 2.7 Identify and Involve Relevant StakeholdersGP 2.8 Monitor and Control the ProcessGP 2.9 Objectively Evaluate AdherenceGP 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.

GG level 3 Institutionalize a Defined ProcessGG 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 ProcessGG 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 ProcessGG 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)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.

Maturity Levels in the CMMMaturity Levels in the CMM

Requirements Management

Software Configuration Management

Software Project Planning

Integrated Software Management

Peer Reviews

Software Quality Management

Quantitative Process Management

Level 2: Repeatable

Level 3: Defined

Level 4: Managed

Process Change Management Technology Change ManagementDefect prevention Level 5:

Optimizing

Further readingFurther 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.