Summary
-
By discussing the level of project uncertainty early in the planning process, you'll set the tone for planning the rest of the project.
-
Agile planning is based on achievements and commitments to meeting them.
-
Network diagrams can clearly show the multiple pathways and decision points in an agile project.
-
The up-front planning effort should consist of a high-level network diagram showing pathways and decision points, plus a detailed Gantt chart looking out to the foreseeable horizon.
-
Make low-level planning a regular part of the project management culture.
-
Concise Project Data Sheets are an effective and "light" planning tool for agile projects.
Project Data Sheet Workflow
This section describes how to use the Project Data Sheet (PDS) when initiating a new project. This process will guide you through the fundamentals of project planning in a logical and concise manner, subsequently creating an executive summary of your project.
The PDS is a communication tool. By summarizing the critical characteristics of your project into the PDS format, you can easily and expeditiously share your project plans with stakeholders (e.g., sponsor, functional management, team members, other project managers) to obtain their support and/or feedback.
The PDS is designed so that individual sections can be easily included or omitted from the final output. Also, there are many different types of projects, and one process does not fit them all. You are encouraged to customize this process where applicable by modifying or adding sections.
Creating the PDS is an iterative process. It generally works well when a small core group (sometimes only the project manager) creates the first draft and then reviews/discusses it with the larger team, perhaps at a project kickoff meeting or project start-up workshop.
An electronic copy of this workflow and template can be downloaded from http://www.xocp.com.
Identify the Project and Project Team
Uniquely identifying the project itself, as well as the project team, is a simple step toward eliminating confusion and setting project accountability. In the PDS, only the names of the respective individuals are included. It is also a good idea to clarify the roles and responsibilities of these individuals; however, this should be done in a separate document from the PDS, such as the Communications Plan, so that adequate detail can be included.
| Project Manager | This is the person responsible for managing the overall project. |
| | |
| Project Sponsor | This is the primary person who wants the project done and who is authorizing that resources be expended to complete it. |
| | |
| Team Members | These are the people who are contributing to the project. |
| | |
Define the Project
A well-defined project sets clear expectations for the project manager, project team, project sponsors, and functional management. Everyone needs to know why they are doing the project and what they hope to accomplish. A good project definition can also head off confusion down the road by identifying, up-front, any ambiguous areas and challenges. It clearly differentiates what "is" and "is not" included in the project.
| Why are we doing this project? | This is the project Problem Statement. It frames the project context for people not intimately involved. Since not all projects are undertaken to address a particular problem, this section may be omitted if appropriate or combined with the next section. However, if there is a particular problem that this project is intended to solve, then a problem statement is very valuable. |
| | |
| What is this project trying to accomplish? | Write one or more high-level Objective statements describing what you hope to accomplish by undertaking this project. These statements are succinct and are essentially describing the scope of the project. To aid in bounding the scope, you may want to include an "Is/Is not" list to help minimize future scope creep. |
| | |
| How will the team approach the project? | This section should capture the technical and/or business approach to the project at a high-level. Discuss the methodologies that will be used to complete the project (not the ones used to manage the project), as well as how and where work will get done. |
| | |
| How will you know when you're done? | This isn't always clear, especially in a technology or product development environment. However, defining your success criteria will aid in planning the overall project. |
| | |
| What are your external dependencies? | Identify the events external to your project that must happen before a part or all of the project can be completed. Pay special attention to those dependencies that could prevent you from completing any of the steps in this Project Data Sheet workflow. If there's an external dependency, such as the marketing strategy, that must be completed before you can properly define your project, then that should raise a red flag and tell you that your project is not being set up for success. |
| | |
| Classify your boundary constraints | There are three core dimensions of any project—scope, schedule, and resources—and each has boundaries that either can or cannot be constrained as the project progresses. Ideally, the project would be completed exactly according to the original plan, in which case there would be no need for this section at all. However, this usually isn't the case. You should assess your level of acceptable constraint during the definition and planning phases for two reasons. It will help identify up-front problems with the project plan, and it will facilitate decision making done "in the heat of the moment" during the project execution phase. If more than one dimension is identified as "fixed", it should raise a red flag. This could indicate a lack of maneuvering room for the team while executing the project. Projects operating in an agile environment should not have any fixed dimensions. |
| | |
| Describe your project | Now that you have thought through all of the above-listed elements of the project, you should have the necessary information to start a short project description. The Project Description should be one or two paragraphs, and it should be able to stand on its own. This is your project "elevator pitch". As the project manager, you should be able to comfortably and concisely describe your project to anyone, either verbally or in writing. If you cannot write a short project description at this time, then you should be cautious about moving forward with the project—there are still holes in your project definition. Having an incomplete project definition isn't a showstopper. Often project teams need to do some investigatory work before they can fully define their project. This is okay, but you should remember to return here to complete the project description. |
| | |
Plan the Project
Now that you have defined your project, the next step is to plan your project. In the ideal world, this is a serial process—planning comes after definition. However, in reality, time pressures often force these steps to happen in parallel. In fact, some project managers prefer to do them in parallel because it helps the overall thought process. This is fine. The mistake that you do not want to make is to totally skip the project definition step and just start out by planning the project. This would be like starting to design a new product without any specifications. There is a high chance that what you create will not be what the customer wants!
Network diagram
If your approach to the project involves decision points, iterations, or multiple pathways, then it will be beneficial to have a separate network diagram since these characteristics are difficult to depict and read in a Gantt chart. A milestone-level network diagram is an excellent tool for illustrating the general approach to a project.
| Identify the project milestones | A milestone is a point of noteworthy accomplishment in your project. These are the points that will appear on your high-level project plans and progress reports to management. A milestone is not the same as a task in that its duration is equal to zero. Milestones are those points in time immediately following the completion of a task.
|
| | |
| Identify the project decision points | Decision points are those places in your project plan where you need to decide which of multiple possible pathways to take. These are not the day-to-day decisions that are made in the course of performing a task, but rather the decisions that will dictate which task to pursue next.
|
| | |
| Lay out the milestones and decision points | Lay out your milestones and decision points in a sequential fashion. (Note: A decision point is also a milestone.) |
| | |
| Connect the milestones and decision points | Use arrows to connect the milestones and decision points, as well as to show the direction of the sequence. |
| | |
| Assign owner ship to mile stones | Work with the project team to assign ownership to the various milestones. While any single person may not own all of the detailed tasks leading up a milestone, it is still beneficial to assign ownership to milestones. |
| | |
| Assign target dates | Assign target dates to milestones and decision points, if known. For example, if you have fixed or limited your schedule (when you classified your boundary constraints), then this would be a guideline for assigning target dates. For milestones within loops or decision points at the end of a loop, identify the target date for the first pass. It is not critical to assign dates to all milestones at this point. The primary goal of the network diagram is to depict the approach to the project. The next section, timeline, will focus specifically on assigning dates to all milestones, after which you may return to this section and fill in the missing dates. |
| | |
| Assign target iterations through loops | Estimate the number of times you expect to go through a loop before exiting it. Iteration through a loop is something that teams get a good grasp on only through experience, but it has a potentially enormous impact on the timeline and is an excellent discussion point. As such, it is important to include here. |
| | |
Timeline
The timeline is your best tool for communicating the project duration in total, as well as between milestones. For the purposes of the Project Data Sheet, which is intended to be an executive summary of the project, it is only necessary to use milestones (not detailed tasks) in depicting the timeline. A task-level Gantt chart is often very valuable, but it should be created as a separate document, either attached to the PDS or included as a separate section in an overall project plan.
| Lay out the milestones, decision points, and external dependencies | Lay out your milestones, decision points, and dependencies in a sequential fashion on a timeline of appropriate scale. (Note: A decision point is also a milestone.) |
| | |
| Assign fixed dates | Review your project constraints for any specific that dates were assigned to milestones as fixed. The most likely fixed milestone is the project completion milestone, though interim milestones may also be specifically fixed as needed. For instance, if a specific individual must start another project on a specific date, then any milestone that he is responsible for must be completed prior to that date. |
| | |
| Assigned limited dates | Review your project constraints for any specific dates that were assigned to milestones as limited. |
| | |
| Insert dates for external dependencies | Review your project's external dependencies for any timeline-related dependencies. For example, let's say a piece of test equipment is being transferred from another facility and it needs to be online before a specific milestone can be reached. This would be an external dependency if the transfer was not being managed as part of the project. It would not be a dependency if it was part of the project, since you would be expected to plan for it. Identify the target dates for external dependencies on the timeline. |
| | |
| Assign ownership to mile stones | If you have previously created a network diagram, then you will have already done this step. If not, then work with the project team now to assign ownership to the various milestones. While any single person may not own all of the detailed tasks leading up a milestone, it is still beneficial to assign ownership to milestones. |
| | |
| Assign dates to remaining milestones | Work with the owners of the various milestones to assign target completion dates to each. For the purposes of the Project Data Sheet, it is appropriate to use a top-down estimate since the timeline only consists of milestones at this time. However, this information can be updated later if a more detailed bottom-up Gantt chart and duration estimate is created. |
| | |
Resources
This section will consist of a top-down rolling estimate of resources required for the project, including people and money.
| List the team | List the team members in the Resource column. |
| | |
| Determine your time horizon | Determine how large of a rolling window you want to capture resource estimates for. It usually works best when done quarterly (e.g., 3, 6, 9, or 12 months). Don't try to estimate further out than you can reasonably foresee, because it could create frustration among the team and give false impressions of the actual resources required. |
| | |
| Make a top-down FTE estimate | Work with each individual team member to create a top-down resource estimate, based on the timeline above, in FTE-months, for each month in your rolling window. An FTE (full time equivalent) is equal to one person working full-time. An FTE month is equal to one person working full-time for one month. Depending on how you track costs, contractors and consultants may be included here or in the money resources section below. |
| | |
| Make a top-down money estimate | Work with the entire team to estimate the amount of money (outside of salaries for the team) that will be required to support the project. New equipment purchases, prototypes, and travel would be included here. Enter the total project money expenditures into the table. |
| | |
| Total the resources | Add up the monthly resource estimates and total (rolling window) resource estimates. |
| | |
Risks
| Identify project risks | Identify potential risks to the project's success. A detailed risk management plan should be a separate document or section in an overall project plan. (See Chapter 8 on Risk Management for details on risk identification.) For the purposes of the Project Data Sheet, the risks only need to be listed. |
| | |
Description completion
| Update your project description | You now have two more elements with which to update your Project Description—time and resource estimates. Rewrite your Project Description to tell the reader why you are doing the project, what you hope to accomplish, when you expect the project to be completed, and how much it will cost. You may also make reference to the dependencies, constraints, and risks, which are described in more detail in other sections of the PDS. |
| | |
Change history
| Record change history of the Project Data Sheet | As one of the primary communication tools for the project, the Project Data Sheet should be maintained as the various project characteristics change during project execution. When modifying the PDS, it is good practice to save previous versions, either electronically or hard copy, so that you have a solid trail of changes that can be reviewed if necessary. Also, this history can be valuable when reviewing the lessons learned after a project has been completed. |
| | |
Template for the Product Data Sheet (PDS)
Project Name Project Data Sheet
| Project manager: name of person |
| Project sponsor: name of person |
| Project team: names of team member 1, team member 2, team member 3, … |
| |
| Description: |
| |
| Objectives: |
| |
| Approach: |
| |
| Deliverables: |
| |
| Dependencies: |
| |
| Boundary constraints: |
| |
| Risks: |
| |
| Network diagram: |
| |
| Timeline/Milestones: |
| Resources: |
Change History
| Date: | Description of change: |
| Today's date | As issued |
EAN: 2147483647
Pages: 96