Practice: Project Data Sheet

Practice Project Data Sheet

Objective

The objective of a project data sheet is to convey the essence, in terms of scope, schedule, and resources, of how a project will deliver on the project vision.

Discussion

A project data sheet (PDS) is the second major visioning practice in the evolution of a project plan (Figure 5.1). While the product vision is an expansive view of what the product could become, the project vision limits product development to the confines of current scope, schedule, and cost constraints. To keep these two elements separated, I usually refer to the product vision and the project scope . Colleague Mike Cohn defines product vision as the "should haves" and the project scope as the "will haves." Eventually the product "should have" 234 features; however, for this project (release 1.0), it "will have" 126 features. A PDS, as shown in Figure 5.7, is the minimum documentation for a project's scope and constraints.

Figure 5.7. Project Data Sheet

A project data sheet ( PDS ) is a single-page summary of key business objective, product specification, and project management information. It is a document to help focus the project team, management, and customers. The PDS's simplicity belies its power to convey quickly these key project elements. It is one of those simple practices with a powerful impact. Not only does its condensed format appeal to stakeholders who might not be fully involved in the project, and remind those who are fully involved about the most important aspects of the project, it also plays a part with those who develop it (Highsmith 2000).

Sections of the PDS might include some combination of the following, depending on organization and project type:

Tradeoff Matrix

The tradeoff matrix is an agreement among the project team, the customer (product manager), and the executive sponsor that is used to manage change during the project. The TOM informs all participants that changes have consequences and acts as a basis for team decision making.

The rows of a project TOM, as shown in Figure 5.8, depict the key dimensions that create a product's valuescope, delivery schedule, stability (defects), and resources. The columns display the relative importance of each dimension and are labeled Fixed, Flexible, and Accept. [4] Fixed means that the dimension, schedule for example, is fixed or constrained and that tradeoff decisions should not impact performance in that dimension. Fixed also connotes that the dimension in question has the highest priority. Flexible is one step down from Fixed; the dimension is still very important, but not important enough to trade off for the Fixed dimension. Accept indicates that the dimensioncost, for examplehas a wider range of acceptable tolerance. In fact, as the importance goes from Fixed, to Flexible, to Accept, the tolerance for variation increases .

[4] Finding the right names for these column headings has proved tricky. Lynne Nix has used Excel, Improve, and Accept, indicating a dimension in which to strive for excellence, a dimension to improve as long as the Excel dimension doesn't suffer degradation, and a dimension whose performance could be acceptable. Ian Savage suggested Fixed, Flexible, and Free to me in an e-mail message, and I've adapted from his and Lynne's usage. Sometimes it is simpler to think of priority 1, 2, and 3.

Figure 5.8. Tradeoff Matrix

In the matrix, columns one and two can each contain only one entry. If the highest priority is scope (Fixed), then everything else takes lower priority. Schedule might be designated as the second-highest priority (Flexible). Similarly, the team would strive to maintain acceptable (Accept) defect levels (within some specified tolerance level; for example, 5 sigma) and to stay with a reasonable tolerance on total project cost (possibly +/15%). [5]

[5] Some might argue that there are no tolerance levels for defects, that the agile principle of technical excellence precludes any tradeoffs for defects. While this may be the case at a module level for engineers , from an overall product perspective there can be levels of emphasis on, for example, extensive QA testing. A video game won't have the same "proof of quality" demands as a CAT scan machine. Balancing between excellence and perfection can be tricky for engineering teams .

Many managers and executives consider project success to be on time, on budget, and on scope. They define each characteristic with no tolerances and then fantasize that the project team can respond to all manner of change without tolerances. Software engineering metrics guru Capers Jones (1994) points out that it is common for customers "to insist on costs and schedules that are so far below US norms that completion on time and within budget is technically impossible." If these three characteristicsplus a fourth, qualityare all top priority, then how do teams make hard tradeoff decisions? Executives and customers put teams into an impossible position by demanding that they respond to change, while failing to give them reasonable tolerances for dealing with those changes.

If a customer executive asserts that the delivery schedule is of paramount importance, then he should also be willing to prioritize other characteristicsto say, for example, that cutting features would be preferable to slipping the schedule. The team strives to meet all the goals, but it also needs to know the relative importance of the key characteristics in order to make informed day-to-day and end-of-iteration decisions.

Another powerful piece of information that can assist teams in making project decisions is delay cost. I once worked with a project team for which the calculated delay cost was nearly a million dollars a day in lost revenue. Knowing this cost drove much of the decision making on the project and helped ward off the constant flow of new features from marketing. When stakeholders insist that schedule is the most critical element of a project, having them calculate a delay cost puts the criticality of the schedule in perspective.

Exploration Factor

An exploration factor acts as a barometer of the uncertainty and risk of a project. Big projects are different from small projects; risky projects are different from low-risk ones. One issue in selecting project management practices and processes is the particular problem domain in which the project team has to operate . An exploration factor of 10 indicates a highly exploration-oriented (high-risk) problem domain, and a 1 indicates a very stable problem environment. It is important to identify the various problem domain factors, but it is even more important to tailor processes and practices to the problem and to adjust expectations accordingly .

The exploration factor is derived from a combination of the volatility of a product's requirements and the newnessand thus uncertaintyof its technology platform. The exploration factor matrix shown in Figure 5.9 shows four categories of requirements volatility: erratic, fluctuating, routine, and stable. "Erratic" requirements depict a situation in which the product vision is understood , but the business or product requirements are fuzzy. An example would be a version 1.0 NPD effort in which features are unfolding as the project goes forward. In this case, the requirements might change drastically as the project proceeds, not from poor requirements gathering but from evolving knowledge of the product. Fluctuating requirements would be one step down in uncertainty. While an erratic problem space might experience a requirements change of 25% to 50% or more, a fluctuating one might be more sedate at 20% to 25%. A routine categorization would apply to a wide range of projects in which up-front requirements gathering yields a reasonably stable baseline for further work, while a stable environment might be something like a federally mandated change to a payroll system that is well defined and unlikely to change. [6]

[6] Ken Delcol comments, "This guides the PM in both how the project and individual requirements should be managed. For example, erratic requirements need a more iterative approach and should be planned that way up front regardless of the overall state of the remaining requirements. Not all requirements fall into the same bucket. The trick is to realize which requirements are key to overall product successthere is no point rushing forward to specify the stable requirements when critical, high-risk requirements are erratic or fluctuating!"

Figure 5.9. Project Exploration Factors

The exploration factor's technology dimension also has four categories: bleeding edge, leading edge, familiar, and well known. "Bleeding edge" would involve a technology so new that very few people have experience with it. With bleeding-edge technology, learning by trying is the only strategy because no one else knows how to use it either. In the early 2000s, Microsoft .NET or nanotechnology might be examples of bleeding-edge technologies. Leading-edge technology is relatively new, but there are pockets of expertise to turn toalthough the cost and availability of these experts might be an issue. Projects employing bleeding- or leading-edge technology have much higher risk profiles than those using familiar or well-known technologies. Development teams should carefully evaluate in what parts of the product technology risk is justified, because even within a single product, not all components should be bleeding or leading edge.

Combining these elements, we might find that an erratic requirements, bleeding-edge technology problem space receives an exploration factor of 10, whereas a stable requirements, well-known technology project receives a factor of 1. A project with fluctuating requirements and leading-edge technology receives a factor of 7. By determining the exploration factor, project and customer teams can now discuss projects from the perspective of the overall "uncertainty" of the problem space. An 8, 9, or 10 project will require a very agile approach since the uncertainty and risk are high. Short iterations, feature-driven planning, frequent reviews with customers, and a recognition that plans are very speculative are imperative for solving problems in this domain. In contrast, projects with a 1, 2, or 3 rating will be relatively stable and low risk. Plans could be more deterministic, iterations could be somewhat longer, and additional up-front requirements gathering and design time can be cost effective.

Without the recognition of different problem domains, one- size -fits-all project processes and practices seem justified. With such a recognition, customization and tailoring to specific problems will enable project teams to be successful.

Related

Категории