Thursday, April 26, 2007

Project Planning: Specific Practices by Goal: SG3

Obtain Commitment to the Plan
Commitments to the project plan are established and maintained.
To be effective, plans require commitment by those responsible for implementing and supporting the plan.

SP 3.1 Review Plans that Affect the Project
Review all plans that affect the project to understand project
commitments.
For Integrated Product and Process Development
When integrated teams are formed, their integrated work plans are among the plans to review. 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.

Typical Work Products
1. Record of the reviews of plans that affect the project

SP 3.2 Reconcile Work and Resource Levels
Reconcile the project plan to reflect available and estimated resources.

For Integrated Product and Process Development
When integrated teams are formed, special attention needs to be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or many projects.
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.


Typical Work Products
1. Revised methods and corresponding estimating parameters (e.g.,better tools, use of off-the-shelf components)
2. Renegotiated budgets
3. Revised schedules
4. Revised requirements list
5. Renegotiated stakeholder agreements

SP 3.3 Obtain Plan Commitment
Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

For Integrated Product and Process Development
When integrated teams are formed, the integrated team plans will need buy-in from the team members, the interfacing teams, the project, and the process owners of the standard processes that team has selected for tailored application.
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.Often, a provisional commitment is adequate to allow the effort to begin and to permit research to be performed to increase confidence to the
appropriate level needed to obtain a full commitment.

Typical Work Products
1. Documented requests for commitments
2. Documented commitments

Subpractices
1. Identify needed support and negotiate commitments with relevant stakeholders.

The WBS can be used as a checklist for ensuring that commitments are obtained for all tasks. The plan for stakeholder interaction should identify all parties from whom commitment should be obtained.
2. Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories.
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.
3. Review internal commitments with senior management as appropriate.
4. Review external commitments with senior management as appropriate. Management may have the necessary insight and authority to reduce risks associated with external commitments.
5. Identify commitments on interfaces between elements in the project, and with other projects and organizational units, so they can be monitored.Well-defined interface specifications form the basis for commitments.

GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.


Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the project planning process.
Elaboration:
This policy establishes organizational expectations for estimating the planning parameters, making internal and external commitments, and developing the plan for managing the project.


Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the project planning process.
Elaboration:
This plan for performing the project planning process differs from the project plan described in specific practices in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from estimating the scope of the project all the way to obtaining commitment for the project plan. In other words, this generic practice calls for one to "plan the plan." In contrast, the project plan called for in the specific practices would address planning for the project effort itself in a comprehensive manner.


GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the project planning process, developing the work products, and providing the services of the process.

Elaboration:
Special expertise, equipment, and facilities in project planning may be required. Special expertise in project planning may include the following:

· Experienced estimators
· Schedulers
· Technical experts in applicable areas (e.g., product domain and technology)
Examples of other resources provided include the following tools:
· Spreadsheet programs
· Estimating models
· Project planning and scheduling packages


GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process,developing the work products, and providing the services of the project planning process.


GP 2.5 (AB 4) Train People
Train the people performing or supporting the project planning process as needed.
Elaboration:
Examples of training topics include the following:
· Estimating
· Budgeting
· Negotiating
· Risk identification and analysis
· Data management
· Planning
· Scheduling

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the project planning process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Work breakdown structure
· Project plan
· Data management plan
· Stakeholder involvement plan


GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the project planning process as planned.
Elaboration:
This generic practice is different from developing the plan for stakeholder involvement for the project itself, which is covered in a specific practice of this process area.
Select relevant stakeholders from senior managers, project managers,project functional managers (e.g., systems engineering, software engineering, other disciplines), software engineers, systems engineers,
manufacturing engineers, logisticians, suppliers, customers, and others who may be affected by, or may affect, the project.

Examples of activities for stakeholder involvement include the following:
· Establishing estimates
· Reviewing and resolving issues on the completeness and correctness of the project risks
· Reviewing data management plans
· Establishing project plans
· Reviewing project plans and resolving issues on work and resource issues


GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Number of revisions to the plan
· Cost, schedule, and effort variance per plan revision


Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence

Objectively evaluate adherence of the project planning process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Establishing estimates
· Developing a project plan
· Obtaining commitments to the project plan


Examples of work products reviewed include the following:
· WBS
· Project plan
· Data management plan
· Stakeholder involvement plan

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the project planning process with higher level management and resolve issues.

(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined project planning process.

GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the project planning process to support the future use and improvement of the organization’s processes and process assets.

Wednesday, April 25, 2007

Project Planning: Specific Practices by Goal: SG2

Develop a Project Plan
A project plan is established and maintained as the basis for managing theproject.A project plan is a formal, approved document used to manage andcontrol the execution of the project. It is based on the project requirements and the established estimates.
The project plan should consider all phases of the project life cycle.Project planning should ensure that all plans affecting the project areconsistent with the overall project plan.

SP 2.1 Establish the Budget and Schedule
Establish and maintain the project’s budget and schedule.
The project’s budget and schedule are based on the developedestimates and ensure that budget allocation, task complexity, and taskdependencies are appropriately addressed. Event-driven, resource-limited schedules have proven to be effective indealing with project risk. Identifying accomplishments to bedemonstrated before initiation of the event provides some flexibility inthe timing of the event, a common understanding of what is expected, abetter vision of the state of the project, and a more accurate status ofthe project’s tasks.

Typical Work Products
1. Project schedules
2. Schedule dependencies
3. Project budget

Subpractices
1. Identify major milestones.
Milestones are often imposed to ensure completion of certain deliverables by themilestone. Milestones can be event based or calendar based. If calendar based,once milestone dates have been agreed upon, it is often very difficult to changethem.

2. Identify schedule assumptions.
When schedules are initially developed, it is common to make assumptions aboutthe duration of certain activities. These assumptions are frequently made on itemsfor which little if any estimation data is available. Identifying these assumptionsprovides insight into the level of confidence (uncertainties) in the overall schedule.

3. Identify constraints.
Factors that limit the flexibility of management options need to be identified asearly as possible. The examination of the attributes of the work products andtasks will often surface these issues. Such attributes can include task duration,resources, inputs, and outputs.

4. Identify task dependencies.
Typically, the tasks for a project can be accomplished in some ordered sequencethat will minimize the duration of the project. This involves the identification ofpredecessor and successor tasks to determine the optimal ordering.
Examples of tools that can help determine an optimal ordering of task activitiesinclude the following:
· Critical Path Method (CPM)
· Program Evaluation and Review Technique (PERT)
· Resource-limited scheduling

5. Define the budget and schedule.
Establishing and maintaining the project's budget and schedule typically includesthe following:
. Defining the committed or expected availability of resources and facilities
· Determining time phasing of activities
· Determining a breakout of subordinate schedules
· Defining the dependencies between the activities (predecessor or successor relationships)
· Defining the schedule activities and milestones to support accuracy in progress measurement
· Identifying milestones for delivery of products to the customer
· Defining activities of appropriate duration
· Defining milestones of appropriate time separation

· Defining a management reserve based on the confidence level in meeting theschedule and budget
· Using appropriate historical data to verify the schedule
· Defining incremental funding requirements
· Documenting project assumptions and rationale

6. Establish corrective action criteria.
Criteria are established for determining what constitutes a significant deviationfrom the project plan. A basis for gauging issues and problems is necessary todetermine when a corrective action should be taken. The corrective actions mayrequire re-planning, which may include revising the original plan, establishing newagreements, or including mitigation activities within the current plan.

SP 2.2 Identify Project Risks
Identify and analyze project risks. Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all the plans thataffect the project to ensure that the appropriate interfacing is taking place between all relevant stakeholders on identified risks. Project planning risk identification and analysis typically include the following:
· Analyzing the risks to determine the impact, probability of occurrence, and time frame in which problems are likely to occur
· Prioritizing risks

Typical Work Products
1. Identified risks
2. Risk impacts and probability of occurrence
3. Risk priorities

Subpractices
1. Identify risks.
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 canbe analyzed. When identifying risks, it is good to use a standard method fordefining risks. Risk identification and analysis tools may be used to help identifypossible problems. Examples of risk identification and analysis tools include the following:

· Risk taxonomies
· Risk assessments
· Checklists
· Structured interviews
· Brainstorming
· Performance models
· Cost models
· Network analysis
· Quality factor analysis

2. Document the risks.

3. Review and obtain agreement with relevant stakeholders on thecompleteness and correctness of the documented risks.
4. Revise the risks as appropriate.
Examples of when identified risks may need to be revised include the following:
· When new risk is identified
· When risks become problems
· When risks are retired
· When project circumstances change significantly

SP 2.3 Plan for Data Management
Plan for the management of project data. For Integrated Product and Process DevelopmentWhen integrated teams are formed, project data includes datadeveloped and used solely within a particular team as well asdata applicable across integrated team boundaries if there aremultiple integrated teams.
Data are the various forms of documentation required to support aprogram 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 ordrawn 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.

The data requirements for the project should be established for both thedata items to be created and their content and form, based on acommon or standard set of data requirements. Uniform content andformat requirements for data items facilitate understanding of datacontent and help with consistent management of the data resources.
The reason for collecting each document should be clear. This taskincludes the analysis and verification of project deliverables and nondeliverables, contract and noncontract data requirements, and customer-supplied data. Often, data is collected with no clearunderstanding of how it will be used. Data is costly and should be collected only when needed.

Typical Work Products
1. Data management plan
2. Master list of managed data
3. Data content and format description
4. Data requirements lists for acquirers and for suppliers
5. Privacy requirements
6. Security requirements
7. Security procedures
8. Mechanism for data retrieval, reproduction, and distribution
9. Schedule for collection of project data
10. Listing of project data to be collected

Subpractices
1. Establish requirements and procedures to ensure privacy andsecurity of the data. 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 aswell as when they have access to the data.
2. Establish a mechanism to archive data and to access archiveddata. Accessed information should be in an understandable form (e.g., electronic orcomputer output from a database) or represented as originally generated.
3. Determine the project data to be identified, collected, anddistributed.

SP 2.4 Plan for Project Resources
Plan for necessary resources to perform the project.

For Integrated Product and Process Development
When integrated teams are formed, planning for project resources has to consider staffing of the integrated teams.
Defining project resources (labor, machinery/equipment, materials, andmethods) and quantities needed to perform project activities builds onthe initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.
The top-level WBS developed earlier as an estimation mechanism is typically expanded by decomposing these top levels into work packages that represent singular work units that can be separately assigned,performed, and tracked. This subdivision is done to distribute management responsibility and provide better management control.Each work package or work product in the WBS should be assigned a unique identifier (e.g., number) to permit tracking. A WBS may bebased on requirements, activities, work products, or a combination of these items. A dictionary that describes the work for each work packagein the WBS should accompany the work breakdown structure.

Typical Work Products
1. WBS work packages
2. WBS task dictionary
3. Staffing requirements based on project size and scope
4. Critical facilities/equipment list
5. Process/workflow definitions and diagrams
6. Program administration requirements list

Subpractices
1. Determine process requirements.
The processes used to manage a project must be identified, defined, andcoordinated with all the relevant stakeholders to ensure efficient operations duringproject execution.
2. Determine staffing requirements.
The staffing of a project depends on the decomposition of the projectrequirements into tasks, roles, and responsibilities for accomplishing the projectrequirements as laid out within the work packages of the WBS.
Staffing requirements must consider the knowledge and skills required for each ofthe identified positions, as defined in the Plan for Needed Knowledge and Skills specific practice.
3. Determine facilities, equipment, and component requirements.
Most projects are unique in some sense and require some set of unique assets toaccomplish the objectives of the project. The determination and acquisition ofthese assets in a timely manner are crucial to project success.Lead-time items need to be identified early to determine how they will bead dressed. 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.

SP 2.5 Plan for Needed Knowledge and Skills
Plan for knowledge and skills needed to perform the project.
Refer to the Organizational Training process area for more informationabout knowledge and skills information to be incorporated into theproject plan.
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 skillsavailable to support the execution of the project.

Typical Work Products
1. Inventory of skill needs
2. Staffing and new hire plans
3. Databases (e.g., skills and training)

Subpractices
1. Identify the knowledge and skills needed to perform the project.
2. Assess the knowledge and skills available.
3. Select mechanisms for providing needed knowledge and skills.

Example mechanisms include the following:
· In-house training (both organizational and project)
· External training
· Staffing and new hires
· External skill acquisition

The choice of in-house training or external outsourcing for the needed knowledgeand skills is determined by the availability of training expertise, the project'sschedule, and business objectives.

4. Incorporate selected mechanisms in the project plan.

SP 2.6 Plan Stakeholder Involvement
Plan the involvement of identified stakeholders.
For Integrated Product and Process DevelopmentWhen integrated teams are formed, stakeholder involvement needs to be planned down to the integrated team level.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 isa convenient format for accomplishing this identification. Relevance ofthe stakeholder to the activity in a particular project phase and the amount of interaction expected would be shown at the intersection ofthe project phase activity axis and the stakeholder axis.
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 thephases 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.

Examples of the type of material that should be included in a plan for stakeholder interaction include the following:
· List of all relevant stakeholders
· Rationale for stakeholder involvement
· Roles and responsibilities of the relevant stakeholders with respect to the project,by project life-cycle phase
· Relationships between stakeholders
· Relative importance of the stakeholder to success of the project, by project lifecyclephase
· Resources (e.g., training, materials, time, funding) needed to ensure stakeholderinteraction
· Schedule for phasing of stakeholder interaction
Conduct of this specific practice relies on shared or exchangedinformation with the previous Plan for Needed Knowledge and Skillsspecific practice.

Typical Work Products
1. Stakeholder involvement plan

SP 2.7 Establish the Project Plan
Establish and maintain the overall project plan content.
For Systems EngineeringSystems-engineering planning details the work activities andwork products of the integrated technical effort across theproject.
For Systems EngineeringExamples of plans that have been used in the U.S. Department of Defensecommunity include the following:
· Integrated Master Plan – an event-driven plan that documents significantaccomplishments with pass/fail criteria for both business and technicalelements of the project and ties each accomplishment to a key programevent.
· Integrated Master Schedule – an integrated and networked multi-layeredschedule of program tasks required to complete the work effortdocumented in a related Integrated Master Plan.
· Systems-Engineering Management Plan – a plan that details theintegrated technical effort across the project.
· Systems-Engineering Master Schedule – an event-based schedule thatcontains a compilation of key technical accomplishments, each withmeasurable criteria, requiring successful completion to pass identifiedevents.
· Systems-Engineering Detailed Schedule – a detailed, time-dependent,task-oriented schedule that associates specific dates and milestones withthe Systems-Engineering Master Schedule.

For Software Engineering
For software, the planning document is often referred to asone of the following:
· Software development plan
· Software project plan
· Software planA documented plan that addresses all relevant planning items isnecessary to achieve the mutual understanding, commitment, andperformance of individuals, groups, and organizations that mustexecute or support the plans. The plan generated for the project definesall 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.

Typical Work Products
1. Overall project plan

Project Planning: Specific Practices by Goal: SG1

SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained.
Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.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.
Factors that are typically considered when estimating these parameters
include the following:
· Project requirements, including the product requirements, the requirements imposed by the organization, the requirements imposed by the customer, and other requirements that impact the project
· Scope of the project
· Identified tasks and work products
· Technical approach
· Selected project life-cycle model (e.g., waterfall, incremental,
spiral, etc.)
· Attributes of the work products and tasks (e.g., size or complexity)
· Schedule
· Models or historical data for converting the attributes of the work products and tasks into labor hours and cost
· Methodology (models, data, algorithms) used to determine needed material, skills, labor hours, and cost
Documenting the estimating rationale and supporting data is needed for stakeholders’ review and commitment to the plan and for maintenance of the plan as the project progresses.


SP 1.1 Estimate the Scope of the Project
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. The WBS is typically a product-oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called "work packages." 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.


Typical Work Products
1. Task descriptions

2. Work package descriptions
3. WBS


Subpractices
1. Develop a WBS based on the product architecture.
The WBS provides a scheme for organizing the project’s work around the products that the work supports. The WBS should permit the identification of the following items:
· Identified risks and their 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
2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule.
The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve.
3. Identify work products (or components of work products) that will be externally acquired.
4. Identify work products that will be reused.


SP 1.2 Establish Estimates of Work Product and Task Attributes
Establish and maintain estimates of the attributes of the work products and tasks.

Size is the primary input to many models used to estimate effort, cost, and schedule. The models may also be based on inputs such as connectivity, complexity, and structure.

Examples of types of work products for which size estimates are made include the
following:
· Deliverable and nondeliverable work products
· Documents
· Operational and support software
Examples of size measures include the following:
· Number of functions
· Function points
· Source lines of code
· Number of classes and objects
· Number of requirements
· Number of interfaces
· Number of pages
· Number of inputs and outputs
· Number of technical risk items
· Volume of data
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.

Typical Work Products
1. Technical approach
2. Size and complexity of tasks and work products

3. Estimating models
4. Attribute estimates


Subpractices
1. Determine the technical approach for the project.
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.

2. Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements. 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.
Examples of current methods include the following:
· Number of logic gates for integrated circuit design
· Lines of code or function points for software
· Number/complexity of requirements for systems engineering
· Number of square feet for standard-specified residential homes

3. Estimate the attributes of the work products and tasks.

4. Estimate, as appropriate, the labor, machinery, materials, and methods that will be required by the project.

SP 1.3 Define Project Life Cycle
Define the project life-cycle phases upon which to scope the planning effort. The determination of a project’s life-cycle phases provides for planned periods of evaluation and decision making. These are normally defined
to support logical decision points at which significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and
determinations of future scope and cost can be made.

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.

For Systems Engineering
Identify the major product phase (e.g., concept exploration, development, etc.) for the current state of the product, expected future phases, and the relationships and effects among phases. Adjust planning parameters to account for relationships and effects among phases.
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, subphases may be needed. A development phase may include subphases 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.

Understanding the project life cycle is crucial in determining the scope of the planning effort and the timing of the initial planning, as well as the timing and criteria (critical milestones) for re-planning.

Typical Work Products
1. Project life-cycle phases

SP 1.4 Determine Estimates of Effort and Cost
Estimate the project effort and cost for the work products and tasks based on estimation rationale. 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. There may be occasions where the available historical data does not apply, such as where efforts are unprecedented or where the type of task does not fit available models. An effort is unprecedented (to some degree) if a similar product or component has never been built. An effort may also be unprecedented if the development group has never built such a product or component.
Unprecedented efforts are more risky, require more research to develop reasonable bases of estimate, and require more management reserve. The uniqueness of the project must be documented when using these
models to ensure a common understanding of any assumptions made in the initial planning stages.

Typical Work Products
1. Estimation rationale
2. Project effort estimates
3. Project cost estimates

Subpractices
1. Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost.

For Software Engineering
Within the software-engineering area, many parametric models have been developed to aid in estimating cost and schedule. The use of these models as the sole source of estimation is not recommended as these models are based on historical project data that may or may not be pertinent to your project. Multiple models and/or methods may be used to ensure a high level of confidence in the estimate.
Historical data include the cost, effort, and schedule data from previously executed projects, plus appropriate scaling data to account for differing sizes and complexity.

2. Include supporting infrastructure needs when estimating effort and cost. The support infrastructure includes items needed from a development and sustainment perspective for the product.

For Software Engineering
Consider critical computer resources in the host environment, in the test environment, in the target environment, or in any combination of these. Computer resource estimation typically includes the following:
· identifying the critical computer resources for the software project and
· basing estimates of critical computer resources on allocated requirements

For Software Engineering
Examples of critical computer resources include the following:
· Memory, disk, and network capacity
· Processor power
· Communications channel capacity
· Workstation power
· Peripheral capacity

For Software Engineering
Examples of software-engineering facilities include the following:
· Host computers, peripherals, and networks
· Software test computers and peripherals
· Target computer environment software
· Software-engineering environment (i.e., software tools)

3. Estimate effort and cost using models and/or historical data. Effort and cost inputs used for estimating typically include the following:
· Judgmental estimates provided by an expert or group of experts (e.g., Delphi Method)
· Risks, including the extent to which the effort is unprecedented
· Critical competencies and roles needed to perform the work
· Product and product-component requirements
· Technical approach
· WBS
· Size estimates of work products and anticipated changes
· Cost of externally acquired work products
· Selected project life-cycle model and processes
· Life-cycle cost estimates
· Capability of tools provided in engineering environment
· Skill levels of managers and staff needed to perform the work
· Knowledge, skill, and training needs
· Facilities needed (e.g., office and meeting space and workstations)
· Engineering facilities needed
· Capability of manufacturing process(es)
· Travel
· Level of security required for tasks, work products, hardware, software, personnel, and work environment
· Service-level agreements for call centers and warranty work
· Direct labor and overhead

Project Planning : CMMI Maturity Level 2

Purpose
The purpose of Project Planning is to establish and maintain plans that
define project activities.


Introductory Notes
The Project Planning process area involves the following: [PA163.N101]
· Developing the project plan
· Interacting with stakeholders appropriately
· Getting commitment to the plan
· Maintaining the plan

Planning begins with requirements that define the product and project.Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments,
producing a schedule, and identifying and analyzing project risks.Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer.
The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and re-planning are contained in this process area. The term "project plan" is used throughout the generic and specific practices in this process area to refer to the overall plan for controlling
the project.

Specific and Generic Goals
SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained.
SG 2 Develop a Project Plan
A project plan is established and maintained as the basis for managing the
project.
SG 3 Obtain Commitment to the Plan
Commitments to the project plan are established and maintained.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.


(The following goal is not required for maturity level 2, but required for maturity level 3 and
above.)

GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.


Practice-to-Goal Relationship Table
SG 1 Establish Estimates [PA163.IG101]
SP 1.1 Estimate the Scope of the Project
SP 1.2 Establish Estimates of Work Product and Task Attributes
SP 1.3 Define Project Life Cycle
SP 1.4 Determine Estimates of Effort and Cost
SG 2 Develop a Project Plan [PA163.IG102]
SP 2.1 Establish the Budget and Schedule
SP 2.2 Identify Project Risks
SP 2.3 Plan for Data Management
SP 2.4 Plan for Project Resources
SP 2.5 Plan for Needed Knowledge and Skills
SP 2.6 Plan Stakeholder Involvement
SP 2.7 Establish the Project Plan
SG 3 Obtain Commitment to the Plan [PA163.IG103]
SP 3.1 Review Plans that Affect the Project
SP 3.2 Reconcile Work and Resource Levels
SP 3.3 Obtain Plan Commitment
GG 2 Institutionalize a Managed Process [CL103.GL101]
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management


(The following goal is not required and its practices are not expected for a maturity level 2 rating, but are required and expected for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information

Requirements Management: Specific Practices by Goal

SG 1 Manage Requirements
Requirements are managed and inconsistencies with project plans and work products are identified.
The project maintains a current and approved set of requirements over the life of the project by doing the following:
· Managing all changes to the requirements
· Maintaining the relationships between the requirements, the project plans, and the work products
· Identifying inconsistencies between the requirements, the project plans, and the work products
· Taking corrective action

For Software Engineering :
The requirements may be a subset of the overall product requirements, or they may constitute the entire product requirements.
For Systems Engineering:
Each level of product-component design (e.g., segment, subsystem) receives the requirements from the higher level.

SP 1.1 Obtain an Understanding of Requirements
Develop an understanding with the requirements providers on the meaning of the requirements.
As the project matures and requirements are derived, all activities or disciplines will receive requirements. To avoid requirements creep, criteria are established to designate appropriate channels, or official sources, from which to receive requirements. The receiving activities conduct analyses of the requirements with the requirements provider to ensure that a compatible, shared understanding is reached on the meaning of the requirements. The result of this analysis and dialog is an agreed-to set of requirements.


Typical Work Products
1. Lists of criteria for distinguishing appropriate requirements providers [PA146.IG101.SP101.W101]
2. Criteria for evaluation and acceptance of requirements
3. Results of analyses against criteria
4. An agreed-to set of requirements

Subpractices
1. Establish criteria for distinguishing appropriate requirements providers.
2. Establish objective criteria for the acceptance of requirements.

Lack of acceptance criteria often results in inadequate verification, costly rework, or customer rejection. Examples of acceptance criteria include the following:
· Clearly and properly stated
· Complete
· Consistent with each other
· Uniquely identified
· Appropriate to implement
· Verifiable (testable)
· Traceable
3. Analyze requirements to ensure that the established criteria are met.
4. Reach an understanding of the requirements with the requirements provider so the project participants can commit to them.

SP 1.2 Obtain Commitment to Requirements
Obtain commitment to the requirements from the project participants.

For Integrated Product and Process Development
When integrated teams are formed, the project participants are the integrated teams and their members. Commitment to the requirement for interacting with other integrated teams is as important for each integrated team as its commitments to product and other project requirements.
Whereas the previous specific practice dealt with reaching an understanding with the requirements providers, this specific practice deals with agreements and commitments among those who have to
carry out the activities necessary to implement the requirements. Requirements evolve throughout the project, especially as described by the specific practices of the Requirements Development process area
and the Technical Solution process area. As the requirements evolve, this specific practice ensures that project participants commit to the current, approved requirements and the resulting changes in project
plans, activities, and work products.

Typical Work Products
1. Requirements impact assessments
2. Documented commitments to requirements and requirements
changes

Subpractices
1. Assess the impact of requirements on existing commitments.
The impact on the project participants should be evaluated when the requirements
change or at the start of a new requirement.
2. Negotiate and record commitments.
Changes to existing commitments should be negotiated before project participants
commit to the requirement or requirement change.

SP 1.3 Manage Requirements Changes
Manage changes to the requirements as they evolve during the project. During the project, requirements change for a variety of reasons. As needs change and as work proceeds, additional requirements are derived and changes may have to be made to the existing requirements. It is essential to manage these additions and changes efficiently and effectively. To effectively analyze the impact of the changes, it is necessary that the source of each requirement is known and the rationale for any change is documented. The project manager
may, however, want to track appropriate measures of requirements volatility to judge whether new or revised controls are necessary.

Typical Work Products
1. Requirements status
2. Requirements database
3. Requirements decision database

Subpractices
1. Capture all requirements and requirements changes that are given to or generated by the project.
2. Maintain the requirements change history with the rationale for the changes. Maintaining the change history helps track requirements volatility.
3. Evaluate the impact of requirement changes from the standpoint of relevant stakeholders.
4. Make the requirements and change data available to the project.

SP 1.4 Maintain Bidirectional Traceability of Requirements
Maintain bidirectional traceability among the requirements and the project plans and work products.
The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source. Requirements traceability can also cover the relationships to other entities such as intermediate and final work products, changes in design documentation, test plans, and work tasks. The traceability should cover both the horizontal and vertical relationships, such as across interfaces. Traceability is particularly needed in conducting the impact assessment of requirements changes on the project plans, activities, and work products.

Typical Work Products
1. Requirements traceability matrix
2. Requirements tracking system

Subpractices
1. Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented.
2. Maintain requirements traceability from a requirement to its derived requirements as well as to its allocation of functions, objects, people, processes, and work products.
3. Maintain horizontal traceability from function to function and across interfaces.
4. Generate the requirements traceability matrix.

SP 1.5 Identify Inconsistencies between Project Work and Requirements
Identify inconsistencies between the project plans and work products and the requirements.
This specific practice finds the inconsistencies between the requirements and the project plans and work products and initiates the corrective action to fix them.

Typical Work Products
1. Documentation of inconsistencies including sources, conditions, and rationale
2. Corrective actions

Subpractices
1. Review the project's plans, activities, and work products for consistency with the requirements and the changes made to them.
2. Identify the source of the inconsistency and the rationale.
3. Identify changes that need to be made to the plans and work products resulting from changes to the requirements baseline.
4. Initiate corrective actions.

GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy

Establish and maintain an organizational policy for planning and performing the requirements management process.
Elaboration:
This policy establishes organizational expectations for managing requirements and identifying inconsistencies between the requirements and the project plans and work products.

Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the requirements management process.
Elaboration:
Typically, this plan for performing the requirements management process is a part of the project plan as described in the Project Planning process area.
GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the requirements management process, developing the work products, and providing the services of the process.
Elaboration:
Examples of resources provided include the following tools:
· Requirements tracking tools
· Traceability tools

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the requirements
management process as needed.
Elaboration:
Examples of training topics include the following:
· Application domain
· Requirements definition, analysis, review, and management
· Requirements management tools
· Configuration management
· Negotiation and conflict resolution

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the requirements management process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Requirements
· Requirements traceability matrix

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the requirements management process as planned.
Elaboration:
Select relevant stakeholders from customers, end users, developers,
producers, testers, suppliers, marketers, maintainers, disposal
personnel, and others who may be affected by, or may affect, the
product as well as the process.

Examples of activities for stakeholder involvement include:
· Resolving issues on the understanding of the requirements
· Assessing the impact of requirements changes
· Communicating the bidirectional traceability
· Identifying inconsistencies among project plans, work products, and requirements

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the requirements management process
against the plan for performing the process and take appropriate
corrective action. [GP110]
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Requirements volatility (percentage of requirements changed)

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the requirements management process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Managing requirements
· Identifying inconsistencies among project plans, work products, and requirements

Examples of work products reviewed include the following:
· Requirements
· Requirements traceability matrix

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the requirements management process with higher level management and resolve issues.
Elaboration:
Proposed changes to commitments to be made external to the organization are reviewed with higher level management to ensure that all commitments can be accomplished. (The following goal is not required and its practices are not expected for a maturity level 2 rating, but are required for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined requirements
management process.
GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and
improvement information derived from planning and performing
the requirements management process to support the future use
and improvement of the organization’s processes and process
assets.


Requirements Management:CMMI Maturity Level 2

Purpose:

The purpose of Requirements Management is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's
plans and work products.


Introductory Notes:
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on theproject by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product-component requirements that will also be managed by the requirements management processes. When the Requirements Management, Requirements Development, and Technical Solution process areas are all implemented, their associated processes may bec losely tied and be performed concurrently.

The project takes appropriate steps to ensure that the agreed-upon setof requirements is managed to support the planning and execution needs of the project. When a project receives requirements from anapproved requirements provider, the requirements are reviewed withthe requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into theproject’s plans. Once the requirements provider and the requirements receiver reach an agreement, commitment to the requirements is obtained from the project participants. The project manages changes to the requirements as they evolve and identifies any inconsistencies thatoccur among the plans, work products, and requirements.

Part of the management of requirements is to document requirements changes and rationale and maintain bidirectional traceability between source requirements and all product and product-component requirements.

Specific and Generic Goals:
SG 1: Manage Requirements
Requirements are managed and inconsistencies with project plans and work
products are identified.
GG 2 : Institutionalize a Managed Process
The process is institutionalized as a managed process.
(The following goal is not required for maturity level 2, but required for maturity level 3 and
above.)
GG 3 : Institutionalize a Defined Process
The process is institutionalized as a defined process.


Practice-to-Goal Relationship Table:

SG 1 Manage Requirements
SP 1.1 Obtain an Understanding of Requirements
SP 1.2 Obtain Commitment to Requirements
SP 1.3 Manage Requirements Changes
SP 1.4 Maintain Bidirectional Traceability of Requirements
SP 1.5 Identify Inconsistencies between Project Work and Requirements

GG 2 Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required and expected for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information


Friday, April 13, 2007

Adapting Small Projects Processes to CMMI

The Problem:
•Standards (CMM, CMMI, ISO, Corporate Initiatives) written for large programs
•Organization processes derived from these standards
•Small projects can follow good process, but
–Often find “process” intimidating
–Do not need as much formal communication among team members
–Cannot afford to produce enough artifacts to easily pass an appraisal
–Metrics used to convey program status to management (generally not used to manage program)

Small Project Process Goals:
•Scoped to include only directives used by most small projects
•Consistent with full process
•Short and Simple
–Project buy-in
–Supplemental non-directive guidelines and templates
•Comply with intent of appropriate standards (CMM, CMMI, ISO, Corporate Initiatives)
–Project audited to tailored process
–Not audited to standards
•Use phased implementation – by Discipline
–Software Engineering, Systems Engineering, CM/DM …

A typical small software project is…
•≤ 3 Software developers for a year
–@ 10,000 Hours
•≤ $5M project cost
•Often are:
–Company Funded
–Software is not deliverable
–Reuse into another project is not anticipated
–Demo’s
•Generally not focus candidates for assessments/ appraisals
•Often resistant to “process”
•Criteria required to use process – approved by Management
•Micro projects (<500>

Small Project Metrics:
•Project Overview
•Accomplishments Summary
•Problem Summary
•Project Schedule
•Risk Status
•Earned Value
•Staffing and Management Effort
•Defect Analysis
•Scope Change
•Lessons Learned and Implemented
•Productivity Measurement
•Software Size Trend
•Software Requirements Volatility

Small Project Software Process:
Overall Procedure:

•Criteria to Determine if Applicable
•Establishes Structure
•Roles and Responsibilities
•Metrics and Management Reporting
•Process Streamlined
•Directives

•Pages
•Paragraphs


Planning Work Instructions:
•Small Project Planning
•Determine Contractual/Program Reqts
•Determine Tasks (SOW)
•Negotiate Budget
•Develop Schedule
•Participate in Program Level Planning
•SDP, SQP, SCMP, Training Plan
• Process Tailoring
•Tailoring Instructions and Guidelines
•Tailoring Codes
•“Red-Lined” Process
•Management Approval
Process Streamlined: Directives
Pages, Paragraphs


Development Work Instructions:
•Requirements
•Allocation of system requirements to software
•Generate software requirements
•Document software, interface requirements, traceability
•Review and Control
• Design
•Generate Design
•Document
•Resource Utilization
•Review
•Coding
•Develop Coding Stds
•Generate Code
•Document
•Resource Utilization
•Review and Control
• Integration and Test
•Plan Testing
•Document in STP/STD
•Traceability
•Test Report
•Process Streamlined:
•Directives
•Pages
•Paragraphs


Support Work Instructions:
•Engineering Repository and Support Documentation
•SEN, SDFs, VDD
• Software Configuration Management
• Peer Reviews
• Software Quality Engineering
• Project Management Team
• Process Streamlined
•Directives
•Pages
•Paragraphs


Software Testing - Full Process:
•Unit Testing Procedure
–Unit Test Procedure and Report Product Standard Work Instruction
•Integration and Testing Procedure
–Regression Testing Work Instruction
–Build Plan Product Standard Work Instruction
–Software Integration and Test Procedure Product Standard Work Instruction
–Software Integration and Test Report Product Standard Work Instruction
–Software Integration and Testing Guideline Work Instruction
•CSCI Testing Procedure
–Software Test Plan Product Standard Work Instruction
–Software Test Description Product Standard Work Instruction
–Software Test Report Product Standard Work Instruction
–Software Test Plan Guideline Work Instruction
–Software Test Description Guideline Work Instruction
–Software Test Report Guideline Work Instruction

Small Project Testing:
•Plan testing. Determine extent of testing, whether to combine unit, integration, CSCI testing.
•Document test planning. Create test plan or include in ENB:
–The test environment
–Background information/overview
–Schedules
–Requirements traceability
–Individual tests to demonstrate compliance to requirements
–Control item tested, including COTS
•Create test description: TP and TD may be combined or included in ENB:
–Test preparations – hardware and software
–Test cases, descriptions, procedures
–Requirements addressed
–Prerequisite conditions
–Inputs, Expected results, Evaluation criteria
–Assumptions and constraints
–Requirements traceability
•For each defined level of testing, execute test procedures and record results.
–Ensure any necessary setup and calibration of test equipment.
–Maintain test history log. Record data from each test, including P/F.
–Evaluate test results, make corrections and retest, as necessary.
–Document and report non-conformances. Classify defects.
•Create a Test Report. TP, TD, and TR may be combined or included in ENB:
–Test results Overview/assessment
–Problems encountered
–Detailed test results or test log (may be annotated TD)
–Deviations from test cases/procedures
•Peer reviews of TP, TD, and TR.
•Control test products: Ensure consistency with other products


Micro Sized Projects – Really small:
•<500>


Results of CMM software projects:
•Initially piloted on 3 programs รจ Deployed on over 40 programs
•Feedback incorporated in subsequent releases (and into full process)
•Overwhelming positive response from PMs, SQE, Business Units, and Line and Project Management
•Tailoring time for software reduced from an average of 160 staff-hours to average of 4 staff hours
•Used in Seven Engineering Centers
–Five non-software centers were also not process oriented
•Adapted for use on micro size projects (200-500 hours)


Summary:
•Goals:
–ISO 9000, IPDS, CMM/CMMI Level 3 Compliant for project, as scoped
–Not Planned for Focus Projects in Assessments or Appraisals
•Method
–Start with full process
–Scope for small projects
–Eliminate items not used by typical small project
–Keep it short and simple ; Really short and simple
–Check for compliance with standards and make adjustments as necessary
–Phased implementation
•Management Approval