Flylib.com

Books Software

 
 
 

Permission acknowledgments

   

Permission acknowledgments

The author is grateful to the following for permission to reproduce excerpts from works indicated.

A.P. Watt Ltd, on behalf of Roland Huntford for permission to quote from Scott and Amundsen by Roland Huntford.

Verso for permission to quote from Judgement Over the Dead by Trevor Griffiths.

Unwin Hyman, of HarperCollins Publishers Ltd, for permission to quote from The Lord of the Rings by J.R.R. Tolkien.

Excerpt from The Fellowship of the Ring by J.R.R. Tolkien. Copyright 1954, 1965 by J.R.R. Tolkien. Copyright renewed 1982 by Christopher R. Tolkien, Michael H.R. Tolkien, John F.R. Tolkien and Priscilla M.A.R. Tolkien. Reprinted by permission of Houghton Mifflin Co. All rights reserved.

Bantam Doubleday Dell Publishing Group Inc. for permission to quote from Voices of Freedom by Henry Hampton and Steve Frayer.

After some time they crossed the Water, west of Hobbiton, by a narrow plank-bridge. The stream there was no more than a winding black ribbon, bordered with leaning alder trees. A mile or two further south they hastily crossed the great road from the Brandywine Bridge; they were now in the Tookland and bending south-eastwards they made for the Green Hill Country. As they began to climb its first slopes they looked back and saw the lamps in Hobbiton far off twinkling in the gentle valley of the Water. Soon it disappeared in the folds of the darkened land, and was followed by Bywater beside its grey pool. When the light of the last farm was far behind, peeping among the trees, Frodo turned and waved a hand in farewell. 'I wonder if I shall ever look down in that valley again,' he said quietly .

The Lord of the Rings

J. R. R. Tolkien

Late in the evening on June 6th, Amundsen came out of his house, shut the door behind him, leaving things as if returning in an hour or two, walked briskly through the trees, and boarded Fram. There was a rattle of chains, the anchor was raised, and slowly she swung out into the fjord. 'Sailed at midnight', ran the opening entry of Amundsen's diary

Scott and Amundsen

Roland Huntford

One writes in a certain sort of way because one is a certain sort of person; one is a certain sort of person because one has led a certain sort of life.

A. A. Milne

   
   

Part 1: ANALYZING AND PLANNING PROJECTS

THE NATURE OF PROJECTS

This book deals primarily with software development projects, although much of what is said here will be applicable to projects in any discipline. In particular, the definition of "project" that I am going to use is that any combination of a noun and verb together constitute a project. Thus, using this definition, any of the following could be a project:

  • be the first person at the South Pole

  • get a promotion and a raise

  • achieve record sales of a new product

  • set up a new business division

  • cost-reduce a manufacturing process

  • build an oil refinery

  • put a man on the moon

  • develop a new computer system

  • build the A-12 airplane

Note that this definition is recursive: it defines the thing in terms of itself. For example, the project "develop a new computer system" in itself consists of a number of projects:

  • develop the hardware

  • develop the software

  • integrate the hardware and the software

  • release the system

Each of these projects can be further broken down. For "develop the software" we might have:

  • identify the requirements

  • do the high-level design

  • do the functional specification

  • etc.

The key factor about projects is that they have a birth, a life and a death. They are not ongoing sorts of things. Identifying the birth, life and death particularly the death are key to the success of a project. In the course of this book I will use various analogies when talking about projects.

The project as a journey

A project is like a journey; it involves identifying a destination, setting out, traveling and ending up somewhere hopefully the place you intended to be.

The project as a state change

A project is all about achieving some goal. The universe is in one state before the project, a different state afterwards, and the difference is the goal. In the examples given previously the destinations/goals/state changes are:

  • a person has stood at the South Pole

  • you have received the promotion and raise

  • you have achieved record sales of the new product

  • the new business division is up and running

  • the cost of the manufacturing process has been lowered

  • the oil refinery has been built

  • a man has landed on the moon

  • the new computer system is available

  • the A-12 is operational

This book presents a methodology called Structured Project Management for handling projects. In the terminology used above, structured project management will help you to identify where you want to go. It will then give you the wherewithal to plan your journey, carry out the journey, arrive at your destination. To put it another way, you will achieve your goal.

STRUCTURED PROJECT MANAGEMENT: THE TEN STEPS

The Ten Steps are the cornerstone of structured project management. They are covered in the next ten chapters of this book.

The Ten Steps are:

  1. Visualize the goal; set your eyes on the prize;

  2. Make a list of jobs to be done;

  3. There must be one leader;

  4. Assign people to jobs;

  5. Manage expectations, allow a margin for error, have a fallback position;

  6. Use an appropriate leadership style;

  7. Know what's going on;

  8. Tell people what's going on;

  9. Repeat Steps 18 until step 10; and finally

  10. The Prize.

I said in the first edition that the first five steps were to do with planning your project, the other five with implementing the plan and achieving the goal. While this is still one hundred percent true, I realize now that there is a deeper, more intuitive reason as to why the steps are structured in this way.

Steps 15 do indeed produce a plan for your project. However, what they also do is to define one possible way in which the project might actually unfold. Let me put this another way. If you build into your project plan the level of intricate detail I am going to ask of you in Steps 2 and 4, then your plan will reflect a possible way that the project could actually happen.

The key to all of this is the word "detail" above. The conventional wisdom is that you can't know much about a project, particularly a software project, at the beginning. This is the I-won't-know-how-long-it-will-take-until-I've-done-it syndrome. I've had people on courses tell me that their plans were criticized for being "too detailed." I've heard somebody say that too much detail early in a project is "inefficient."

This is complete hogwash

If there is a Silver Bullet in all of this, some new development, then it is the notion of catching every fragment of detail that you can as early as possible. Only in this way can you build a possible scenario of how the project might turn out.

In reality, you do something slightly more fancy than producing a single model. You actually produce multiple models.

Let me explain. Steps 14 cause you to build a prediction of the way the project might turn out. One part of Step 5, Step 5a, gets you to build some contingency, or margin for error into your model. This means that, to some extent, things can turn out differently from your prediction, and it still won't be a problem provided the differences are covered by your margin for error. Step 5b then allows for the fact that people your boss, your customer may not like what your prediction says. This again, is no problem. What you do then is to use your initial model to produce a whole series of models. For example, if they are not happy with the existing delivery date, you can say "OK, here's a model showing what we can do by the date you require," or "Here's what we can do if you give us extra people."

This process is described in detail in Chapters 1 through 5. Each step is described individually. In Appendix 1, we combine all the steps into a software estimating procedure that you could (a) use, and (b) make part of an ISO 9000 or other process improvement program in the project management procedure.

Having done this much, what we want to do then is to make things actually happen this way, to make reality adhere to the plan, to turn the plan into a self- fulfilling prophecy . That is what Steps 610 do. And, as you will see, making reality adhere to the plan does not require anything like the god-like levels of ability that such a statement might seem to imply. In fact, you will see that making reality adhere to the plan is one of the most conceptually simple things imaginable.

Thus you get two chances to make your project a success:

  • first, by planning your project in intricate detail;

  • then, by causing your plan to become a self-fulfilling prophecy.

Not all of the Ten Steps are equally important. There is a weighting associated with each step and, collectively, these weightings add up to something we call the Probability of Success Indicator, or PSI. The PSI is an instantaneous measure of how likely or not a project is to succeed. You can read the original derivation of the PSI in Appendix 3. However, I can summarize the weightings as follows :

STEP WEIGHTING (CONTRIBUTION TO PSI)
1 20
2 20
3 10
4 10
5 10
6 10
7 10
8 10
9
10
Total 100

graphics/psi.gif In the chapters describing each of the Ten Steps I will show how that step's individual score is calculated, and how the sum of these scores in turn contributes to the PSI. This will be shown by the "PSI contribution" heading indicated by the icon shown in the margin.

In Chapter 1 of The House at Pooh Corner (Milne, 1923) we come across the following comments by Eeyore, the down-at-heel donkey who inhabits that book:

'It just shows what can be done by taking a little trouble,' said Eeyore. 'Do you see, Pooh? Do you see, Piglet? Brains first and then Hard Work. Look at it! That's the way to build a house,' said Eeyore proudly.

Brains first and then hard work. That's not only the way to build a house: it's the basis for a way to carry out any project. Structured project management follows this approach in that half of its Ten Steps are to do with planning the project, i.e. they occur before the project really gets moving. This reflects a firm belief of my own: that most projects succeed or fail because of decisions made during this planning phase. Many of the case studies in the pages which follow will serve to illustrate this statement. As for Winnie the Pooh, we will return to him again in Chapter 16, Coping with stress.