Defining the Project

Defining the Project

Many projects are managed on the explorer principle: "Let's get moving and see what happens." While this approach can be exciting, particularly at two in the morning before a milestone deliverable is due, it rarely produces what the client wants. Defining the project consists of finding out what that is. It may seem insultingly elementary to point out that in order to satisfy a client, you need to identify what will do that, but too frequently, the client's needs finally become clear at implementation. That is too late.

You may wonder why so many projects do not define at the start exactly what will be produced, but a more useful question is what indicators will tell you that perhaps your project is not focusing on client needs. There are several.

1. There is a "done it before" attitude on the part of your team (including you). You may, therefore, be deluded into believing that because you understand the application (such as inventory), you know what the client needs and there is little point in taking up valuable time asking silly questions.

2. When you and your team address problems, you focus on technical solutions instead of client needs. If you are to be clientfocused, then all problems that you and your team discuss must be solved by considering what is best for the client, not by relying on technical ingenuity.

3. The project is rushed at the start. You have near-impossible deadlines to meet and the imminent inevitability of night and weekend work. If this is the case, you are being pressured to "get on with it" and to produce somethinganythingfast, and you will come to regard slowing down to talk to the client as a career-limiting move.

4. Your client or your management (or you) believe that the only valuable product from a computer systems project is code, and that everything else is preamblecostly, time-consuming, and of limited value. If that is the case, any actions that delay the start of "real" work will be wasted and unwelcome.

If any of these conditions is true, then you have forces that are diverting you from laying the necessary groundwork. The counterforce to each of them is to insist that the requirements of the project be defined as clearly and unambiguously as possible.

There is another emerging threat to a clear definition of deliverables. Many projects are now structured around some form of iterative development in which prototypes are prepared, reviewed, and successively refined until the prototype evolves into the final system. In this approach to systems development, the prototype is often used to identify business rules and procedures, leading to a temptation to dismiss the need to define requirements because "they will become clear as we evolve the prototype." If you hear this argument, point out that iterative development is one way of reaching the desired end result, but that the result still needs to be defined. In fact, this approach to projects needs, if anything, an even clearer definition of the end goal.

To define a project, you must define, document, and gain client approval for two things: the deliverables and the scope. These are discussed later in this chapter.

However, defining a project is more than defining deliverables and scope. You also need to define how the project will be conducted. Specifically, you will need to establish:

How you will manage requests for changes to the scope

How the client will review and approve deliverables

How you will develop client expectations

How you will conduct notification and escalation

How the client team is structured and the style it will use

How the project team is to be organized

These are the subjects of this chapter. A checklist at the end will help you ensure that you and the client agree on the important issues in the project.

Defining The Deliverables

On the face of it, defining deliverables should be simple. The client wants a recommendation on a software package, a set of models, a technology architecture, or an application system consisting of code and documentation. While these products might be complex to produce, defining them seems to be straightforward. Unfortunately, in the world of projects, straightforward usually leads off a cliff.

Problems arise from apparently innocuous statements such as, "The new inventory system will facilitate processing of financial data by the general accounting system." This could mean that:

The new system will provide a simple report showing summary data to be manually entered into the accounting system.

The new system will create a month-end file transferring a batch of data to the accounting system.

The system will update accounting databases from inventory transactions on-line.

The efforts that correspond to each of these interpretations are vastly different. If you plan to produce a month-end report and the client insists on on-line database updates, you are in trouble. Before the project starts, you must understand not only what all such statements mean but also what the client thinks they mean.

A definition of project deliverables consists of a list, with a brief description, of everything tangible that the project will produce. Depending on the client's technical sophistication, the descriptions will vary in complexity. Hence one client's deliverable may be described simply as a "data model of the inventory application, showing major data entities and their relationships," while another may require "logical data model of the inventory application normalized to Gane & Sarson third normal form." There is little point is showing the second description to the first client, since nobody will understand it, and if you show the first description to the second client, you will be regarded as simplistic.

A word of warning, especially if you are technically inclined: Do not build this list in seclusion. Discuss it with client representatives, and develop it with their active participation. Take the time to review each deliverable with the client, and if you detect any hesitations or areas where there is confusion, lack of clarity, or disagreement, make sure that you resolve whatever the issues are. Finally, get the client to sign off on the deliverables, which means that someone in authority signs his or her name to the deliverable list and descriptions.

Typical Deliverables

Exhibit 3.1 is a list of deliverables that a systems development project might be called upon to produce. Of course, if you are working with a development methodology, the list of deliverables is mandated. If not, the list in Exhibit 3.1 may be useful.

This list is not exhaustive, nor does it apply to all projects. It is provided here as a checklist to stimulate your thinking as to the deliverables your project will provide.

Exhibit 3.1 Sample List of Deliverables

Planning Deliverables

Project plan, charter, or statement

____

Statement of work

____

Cost-benefit analysis

____

List of deliverables

____

Definition of scope

____

Quality plan

____

Work plan

____

Estimate

____

Budget

____

Schedule

____

Project overview and approach

____

Design Deliverables

Logical data models

____

Logical process models

____

Business rules

____

Physical data models

____

Physical process models

____

Data dictionary

____

Buy vs. build analysis

____

(continues)

Exhibit 3.1 (continued)

Acquisition Deliverables

Request for proposals

____

Proposal evaluation procedures

____

Hardware capacity plan

____

Recommendations

____

Maintenance plan

____

Development Deliverables

Code

____

Unit documentation

____

Unit test plan

____

Unit test results

____

Integration test plan

____

Integration test results

____

System test plan

____

System test results

____

Application documentation

____

Implementation Deliverables

Implementation plan

____

Acceptance test plan

____

Training plan

____

Training materials

____

Operating procedures

____

Cutover plan

____

Phaseout plan

____

What If?

The Client Will Not Get Specific, or Prefers To Leave The Details Until Later in The Project.

You risk being surprised by new demands for deliverables or by increased complexity. In particular, you will not be able to establish a scope from which to identify scope changes.

Actions

Create your own list of deliverables with whatever level of detail you need, and document that your estimates of effort and the budget and schedule are based on that list.

As the project proceeds, present the client with design documents, screen and report mock-ups, and business rules that reinforce your list of deliverables.

Treat any attempt to expand the deliverables, either in number or in content, as a change of the scope that you have defined.

The Client Demands Deliverables That The Project Size Does Not Warrant.

You will spend a great deal of effort producing deliverables that have no effect on the project, and you risk the project's being bogged down by acrimony over irrelevant issues.

Actions

Estimate the additional cost of producing these deliverables and their effect on the budget.

Develop an alternative mechanism for providing what each such deliverable provides. For example, if the deliverable is a buy versus build analysis and there is no intention of buying a package, the client might be satisfied by a memo stating that you have considered the option of buying a package and rejected it for reasons presented in the memo.

Present your costs and alternatives to the client. If, after reviewing them, the client still insists on the deliverables, make sure that the budget and schedule reflect the extra effort.