Part 2: REVIEWING AND IMPLEMENTING THE PLAN

   

INTRODUCTION

At this point in the proceedings you have spent all your time planning your project; you have still not set out on the journey. It is not an exaggeration to say that the fate of your project has been, to a very great extent, sealed by the work you may or may not have done so far. If you have applied the steps of structured project management to your project, then you will:

  • Know in intimate detail the goal of the project

  • Have a plan “ very detailed for the immediate future, less so thereafter, but at least showing the remaining important milestones

  • Have identified who is going to be the leader

  • Have assigned the members of your team to the jobs on the list of jobs

  • Have ensured that everyone understands the big picture and how their particular piece fits into the jigsaw

  • Know what everyone is expecting and have some room for maneuver between that and what you plan to deliver

You can now begin the journey secure in the knowledge that you are starting from a secure base, and that you have done as much as you could do at this stage to expect the unexpected. If you have not done some or all of these things, then there is a startling amount of very bleak news for you, which I had better begin to recite. If you have tears to shed, prepare to shed them now. Your project may not fail. After all, life is full of surprises “ that's part of what makes it so enjoyable.

If your project does not fail, then you will have pulled off a major success. You will have succeeded against the odds. I'll bet it won't have been very pleasant and that there were times when it was just awful , and I'd say nobody enjoyed themselves all that much. But if you did it, hats off to you is what I say. I do wonder why you would choose to put yourself and your team through an experience like that. And I also wonder why you choose to do projects in this way, since it can't get any easier from one to the next, never knowing whether it's going to work out or not. Anyway, it's your call and good luck with the next one.

That was the good news. The bad news is that I believe your project is bound for disaster, speeding toward it as surely as the Titanic toward its encounter with the iceberg. Your project will be a disaster and you, as project leader, will have a monumental mess on your hands that will make you wish you had never become involved with the project. Whatever you had hoped to gain from it (money, promotion, prestige, an enhanced r sum , fame, recognition, whatever it was) will be lost in the appalling shambles that lies ahead of you. There are only two possible pieces of advice I can offer you. Either do a proper plan or get out while you are still untarnished.

Assuming you have done a proper plan, with all of the detail that we've stressed so much, then what you have done is you have identified one possible way that the project could unfold. What we are now going to do, in Steps 6 “10, is to make this plan into a self-fulfilling prophecy . We are going to try to force reality to adhere to the plan. And if that sounds as though you would have to have god-like qualities to make it happen, forget it, you need nothing of the sort .

The plan says that certain sets of jobs are going to have to get bitten off every month, every week and ultimately every day. If the jobs are bitten off exactly as specified in our plan “ in other words, if we reach the monthly, weekly and daily targets that our plan specifies “ then the project will remain on schedule. Amongst other things we can use the interaction of our four parameters:

  • functionality

  • delivery date

  • effort (cost)

  • quality

to try to ensure that this happens. Thus, for instance, if a particular milestone has to be met on a certain day, then we can, say, add people (increase effort) or reduce functionality to try to ensure that this happens. If we do this for every milestone, large and small, throughout the life of the project, then the project will remain on schedule, and our plan will indeed turn into a self-fulfilling prophecy. Reality will indeed have adhered to the plan. These comments apply completely too, to cost or budget.

This is what Steps 6 “10 as well as the material in Part 3, about running multiple projects, is all about.

There is another thing on offer here as well. At one point I wanted to call this book "The Lazy Project Manager," but Viki, my editor, wasn't at all keen on the idea. The word lazy is normally used in a pejorative sense, but in this context I intend it to be highly complimentary . The Lazy Project Manager doesn't just have successful projects. She has them by doing the least amount of work possible.

You see, the Ten Steps don't just guarantee a successful project. They also are the least you have to do for a successful project. Mathematicians would describe them as a "necessary and sufficient condition" for a successful project. Necessary because you have to do these things; sufficient because these things are enough, once you have done them you need do no more.

The Ten Steps stop you from fretting about whether you have done enough project management. They stop you from waking in the middle of the night in a cold sweat wondering whether you have missed something. They tell you when you have done enough, when you have done your job as well as it can be done.

In Chapters 6 “10 and in Part 3, I will show you how you become a Lazy Project Manager.

Finally, there is one last use for the Ten Steps worth mentioning. When I first began managing projects, and when I took over or started a new project, the first thing I did was to "read myself in." This involved laying my hands on every document that I could find related to the project, everything related to the technology the project used, and any other background information that seemed remotely relevant. Then I would read and highlight away to my heart's content. Often the stuff was non-existent or out of date, and then you ended up with an incomplete or skewed picture of what the project was all about.

With the Ten Steps, reading-in is at an end. The first five steps tell you exactly what things you need to know:

Where can I find a description of the goal of the project and evidence that the detail in this goal is being developed ( specs , designs, etc.)?

Is there a plan? (If there is you can use the material in Part 4 to analyze it.) Who's leading the project if it's not meant to be you?

Are all jobs assigned to people? Have people's other commitments been taken into account? Where are the potential weaknesses in the work assignments?

Is there contingency and a fallback position? What expectations have been created? How do the goal, the fallback position and the expectations all relate to one another?

APPLICATION TO SOFTWARE ENGINEERING

graphics/application.gif

At this stage you should have the following:

  • a detailed description of the goal of the project (from Step 1)

  • a job list, complete to the first milestone, and as detailed as you can be thereafter, but with the major milestones included (from Step 2)

  • a project leader (from Step 3)

  • an allocation of your team to the jobs on the job list, so that all jobs are covered (from Step 4)

  • some contingency plans (from Step 5) if things go wrong

In other words, you have all the things that a good project plan should have, and you are ready to set forth into the great unknown. Just as a final cross-reference, here's a proposed table of contents for a project plan, into which you could structure all the information you have gleaned by applying Steps 1 through 5.

SECTION IN PROJECT PLAN INFO . FROM STEP
Related documents  
1 Introduction 1
2 Project description  
2.1 Statement of work 1/2
2.1.1 Requirements specification  
2.1.2 High-level design  
2.1.3 Low-level design  
2.1.4 Implementation  
2.1.5 Alpha test  
2.1.6 Beta test  
2.2 Deliverables 1
2.2.1 Software  
2.2.2 Documentation  
2.2.3 Services  
2.2.4 Acceptance criteria  
2.3 Completion criteria (how do we know when it's over?) 1
3 Development plan  
3.1 Work breakdown structure (WBS) 2
3.1.1 Requirements specification  
3.1.2 High-level design  
3.1.3 Low-level design  
3.1.4 Implementation  
3.1.5 Alpha test  
3.1.6 Beta test  
3.2 Work plan 2
3.3 Effort 2
3.4 Schedule 2
3.5 Milestones 2
3,6 Resource loading/project ramp-up 2,3,4
3.7 Budget 2,3,4
3.8 Critical items 5
3.9 Project organization 3,4
4 Resources required  
4.1 People 3,4
4.2 Equipment 2,5
4.3 Training 2,3,4,5
4.4 Other 2 “5
5 Assumptions 1 “5
6 Unresolved issues 1 “5
Appendix A Derivation of estimates 2,4,5
  A.1 Effort and manpower  
A.2 Schedule  
A.3 Margin for error 5

Finally, software projects fail for a variety of reasons, but often they fail just because:

  • things took longer than expected

  • requirements kept changing in an uncontrolled way

  • something came up that nobody had anticipated

  • nobody estimated “ in any kind of a commonsense way “ how long the thing was likely to take or what it would cost

  • technical problems, that nobody had foreseen, caused delays

Admittedly, some of these things can be valid. But often they are presented to cover up an absence of basic planning and forethought. Carry out Steps 1 “5 of structured project management on your project and you give yourself some kind of a fighting chance. If you inherit a project, insist that you be allowed to carry out these steps, and don't be surprised if your management are alarmed at the result.

However, don't you be alarmed. Structured project management provides you with the proof that what you say is true, and anyway, at this point in a project, you have the moral high ground. Hold your nerve and if the project is important enough, they'll let you do it the correct way. This is also true if you are dealing with a subcontractor. Ensure that, at the very minimum, his proposal contains the elements already outlined, and kick him out if it doesn't.

You have done all your planning and your project has hit the road. The next five chapters talk about what you need to do during the journey to your destination.

STEPS 1 “5 SIGNIFICANCE OF PSI AT THIS POINT

graphics/psi.gif

Two points need to be made here. First, you should notice that 70 percent of the PSI is accounted for by Steps 1 “5, the planning steps. If this is true, and all the evidence we have gathered to date suggests that it is, then this confirms what was said earlier about the fate of your project being sealed in the planning phase.

Secondly, the projects we have analyzed to date reveal that 40 is the threshold from the planning steps. What I mean by this is the following. When the project starts, during its very first moments of life, things like the goal (Step 1), the list of jobs (Step 2) and so on will register little if anything in terms of scores. For example, you might have little more than a one- or two-line sentence describing the goal of the project, and this would earn you a score of perhaps 1 or 2 out of 20, if you were lucky. Similarly for the other four steps.

The 40 threshold says that the first things you have to do in the project, the absolutely first things you have to do to the exclusion of all others, are to go through the processes of:

  • Defining the goal in successive levels of detail. (If you think about it, the first few phases of any project life cycle “ requirements gathering, design, and so on “ are concerned with doing precisely this.) (Step 1)

  • Refining the plan as the goal becomes more definite and detailed. (Step 2)

  • Ensuring that one person is driving the project, setting up the project organization structure and installing the processes and procedures that are going to operate throughout the remainder of the project. (Step 3)

  • Getting your hands on people (real warm bodies) and allocating them to jobs. (Step 4)

  • Structuring your plans such that you have a fallback position and a margin for error. (Step 5a)

  • Creating the right expectations. (Step 5b)

In doing these you will gradually raise your PSI scores until they reach the critical 40 level. Until you get to 40, you should be trying to expend as little effort as possible on the project, since you won't be sure of anything like a successful outcome until you get past 40. Also, doing anything else, other than the things mentioned above, is wasting time, effort, resources, money and energy.

   


How To Run Successful Projects III. The Silver Bullet
How to Run Successful Projects III: The Silver Bullet (3rd Edition)
ISBN: 0201748061
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net