Defining Project Success

For decades, project managers preached the mantra of the "Iron Triangle" to project teams and stakeholders: Cost, Time, and Scope, also known as the "Triple Constraint."

Originally posted on enweave as: And Then What?

It is often said that change is inevitable. A friend in the door64 and LinkedIn communities recently posed this question:

"As you know, the real problem is once there are structural changes in an economy or economic system, the "return to normal" never really gets to "normal." Job displacement, under employment, unemployment, regardless of how you say it means that skills are lost to an economy or a region. Then what?"

"Then what" is a really good question in any situation dealing with change -- personal, project, or huge macro shifts in social and governmental areas. Truth of the matter is we cannot forecast all potential outcomes from change -- negative or positive.

This (below) is the response given.

---

Then What: Change

At risk of seeming both specious and simplistic, the answer to "then what" is "change." And, change comes with both positive and negative effects; unintended consequences as well as known and unknown outcomes.

Disclaimer: The term "change" is used here without political implications. It is simply "change" in the dictionary sense.

The one central fact around change at the macro level is that we humans lack the ability to fully understand or forecast its result. And, that's not from lack of effort or rhetoric. We see change in an historical context with 20/20 hindsight but our vision is blurred as we turn our attention to the future.

Lessons Learned

One lesson from history is that becoming locked in a paradigm while faced with a sea change leads to disaster.

Originally posted on enweave: 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