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