* * *
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.
Determine a target date by which you need the dependency resolved in order to make your project plan work.
All dependencies should be discussed with the appropriate owners of the events that you are dependent on so that they know your time requirements and they are aware that they are a potential bottleneck to your project.
The information you collect should be copied to the dependencies section of the Project Data Sheet.
* * *
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.
For each core project dimension, select one of the following levels of constraint that is acceptable and agreed to by the project sponsor and project manager:
Fixed: No significant change from the original project definition and plan. Be as specific as possible in identifying sub-elements within a core dimension because it’s very difficult and often not realistic to fix every minute detail.
Limited: Can be changed from the original plan within limits. If this level is selected, then you should also be as specific as possible in identifying the sub-elements in question, as well as specifying the limit.
Flexible: Can be changed as needed.
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.
Constraint levels and limits should be reflected in the boundary constraints section of the Project Data Sheet.
* * *
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.
At this time, your project description should tell the reader why you are doing the project and what you hope to accomplish. (Note: The project description is not complete at this time. You will add to the project description later in this workflow.)
* * *
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.
The first step is to identify your milestones. Start this process with the project deliverables (defined previously) since the completion of a deliverable is considered a milestone.
Examples of other milestones might be:
When you exit an iterative loop in your plan, such as when a product finally passes a suite of tests
The completion point of the whole project, as well as any subprojects
Other major project accomplishments
* * *
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.
Examples of decision points might be:
The pass/fail point of a test that indicates whether to proceed or to loop back and modify the product before testing again
The fork between two or more pathways, where you need to decide which one(s) to pursue
* * *
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.
Identify milestone ownership on the network diagram.
* * *
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.