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.
(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).
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: book-review, business-results, ideas, principles, project-management











7 Comments:
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.
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
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.
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.
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
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
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
101 Project Management Uses for Mind Mapping Software
A Little Project Management Anarchy Never Hurt Anyone
AEC Project Management Software: Prolog Upgrade ...
Agile Project Management Software APM: Distributed Visibility ...
Agile Project Management vs. Winging It
Agile Project Management; What's It All About?
Another Great Project Management Framework
Art of Project Management Webcast ...
Art of Project Management: Soft Skills ...
Backed Into a Project Management Corner?
Best Practice - An Online Project Management Framework --
Best Practice Project Management Framework
Branded Project Management Methodology: Service Differentiator
Categorizing Project Management Lessons Learned; Usability is Key
Collaborative Project Management Solution: Distributed Mobile Workforce
Confucius on Project Management
Critical Chain Project Management (CCPM) - The Goldratt advantage
Critical Chain Project Management (CCPM); The Betamax or DVD of Project Management?
Customer Driven Project Management
Earned Value Gone Wild; Exploring New Frontiers in Project Management
5 Tips to becoming a Great Project Manager
Are Your Project Managers Leaders?
Are Your Project Managers Slowed Down by Bureaucracy? Consider Adding a Project Administrator
Be a Project Manager, Not a Project Reporter; Learn the Subject Matter
Can't Retain Your Project Managers?; Here's why
IT Project Managers Seek Business Mentoring
ITProject Manager Alternatives to PMP ...
Management UpSkilling: Project Manager Event ...
PMP eLearning Alliance Drives Project Manager Development
Presentation Skills for Project Managers
Project Manager Development: Business of Innovation
Project Manager Remembers: Good Ol' Project Days When a Project Was a Project ...
Project Manager Salary Report
Project Manager: New PM Discussion ...
Project Manager: Strategic Team Leader: What Are Your Skills?
Project Managers Are Too Soft; Says Neal Whitten
Project Managers Can Influence Without Authority
Project Managers Must be PR Experts
Project Managers Shouldn't Be Afraid to Ask Questions
Project Managers: Stakeholder Expectations Discussion ...
Project Managers: Staying Positive
Project Task Manager Tool for Lotus Notes
Student Project Managers: Shell STEP
Systems Thinking for Project Managers
The Project Manager's Ethical Dilemma
For Well-Rounded IT Project Management - Learn ITIL and PRINCE2
IT Service Transformation Through ITIL Service Catalogs ...
ITIL Certification BTO Software ...
ITIL Helpdesk Transformation: Services Model
ITIL IT Management Processes ...
ITIL IT Service Management Differentiators
ITIL Market Assessment: Podcast
ITIL Microsoft Operations Framework Assessment ...
ITIL Process Approach: Federated CMDB ...
ITIL Process: Run IT Like Business ...
ITIL Project: Cultural Implications ...
ITIL Projects: Avoid Pitfalls ...
ITIL Technology Standard Framework ...
ITIL: IT Service Catalog: Alignment Focal Point ...
Microsoft ITIL Sans CMDB ...
Process Models: ITIL ITGovernance ...
Ready or Not; Here comes ITIL
Siebel CRM ITIL Ready: Helpdesk Capabilities ...
Art of Project Management: Soft Skills ...
Management UpSkilling: Project Manager Event ...
PMForum Announces Project Management Soft Skills Survey
Presentation Skills for Project Managers
Project Management IT Skills Critical, Survey Says ...
Project Management Soft Skills; Communications, Conflict Management, Ethics, and More
Project Manager: Strategic Team Leader: What Are Your Skills?
CA Niku ITGovernance Growth Engine?
Centralized IT Governance: Enterprise Architecture Modeling Tool
COBIT Course: IT Governance Controls Framework ...
Discussion on Distributed IT: Governance ...
Does Architecture Visualization Enable ITGovernance?
EPM Software IT Governance Market Growth ...
From CIO Magazine - A Cry for Full-Cyle Governance
Governance Alignment: Project Portfolio Management (PPM)
Governance Software: OMB A123 Compliance
IT Governance Common Themes ...
IT Governance Integrated Application Development: Software Solution
IT Governance Repeatable Processes ...
IT Governance Road Map ...
IT Governance Role: Architecture
IT Governance Solution: Maturity Acceleration ...
IT Governance Transformation: New York State CIO
IT Governance: Application Services Flexibility or Efficiency?
IT Governance: Board-Level Visibility ...
IT Governance: Board of Directors ...
IT Governance: SAP ESA Strategy
IT Governance: Services Transformation ...
IT Governance: Service Portfolio Management Applications ...
IT Governance: Shift Investment to Business Value Opportunities
IT Governance: The Board ...
IT Governance: Value and Cost Measurement ...
IT Governance; Where the Value of IT is Hiding
IT Savvy: Governance Best Practices: Peter Weill
Leadership and IT Governance
Microsoft IT Governance Woes ...
Process Governance Tool Upcoming ...
Process Models: ITIL ITGovernance ...
Project Management and Governance
ProjectManagement ITGovernanceSoftware Linux Capable ...
SOA and IT Governance ...
SOA Governance: Best Practice Strategies Webinar ...
SOA IT Governance
Software Supports ITGovernance CorporateGovernance