Management by deliverables March 26, 2008

Didn’t think I would want to write about this in 2008 but there still are people who don’t get it.   Just did a search on the subject and for all practical purposes I didn’t find anything about “Management by Deliverables”. 

Management by Deliverables is so important.  So lets see if I can convince you to adopt this approach religiously.

Lets take a simple example. Most requirements gathering phase call for a review of existing documentation. Sounds pretty simple so you might think can’t go wrong with that. Well lets look at how not to do it first.

A untrained project manager might simply add a task “Review documentation” to his project plan and assign it to you.  And you will start working hard at finding the documents and reviewing the thousands of pages.  You will be working very hard and will be learning all kinds of useful things.  And then the problems start.

Lets assume you do spend 30 hours reviewing  the documentation. 

How can the project manager be sure you have properly reviewed the documentation.?
How can you be sure you did?
 And how can the client tell if you have reviewed the documentation?
And even if the client does not ask any questions,  what happens if you leave the project or take a day off?

You will quickly notice that people are trying to reinvent the wheel. You will feel like telling them “Didn’t you read the 2004 study”.   

Trust me !  At one point someone will ask to see the ”Review of existing documentation”.    Your client might not realize this. Your project manager might not. But somewhere, someone is expecting to see tangible proof of activities.  Or someone is expecting you to follow a management by deliverables approach.  It might be quality assurance, it might be the accounting department, it might be a new project manager on the client side, it might even be your lawyer at one point.

A better approach
An experienced project manager would have asked that you prepare a document name “Review of documentation”. He would have also provided a predefined table of contents for this document or at the very least would have asked you to produce one and get it approved.  The client would probably have signed of on the TOC at one point and the “Review of documentation” deliverable would part of the Work Breakdown Structure of the project.  The document would have been circulated to the rest of the team to avoid the reinventing the wheel syndrome.  

So lets dig a little deeper in this “Management by Deliverables” philosophy.

Let the deliverables drive the activities
The deliverables drive the activities.  It is not the other way around.  Ask for the deliverables and people will do what is required to produce results. Specify activities and you risk of telling people how to do their jobs.  Not the best thing to do when working with people who probably know more than you about their work.   And because you are not thinking in terms of activities it is a lot easier to create controls for you projects.  A deliverable is either complete or it isn’t. And there are a lot less deliverables than there are activities. 

 Change Management
Activities will change on you all the time. Almost impossible to track.  On the other hand a well defined deliverable should not usually change. 

Why do we need a list of activities?
You might ask where the list of activities fits in.  The list of activities is required for estimating and reflection purposes. Activities take time to complete so listing the activities associated with a deliverable will let you provide an estimate of how long it will take to deliver and a date by which you can produce the deliverable.   You might want to read this article about estimating.

We already use deliverables 
Yes everyone does. But do you “Manage by Deliverables”.  Every project has a list of deliverables to produce. This list is placed in the project charter under the heading WBS.    Where things break down is usually once the project planning starts. In this phase you have no choice but to list activities for estimating purposes.  PMs who do not fully understand the importance of the deliverables approach tend be sloppy.  They ask for reports on activities, they tend to tell you how to do your work, they get caught up in all kinds of quick fixes that don’t really contribute to the deliverables, etc.    I also noticed that they will tend to add activities to a project to solve problems that could be solved at a deliverables definition level.

To take advantage of the “Deliverables Approach” there should be no activities not directly accrued to a pre-defined deliverable.

WBS
The WBS defines the deliverables to be produced. Try not to include activities in the WBS. There are cases where this is acceptable but unless you are scoping expert you will be looking for trouble.   If you don’t take a Management by Deliverables approach you will have a hell of a time scoping your project. 

I could write for hours but do have better things to do.

Hey, I never said you couldn’t manage a project using other approaches.  If you like pain go right ahead.  But never forget that somewhere there is someone that is watching you fumble to get things done.

Gilbert 

Estimates and Precision February 9, 2008

Estimates and Precision

The following example is very interesting because it show how overall precision
increases as activites are broken up in tasks.A project is made up of 4 task. We estimate the time for each of these tasks to be 100 hours, 200 hours, 400 hours and 300 hours respectively. We are pretty sure (99% certain) that our estimates have a precision of plus or minus 30 pourcent.

Total Duration = ______________ ?
Range + ou – = _________________________?

1) What is the estimate for the activities? (X plus or minus Z)
2) What is the precision for the sum of the activities?
3) Note how precision increases with the number of tasks.

Statistical Solution

To cover most cases, we can assume 6 stand.dev = Max – Min.

A 100 hour task varying by 30% represents a minimum of 70 and a maximum of 130.
6 stand.dev = 130-70 = 60 –> stand.dev = 10

Variance = (stand.dev)x(stand.dev)
Variance of a sum is the sum of the variances = 3000

Total Stand.Dev = Square Root of 3000 = 54.7726

We are 99% certain that the total duration will be a value between 1000 – (3*stand.dev) and 1000+(3*stand.dev).

We are 99% certain that the total duration will be a value between 1000 – 164.32 et 1000 + 164.32.

To anwer the initial questions!

1) What is the estimate for the activities? (X plus or minus Z)

1000 plus ou moins 164.32

2) What is the precision for the sum of the activities?
The precision now is 16.4 pourcent.

3) Note how precision increases with the number of tasks.
Starting with a 30% precision on the individual activities we end up with a 16.4 aggregate value.

Although statistics and the real world don’t always agree the above method does represent the best unbiased way of determining the increase in precision.

The morale of the story is don’t spend too much $+time on individual tasks estimates. The total precision is much higher than the precision of the parts.

———————————-

Fully Qualifying estimates is very important. A fully qualified estimate is a central value, a precision and a level of certainty.

I weigh 147 pour + or minus 5 lbs. How sure am I of my estimate. Well, not too sure,
because I haven’t been on a scale for 15 years.

John: How long will it take to setup those machines
Jim: 40 hours
John: Exactly 40 hours
Jim: Between 20 and 60
John: Are you sure.
Jim: Hell no! I am just trying to get rid of you. Paul might not even be here tomorrow. So I guess it could take 80 hours or more.

John knows how to qualify estimates. He comes out of the discussion with more info than he would had he taken the 40 hour estimate as granted.

____________________________________

Estimates (basic principles)
 If we want to meet requirements, deliver on time within budgets, we need realistic estimates.
 GIGO (Garbage In Garbage Out)
 A estimate is a prediction that has as many chances of being to high as of being to low. It is a centered value.
 Each phase requires an estimate for the next phase and one for the total project.
 The people doing the work are not the best to consult for an estimate
 use a range rather than a fixed number
 Use the technique appropriate to the phase
 Use several techniques.
 Revise the estimates as the project unfolds
 Gather and analyse data
 Use common sense
 Add amounts for contingencies (Other costs > 20% is reasonable)
 Qualify your estimates fully by specifying the central value, the range of error and the level of certitude.
Items below Not required for Exam….
 You will often see formulas such as below:
New estimate = (Min + 4*PlusProbable + Max)/6
 Range = (Max-Min)
 3 standard deviations = (Max – Min)/2 certain at 99%

Back to work…