| ||  about us      |
| ||  consulting    |
| ||  training        |
| ||  home          |
| ||  what is KM?|
| ||  eTutorial    |
| ||  links          |
|setup & init|
|exec & cntrl|
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:
Policy and Standards
One of the most important parts of the detailed project planning process is the
definition of the work that will be undertaken as part of the project. Defining
the work involves dividing the project into smaller, more manageable components
and tasks and then specifying the order of completion. The lists of components
and tasks are often called a Work Breakdown Structure (WBS). One of the goals
of project planning is to integrate the WBS, the schedule, and the budget into
a written plan.
The WBS reflects the components of the project and the tasks associated with overall project management, requirements, design, implementation, transition management, testing, training, installation, and maintenance. The project manager is responsible for defining the project components and then further decomposing them into tasks as planning continues.
A WBS is typically shown in one of two ways. It can be shown as an outline or it can be graphically represented.
A WBS is developed by asking, "What are the components and sub-components of the project?"
As levels of the WBS become lower or more granular, the scope, complexity, and cost of each sub-component becomes smaller.
As efforts of similar scope and type are planned, the basic WBS remains similar, but each project requires a specific set of tasks that address the uniqueness of the project's requirements. Certain top-level elements, such as project management, are included in the WBS of every project, regardless of its type, size, or complexity. Other items, like user documentation, may not apply to every project.
There is no simple formula to determine how detailed to make a WBS. There are, however, some helpful guidelines for completion:
When creating a WBS, each component, sub-component, and task receives a unique identifier. Components and sub-components receive a numeric identifier (e.g., 07.03.02). The project manager uses the corporate or project standards to create task identifiers.
The WBS does not take dependencies or durations into account. Dependencies and durations derive from task-level information in the project plan. Once entered into the project plan, this information can be rolled up to any level of the WBS.
Best Practice Tip:
Developing a WBS and identifying all the relevant relationships and
dependencies can be a daunting task on any sizeable project. Most automated
tools are incapable of displaying the entire WBS in a readable format, making
it difficult to identify dependencies between tasks that are widely separated.
The technique described here works well for nearly any project and also
facilitates the participation of other team members in the development of the
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.
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:
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.
|Best Practice Tip: The Delphi technique can produce good estimates in the absence of expert advice or sufficient historical data. This is a group technique that extracts and summarizes the knowledge of the group to arrive at an estimate. After the group is briefed on the project and the nature of the activity, each individual in the group is asked to simultaneously make his or her best guess of the effort required to complete the activity. The results are tabulated and presented as a histogram. Those participants whose estimates fall in the outer 25% are asked to share the reasons for their guesses. After listening to the arguments, each individual is asked to estimate the activity once again. This process is repeated for three passes. The third pass, with any final adjustments, is used as the group's estimate. While this technique seems rather simplistic, it has been shown to be effective in the absence of historical data and expert advice.|
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 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 SchedulingTime scheduling is the process that calculates the planned dates for each activity and identifies the critical path through the overall project.
The critical path is the set of sequential activities, which represents the largest duration of any path in the project. If any activity on the critical path is delayed or extended, the finish date of the project will be affected.
Once a project has been entered and checked, you are able to perform time scheduling. Time scheduling involves the following steps:
Activity progress information that might be updated are actual start and actual finish dates, remaining duration, percent complete, and expected finish date.
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:
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
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:
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.
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 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:
Best Practice Tip:
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:
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 2, direct the assigned owner to develop a mitigation strategy. Formally review all risks of this severity on a relular basis. Direct the assigned owners to monitor the risk and report any change in status that might result in a higher priority.
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.