Sunday, July 29, 2007

What is a Project? Think Again!

Max Wideman’s very impressive Comparative Glossary of PM Terms contains 23 different definitions of the word project – all written by very knowledgeable people. Creating a sticky definition of the word “project” (a sticky definition is one that can be easily memorized by a general audience) requires battling the Curse of Knowledge. The Curse of Knowledge is the result of forgetting what it’s like NOT to know what you know. The more you know, the stronger the curse. That’s why truly sticky ideas often come from unexpected sources, and different fields. (Unexpected is one of the Made to Stick principles.) In my opinion, the very best definition of the word project comes from personal productivity guru David Allen, in his brilliant book Getting Things Done. Here it is...
  • A project is any outcome you’re committed to achieving that will take more than one action step to complete.

Why is this a great definition?

(1) This definition is water tight. Unlike the other 23 definitions, I can’t think of a single exception to this definition. (If you can, please post a comment.)

(2) The word outcome covers a lot of PM territory. The word outcome includes the concepts of “deliverables” and “creating unique products, services or results.” It applies to your garage project and it applies to “landing a man on the moon and returning him safely to earth.”

(3) The word action captures an essential element of every project – making progress one discrete step at a time.

(4) The word committed filters out activities that are not projects.

(5) The three key words outcome, action, and committed are simple and concrete (two more Made to Stick principles).

Most of the definitions in Widemans’s glossary define projects as the way very knowledgeable people LIKE TO MANAGE projects, especially large ones. Knowledgeable project managers like clear specifications (or user stories), they like budgets and change control, they like project-friendly cost accounting, they adore network schedules (or iterations), they like to manage risk, they manage resources, they create return on investment in their project portfolio, etc. There's nothing incorrect about any of these ideas, but these XL clothes don’t fit very well on small projects. After all, small projects are projects too, and there are far more small projects than there are large ones!

Example: If we are visiting a science museum (just a casual visit) it is certainly not a project. However, if we are committed to organizing a safe, enjoyable learning experience at the science museum for a large group of Third Graders, our project is the set of actions that we take to achieve this intended outcome. It isn't about abstractions like temporariness and uniqueness. This project does not have a budget, it doesn’t have a logic-driven schedule network, there’s no accounting system, there are no deliverables, we might repeat the adventure every school year, and it isn’t formally risk-managed or resource-managed. But anybody that has organized a major field trip for a large group of kids knows that it is indeed a project! Why? Because it has an intended outcome, it has action steps, and it requires commitment.

David Allen's definition deserves to be in the Hall of Fame of Sticky Ideas.

P.s., Thanks for reader Kurt U. for prompting this post.

Labels: , , , ,

7 Comments:

At 10:23 PM, Anonymous Jerry Manas said...

Garry, good points. Initially, I felt my simple definition of "an endeavor to achieve one or more objectives successfully" covers the territory.

The act of achieving something implies that the endeavor is temporary, so no need to state it. However, there's still a need to differentiate a project from a repetitive process or a quick action.

For instance, if I have an objective to tie my shoes or to write a blog, I'd hardly call those a project (although writing a book may be). A repetitive process on an assembly line isn't a project, although it achieves an objective each time.

Thus, I think we need to address the "size" or "complexity" angle. This may be different than simply the number of actions, although having more than one action may be a good way to designate adequate complexity.

However, the definition of "A project is any outcome you’re committed to achieving that will take more than one action step to complete." still doesn't differentiate projects from grouped initiatives (such as programs) or ongoing processes.

I don't even think risk has to be a component of a project, as I could think of a number of efforts that could be a project without having risk (i.e. cleaning out a garage, for example, unless of course you leave a pair of scissors on the open garage door and then close it and the scissors fall on your head - which nearly happened to me).

As for "success" (which I think should a necessary component of a project, or at least of project management), Merriam-Webster's dictionary defines success as: a favorable or desired outcome. Thus it is up to the project manager to determine what constitutes a favorable outcome. For project success, I like what Max WIdeman has on this website:

Project Success

- Success is achieved when a project has been completed according to all requirements and satisfies the project's Key Success Indicators. [D01523]
PMGdLns
- The achievement of stakeholder satisfaction. [D01524]

Of course, some requirements may evolve, based on feedback from iterations (such as with Agile projects, but in the end, there must be an agreement on what "complete" means, and that ends up as "requirements" and "key success indicators."

This is much better than the short-sighted view of success as "on-time and on-budget."

Let me try one more crack at a definition that may address the singularity of a project, and the size:

A project is a singular, complex endeavor to achieve one or more objectives successfully.

This leaves the interpretation of "complex" and "successfully" up to the organization and the project manager. After all, each organization has a different threshold for what constitutes a project versus a service request, and each project has a different meaning of success.

I'd like to ask PMThink readers add to this post with their thoughts on definitions of a project.

 
At 12:15 AM, Blogger Garry B said...

Jerry, great discussion! I prefer David Allen's term "outcome" over "objective" because one might establish an objective but never turn it into a project. Projects always have discrete outcomes that are implemented with discrete actions.

Think of Management by Objective (MBO). We set an objective, let's say increase revenue and margins by 10%, and then we let the workforce sink or swim with achieving that objective -- somehow. Management by Project (MBP), on the other hand, goes the extra mile of decomposing the objective(s) into a set of intended outcomes (e.g. Project 1 = relaunch our web presence, Project 2 = introduce a new product in July, Project 3 = retrain our Eurasia sales force.)

Our definition does not need to differentiate projects from programs, because programs are simply a set of related projects. The definition of a program can do that by itself.

What filters out tying my shoes and writing a blog entry is (a) the word "committed" and (b) the fact that multiple discrete actions are required to achieve the intended outcome. Writing a book does require those things, so it is a project.

David Allen's definition also includes the word "achieving" which I think is sufficient. Achieving intended outcomes is perhaps more objective and concrete than achieving "success" on an objective. Did we relaunch our web presence? Yes, outcome achieved. Did we introduce a new product in July? Yes, outcome achieved. Did we retrain our Eurasia sales force? Yes, outcome achieved. Were we successful on our revenue and sales objectives? Well, hmm, not really, because of the Asian economic slowdown and other things beyond our control, but we held sales and margin steady, unlike our competitors, so maybe we are successful and maybe we're not.
/Garry

 
At 3:11 AM, Blogger Anuja said...

Hi

We are looking for Industry professionals who write on IT, ITeS or related Industry. We would be interested in talking to you. Can you please send us your email at Invitation.thinkingstreet@gmail.com

Thanks Anuja.

 
At 8:42 PM, Anonymous Jerry Manas said...

Anuja, I can barely keep up with my current committments, so I doubt I'd be able to add any additional ones. I appreciate the offer though. I'd be glad to chat about a link exchange. My contact info is on my profile.

Garry, once again, valid points. David Allen's definition is growing on me. You raise a key issue about success. A project manager should ideally identify success factors relevant to the project that are achievable by the project.

An "outcome that you are committed to achieving" probably addresses that, assuming those success factors have been identified as outcomes (and that the outcomes don't only represent tangible deliverables).

Your point about unforeseen circumstances is interesting. What if you have a project to construct a library, and it gets destroyed by an earthquake before it's completed. Is the project a success? I'd say no, even though it was no fault of the project manager. However, it was still a project (albeit an unsuccessful one), so "success" probably should not be in the definition of a project.

In your example, there are some valid successes and other elements that weren't successful because of external events. Thus success is relative. That may indeed be a successful project if that is what is agreed.

The key point is: David Allen's definition makes no promises of success, only the committment to achieving the outcomes. That may be a more realistic approach.

 
At 8:02 AM, Blogger Garry B said...

Jerry,
I agree.
Notice that if we are "committed to achieving" the library completion, it is a project, even though the library was never delivered. David Allen's simple definition is very robust.
Where (and when) is the best place to define (and communicate) what constitutes success? Side note: we're drifting into "project management" here, as opposed to the basic definition of a project, but that's great.
/Garry

 
At 1:47 PM, Anonymous David Allen said...

Garry, Jerry, delighted to get a glimpse into your world and your thinking about this. At the risk of being somewhat simple on this whole topic, what's missing for me is the answer to "what's the purpose?" relative to deciding what the definition of a project is. My purpose was simply to get people to identify commitments they have that they'd better keep track of, in order to feel OK what they're doing (and not doing) about them at any point in time. If you can finish something in one sitting, with 99% surety, then, sure, no need to call it a "project." But if you're likely to NOT finish in one sitting, and get interrupted before the commitment is complete, you'd better have some stake in the ground that will remind you of that "open loop" - otherwise your psyche will have to be tracking it instead of your system (which is the curse of knowledge workers who haven't yet trained themselves to keep it all objectified and out of their heads).

Also, my simple definition puts the onus back on each of us to identify those kinds of outcomes that people seldom call "projects" but which really are. E.g. "Get kids onto cruise control for the new school year" and "Handle dad's elder care situation."

Thanks again, Garry, for letting me peak into your world here.

David Allen

 
At 10:07 PM, Anonymous Jerry Manas said...

David, great to hear your thoughts on this. I think "what's the purpose" is a very valid point. I always say that's the main thing we need to ask when managing projects, so I suppose it should be no different when trying to refine the definition of a project.

First, I agree, there are many efforts that should probably be managed as projects, but are usually not. It's up to people to determine which endeavors will benefit from a project approach. If the definition can help distiguish those efforts, either through a threshold of project size, project complexity, or as in your definition, number of actions, that may help.

I'm probably not as concerned about the definition per se, as much as I am about the lack of focus these days on value. It seems too much attention is directed inward toward controlling specific activities and delivering work on-time, on-budget, and on spec (never mind if the work is actually supporting the intended outcomes). That's why I like the idea of including outcomes in the definition.

If we focused on managing outcomes, as Garry had suggested in line with your definition, and leveraged the collective intelligence of people to achieve the actions necessary to support the outcomes (only controlling those actions that must be controlled), we'd be much better off.

 

Post a Comment

Links to this post:

Create a Link

<< Return to PMThink! Project Management Gateway