What is the generally-accepted definition of a "software project?"

Question

One of side discussions here on PMSE brought me to this: what exactly do we understand when we say "a project?"

The most obvious thing is to start with Wikipedia definition:

A project is a temporary endeavor, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables), undertaken to meet unique goals and objectives, usually to bring about beneficial change or added value.

However this brings me to another problem: using this definition in orthodox way would make many ventures, well, non-projects. Consider Google search as an example - its development isn't constrained by date or funding or specific deliverables, yet my guess is no one would deny it is a project.

Also, many R&D projects don't suit the definition well. Same with many startup projects which change rapidly along with their constraints.

Then, even if we think about "classic" software projects, when exactly do they end? I mean there's maintenance and operations and such and you can treat it as a part of a project or not. If the former is true we come back to constraint problem - how long is the venture going to last?

So what would be a common definition of a software project?

Note: I didn't try to make the question cross-industrial as that would be even more difficult to define, so let's stick with software.

Answer 1

Defining "Project" from a Practical Point of View

When I'm speaking as a project manager, a "project" is a formalized process with a defined goal and an attendant methodology. One can argue about how well-defined the goal should be, how formal the process ought to be, or how rigorous the applied methodology may be, but you can cut through a lot of fog by saying that any project isn't being actively managed to complete a finite goal is simply not a project from a PM perspective.

For example, ongoing technical support would not generally be considered a discrete project. On the other hand, forming a team tasked with delivering an embiggening feature for your therblig generator by the third quarter of next year fits the PM-oriented definition of a project rather well.

A Flexible Project Still Has Finite Goals

The original question states:

Google search...isn't constrained by date or funding or specific deliverables...[and] R&D projects don't suit the definition well. Same with many startup projects which change rapidly along with their constraints.

Firstly, "Google search" is not a project. It's a product line, a mathematical endeavor, and a business model. However, I'm sure that Google has many search-related projects, including R&D projects, that are being actively managed internally.

In my opinion, thinking of R&D as "not a project" is a mistaken viewpoint. R&D projects do have goals, even if the goals are exploratory in nature. I've never heard of an infinitely open-ended R&D project with no objectives, time or resource constraints, or a complete lack of process or methodology. In fact, research by its very nature requires rigorous methodology if the results are to be meaningful.

Likewise, any project can be redefined, refactored, or re-envisioned along the way while still clearly being a project in the PM sense of the word. Agile projects are explicitly designed to do this through the application of a defined methodology and various inspect-and-adapt processes.

Lack of flexibility in delivering business value should not be the hallmark of a project, although when 68% of projects fail (often through ossified processes, in my personal experience) one could certainly be excused for confusing inflexibility with "project management."

Answer 2

PMBOK Guide 4th Edition, page 5:

A project is temporary endeavor undertaken to create a unique product, service, or result.

Google Search is a product, created by some project. Every new version of Google Search is a new service to the original product. Maintenance, for example, is a service.

Misunderstanding of 1) temporary nature and 2) uniqueness of deliverables leads to misunderstanding of project management triple constraint. It's mission critical for a project manager to separate project from its product.

Answer 3

I believe that the IT / software industry is guilty of using terminology in an imprecise manner to suit itself - which is ironic, when you consider how accurate a developer must be when writing code!

For me, a project is defined by its original, baselined scope, with variations to the scope having to be agreed by appropriate governance. Perhaps that's the Prince 2 training kicking in!

Very often, we use the term "project manager" to mean "the manager who once ran the project but now is responsible for all aspects of the system and will remain in this position until either he or the system dies". That is not project management. It may be commonplace: it may even be what your organisation wants; but it is not project management in any formal sense.

If you want the project to include handover to operations / support, write that into the project scope, and close the project once the scope has been completed. If the same manager takes care of the work afterwards, that's fine, but recognise him as the in-life manager, and no longer the project manager.

Answer 4

While both yegor256 and Iain9688's answers are great and complementary, I'd like to add my two cents worth.

Have you ever seen an endeavour that was not limited by any type of constraint?

Just to take one example, even google search is limited in resources. Sure the limit is quite high in the present day, but they had to start out with small budgets like everybody, and deliver tangible results with those tight budgets. The fact that their budget is likely to be huge nowadays does not abstract them from harsh reality. To be a successful business they still need to produce results in a fashion that consumes less than it brings in, in a timely manner. This can only be ensured by setting milestones for specific deliverables to be developed within a given timeframe with a limited amount of resources. To you some of those constraints might appear so large that they do not exist, but to the business that sets them they are very real nonetheless.

Like others have said your product or service may not have a theoretical end of life (although even that is a rare thing - technology advances and changes generally take over at some point or other, so watch your competition and market advances). But to make your product or service evolve, you need to set targets to reach. The act of reaching for those targets is what a project is about. The art of going about this act is project management.