Detailed Project Planning defines the project activities and describes how the activities will be accomplished. The purpose of project planning is to define each task, estimate the time and resources required, and provide a framework for management review and control. The project planning activities and goals include defining:

• The specific work to be performed and goals that define the project
• Estimates to be documented for planning, tracking, and controlling the project
• Commitments that are planned, and agreed to by stakeholders
• Project alternatives, assumptions, constraints and risks.
• The Project Schedule

  Policy and Standards

  All projects should:

• Use the Project Charter (requirements) as the basis for planning the project,
• Negotiate the project's commitments between the project manager and all other managers involved in the project,
• Negotiate the involvement of subject matter expert(s) with representatives of those groups and document those negotiations,
• Negotiate the involvement of subject matter expert(s) with representatives of those groups and document those negotiations,
• Document the project's size estimates, as well as estimates of other product characteristics, effort and cost estimates, schedules, and other commitments,
• Ensure review of the estimates and commitments by all affected groups, such as engineering, estimating, system engineering, system test, standards compliance, configuration management, contract management, and documentation support,
• Ensure review by senior management of all project commitments made to individuals and groups external to the organization,
• Use the project's documented estimates and commitments to plan and manage the project,
• Plan and document the project's activities and commitments in the project's development plan,
• Manage and control the project's development plan,
• Document the project's defined process by selecting and tailoring one of the organization's Standard Project Processes, and
• Document approved deviations from the organization's Standard Project Process.

  Applicable Standards:

Will vary according to organizational standards and requirements.

  Responsibilities

  The responsibilities for Detailed Project Planning are summarized below:

• Project Managers are responsible for developing the project plan and all supporting documentation.
• The organization is responsible for developing internal procedures to ensure that the planning process is completed conistently. Projects undertaken must be well thought out, supported by a key stakeholder's goals, and include processes that allow the project to be tracked and controlled until completion.
• The organization is responsible for ensuring that there are adequate resources assigned to manage the project. Management costs should not be rolled into overhead costs. Managment is a full time job for most projects. It is an activity which requires training, experience, focus and appropriate managment and communication skills.

  Templates:

Software Estimates Template Buy Now
Software Development Plan Buy Now

  Checklists:

Schedule Review Checklist Buy Now
  Communications Management Planning Matrix

If you would like to order a full set of the Project Templates and Checklists click here Buy Now

Define Work

• Break down the work until you are able to generate accurate estimates of cost and resources needed to perform the work
• Ensure that each WBS element relates to a clearly defined deliverable. You should be able to associate starting and ending dates for each deliverable
• Verify that people assigned to the project fall underneath one or more WBS elements. Have a firm rule: if the work does not fall underneath the WBS, it is not worked on.

On a large whiteboard or wall, use Post-It notes to identify the components and sub-components (e.g., design, code, documentation, etc.) for the project. Use an existing WBS or template as a starting point. Stick these to the wall or whiteboard in the form of an organizational chart, with the project name recorded on a Post-It note at the top. Once you are satisfied that there are no major components or sub-components missing, go back and assign an appropriate WBS identifier to each component and sub-component. If you are tailoring an existing WBS, use the identifiers that have already been created. You now have "sketched" your WBS with a minimum of pain (it's pretty easy to move Post-its around).

This technique can also be used to move beyond the WBS by idenitfying the tasks required to to produce each sub-component. Once you've identified all the tasks, review each one and annotate the associated predecessor or successor tasks. A predecessor task is one that must be completed before the task under review can be finished. A successor task is one that can not be completed until the task preceding it is finished. Make sure you identify dependencies not only among tasks grouped in the same sub-component by also between tasks that fall under different sub-components.

A component oriented WBS should show tasks only at the lowest level, with deliverables above tasks and ascending from sub-component deliverables (sub-assembly) to finished product.

Generate Estimate

Overview

Before you can estimate the duration of a project, you need to understand the difference between duration and work effort. The duration of an activity or project is the elapsed time in business working days, typically excluding weekends, holidays, or other non-work days. Work effort is labor required to complete an activity. For example, an individual may work 4 hours a day for 5 days developing a user-training manual. The duration of the activity is 5 days while the work effort is only 20 hours.

Generally, the estimation process begins by estimating work effort required to complete each activity. Once the work effort is estimated, you apply resources, and determine the duration of each activity and the overall project. You may choose to apply additional or remove resources to shrink or extend the duration of each activity to meet specific project needs. Resource planning is covered in more detail under step 3, Create Schedule.

Estimating the work effort associated with each activity can be a challenging task. You will be on familiar ground for some activities and totally unfamiliar ground for others. It is important to understand that early estimates are often little more than a "best guess". In many projects, the estimate will be improved as you learn more about the deliverables and nature of the work from completing some of the project.

There are numerous estimation tools and techniques, but four of the easiest and most commonly used methods are:

• Similarity to other activities
• Historical data
• Expert advice
• Delphi technique

Based on your project needs, you should employ one or more of these techniques as described below. Regardless of what technique you select, the estimate should be documented using a standard template to record the estimate, technique used, and other information affecting the estimate.

Estimation Technique: Similarity to Other Activities

Some of the activities in the project WBS may be similar to activities completed in other projects. Recollections of those activities and the associated effort can be used to estimate the effort for the new activity. In many cases, this technique may require extrapolation, but generally provides an estimate that is of sufficient accuracy.

Estimation Technique: Historical Data

Historical project data provides one of the most accurate means of estimating activity duration. Historical data that includes both the estimated and actual effort for activities completed on other projects can be used in quite sophisticated ways. Over time, historical data can provide ranges and typical averages for completing various types of tasks. This technique differs from "Similarity to Other Activities" in that it uses recorded data rather than depending on memory.

Estimation Technique: Expert Advice

Expert advice is one of the most often-abused estimation techniques and is frequently used as an excuse for not utilizing a more rigorous approach. However, using expert advice is a good choice when the project involves breakthrough technology or a technology that is being used for the first time in the organization. In these cases, it is a good idea to appeal to outside authorities for advice. Vendors may be a good source, as are non-competitors who use the same technology.

Create Schedule

Overview

Project scheduling is the process by which the Work Breakdown Structure (WBS), sequencing of activities, estimates, and resource requirements are integrated into a holistic time phased view. Generally this process involves the use of scheduling tools such as Microsoft Project or other software the organization has chosen as the standard project-scheduling tool.

Building the project schedule is an iterative process consisting of the following activities:

• Entering the WBS information and network logic
• Identifying resource requirements
• Time scheduling
• Resource scheduling
• Baselining the project schedule

Entering the Task Information and Network Logic

When initially creating a project, the Project Manager informs the project sponsor and project team which standard WBS is applicable to their project and also which project template (if any) they plan to use. Importing an available project template, complete with typical tasks dependencies, provides a rapid start to project planning. If there is no suitable template, there may be a need to tailor the selected WBS,

Identifying Resource Requirements

Resources are the personnel, equipment, dollars and other items required to complete an activity. An activity can have any number of resource requirements associated with it, several of which can even refer to the same resource.

The resource amount required by an activity can be assigned either as a total or rate amount and can be used for the entire activity duration or for only a portion of the duration.

The resource requirement can also be used to determine the activity's original duration. By examining the resource requirement specifications, the duration of the activity can reflect the effort required of the resource and the rate at which the effort will be expended.

The resource amount can be assigned as a fixed total quantity, one that will never change, or as a rate resource, one whose total requirement will change as the activity's duration changes. The fixed quantity resource is referred to as total content and the rate resource is referred to as constant rate.

The way in which an activity requires a resource is termed the resource requirement profile. The resource requirement profile for an activity can be specified in a simple, linear pattern or as a complex pattern with varied amounts over varied time periods.

Resource requirements can be used to calculate the original duration of an activity, which is often referred to as an "effort based duration".

Time Scheduling

Once a project has been entered and checked, you are able to perform time scheduling. Time scheduling involves the following steps:

• Read and validate - This step validates the project data and connects relationships to activities. Warning messages are generated for data that fails the validation condition.
• Loop check - This step checks for loops, which are created by adding incorrect relationships that cause an activity to precede itself. A project cannot be analyzed if it contains a loop.
• Forward and backward pass - This step finds the start and end dates for each activity and identifies the critical path.

Activity progress information that might be updated are actual start and actual finish dates, remaining duration, percent complete, and expected finish date.

Resource Scheduling

The resource scheduling process attempts to match resource requirements against resource availability while taking into account the project logic. It tries to calculate the start date for each activity so that all limitations imposed by the project are satisfied and the resource supply covers demand wherever possible.

A resource-scheduled project can provide management with answers or insights into the following practical alternatives:

• If only the available resources are used, by how much will the project end be extended?
• If the project end date is to be met, how many extra resources (if any) will be required?
• If overtime is worked on the project, by how much will the end date be brought forward?
• How will a design change affect the project schedule and the resources required?
• If project A is given top priority, how will this affect projects B, C, and D?
• If activity schedule dates are changed, what will be the effect on the project schedule and resources?

Baselining the Project Schedule

A baseline is a snapshot of your project plan, including the WBS, project tasks, dependencies, and resource allocations. By establishing a baseline version, you will always be able to review the factors that changed your project plan, for better or for worse. Other versions will probably be established as you move through the project; however, it is the baseline version that you can always look to as the comparison point for project progress.

The baseline version can be used to compare the project schedule, resource utilization, and project costs.

To create a project baseline, copy the current working version of the schedule to a separate version. Re-baselining the current baseline is at the Project Manager's discretion.

You should request a baseline after the current version has been reviewed and has received the necessary approval from the project sponsor.

Develop Project Plan

Overview

The quintessential output of the planning process is the detailed development plan, or as we offer as a template, the Software Development Plan (SDP). The SDP is a consolidated source of project planning information and describes the project management approach of a software development project. However, the SDP does not needlessly duplicate information contained within other project documentation. In fact, the SDP often simply summarizes and refers readers to other documents for additional information. For example, within the introduction, summarize the project background and refer the reader to the Project Charter for further details.

Development of the SDP is the responsibility of the Project Software Manager, under the direction of the overall Project Manager. Here is a high-level outline of a typical Software Development Plan:

1. Introduction
2. References, Definitions, Acronyms, and Abbreviations
3. Software Development Life Cycle
4. General Plans for Software Development
5. Detailed Software Development Plans
6. Software Configuration Management
7. Standards Compliance
8. Reviews
9. Risk Management
10. Resource Estimates
11. Software Subcontractor Work Allocation
12. Training Needs
13. Schedule and Activity Network
14. Appendices (as required)

To ensure consistency across projects a template should be used. This template should provide examples and directions on how to complete each of the sections identified in the above outline (as our offering does). Two areas are worth discussing in more detail: Reviews and Risk Management.

Reviews

The identification and scheduling of project related reviews falls under the general process of Communication Management Planning. It is important to identify the information needs of all project stakeholders, how that information will be communicated, and with what frequency. You should conduct reviews on regular intervals (e.g., project status review) and in conjunction with major project milestones (e.g., completed software design). The amount of planning you need to expend on communication management is greatly dependent on the size and nature of the project. For simple projects, identifying regular status reviews, the intended audience, and frequency of occurrence may be sufficient. For larger or more complex projects, a more detailed communication plan may be essential. To help determine how much effort you should expend planning reviews and general communications, refer to the recommendations in the Communications Management Planning Matrix (free of charge with our compliments).

For extremely large and complex projects, a separate Communication Management Plan may be required. In addition to formally documenting the details regarding reviews, a Communication Management Plan describes responsibilities and procedures for managing and escalating unresolved project issues.

Risk Management

Risk management deals with identifying, preventing, mitigating impact, and planning for potential problems. It is different from Issue Management, in the sense that an issue is a problem that has already occurred, and a risk is a problem that hasn't happened yet. In addition to identifying, analyzing, and assigning risks, describe in the Risk Management section the process you will use to actively manage risks. In general, you should address the following questions:

• How often will risks be reviewed?
• How will you group risks to ensure high-priority risks are given adequate attention?
• Which risks must have completed mitigation strategies?
• Which risks must have completed mitigation strategies and a contingency plan?

Risk Management Approach

The approach described below can support both small and larger projects. To adopt the process, simply incorporate it into your detailed development plan.

Use a risk management tool to capture and manage the information collected about each project risk. When entering new risks be sure to include the "Probability of Occurrence", "Impact/Cost of Occurrence", and "Priority". Accurately describe each risk in terms of the problem and the potential impact on your project. Assign an owner who will be responsible for analyzing, monitoring, and developing any required mitigation strategies and/or contingency plans.

Risks can receive a priority between 1 and 3 (1 being high and 3 being low). Further, group risks into the following categories:

• Priority 1: Risks that pose a sever threat to the project
• Priority 2: Risks that pose a moderate threat to the project
• Priority 3: Risks that pose a minimal threat to the project

For any risk that has an assigned priority of 1, direct the assigned owner to develop both a mitigation strategy and a contingency plan. The risk management tool should provide appropriate fields to document the mitigation strategies, contingency plans, and contingency triggers. Contingency triggers describe the event (e.g., missing a specific milestone) that will cause enactment of the contingency plan. Formally review all risks of this severity frequently.

For any risk that has an assigned priority of 3, direct the assigned owner to monitor and report any change in status that might result in a higher priority.