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.
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 called for by CMM include:
- 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.
- Software planning is initiated in the early stages of, and in parallel with, the overall project planning. It is.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- The risks are identified, assessed and documented. This is part of your Risk Management plan.
- 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.
- 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.
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.