Tuesday, May 26, 2009

Project Objectives: An Addendum

A few weeks ago a fellow PM, blogger, and tweeter to the Project Managers on Twitter group (Josh Nankivel) posted an interesting and thoughtful piece called "Project Objectives and Deliverables" on his blog (pmStudent).

First a little about Josh. The word "student" in the blog title describes the intended audience, not his qualifications.

..is the founder of pmStudent.com, a site dedicated to helping new and aspiring project managers succeed. He is a project manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. Josh's academic background includes a BS in Project Management and holds the PMP certification.

In this piece, Josh establishes a relationship between project objectives, deliverables, and activities: Objectives >> External Deliverables >> Internal Deliverables >> Activities. It is the response to this from readers that is most interesting.

There is, apparently, a bit of misunderstanding around the concepts of objectives, deliverables, and the WBS (Work Breakdown Structure) within the community of project management practitioners. The comments following the post are worth reading for context as is the piece by Josh that started the discussion: Here.

You may have read my response in the comments if you followed that link but if not, it is posted below. A fairly succinct, straight-up description of project objectives that holds true in Agile teams as well as other contexts. I've added an addendum as well.


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.


Addendum


It is worthwhile noting that objectives, during a project lifecycle, can and do change -- usually through an evolutionary process based on refinement or new knowledge. In addition, internal business or external market conditions may change as well, forcing a re-evaluation of project objectives. A change in objective(s), however, is not as common as other types of change in a project.

If objectives do change, it is a different level of change than, for example, a requirement or user story change modifying a deliverable. Deleting, adding, or significantly modifying a project objective usually means a wholesale, major change in direction for a project. This, among others, is one reason getting objectives right from the start is so critical.

For example, here is a hypothetical project objective or goal: "The percentage of web site visitors converted to paying customers will increase 30% by end of year.

If the percentage within the objective changes significantly, the time limit increases or decreases, or the objective is eliminated entirely during the course of the project , the impact to user stories and deliverables could be quite dramatic.

If objectives are clear and understood, project priorities can be set clearly and intelligently as well. The more a group (team) really understands what their purpose is, the more clearly they can see the way forward. Objectives are critical to self-direction.

Posted by: William W. (Woody) Williams

Add to Technorati Favorites Subscribe

No comments: