Business Continuity Management/Managing Business Continuity/Project Management
Chapter 3: Defining the IT Project
Overview
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.
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 that there is little point in taking up valuable time asking silly questions.
When you and your team address problems, you focus on technical solutions instead of client needs. If you are to be client-focused, 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.
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 something—anything—fast, and you will come to regard slowing down to talk to the client as a career-limiting move.
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 preamble—costly, 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 that 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
For development projects, what kind of approach the project will take
These are the subjects of chapter 3. A checklist at the end will help you ensure that you and the client agree on the important issues in the project.