Ambysoft logo

Why I Use the Term “Initiative” Rather than “Project”

Follow @scottwambler on Twitter!

In short, the term project is too narrow given how it is used in practice. Not that there is anything wrong with the concept of projects, they certainly have their place and will do so for a long time to come. But they’re not the only game in town, nor have they ever been.


Definining "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 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:

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.