Defining “Project”

According to the Oxford dictionary, a project is “an individual or collaborative enterprise that is carefully planned to achieve a particular aim”. According to Project Management Institute (PMI) a project is “a temporary endeavor undertaken to create a unique product, service, or result“. These two definitions are both good, although I have to admit that as a former PMI executive I’m biased towards PMI’s definition. The interesting thing about projects is that they are temporary, with a beginning and an end – therein lies the rub.

We Do a Lot of Non-Project Work

Look around your organization at what it does. Some of the efforts are projects yet many are not, such as:

1. Your IT help desk. Requests for assistance come in all day long. Support engineers pick up a request, address it appropriately, and then move on to the next one. This is a continual, ongoing effort, it is not a project.
2. Product development and evolution. The most appropriate strategy for bringing offerings (products or services) to market is via long-standing teams, not via teams. Yes, many organizations still choose to accept the risk and overhead of projects for the initial development of an offering, but quickly discover that they need a long-standing team for evolution and operation of that offering. This has become a clear trend in the software world in recent years, and is well captured in Mik Kersten’s book Project to Product.
3. Strategy. Your organization’s strategy efforts, I hope, are an ongoing effort performed by your executives.
4. Process improvement. Similarly, process improvement, at least in healthy organizations, is an ongoing journey that never ends. Although transformations are often naively started as a project, you quickly discover that the change management efforts required are a long-term, ongoing iterative effort.
5. Vendor management. Your organization’s efforts to identify, contract with, collaborate with, partner with, and govern various vendors/suppliers is also an ongoing effort. Sometimes you may choose to organize the procurement of a large contract as a mini-project, but that would only be a small portion of your vendor management work.
6. Your project management office (PMO) efforts. Here’s some irony for you, the work of a PMO is an ongoing effort, it is clearly not a project.

Those were but a few examples, and I’m sure you have many more. The point isn’t that we don’t have projects, rather, it is that we’re dealing with more than just projects.

Projects are One Type of Initiative

An initiative is an effort to achieve something of value. Initiatives will have a beginning but may not have a foreseeable end. Initiatives include:

1. Projects
2. Product management efforts (development, evolution, operations, …)
3. Business operations
4. Technical operations
5. Services provided to others

Words Matter

I see PMOs that are conceptually hobbled because they want to focus on projects rather than on delivering value. When a PMO only focuses on projects, they ignore a lot (and often most) of the value-added effort within their organizations, limiting their scope and effectiveness. Worse yet, when a PMO has the mindset “everything is a project” they invariably inject needless risk and overhead into many initiatives that can be better supported by a long-standing team or an impromptu team rather than a project team. The book From PMO to VMO: Managing for Value Delivery provides great advice for how PMOs can evolve beyond the project mentality to focus on adding real value to their organizations.

I read a lot of articles and books about software development that use the term “software project” yet most software development is performed outside the scope of a project. Instead of calling it a software project, call it a software initiative. Similarly, call it a team, or a software team, not project team. Use the term project if you explicitly mean project, otherwise don’t needlessly add that constraint.

I also see people use the word “project” as a short form of “project team.” In fact, I’ve done this myself in most of my books. An example of this mistake can be found in one of the most important writings in software engineering, the Manifesto for Agile Software Development. The authors of the agile manifesto use the word project throughout the 12 principles where they were referring to teams. This is a reflection of the project-oriented culture of the time, a culture that the manifesto was clearly pushing back against.

My Advice

Here is my writing style advice:

• Use the word initiative to refer to a general endeavor because it is more inclusive than project.
• Use the term project if you explicitly mean project, otherwise avoid it because it needlessly constrains your thinking.
• Use the word team to refer to the group of people working on the initiative.
• Avoid using project as an adjective, as in “project manager”, “project team”, or “project plan” unless you explicitly want to restrict the given term. Many endeavors start as projects but evolve into a more general strategy, although the people and artifacts involved remain the same. For example, Sally Jones remains the manager although it’s no longer a project that she’s managing so referring to her as a “project manager” isn’t appropriate.

Throughout my writings I do my utmost to use the term initiative, and sometimes “effort”, rather than project. When I use the term project it’s because I specifically mean project.