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:
-
Visualize the goal; set your eyes on the prize;
-
Make a list of jobs to be done;
-
There must be one leader;
-
Assign people to jobs;
-
Manage expectations, allow a margin for error, have a fallback position;
-
Use an appropriate leadership style;
-
Know what's going on;
-
Tell people what's going on;
-
Repeat Steps 1–8 until step 10; and finally
-
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 1–5 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 1–4 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 6–10 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:
| 1 |
20 |
| 2 |
20 |
| 3 |
10 |
| 4 |
10 |
| 5 |
10 |
| 6 |
10 |
| 7 |
10 |
| 8 |
10 |
| 9 |
0 |
| 10 |
0 |
| Total |
100 |
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 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 Coping with stress.