Home » Agile Project Management » What is a Project? Do We Need to Redefine It?

What is a Project? Do We Need to Redefine It?

What is a Project?

What is a project? I recently wrote a blog post on “What is Project Management?” that has generated some good comments on LinkedIn.  One of the comments was that “the change is not merely to redefine ‘project management’ but to redefine ‘project'”. That is absolutely correct.

What Is a Project?

PMBOK defines a project as follows:

“A project is a temporary endeavor undertaken to create a unique product, service, or result”. The temporary nature of projects indicates that a project has a beginning and an end.”

How Does This Apply to Agile?

There are potentially several problems with applying this definition to an agile project:

Beginning and End

An agile project may not have a well-defined beginning and end:

  • An Agile project will have an end at some point in time, but
  • The end may be indeterminate when the project starts

Temporary Nature

An Agile project may be:

  • More of an ongoing development effort with an end that is not well-defined and
  • The end, when it happens, may be a long time in the future. That kind of effort might not be considered to be “temporary”

Results

An agile project generally creates “a unique product, service, or result”; however,

  • The “unique product, service, or result” might not be well-defined at the beginning of the project and
  • The goal of the project may be more broadly-defined at the beginning of the project.

The Value of a Project Manager

The traditional definition of a “project” is probably based on how people have seen the value provided by a project manager.

  • The value provided by a project manager has traditionally been in planning and managing the activities of a project to meet well-defined requirements within expected costs and schedules
  • Obviously, a project manager can’t do that unless
    • The project has a beginning and an end
    • The product, service, or result the project is intended to create also needs to be relatively well-defined at the beginning of the project

What is a Project? A More Broadly-Defined Definition

An Agile project may be a more broadly-defined initiative to meet a business goal or objective.

  • It may not have specific, well-defined requirements at the beginning of the project and
  • May not have a well-defined end-date at the beginning of the project probably wouldn’t fit this definition of a “project”

In that situation, the value provided by a project manager is likely to be very different. It may put more emphasis on guiding the people, process, and tools, to maximize the business value that the effort produces.

If we broaden the vision of what “project management” is, we also need to broaden the definition of what a “project” is. There are probably two key things that are needed to develop a more general definition:

  1. A project does not necessarily have a well-defined beginning and an end
  2. The goal of the project may be to satisfy a more broad-based business objective

The new definition of a project would come out something like this:

“A project is a endeavor undertaken to satisfy a broad-based business objective/outcome or to create a unique product, service, or result”.

Overall Summary

If we broaden the definition of “project Management” to embrace Agile as well as traditional plan-driven projects, we must also broaden the definition of what a “project” is as well.

Related Articles

Check out the following related articles on “Agile Project Management”:

Additional Resources

Resources for Agile Project Management Online Training.

6 thoughts on “What is a Project? Do We Need to Redefine It?”

  1. I disagree. Just because your definition of Agile doesn’t fit with the definition of projects does not necessarily mean we should redefine what a project is. There is more than one definition of a project and they are all perfectly valid the way they are.

    The reality is that most Agile methods were not designed with projects in mind; they are designed for PRODUCT development where things are less well defined.

    The answer, Sir, is not to redefine ‘project’ but to consider how to adapt Agile when what you’re dealing with is genuinely a PROJECT.

    1. I think you’re actually agreeing with me when you said “there is more than one definition of a project”. That’s very consistent with what I’m saying. I think you’re probably associating the PMI definition of a “project” with traditional plan-driven projects because that’s what it has been most heavily associated with. The PMI definition of a “project” is supposed to be a universal definition that applies to all “projects” and what I’m saying is that if the PMI definition of a “project” is intended to be universal, it needs to be broadened to embrace other kinds of projects in addition to traditional, plan-driven projects.

      What do you consider “what is “genuinely” a PROJECT”?

  2. As I seem to have kicked this off, let me offer a slight variation of Chuck’s description. The issue is not the definition of “agile projects”, it is the definition of “project” that is in common use in business. The business definition of project does not always align with the PMI definition of project. I happen to believe that agile project management is the way to address this broader range of projects.

    One example might be an O&M Project. The team is funded for a year to work on one or more systems with a list of enhancement requests, bug fix requests, and vague user comments. More will likely be received through out the year. In this case, time and cost are clearly bounded, so the project would be “temporary” even though it is highly likely that it will be refunded next year. The scope of the work consists of lots of loosely coupled pieces and is highly dynamic. I would argue that this is a very common type of IT project as described by business, but one that does not match the PMI definition.

    Another example might be a system replacement project. A team is tasked with replacing an existing system with the guidance that it should be just like the old system only better. The high-level scope seems clear and fixed and an implementation plan and schedule can be developed. The challenges lie in that the detailed functionality of the existing system is unlikely to be fully know and the users are often more concerned with how to use the new system than the actual functionality. This definitely fits with “creating a unique result” and would have a fixed scope, if the original plan is accepted as the scope, but it is usually acceptance by the users that is the true scope of the project.

    At least in my experience within IT, the above types of “project” are far more common than work that would meet the PMI definition. We really need to recognize this broader range of work in the definition of project. Agile project management provides tools and techniques to address these unbounded projects in a far more effective manner than trying to force them into a bounded work model.

    1. Excellent comments, Wayne…I agree. The challenge, as I see it, is to broaden PMI’s thinking about what “project management” is and what a “project” is. In theory, PMI is supposed to be the worldwide organization that represents all types of “projects” and all styles of “project management”. The reality is that isn’t the case – PMI is heavily associated with one predominant style of “project” and “project management” and that is the traditional, plan-driven style of project management. There is a big need for PMI to “reinvent” itself, as I see it, in a very different and much broader context.

  3. This is an interesting discussion. I also am thinking along the same lines, especially after attending the recent DEVOPS Summit at the Javits center.
    In the IT-Software space, what is clear is that in the future Applications will be the be-all end-all, businesses using a continuous delivery model, with the possibility to deliver multiple updates a day. This is especially relevant where the Application is the business (Facebook, Netflix, Google etc…). How does a temporary endeavor apply here? The business is very dynamic. Even to Agile/Scrum, this is extreme. After all, one can view Agile as iterative projects and rolling wave planning, with each Sprint being viewed as a lightweight project.
    What businesses are looking for here is a very dynamic model where they can make quick decisions and respond to market changes as and when needed, possibly several times a day!

    The Application ends up being in a state of constant change, with no end in site except for its retirement. However it is built upon discrete units.

    Does anyone see how projects and project management fit in with DEVOPS? It is clear the skills of a project/program manager are required but they may be performed by someone with a different title.

    Should this project just be assumed to be a Program? It is just a collection of very small projects which are interdependent. It is a PRODUCT that is in a state of continual evolution. Perhaps each delivery is a “quantum project”, still a temporary endeavor though.

    Should we look at this as Quantum project management? After all each delivery is a unique entity, very small and it may have a very short shelf life. As it is very small, it must have a lightweight management approach. I am not convinced Agile/Scrum is as lightweight as it would need to be.

    A good comparison here is with Classical Physics to Quantum mechanics. Classical physics is deterministic, rather like Classical Project Management. Quantum mechanics forces one to look at the world differently and accept uncertainty. Depending on the size and composition of a particle one can choose which model to apply. This applies to project management as well where one replaces particle with project.

    So, in conclusion, maybe we do not really have to redefine what a project is, because in reality each delivery instance has a beginning and an end, all be it some are very small. What is really needed is a collection of models that the business/project/program manager can choose to apply depending on their needs – this will require a well trained and adaptive workforce. And it will also require PMI to recognize that their relevance to the Software-IT space will diminish unless they adapt and change. They seem very slow right now.

    1. Hi Andrew,

      Although it is tempting to define projects as micro-level activities, at least in Scrum or XP situations, it is unlikely that these levels of projects need management. If project management is to survive, at least in the IT or software development world, projects need to be defined at a level meaningful to the business and project management needs to address concerns of the business.

      It is easy to see the similarities between a Scrum Sprint and a Fixed Price Contract – the scheduled duration is set, the labor rate is static so it is essentially fixed, and the scope is defined even though Scrum enthusiasts are backing away from the concept of committing to the scope. If this work is defined as a project, then I would agree that no project manager is needed to manage this scope of work. When we get to Kanban or DevOps, where multiple work activities are running in parallel leading to sequential deployments, the need to manage these activities is zero.

      It is my contention that there is a higher level aggregation of work that does require management beyond direction by a Product Owner. This aggregation is usually referred to as a project, even though the boundaries may be quite fuzzy and not really meet the PMI definition of temporary or unique. We can either create a new term to describe this level of work with its associated management and get the rest of the world to adopt it, or we can modify the formal definition to align with common usage.

      One of the long simmering issues in agile development has been balancing the need for purely technical work (i.e. technical debt) with meeting Product Owner desires. The more effective teams I work with have project manager assuring that the technical needs are met alongside the business needs. Another area, overlooked by agile and mentioned but not addressed in detail by PMBoK is personnel development (“managing resources”). How do we bring new or improved skillsets to the team.

      The challenge is that the more rigid PMBoK definition of project does not match the more fluid definition of project used in business. The result is that project managers focus on areas of concern that are not of interest to the business and overlook areas that are of interest. Either project management must adapt to this new area of management or a new role will arise to address it.

Leave a Comment

Your email address will not be published. Required fields are marked *