CHANGES TO THE GOAL AND CHANGE CONTROL

Nobody, least of all myself , is daft enough to believe that the goal, once set, will never and can never change. In the real world we expect that things will have been forgotten, overlooked, appear differently, change or become redundant as the project proceeds. We have no problem with this provided we have a mechanism for controlling these changes.

Any change control mechanism we institute has to operate within the confines of the First Law of Project Management. You already know the First Law; you just may not have seen it formulated in the following way before. The First Law of Project Management states that on any product or system development project there is a function that relates four variables .

These four variables are:

1. Functionality

2. Delivery date

3. Effort (or cost)

4. Quality

The law says that there is a function of these four variables that is constant, i.e.

Function (functionality, delivery date, effort, quality) = Constant.

(And if you want to find out more about what this function might be “ for software “ then you could do a lot worse than reading the book Measures for Excellence (Puttnam and Myers, 1992).)

If you change any one of these variables, then all the others will change correspondingly. We have all seen this effect. For example, increase functionality, let's say by adding a new feature, and delivery date will extend or effort will increase or quality will go down, or some combination of these, for the function to remain true.

Much of what is talked about in this book is opinion ( generally mine), or analysis of some event or situation. This, however, is a law “ a law like, say, gravity. You can certainly pretend that gravity doesn't apply to you. Equally you can pretend this law doesn't apply to you. Both courses of action are about as sensible as each other!

If you believe in the existence of the First Law of Project Management, then it will be your true friend and protector. Pretend it doesn't exist and you will find it the most unforgiving enemy in the world.

One of the immortal phrases from software projects is "we're absorbing that into the schedule." The First Law of Project Management is the reason why nothing can be absorbed into the schedule. Later on, in Step 5, I will show you a way you can pretend to absorb things, but this is all that it is “ a pretence. It is a management convenience as much as anything else, a way of not having to go back to your boss or customer to renegotiate the contract every time a change occurs. But it is a pretence, an illusion. The law operates and you had better believe that it does.

Change control can be implemented very simply using a change control log. This can be nothing more than a folder containing a page per change, and a table of contents (with one line per change) which summarizes all the changes. Each change page basically describes:

• the nature of the change

• an analysis of the impact

• what action was taken

Two sample pages, one for changes and one for the table of contents, are presented in Appendix 5.

Ways of visualizing the goal

So how do you go about visualizing and fixing the goal? Two possible ways are suggested here, one using a checklist which focuses, among other things, on the day the project will end; the other using a method that I like to think of as the and-they-all-lived-happily-ever-after method.

Visualization checklist

• What will the goal of the project mean to all the people involved in the project when the project completes?

• What are the things the project will actually produce? Where will these things go? What will happen to them? Who will use them? How will they be affected by them?

• What will the completion of the project mean to the team as a whole and to each of its members ?

• Why do they want to do this project?

• Why do you want to do it?

• What will life be like on the day/week the project completes?

• What will you do that day? During that week? What will be your routine? Your schedule? Where will you eat? Whom will you meet? What will be the topics of conversation with these people?

• What will people be saying of the project and its deliverables? You? Your boss? The people who worked on the project? The customer for whom you carried the project out?

• What would you like an audit of the project (see Section The reckoning in Chapter 10) to be reporting?

• How will you feel?

• What do you think people will be saying about you? Your boss? Peers? Subordinates? The project's customer? Other parts of the organization?

• What will be your ambitions/hopes/dreams on that day?

• Will your standard of living have changed?

• Will your position within the organization have changed?

• Will your view of yourself have changed? If so, how?

• Do you think it is a difficult task you have set yourself?

• Could it fail?

• How would you feel then? What would you do?

• Will you have power you don't have at the moment?

• Will you have changed as a person? If so, how?

• What sort of recognition will you achieve for this project?

• What would you like to do after this project is over?

• What would the best possible outcome of this project be?

The and-they-all-lived-happily-ever-after method

This method involves thinking of the goal of your project in terms of three mutually perpendicular axes as in Figure 1.1.

Figure 1.1.

The first axis is functionality. Low on this axis means minimal functionality, high means all- singing all- dancing . What are you going for here? A lot, a little, or something in the middle?

The second axis is time. When in time will your project end? Will it end when your product is released? Or will it be when your customers have begun to use it and are sending back glowing reports of it? Or will it be when your product has recouped its development costs and is now generating profits for you? Similarly, for a system development does the project end when the system is released to the users? Or when the users have settled in and become comfortable with the new system? Or when the system has brought the business benefits that were originally set out in the business case? Or when? How you define the end of the project is, to a large extent, arbitrary “ that is, it's up to you. All that is important is that you fix what lies within the scope of the project and what lies outside it; that you know what elements form part of your goal and what elements definitely don't.

Finally, a question that seems to be very seldom asked, but is perhaps the most important of all, makes up the third axis. Projects can have lots of different outcomes “ bad, average, good, outstanding and the whole gamut in between. What is the best possible outcome from your point of view; the fairytale ending, the one that would really knock everyone's socks off? And just who are "everyone"? By everyone I mean the team, your boss and the customer. Given that the project can have all these possible outcomes, why opt for an average, scrape-across-the-finishing-line sort of one, when you could have a great one?

Conceptually, the points you select on the three axes fix a point in three-dimensional space which is the goal of your project. Thinking about these three aspects of your project puts a boundary around the goal and determines what lies within and outside the compass of your project.