What is a Project?

For many years people have been trying to compare projects, created by different organizations, in different situations. Comparisons are found in many reports and polls about best practices, project size and project success. But what is a project? Is all the effort that we put into version 1.0 of a system a complete project? Or do we distinguish different projects when multiple teams have been working on different subsystems? Does the same project include version 1.1 shortly released after the first version? Or do we treat that version as a new project? Can we go to the extreme and aggregate all versions, released over a time span of several years, as one big ongoing project? Or are they necessarily different projects, with project boundaries defined by either major or minor releases? It confuses the hell out of me. Isn’t it strange that, after working in this business for 15 years, I still have no clear picture of what constitutes a project?

I don’t like the word “project”. It’s completely interchangeable with “foo”, “stuff” and “thingy”. I don’t understand anyone who comes up to me and starts talking about some project or other. Sometimes I want to grab people by their shoulders, shake them and ask them “Please… Make sense! Talk English! What do you mean??”

The standard view in other disciplines, like mechanical engineering, civil engineering and electrical engineering, is that a project ends when a product goes into production, and the maintenance phase takes over. This arrangement works fine for motor engines, bridges and devices for erotic electro stimulation. But in software engineering, and particularly in agile software projects, our products are often used long before the projects are considered to be finished. Besides, it is well known that the maintenance phase of a software product often swallows up the bulk of a customer’s budget. This is because, contrary to motor engines, bridges and interesting electrical devices, most software products are never finished. So, what constitutes a project in software engineering? Here are some standard definitions:

• A project is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim. (Oxford English Dictionary)
   
• A project is a finite endeavor – having specific start and completion dates – undertaken to create a unique product or service which brings about beneficial change or added value. (PMI/PMBOK)
   
• A project is a temporary organization that is needed to produce a unique and pre-defined outcome or result at a pre-specified time using pre-determined resources. (PRINCE2)

The textbook definitions do not seem to agree. A project can be either temporary (finite) or endless; it can be either collaborative or individual; it may have complete plans or just some start and completion dates; and it has either a pre-defined aim or it simply allows for any beneficial change. I’m afraid that this doesn’t answer any of my previous questions. It only raises some new ones!

Tool builders have muddled the waters even further by giving the term “project” a technical and context-dependent meaning. A “project” in my development environment does not match with the “project” as it is created in my source control system, because both are organized in a different way. Neither of them matches the “project” as I have defined it in my issue tracking system, because issue management covers a wider area than just code. And the “project” folder on the network drive is different in its own right, because its scope extends to any non-coding initiatives and activities that are in some way related to the system that is under construction. With so many views on our projects it seems like a wonder we are even able to get some working products out the door!

The term “project” is context-dependent, and therefore useless when trying to compare practices, project size or project success across different products and organizations. It might be better if we used something more tangible. Have you noticed how the term “product” has remained undefined by both project management textbooks and tool vendors? It might be because nobody is able to define what makes up your product. It is defined by whatever you decide to deliver to your customers. The product is more tangible than any of the multitude of “projects” that were defined in order to have the product built and delivered. Therefore, when discussing best practices, size or success, I prefer to talk of products. These may be products of specific versions or products of a number of consecutive versions. I do not wish to talk of projects. This enables me to do away with most of the context dependencies, and it relieves me of having to shake my co-workers’ mumbo-jumbo into something meaningful.