Identify the dates of fixed milestones on your time-line.
* * *
Assigned limited dates
Review your project constraints for any specific dates that were assigned to milestones as limited.
Identify the limited dates on your timeline with your early target date and show their limit.
* * *
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.
Identify milestone ownership on the timeline.
* * *
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.
Identify the dates of the remaining milestones on the timeline.
* * *
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.
Delete any extra columns so that you do not leave blank columns.
* * *
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.
Enter the FTE estimates for each team member into the table.
* * *
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.
List the top risks in the risk section of the Project Data Sheet.
* * *
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.
Record the date and a brief description whenever the PDS is changed.
* * *
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:
Your project description should tell the reader why you are doing the project (problem statement), what you hope to accomplish, when you expect the project to be completed, and how much it will cost. (Note: Complete this section last.)
* * *
Objectives:
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.
* * *
Approach:
Describe your technical and/or business approach to the project.
* * *
Deliverables:
Write one or more deliverables (nouns) that, when complete, will indicate that a major milestone has been reached or that the project itself has been completed.
* * *
Dependencies:
Describe external activities/projects that must be completed before you can complete this project (or a part of this project).
* * *
Boundary constraints:
Identify the level of constraint that the project team and sponsor agree to, for each major project dimension.
* * *
Risks:
List the top project risks. See Chapter 8 on Risk Management for details on risk identification.
* * *
Network diagram:
Insert a graphic showing the sequence of milestones, decision points, loops, and target competition dates. Also indicate (using initials) the person responsible for each milestone.
* * *
Timeline/Milestones:
Resources:
Provide an estimate of the resources (people and money) required to complete this project, as described above. People should be estimated using FTE (full time equivalent) months.
Change History
Date:
Description of change:
Today’s date
As issued
Chapter 8: Approaching Risk in an Agile Environment
Risk management is one of those areas where the rubber meets the road. Do it well, and you will avoid the numerous potholes and road-blocks that inevitably pop up in most projects. Do it poorly, and you will find yourself in crisis-management mode more often than project-execution mode. This chapter looks at the subtle differences in the mechanics of risk planning in an agile environment versus a classic one. It also covers the not-so-subtle attitudes of how risk management is often perceived in one environment versus the other.
Let’s start off by taking a look at a hypothetical business scenario and reviewing the potential impact of classic and agile risk management approaches.
Time to Market
Getting to market as fast as possible is, perhaps, the most frequently cited project management urgency. And this is for a good reason. Financial analysts everywhere are influenced by the “first mover” advantage. Simply put, the first-mover advantage states that the first company to market with a new product or feature will grab the majority of the market share. Of course, there are many other variables that can affect the market share captured by a new product, but the absence of a competitive product is very compelling.
Imagine the business advantages of beating your competition to market and enjoying a temporary monopoly (of sorts) until they catch up. You lock in your current customers, and then convert some of your competitor’s customers, thereby increasing your market share. Your increased volume gives you economies of scale and better terms with your suppliers, thus, driving down your costs. You have pricing flexibility, which leads to higher margins. Your project breakeven time is drastically reduced, making future projects that much easier to justify. And the lifetime return on the project has just shot up dramatically, increasing your company’s bottom line. All in all, being first to market allows you to create a whirlwind of enthusiasm around your product and within your company.
Product lifecycles are continuing to shorten, and getting to market within the target window (of opportunity) often determines the over-all success of both the project and product. By classic PM standards, the project can be successful (if the scope is delivered on schedule and within cost), while the product is actually a failure. Running too many of these so-called “successful” projects will eventually bring down the whole organization. When presented with a business scenario that requires a course change for the project, you need to remember to equate the project to the current business realities rather than the previously determined, and possibly out-of-date, project boundaries. Now let’s see what the picture might look like if you are beaten to market and your competition steals even a small percentage of your customers.