Should We Strike the Word “Project” From Our Vocabulary?

I’d like to pose the question above in the title. . .  should we strike the word “project” from our collective agile vocabulary?  Before we rush to any hasty decisions, let’s take a look at the facts:

The word project, properly defined by Webster’s Dictionary, means:

  1. A specific plan or design
  2. A planned undertaking: as
    1. a definitely formulated piece of research
    2. a large usually government-supported undertaking
    3. a task or problem engaged in usually by a group of students to supplement and apply classroom studies

Let’s also take a look at the historical definers of such project things, PMI, and see what they say:

It’s a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.

Now, for this specific example, I am going to focus purely on software development but I believe this could stretch across many disciplines and markets.  Most software itself is product based, meaning that a product or product line has a core set of features that make up the intellectual property and value of a said product(s).  Those features are unique but connected functions that need to be improved to increase the value and, in the long run, the market share of the product(s).  As we improve features, we become aware (through many different drivers – consumer, compliance, competition, cognition, change) of even more improvements or features that we wish to incorporate as well as old features we wish to sunset.
This cyclical approach might have a starting plan or design, but is evolutionary and “iteratively recursive” meaning that it builds upon past iterations.  Many times these features start out as small experiments that grow.  Additionally, many features are on a regular improvement schedule and are recurring and routine, but are meant to maintain compliance or incorporate the latest hardware iteration.

As agilists, we are focused on many changes to standard culture – minimizing variables, improving efficiency, reducing lead time (time between when a request or bug or whatever is identified/logged and when the enhancement/fix is provided back to the customer base), creating more consistent and accelerating work, enhancing work life, etc.  Less and less are customers focused on spending “x” dollars no matter what; they are concerned with getting the most valuable product.  Most temporary goals are seen as “drivers” that direct features continually, not simplistic start/stop initiatives.

Why would we, then, maintain terms and titles and concepts that reflect a rapidly diminishing thought process?  I understand that we have maintained certain terminology because it is common and allows non-agile folks to understand what we do, but maybe it is time to educate those on what we do rather than perpetuate concepts that can be in contrast to our efforts.  In an age of correctness, there is a need to call something what it is.  We are not agile project managers, we do not run projects, we are not the top dog on the project team; we help teams either do better and more efficient work or we help organizations identify, organize and prioritize their business needs in a way that teams can consume them rapidly and consistently.  But again, this is just a thought!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.