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
