Lately I have been working on thinking about the best way to go about project planning, especially in terms of objectives and deliverables. Based on my experience at several companies and some independent research, here are my current thoughts on the subject.
Hierarchy
I’m fairly convinced that in most cases, this is an effective hierarchy to observe:
Objectives >> External Deliverables >> Internal Deliverables >> Activities
Additionally, I have seen some people classify their deliverables by type:
- Project Deliverables
- Usually deliverables to external stakeholders
- Usually deliverables to external stakeholders
- Planning Deliverables
- Management plans, scheduling and budgeting, project artifacts, etc.
- Management plans, scheduling and budgeting, project artifacts, etc.
- Activity Deliverables
- Status reports, meetings and reviews, etc.
I’ve never done this before. Usually in smaller projects the only deliverables that get identified are the “Project Deliverables” specified in the first bullet. I can certainly see the benefit of explicitly identifying the other types though, and differentiating them. It would certainly help when monitoring the health of the project to have these identifying markers available. After all, not all deliverables are created equal. If you miss a status report, it may not be a big deal. If you miss a project deliverable however, you are probably in hot water.
Traceability
Full traceability is important to ensure that the following possible errors do not occur:
- Activities that do not support a deliverable (drop the activity or add/redefine a deliverable)
- Deliverables that do not support an objective (drop the deliverable or add/redefine an objective)
- Objectives with no supporting deliverables (drop the objective or add deliverables)
- Deliverables with no supporting activities (drop the deliverable or add activities)
There are many ways to develop and maintain traceability. Tools exist such as Telelogic DOORS, etc. Alternatively, you could use an Objective-Deliverable Breakdown Structure (ODBS?) to represent this graphically. I’ve used something like this in a spreadsheet format before, but you could easily create a more graphic representation.
Figure 1 is an example of what this might look like. First is a spreadsheet representation, 
and second is the same structure represented graphically. You can see there are 4 project objectives. All of the project objectives have at least one external deliverable, except PO-4. That objective apparently has no deliverable with an external stakeholder. My guess is that would be internal project management processes, such as management plans, etc.
Most of the external deliverables have an internal deliverable that supports them. PD-05 is an exception. This external deliverable requires no extra internal deliverables to support it. This may be a fairly independent external deliverable that only requires one set of activities to produce, without handing off an internal deliverable from one segment of the project to another.
Traceability should go down to the activity level, even if the links are in the background or tools and not displayed on artifacts like these.
Process
Here is the process in more detail:
- Define Project Objectives
- Identify External Deliverables, linking to Project Objectives
- Identify Internal Deliverables, linking to Project Objectives(required) and external deliverables(case-by-case)
- Find gaps or orphans using the links between objectives and deliverables described above
- Make any necessary changes based on gaps or orphans found
- Identify high-level Activities (groups of work packages) for each deliverable
- If activities will be required that do not trace to a deliverable, evaluate if a deliverable must be added to accommodate
- Any added objectives, deliverables, or activities must trace up and/or down the hierarchy
- After all of the objectives, deliverables, and high-level activities are well established, then it is time to start defining and estimating work packages, dependencies, resource utilization, and other scheduling concerns.
Please let me know what you think! How do you go about this on your projects?
No related posts.
{ 16 comments… read them below or add one }
Id be afraid to do all this up frnt. Would be asking for trouble, and if you have the budget to spend all this time defining requirements and WBS, think of all the $ you could pocket by going Agile and learning what you dont know as you go intead of after you’ve done all this work
Nice post. Thoughtful.
Josh
As I understand and have used Agile, it is not meant to get you out of doing anything I’ve talked about in this post.
High-level objectives and requirements are critical, they are the vision of your project.
Some teams turn agile into a checklist they make up every sprint with no other direction except a vague email from an exec to kick it off. I think this is simply wrong. Agile is meant to make the ‘how’ more dynamic and well, agile, but I don’t think it should be used to give people a blank check when it comes to scope. I’ve been a developer on projects like this. It was easy for the team to get lost in ‘cool’ programming and design. Looking back, it seems most of that effort provided very little extra value to the customer. There were times I became unmotivated because I couldn’t see how my work was achieving a project goal. I didn’t even know what the goals were, and if they were valid objectives in the first place.
You can always change the deliverables and even objectives as you go along and the agile methods reveal gaps or opportunities. You would want to do that with any methodology if the change adds enough value to warrant adjusting scope. But it’s a controlled adjustment.
I like your Post, I have done this in the past but I useed to define two general categories:
Deliverables: All Project Management Information (internal and external).
Products: The results of executing the project.
This approach is simple and very easy to understand by not so versed people.
What do you think?
That definitely sounds reasonable to me. In the industries I’ve worked in, the term deliverable is used more frequently when there is something developed that then become an input for another group, etc. But those could just as easily be referred to as products or sub-products.
Josh Nankivel
Great post Josh. So good I have linked to it twice!
What is the difference between your approach and a properly done WBS? And by “properly done,” I mean as described in the 1996 PMBOK Guide, not the DoD-style WBS described in PMI’s WBS standard.
What is a “project objective”? A definition or example would be useful. I never, never, never use either goal or objective because each usually has a very specific meaning to everyone involved with the project, and those specific meanings are often quite different.
I agree with you that project, planning, and activity deliverables is a strange classification system. Doesn’t work for me at all, especially since it suggests that planning and activity deliverables are not part of the project!
Your hierarchy doesn’t work for me (internal deliverables may not tie to a single external deliverable, and depending on how you define project objectives, external deliverables may not tie to a single objective. I would also expect to have multiple levels of each: few projects will have exactly 4 levels along each branch.
Duncan
Bill, thanks for the comments! I’m not familiar with the 1996 PMBOK version of WBS, are there any online links you can point me to that describe it?
This is actually a description of traceability in the contract documents. Our customer had high-level objectives in the contract, and we respond with deliverables that satisfy those objectives. An example of their objective might be “provide configuration management services to the project….” and our response might include several deliverables like “stand up and facilitate the change control board….”, “develop and publish a configuration management plan….”, etc.
Hi
I’m having a debate with my colleague about what a project objective is. My definition that I’m suggesting for our documentation is:
Your project objective(s) is one or more business benefits that you expect to achieve as a result of the use of the outputs created by the project. A project can have more than one objective. Each should be listed as a simple sentence and should be measurable.
She says:
still struggling with this. Benefits are outcomes, not objectives. Objectives are usually the ‘how’
so we will get to the aim by doing these things.
She’s my boss, can someone help by giving me a tight, couple of line explanation as to the best way of describing a project objective.
Cheers
I disagree with her.
Deliverables and the tasks in your schedule to make them happen are the “how”.
Objectives are goals. They should speak to outcomes. They may also contain constraints.
I disagree with her too.
Objectives are the reasons for the client undertaking the project. Objectives tend to start with “To…”.
Deliverables are results the project must deliver so the client can achieve their objectives.
Requirements define the characteristics of the project deliverables.
Objectives (project objectives, in this case) are concise statements that define what the project will achieve. They are written in business terms. I like the SMART approach – Specific, Measurable, Attainable/Achievable, Realistic, and Time-bound.
If you can’t get a sense of the deliverable(s) needed to achieve the objective, it may be written at too high a level. If an objective describes the characteristic(s) of a deliverable, it may be written at too granular a level. If the statement describes features or functions, it is a requirement, not an objective.
Objectives are important for three major reasons.
1. They are in business terms. Once they are approved, they represent an agreement between the project manager and the project sponsor (and other major stakeholders) on the main purpose of the project. The specific deliverables of an IT project, for instance, may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.
2. They help frame the project. If you know the project objectives, you can determine the deliverables needed to achieve the objectives. This in turn helps nail down the overall project scope, helps you identify risks and allows you to provide estimates on effort, duration and cost. Once the project starts, you can validate that all of the work that you are performing will ultimately help you achieve one or more project objectives.
3. They help you declare success. At the end of the project, you should be able to talk to your sponsor to determine whether everything expected in the project objectives has, in fact, been achieved. If all of the objectives were not fully met, you may still be able to declare partial success.
The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives – not the other way around. That is, you don’t agree on the deliverables first and then establish objectives to match. You must understand the objectives of a project and then determine the deliverables that are needed to achieve them. You would then structure the entire project to meet the project objectives.
Josh,
Great post. I can definately use this information. I like that you have both the spreadsheet and graphic showing. My freelance client will be able to relate to and understand project management better when I talk about documents and reports as deliverables.
Josh,
This is really very good aricle for those are new project management and organisations where project management processes are in early state of maturity.
Really good stuffs. Highly educative for a new PM. Thanks to you all.
whats-up! my question is, HOW TO DETERMINE PROJECT DELIVERABLES ? AND HOW TO ESTABLISH SCOPE OF THE PROJECT.
Going through the process of creating a deliverables-based work breakdown structure is the best method I have found. I share the process for you at http://WBSCoach.com
Thanks for the great question!
{ 2 trackbacks }