CMM and Software Project Planning

CMM and Software Project Planning
By Dave Nielsen

Software project planning is a Key Process Area (KPA) that spans many of the knowledge areas from the PMBOK as it describes activities performed during the planning phase of a software project. The knowledge involved include: Integration Management, Scope Management, Time Management, Cost Management, Human Resource Management, Procurement Management, Risk Management, and Communications Management. The only area not touched is Quality Management. Many project managers also define a change management process that covers each area of the project and describe that process in a Change Management plan. This plan also supports the Software Project Planning KPA.

CMM divides this KPA into goals, commitments, abilities, activities, measurements, and verifications. This article will attempt to relate each of these to its PMBOK component.

Goals

CMM defines 3 goals for this KPA: software estimates are documented and used to plan and track the project, activities are documented and planned, and affected groups agree to their commitments. These goals are supported by the Time Management knowledge area with the exception of the agreement of “affected groups” to their commitments. Agreement of senior management and other stakeholders to the plan is accomplished by Gate Review meetings described in the Communications Management plan and agreement of other team members is described in the Human Resources Management plan.

Commitment to Perform

The first commitment is that a project software manager is designated for managing the work. This would be you. The Project Charter is the document that speaks to this. The next commitment is that the project follows a written organizational policy for planning a software project. Unless your organization includes a PMO, or PMC, you won’t be able to meet this commitment to perform; your plans apply only to the current project and aren’t part of a standard applicable to all projects. Some of the specifics of this commitment can be supported by your plan, however. Some will be supported by your Project Management plan. This could be one document or a compilation of plans for each of the knowledge areas. The second commitment requires negotiation of the requirements with the project manager, software project manager, and other software managers. This process is described in your Scope Management area in the Requirements Gathering process. The process of negotiating the participation of the various software development groups on the project should be described in your Human Resources Management plan. This is described for you in the Acquire Project Team process. Keep in mind that while the PMBOK is referring to the entire team, CMM refers to only those groups engaged in software development.

The second commitment also specifies that senior management reviews all software related commitments made to external stakeholders. This review should take place at a Gate, Phase Exit, or Business Decision Point review meeting which will be described in your Communications Management plan. Keep in mind that this meeting will review all project commitments, not just software related ones. These reviews are described in more detail for you in the Context and Integration Management areas of the PMBOK.

Ability to Perform

CMM requires the work of the project to be described in a Statement of Work (SOW). Again, CMM only refers to that portion of the work related to software development. The PMBOK describes the SOW and its use in the Integration Management and Procurement Management knowledge areas. The description in the PMBOK will deliver an SOW that satisfies CMM criteria. Although the PMBOK specifies this artifact for work that is procured externally, an SOW must be produced for each project to satisfy the CMM criterion.

The second ability requires responsibility for developing the project plan to be assigned. This is your work and responsibility should be defined in your Project Charter. The third ability speaks to the provision of adequate resources and funding. The Estimate Activity Resources and Activity Duration Estimating processes in Time Management describe how resource requirements are derived. Human resources are assigned to your project by the Acquire the Project Team process in the Human Resources Management area and any other resources, such as software testing tools, are acquired by the Procurement Management plan. Funding is addressed in the Cost Management area, but CMM refers specifically to the provision of the funding. This provision should be negotiated and committed to at the Gate Review meeting that happens between planning and implementation. Funding for planning activities will only be negotiated and committed to when your organization is performing the project for an external customer under contract.

The fourth ability refers to your training in the area of software project planning. This criterion can easily be satisfied by a project manager who has been certified by the PMI as a Project Management Professional (PMP). PMI is the most recognized certification body in the area of project management and certification is relatively straightforward for those who meet PMI’s criteria. Certification requires eligible candidates to pass an exam testing their project management knowledge, including planning knowledge. There are numerous PMP courses or PMP exam preparation training products available to prepare you to pass the exam.

The ability also calls for any other person involved in planning to be trained in software estimation and planning. This is a somewhat more difficult criterion to meet. Since you will rely on Subject Matter Experts on your team to provide accurate effort estimations for the various tasks in the WBS, you will need to identify the process you will use to do the estimating and provide any tools and training required to use the chosen process. The process of training those individuals will be described in your Human Resources Management plan (Develop the Project Team).

Activities Performed

Activities called for by CMM include:

  1. The software engineering group participates on the project proposal team. The software engineering group will be engaged in the project as team members and SMEs as described in the Project Charter (critical or key resources) and the Project Staff Assignments produced by the Acquire the Team process. If your project entails drafting a proposal in response to an RFP (Request for Proposal), then these documents should assign key engineering group resources to this work. The documents should also assign responsibility for review of the work commitments to the engineering group.

  2. The software engineering group participates with other affected groups in the overall project planning throughout the project’s life. This participation will be defined by the Project Staff Assignments document, and other project plans which define roles and responsibilities. These SMEs should also be assigned responsibility for providing analysis and estimation for change requests in the Change Management plan.

  3. Commitments made to external groups are reviewed with senior management according to a documented procedure. This procedure will be your Gate Review meetings as described previously.

  4. A software life cycle with predefined stages of manageable size is identified or defined. The Software Development Lifecycle Method (SDLC) should be specified in your project charter as part of your approach to the project. Stages or iterations will be further defined in the WBS and schedule.

  5. The project’s software development plan is developed according to a documented procedure. This documented procedure is called the Project Management Plan. This can be one document or many. This activity also specifies that the plan is negotiated with the software engineering group doing project work and other groups that are stakeholders, and that the plan is managed and controlled. Management and control activities are specified in the Project Management plan and Change Management plan.

  6. The plan for the software project is documented. Documentation will be the Project Management plan, including the project schedule. This activity specifies software configuration management and this process should survive the project. If there is no software configuration management plan in place for your project to use because you are creating a new system, your project management plans should include creation of a configuration management plan.

  7. Software work products that are needed to establish and maintain control of the software project are identified. This refers to the files that will be checked into the source library and managed by the configuration management plan. These files will be specified in Detail Design Documents (DDDs), the WBS, and the project schedule.

  8. Estimation is done according to a documented procedure. This activity specifies that organizational experience in estimation be used to guide the current estimation and that historical information be consulted when available. This refers to the “Enterprise Environmental Factors” and “Organizational Process Assets” which are inputs to many PMBOK processes including the Activity Duration Estimation process. The activity further specifies that the estimates should be agreed to by the folks performing the work. Although this is not spelled out in the PMBOK it is always a good idea to have the resource agree to the work and deadline they are asked to commit to. This agreement and commitment needs to be documented somewhere in the Project Plans.

  9. A documented procedure is used to estimate project effort and cost.These procedures should be documented in the Time Management plan and Cost Management plan. Agreement to effort estimations is described above and agreement to cost is achieved during Gate Review meetings described in the Communications Management plan

  10. A documented procedure is used to estimate critical computer resources. This is a specific instance of the resource estimation produced by the Estimate Activity Resource and the Activity Duration Estimation processes and captured in the Time Management plan.

  11. The project’s software schedule is derived according to a documented procedure. This is accomplished by the procedures described in the Time Management area, up to and including the Schedule Development procedure.

  12. The risks are identified, assessed and documented. This is part of your Risk Management plan.

  13. Plans for the project’s software engineering facilities and support tools are prepared. This is part of the Estimate Activity Resource procedure. Acquisition of non-human resources is managed by the WBS, or the Procurement Management plan where resources must be procured externally.

  14. Software planning data are recorded. The estimates will be recorded in the schedule and estimation information, including assumptions, will be recorded in the WBS. In most cases the schedule and WBS will be one and the same document, your MS Project file.

Measurement and Analysis

CMM requires you to track the progress of your planning activities. The Time Management processes culminate in the project schedule so we can’t say that this measurement is supported by Time Management. The initiation of the project will usually result in a preliminary schedule of planning events, milestones, and deliverables in your MS Project file. The planned and actual dates in this file are what you will use to track progress.

Verifying Implementation

CMM calls for project planning activities to be reviewed with senior management periodically. These reviews will be described in your Communications Management plan. The senior management referred to may be the project business sponsor, the project IT sponsor, or a Steering Committee, or a combination of these. Your Gate Review meeting to move the project forward from the initiation phase to the planning phase is also verification. CMM also calls for a summary report from each of these meetings to be prepared and distributed. Status review meetings are also called for and a summary report is to be issued for these meetings.

CMM requires a software quality assurance group to review/audit the project plans. This audit or review may be a service that your PMO or PMC provide, if your organization has one. This software quality assurance group could be an existing group in your organization or that role could be assumed by your PMO or PMC. If your organization has neither of these groups, it will have to create one in order to satisfy this point.

Dave Nielsen is a principal with three O Project Solutions, the vendors of AceIt©. Dave was also the key architect responsible for the creation of the product. AceIt© has prepared Project Managers from around the world to pass their PMP® exams. You can find endorsements from some of his customers on three O’s web site (http://www.threeo.ca/).

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

3 Responses

  1. Dave,

    When was this article written?

    We’re on CMMI-DEV V1.2 with V1.3 coming this year. The term Key Process Area does not appear in CMMI, nor are the detailed activities you describe.

    Is this a retreaded piece from a decade ago?

    Neither CMMI nor PMBOK calls out “how” to do things in the detail you describe. The term Gate Review does not appear in PMBOK 4th Edition. Nor does CMMI specific “how” to do things, just “what” is the evidence that the Process Area is being full filled.

    It seems a bit odd that such details are implied to be part of CMMI or PMBOK.

  2. Avatar Dave Nielsen says:

    Hi Glen,

    The article itself is fairly recent, but based on SEI’s original CMM methodology and the 4th Edition of the PMBOK. The key difference between CMM and CMMI Dev V1.2 is the inclusion of various “process areas”, including Project Management, in the methodology. I’m not sufficiently familiar with CMMI Dev V1.2 to offer any comment on its alignment with the PMBOK but would say that PMI/PMBOK are still the accepted SMEs on project management.

    Perhaps I should follow up this article with one relating the latest & greatest from SEI to the practice of project management according to the PMI/PMBOK. I think there would be value in this exercise for the project management community so, if you have the time & inclination you could benefit the community with an article on the subject.

    Regarding your comment about “how” vs. “what”, the article was written as a “how to” vs. a “what to do”. The PMBOK and CMM/CMMI are written as guides/methodologies governing what project managers and/or software development shops should do. The job of the project manager is to convert those practices into actions.

    Best Regards,
    Dave Nielsen PMP

  3. David,

    Here’s a quick history of CMM/CMMI
    http://www.sei.cmu.edu/library/assets/cmmihistory.pdf

    The process you speak about are no longer used in CMMI. CMM for SW was released in 1991. Much has happened in the Maturity Model world since then.

    As well CMM, CMMI and PMBOK are not methods. To suggest so creates confusion. There is no “how” in CMMI or PMBOK, just what.

    In CMMI the Technical Solution (TS) Process Area says NOTHING about how to development software.

    It may serve your purposes better for the next article if you downloaded CMMI-DEV V1.2 and looked at the TS Process Area.

    A map of CMMI-DEV V1.2 and PMBOK 4th edition to a specific software development method, or a project management method might be useful. The CMMI to SW Dev methods like RUP, Scrum, and XP are available on the web.

    Mapping to specific project management methods (process handbooks for example) is common in the defense and government industries where I work. For commercial IT, CMMI-DEV V1.2 is many times the basis of a companies project management guidebook. TenStep is a commercial example of such a mapping, but there are others.

    But it is critically important not to confuse Process Maturity Assessment framework (CMMI) and Project Management Bodies of Knowledge (Process Groups and Knowledge Areas) with a “methodology”.

    For a project, program, and portfolio management framework, look at the OGC P3M3 materials. This is closer to “how,” but still not a methodology. There are methodologies derived from P3M3 that connect to the process areas in the same way there are SW Dev and PM methods connecting to CMMI and PMBOK.

Leave a Reply