Category list

AFTERWORD

DELEGATION (OR THE REAL JOY OF MANAGEMENT)

We only pass through this world once and we are limited in what we can do by the amount of waking hours available to us. We as project managers are in a unique and privileged position: we can use other people's time to accomplish what we want, thereby dramatically increasing the amount of time available to us, and as a result, the things we can achieve.

Think about it. For each person on our team, we have that person's time to harness to our ends. It's like having our own lifetimes extended or even being given multiple lifetimes. We can only make truly effective use of this power if we delegate, passing down as much stuff as we can to our team members .

Use the guidelines in Chapter 17 to surround yourself with the right people.
Delegate as much stuff as you can away to them, following the guidelines in Chapter 7.

Do this as fast as you can trust people to take it. If you do both of these things, you will find your days opening up with time that you can use for all those new things you always wanted to do. Then, and only then, will you experience the real joy of management.

APPENDICES

Appendix 1. ISO 9000 ESTIMATING PROCEDURE

INTRODUCTION

Section 1. WORK BREAKDOWN STRUCTURE, EFFORT, TASK DEPENDENCIES

Section 2. AVAILABILITY OF RESOURCES

Section 3. THE PROJECT MODEL

Section 4. BUILD IN CONTINGENCY

Section 5. IDENTIFY OPTIONS

Section 6. THE PREFERRED OPTION

Section 7. SAMPLE WBS

INTRODUCTION

This document describes an estimating procedure, based around Steps 1 “5 of the Ten Steps, which could be used by all personnel, not just project managers, when making estimates. This procedure could form part of a series of project management procedures which could, in turn , go into a software development organization's quality manual. The procedure has seven sections.

Section 1 shows how to develop a work breakdown structure (WBS) and to use this to make estimates of effort. This is the "demand" side of the project equation.

Section 2 shows how to calculate the "supply" side, i.e. the availability of resources.

Section 3 shows how to match the demand to the supply, thereby building a model of how your project might unfold.

Section 4 shows you how to build in some contingency to your plan.

Section 5 shows you how to use this model to identify options and make sensible decisions about what can and cannot be achieved.

Section 6 shows you what to do once a preferred option has been chosen .

Section 7 contains a sample WBS.

1 WORK BREAKDOWN STRUCTURE, EFFORT, TASK DEPENDENCIES

Produce a WBS for the project

This is essentially a structured list of all the jobs that must be done to complete the project. The list should have a "folded map" format, that is:

All the major milestones shown you can get these immediately from Step 1 in the following section.
As much detail as possible (i.e. down to the manday level) in the upcoming phase.
As detailed as it can be thereafter.

Make the WBS as excruciatingly detailed as possible by milking every scrap of information you have for all that it's worth.

To help you to do this, a sample WBS is provided in Section 7 of this appendix. This WBS follows a general purpose software development life cycle. The WBS is presented in such a way that you could add in your own life cycle elements and WBS checklist elements, gathered from your own experiences over time.

Steps to take

Write down all the jobs in your project and for each job identify:
- which jobs it depends on
- which jobs depend on it.
Present this list in a top-down way with:
- clear start and end points
- a high-level overview, i.e. the (less than a dozen or so) top-level jobs that have to be done to complete the project
- the milestones associated with these jobs
- wherever possible, these jobs broken down repeatedly until the lowest level of detail (i.e. the manday level of detail) is achieved
- For the next 46 weeks, no job should be more than 5 man-days in size .
You can do this with whatever you normally use for writing, or alternatively and far better use a PC-based project planning tool.
Guess and document the amount of effort (sometimes also called work) in each job. Note that it is effort, not elapsed time that we are looking for here. Nor is it the quantity called duration that PC-based project planning tools are so fond of. For each element write down the basis on which the guess was made, e.g. the document has 12 sections, allow 1 hour per section, therefore 1.5 man-days; or "This is what one of these normally takes me" etc. If any data are available from previous projects, use them.

If you feel that you simply cannot guess certain jobs because they are unclear or unknown try first to break them down to lower levels of detail.

When you eventually feel you can go no further in this process, and if certain jobs are still unclear or unknown which they will be then make and document an assumption. Finally, involve the people who will do the work in the estimating process. For that matter involve anyone whom you think might have a valid input.

Enter the guesses of effort for each job onto your list. Document the way each guess was arrived at. Note that this includes documenting all the assumptions you made.

When producing estimates with an individual, the individual's normal working day should be used: no productivity factor should be used. Where it is not known who will work on a particular job, a productivity factor of 20 percent should be used. Thus a 10 man-day task actually becomes 12 days.
Add up all the effort in all the jobs. This gives you the total amount of work in the project. Using manpower rates, it also gives you the project budget, if you need it. This is the "demand" side of your project. All of this should be documented in the project plan.