CMMIsm Project Planning
The CMMIsm Project Planning process is part of the Capability Maturity Model Integrationsm. The Project Planning process Meta-models are based on the Staged representation of CMMIsm (see #References).
About the meta-models
CMMI consists of 25 key process areas which are present in both the staged and continuous representation. Of these key process areas and the overall structure (see Capability Maturity Model Integration) of CMMI meta-models have been created. The staged representation of CMMI has been used. The more specific name of the model is CMMI-SE/SW/IPPD/SS (Version 1.1, March 1, 2002), it contains systems engineering, software engineering, Integrated Product and Process Development, and supplier sourcing (Staged Representation, SEI CMMI Product Team, 2002). Since only one source is used for the meta-models, all references are referring to a page number in the previously mentioned document describing the staged version. The meta models are created using the Meta-modeling technique (also see Meta-Process Modeling). Furthermore, the models are part of the Wikipedia:WikiProject_Method_engineering.
Project Planning – Meta-process model
In Figure 3 the meta-process for the Project Planning process is displayed. The first three processes are derived from specific goals whereas the last two are derived from generic goals. Generic goals are: “generic because the same goal statement appears in multiple process areas.” (page 32), therefore they are not modeled in detail here.
The first four activities are required for maturity level two, the last one is required for maturity level three and above. The CMMI model does not provide a lot of guidance on the order of execution of the sub-activities, the main concern is whether or not the activities are present in an organization. To assess the maturity of the Project Planning process, the following statements are evaluated for the five activities:
- 1. Estimates of project planning parameters are established and maintained.
- 2. A project plan is established and maintained as the basis for managing the project.
- 3. Commitments to the project plan are established and maintained.
- 4. The process is institutionalized as a managed process.
- 5. The process is institutionalized as a defined process.
“Plan for project resources” is an interesting sub-activity, the top-level Work breakdown structure developed earlier in “Estimate the scope of the project” is expanded with work packages and task descriptions (also see Figure 4). In Table 1 the activities and sub-activities and relations to the concepts are described in more detail (derived from the Project Planning process description, page 96-123).
Project Planning – Meta-data model
In Figure 3 the Meta-data model for the Project Planning process is displayed. This model gives an impression of how many documents one process (of the in total 25 key processes areas of CMMI) can generate. In Table 2 the concepts are described in more detail.
Project Planning – Process-data diagram
In Figure 4 the meta-data model and the meta-process model are combined into one model, the process-data diagram.
See also
- Capability Maturity Model Integrationsm
- Meta-modeling
- Meta-Process Modeling
- WikiProject Method engineering
References
- SEI CMMI Product Team. (2002). "CMMI Staged Representation" (DOC). CMMI-SE/SW/IPPD/SS (Version 1.1, March 1, 2002). Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-10.
{{cite web}}: Cite has empty unknown parameters:|accessyear=and|coauthors=(help)
| Establish Estimates | Estimate the Scope of the Project | Establish a top-level WORK BREAKDOWN STRUCTURE (WBS) to estimate the scope of the project. |
| Establish Estimates of Work Product and Task Attributes | The estimates should be consistent with project requirements to determine the project’s effort, cost, and schedule. A relative level of difficulty or complexity should be assigned for each size attribute. | |
| Define Project Life Cycle | The PROJECT LIFE CYCLE consists of phases that need to be defined depending on the scope of requirements, the estimates for project resources, and the nature of the project. | |
| Determine Estimates of Effort and Cost | Estimates of effort and cost are generally based on the results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on the rationale for the selected model and the nature of the data. | |
| Develop a Project Plan | Establish the Budget and Schedule | The PROJECt’s budget and SCHEDULE are based on the developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed. |
| Identify Project Risks | Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all the plans that affect the project to ensure that the appropriate interfacing is taking place between all relevant stakeholders on IDENTIFIED RISKS. | |
| Plan for Data Management | The DATA REQUIREMENTS for the project should be established for both the data items to be created and their content and form, based on a common or standard set of data requirements. Uniform content and format requirements for data items facilitate understanding of data content and help with consistent management of the data resources. | |
| Plan for Project Resources | Defining project resources (labor, machinery/equipment, materials, and methods) and quantities needed to perform project activities builds on the initial estimates and provides additional information that can be applied to expand the WBS used to manage the project. | |
| Plan for Needed Knowledge and Skills | Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources. STAFFING REQUIREMENTS are dependent on the knowledge and skills available to support the execution of the project. | |
| Plan Stakeholder Involvement | Stakeholders are identified from all phases of the project life cycle by identifying the type of people and functions needing representation in the project and describing their relevance and the degree of interaction for specific project activities. A two-dimensional matrix with stakeholders along one axis and project activities along the other axis is a convenient format for accomplishing this identification. Relevance of the stakeholder to the activity in a particular project phase and the amount of interaction expected would be shown at the intersection of the project phase activity axis and the stakeholder axis. | |
| Establish the Project Plan | A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project defines all aspects of the effort, tying 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. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations. | |
| Obtain Commitment to the Plan | Review Plans that Affect the Project | Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control. All plans that affect the project should be reviewed to ensure a common understanding of the scope, objectives, roles, and relationships that are required for the project to be successful. Many of these plans are described by the Plan the Process generic practice in each of the process areas. |
| Reconcile Work and Resource Levels | To obtain commitment from relevant stakeholders, it is important to reconcile any differences between the estimates and the available resources. Reconciliation is typically accomplished by lowering or deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or schedules. | |
| Obtain Plan Commitment | Obtaining COMMITMENT involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints. | |
| Institutionalize a Managed Process | A “MANAGED PROCESS” is a performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. This is a generic process. | |
| Institutionalize a Defined Process | A “DEFINED PROCESS” is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process-improvement information to the organizational process assets. (In Chapters 2 and 4, see the descriptions of how “defined process” is used in the CMMI Product Suite.) A project’s defined process provides a basis for planning, performing, and improving the project’s tasks and activities. A project may have more than one defined process (for example, one for developing the product and another for testing the product). This is a generic goal required for maturity level three. |
| COMMITMENT DATA | To obtain commitment from relevant stakeholders, it is important to reconcile any differences between the estimates and the available resources. Reconciliation is typically accomplished by lowering or deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or schedules. The result of the previously described process is COMMITMENT DATA. (page 117) |
| DATA MANAGEMENT PLAN | The DATA MANAGEMENT PLAN enables uniform content and format requirements for data items, to facilitate understanding of data content and help with consistent management of the data resources. (page 110) |
| DATA RETRIEVAL, REPRODUCTION AND DISTRIBUTION MECHANISM | Accessed information should be in an understandable form (e.g., electronic or computer output from a database) or represented as originally generated. A DATA RETRIEVAL, REPRODUCTION AND DISTRIBUTION MECHANISM enables the previously described requirement. (page 111) |
| DOCUMENTED COMMITMENT | Well-defined interface specifications form the basis for COMMITMENTS. Commitments must be documented to ensure a consistent mutual understanding as well as for tracking and maintenance. Provisional commitments should be accompanied by a description of the risks associated with the relationship. Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories. Identify commitments on interfaces between elements in the project, and with other projects and organizational units, so they can be monitored. (page 118) |
| DOCUMENTED REQUESTS FOR COMMITMENT | The plan for stakeholder interaction should identify all parties from whom commitment should be obtained. Part of the plan are the DOCUMENTED REQUESTS FOR COMMITMENT. The WORK BREAKDOWN STRUCTURE can be used as a checklist for ensuring that commitments are obtained for all tasks. (page 118) |
| EFFORT ESTIMATE | ESTIMATES OF THE EFFORT include a rationale (and resulting costs) and are created by using models and/or historical data. (page 105) |
| ESTIMATING METHOD | An ESTIMATING METHOD is a method for determining attributes. Methods for determining size and complexity should be based on validated models or historical data. The methods for determining attributes evolve as our understanding of the relationship of product characteristics to attributes increases. (page 102) |
| IDENTIFIED RISK | The identification of RISKS involves the identification of potential issues, hazards, threats, vulnerabilities, etc. that could negatively affect work efforts and plans. Risks must be identified and described in an understandable way before they can be analyzed. When identifying risks, it is good to use a standard method for defining risks. Risk identification and analysis tools may be used to help identify possible problems. (page 109) |
| MANAGED DATA | DATA are the various forms of documentation required to support a program in all of its areas (e.g., administration, engineering, configuration management, financial, logistics, quality, safety, manufacturing, and procurement). The data may take any form (e.g., reports, manuals, notebooks, charts, drawings, specifications, files, or correspondence). The data may exist in any medium (e.g., printed or drawn on various materials, photographs, electronic, or multimedia). Data may be deliverable (e.g., items identified by a program’s contract data requirements) or data may be nondeliverable (e.g., informal data, trade studies and analyses, internal meeting minutes, internal design review documentation, lessons learned, and action items). Distribution may take many forms, including electronic transmission. (page 110) |
| PLANNING DATA | Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting. PLANNING DATA are estimates of planning parameters. Estimates of planning parameters should have a sound basis to provide confidence that any plans based on these estimates are capable of supporting project objectives. (page 99) |
| PROCESS/WORKFLOW DEFINITION | The PROCESS/WORKFLOW DEFINITION WORKFLOW and matching DIAGRAM can be used to assess the SKILL NEED. (page 112) |
| PROJECT BUDGET AND SCHEDULE | The PROJECT’S BUDGET AND SCHEDULE are based on the developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed. (page 106) |
| PROJECT DATA | The reason for collecting each document should be clear. This task includes the analysis and verification of project deliverables and nondeliverables, contract and noncontract data requirements, and customer-supplied data. Often, data is collected with no clear understanding of how it will be used. PROJECT DATA is costly and should be collected only when needed. This is part of the SCHEDULE FOR COLLECTION OF PROJECT DATA. (page 110) |
| PROJECT LIFE-CYCLE PHASE | The PROJECT LIFE CYCLE consists of phases that need to be defined depending on the scope of requirements, the estimates for project resources, and the nature of the project. Larger projects may contain multiple phases, such as concept exploration, development, production, operations, and disposal. Within these phases, sub phases may be needed. A development phase may include sub phases such as requirements analysis, design, fabrication, integration, and verification. Depending on the strategy for development, there may be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles. (page 103) |
| PROJECT PLAN | A documented PROJECT PLAN that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project defines all aspects of the effort, tying 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. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations. (page 115) |
| RECORD OF THE REVIEWS OF PLANS THAT AFFECT THE PROJECT | Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control. All plans that affect the project should be reviewed to ensure a common understanding of the scope, objectives, roles, and relationships that are required for the project to be successful. Many of these plans are described by the Plan the Process generic practice in each of the process areas. The result of this process is a RECORD OF THE REVIEWS OF PLANS THAT AFFECT THE PROJECT. (page 116) |
| RENEGOTIATED BUDGET | A BUDGET which is renegotiated to obtain commitment from relevant stakeholders, by reconciling differences between the estimates and the available resources. (page 117) |
| RENEGOTIATED STAKEHOLDER AGREEMENTS | A STAKEHOLDER AGREEMENT which is renegotiated to obtain commitment from relevant stakeholders, by reconciling differences between the estimates and the available resources. (page 117) |
| REQUIREMENT | A demand or need; a requirement is listed on the commitment and must be satisfied before closing. Multiple REQUIREMENTS exist: -STAFFING requirements must consider the knowledge and skills required for each of the identified positions, as defined in the Plan for Needed Knowledge and Skills specific practice. -Even when the required ASSETS are not unique, compiling a list of all of the FACILITIES, EQUIPMENT, and PARTS (e.g., number of computers for the personnel working on the project, software applications, office space, etc.) provides insight into aspects of the scope of an effort that are often overlooked. -The processes used to manage a project must be identified, defined, and coordinated with all the relevant stakeholders to ensure efficient operations during project execution (a PROCESS requirement. (page 111) |
| REVISED METHOD | A METHOD which is revised to obtain commitment from relevant stakeholders, by reconciling differences between the estimates and the available resources, it also contains a corresponding estimating parameter. (page 117) |
| REVISED REQUIREMENT | A REQUIREMENT which is revised to obtain commitment from relevant stakeholders, by reconciling differences between the estimates and the available resources. (page 117) |
| REVISED SCHEDULES | A SCHEDULE which is revised to obtain commitment from relevant stakeholders, by reconciling differences between the estimates and the available resources. (page 117) |
| SCHEDULE FOR COLLECTION OF PROJECT DATA | A SCHEDULE FOR THE COLLECTION OF PROJECT DATA, contains PROJECT DATA to be collected. (page 110) |
| SECURITY PROCEDURE | Not everyone will have the need or clearance necessary to access the project data. Procedures must be established to identify who has access to what data as well as when they have access to the data, this is called a SECURITY PROCEDURE. (page 111) |
| SKILL AND TRAINING DATABASE | To establish the STAFFING AND NEW HIRE PLAN a DATABASE with skills can be used (page 113) |
| SKILL NEED | Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources, this is need for acquisition of knowledge is a SKILL NEED. (page 113) |
| STAFFING AND NEW HIRE PLAN | To meet the SKILL NEED a STAFFING AND NEW HIRE PLAN to hire new employees should be made. (page 113) |
| STAKEHOLDER INVOLVEMENT PLAN | For the inputs of stakeholders to be useful, careful selection of relevant stakeholders is necessary. For each major activity, identify the stakeholders that are affected by the activity and those who have expertise that is needed to conduct the activity. This list of relevant stakeholders will probably change as the project moves through the phases of the project life cycle. It is important, however, to ensure that relevant stakeholders in the later phases of the life cycle have early input to requirements and design decisions that affect them. The result of the previously described process is a STAKEHOLDER INVOLVEMENT plan. (page 114) |
| TASK & WORK PRODUCT ESTIMATE | TASK & WORK PRODUCT ESTIMATE is an estimate of the size, complexity and attributes of a task and it’s resulting work product. The estimates should be consistent with project requirements to determine the project’s effort, cost, and schedule. A relative level of difficulty or complexity should be assigned for each size attribute. (page 101) |
| TASK DESCRIPTION | TASK DESCRIPTION is a description of a task, including: mitigation tasks, tasks for deliverables and supporting activities, tasks for skill and knowledge acquisition, tasks for development of needed support plans, such as configuration management, quality assurance, and verification plans tasks for integration and management of non-developmental items (page 100) |
| TECHNICAL APPROACH | The TECHNICAL APPROACH defines a top-level strategy for development of the products. It includes decisions on architectural features, such as distributed or client server; state-of-the-art or established technologies to be applied, such as robotics, composite materials, or artificial intelligence; and breadth of the functionality expected in the final products, such as safety, security, and ergonomics. (page 101) |
| WORK BREAKDOWN STRUCTURE | The WORK BREAKDOWN STRUCTURE (WBS) is typically a product-oriented structure that provides a scheme for identifying and organizing WORKPACKAGES. The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project. (page 99) |
| WORK PRODUCT | The term WORK PRODUCT is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Examples of processes to be considered as work products include a manufacturing process, a training process, and a disposal process for the product. A key distinction between a WORK PRODUCT and a product component is that a work product need not be engineered or part of the end product. (page 25) |
| WORKPACKAGE | WORKPACKAGES are logical units of work to be managed or in other words: singular work units that can be separately assigned, performed, and tracked. (page 99 and 111) |