If the end (date) is forever sliding intentionally, is it a project?

Question

I have this struggle in my mind, on how to define projects, and how much can I (we) stretch the definition of a project.

A rough, simplistic definition of a project would be "an endeavor taken in order to achieve a certain goal". And this kind of definition (somehow) implies the idea that a project always has an end (date).

However, running a business is done with "the same" knowledge of management, but at another scale. And all the activities of the business can then be seen as sub-projects (especially including the activities which are projects undoubtedly).

So, the bottom line question is, is it OK to consider that some projects have no end (date)? Or, with different words (or different point of view), is it OK to consider that some special projects have a (forever) sliding end (date) intentionally?

I am especially interested the "why not" explanations. My attempt is to mentally "unify" project management and business management in a way that makes sense. They are both based on the same science of management after all.

Note: to give a sense of time-framing, the farthest milestone can be considered the "end of the project". A company without clear milestones will end quite soon, I guess, anyway - so they are out the scope of the question. As long as new milestones and targets are added, the project's end moves ahead in time.

Answer 1

The PMI's definition of project, from "A Guide to the Project Management Body of Knowledge, 7th Edition" is:

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

I don't see an implication of an end date, but there must be an end because a project is a "temporary endeavor". I don't see why you can't define the end as being when a particular goal is reached (or becomes obsolete or impossible to reach), expending a defined level of effort regardless of how many calendar days it takes to expend that effort, or a fixed date.

I would struggle with a definition of a specific project that did not have some defined end point, whether it's a date, a goal, a level of effort, or something else. If you cannot say what event or condition causes a project to conclude, I don't know if that meets the intention of a temporary endeavor.

If you don't have a temporary endeavor, you may want to start looking at product management and service management instead of project management. At a high enough level of abstraction, it may appear that project management, product management, and service management share a lot of the same activities and processes but going into more detailed views will show differences in practices, techniques, and tools.

Answer 2

What is important about language and your choice of words is how your audience interprets and understands what you are trying to communicate. It matters far less what your interpretation is as you encode a message. If in your mental model you equate projects with operations, tasks, and activities, have at it; however, if your audience is confused, you might want to change your language.

In my view, an operation has an indefinite finish. There are certainly milestones and there are similarities to managing operations as one would manage a project but the indefinite finish is what separates it from a project in my interpretation.

A project has a finite finish, a definition of done.

But at the end of the day, it only matters how your audience decodes your message.

Answer 3

Projects ultimately matter very little. The products / value streams that they create, adapt or influence are what matter. Manage the product, not the project, would be my advice. End the project at the point where it becomes a distraction from delivering value - which may be even before the project has started.

Answer 4

It is "your company" that has no end date, the projects of your company should have end dates. The sprints in Scrum have end dates as well.

If "project" is not the right form of your increments, you can use Kanban methodology for example; Kanban does not enforce time-boxed increments.

Answer 5

Words have meanings, so if you accept the normal definition of a project as being having a defined outcome, then by definition it must have an end. If you want to create an alternative definition that is used within your business to mean an ongoing task or set of tasks, then that's fine - but don't expect people from outside your business to understand it.

I once worked in a business where each financial month end was considered to be a project, as it was defined, had a clear outcome, and was time-bounded. In that sense, that was a valid use of the word "project" in my opinion.

Moving into a different area, most people think of a car as a mode of transport for (normally) up to 5 people - with a few exceptions for large cars. But if you choose to define a car as any mode of transport for people, regardless of the number - and that definition is accepted within your company - then as long as you are clear about the definition and don't try to use it outside the company, then a bus, a train or a motorcycle could be considered (by your definition) as a car. It really does come down to what you and your colleagues understand, and whether you want to use that definition more widely elsewhere.