Category Archives: Project Management

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 from Wayne Mack on that post was that “the change is not merely to redefine ‘project management’ but to redefine ‘project'”. He is absolutely right.

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.”

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

  • 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.
  • 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”.
  • An agile project generally creates “a unique product, service, or result”; however, that “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.

This definition 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 seen as planning and managing the activities of a project to meet well-defined requirements within expected costs and schedules. Obviously, you can’t do that unless the project has a beginning and an end and the product, service, or result the project is intended to create is relatively well-defined at the beginning of the project.

A more broadly-defined initiative to meet a business goal or objective that doesn’t 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 and may put more emphasis on guiding the people, process, and tools, to maximize the business value that the effort provides.

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 things that are needed to develop a more general definition:

  1. Drop the second statement that a project has a well-defined beginning and an end
  2. Broaden the first statement to include the potential that a project may be designed 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”.

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.

What is Project Management?

I recently saw a LinkedIn post on the subject of “What is Project Management?” that suggested the standard PMI definition of project management from PMBOK:

“‘the application of knowledge, skills, tools and techniques to the project activities to meet project requirements’

I had to respond to that because it seems to me that this classic definition that so many people seem to take for granted is way out-of-date. It seems to be based on the narrow, traditional notion that a project manager is someone who manages the costs and schedule of a project to meet defined requirements. That implies that there is only one way to do project management and that is based on simply executing a project where the requirements have been defined in advance.

We need to significantly expand that thinking to embrace the idea that a project manager may play a role in a much more uncertain environment where the requirements are less-defined and the project requires a more adaptive (Agile) approach that is focused more on maximizing the value the project produces rather than being totally focused on managing costs and schedules to deliver well-defined requirements. The person performing that function may not even have the formal title of “Project Manager”. Many people will claim that is not “project management” because there have been so many well-established stereotypes that have developed over the years about what “project management” is. Here are a few of them:

  • Project managers are very “command-and-control” oriented – Project managers are noted for getting results and sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams. Many times that behavior is expected of a project manager by the businesses that they operate in. In many companies if a project team is underperforming, the Project Manager is the one held responsible and is expected to take corrective action to get the project on track.
  • Project managers are rigid and inflexible and only know how to manage by the “Waterfall” methodology – For many years, project managers have been held accountable for managing the costs and schedules of projects and we all know that in order to meet cost and schedule goals, you have to control the scope of the project. That, in turn, requires a disciplined approach to defining and documenting detailed requirements and controlling changes where changes become the exception rather than the norm. The emphasis on managing costs and schedules naturally leads to extensive use of plan-driven or “Waterfall-style” methodologies that are based on trying to define the project requirements in detail upfront before the project starts and controlling changes once the project is in progress.
  • Project managers are just not adaptive and cannot adapt to an agile environment – Like the other stereotypes, there may be some amount of truth in this stereotype, but it would be inaccurate to generalize and say that this is true of all project managers. Agile will require some considerable rethinking of the project management approach and some project managers are so heavily engrained in the traditional way of operating because it has been so widely accepted as the norm for such a long time that they may have a difficult time adjusting to an Agile project approach.

The definition of “Project Management” should also not be limited to someone who has a title of “Project Manager”. In an Agile environment, “Project Management” functions are often distributed among other roles, but just because they are being done by someone who has does not have a formal title of “Project Manager” doesn’t mean that they are not part of the functional discipline of “Project Management”.

In my opinion, we need to make some radical shifts in thinking about what “Project Management” is – it’s evident to me that the project management profession and PMI, in particular, seem to unintentionally perpetuate these stereotypes by not addressing these basic definitions that are published in PMBOK that many project managers have taken for granted for many years.

Here’s my suggestion for a broader definition of what “Project Management” is:

“Project Management is the application of knowledge, skills, tools, and techniques to maximize the value that the project produces.”

Project management is focused on maximizing business results within the context of the business environment that a project is part of in a way that is appropriate to the nature of the project.

I’m sure that definition could be fine-tuned, but the key point that I’m trying to get across is that there isn’t just one way to do project management and one of the greatest skills of a project anyone performing a project management function should be to select the right approach to fit the nature of the project within the context of the business environment the project is part of. I’m also not excluding the possibility that this function might be performed by someone who doesn’t have the title of “Project Manager” (for example, a Product Owner in an Agile/Scrum project).

Rescuing Failing Projects

Rescuing failing projects is an interesting topic. There’s a show on TV that I really like – it’s called “The Profit” and it features a guy named Marcus Lemonis who goes out and turns around failing businesses. It comes on right after “Shark Tank” which is another popular show – the two shows are similar. The difference is that Shark Tank is primarily about entrepreneur’s who need help in the startup phase of getting a business off the ground where “The Profit” is about turning around established businesses that are failing because of poor business management.

The star of the show is a billionaire named Marcus Lemonis. I think his approach is very unique and is very similar to the approach I try to use in turning around failing projects:

  • Marcus recognizes that there are systemic factors that make a business successful and if those systemic factors are not well-designed and aligned with the objectives of the business, the business is going to have lots of difficulty succeeding no matter how hard people try to make it work. His view of the systemic success factors for a business are:
    • People
    • Process
    • Product
  • When Marcus goes in to turn around a failing business, he usually buys a controlling interest in the business. He tells the people in the business something like “I’m not here as a consultant, I’m here to turn this business around and make money from it”. Sometimes the existing business owners aren’t happy with giving up a controlling interest in their business but he knows that without a controlling interest in the business, he will have a difficult time having the influence he needs to turn the business around.
  • The show has a broad variety of episodes in different situations with different kinds of businesses and it is very interesting to watch the dynamics of the people involved – sometimes Marcus gets into very heated arguments with the existing owners of the business because they are so set in their ways of how they’ve run the business for so long and resist making a change. There are actually one or two shows where he has walked away from a failing business and he wasn’t able to turn it around. Generally, in those situations the existing owners of the business resisted what he wanted to do to turn the business around.

I feel like “the Marcus Lemonis of project management” because I have been called upon to help save a number of failing projects and I have a similar approach for rescuing failing projects – the three systemic factors that I look at are:

  • People – Having the right people on the project where the resources are well trained in the process and technology and a team that is cohesive, cross-functional, empowered, and self-organizing
  • Process – Having the right methodology in place that is well designed and appropriate to the nature of the project and is also well integrated with the client for the project so that the client is fully engaged collaboratively in the process in a spirit of partnership and trust
  • Tools – Having the right tools in place to support the process and people is extremely important to maximize the efficiency of the people and process especially in cases that involve distributed teams that are not collocated and very fast-paced demanding projects

My experience is that many times when a project is failing, people just push harder to make it work by putting pressure on people to work harder and neglect to address these systemic factors that are at the core of making any project successful. The approach I use is based on the notion that if these three factors are addressed and are well-designed, the project has a much higher probability of success and people shouldn’t have to work so hard to make it successful. It’s a case of working smarter rather than just working harder.

This is a good illustration of how an Agile Project Manager is very different from that of a traditional Project Manager. A traditional Project Manager is noted for “ram-rodding” projects and sometimes over-controlling and pushing hard on people to make it successful. That is what is frequently known as a “Death March” project. An Agile Project Management approach is to put in place the right people, process, and tools and not micro-manage the effort any more than necessary to make it successful.

“The Profit” is on CNBC right after Shark Tank; however the episodes are already over for this season and you would have to watch a previously recorded episode to see it at this point. I highly recommend it – it’s one of my favorite shows on TV. You can read more about it here if you’re interested:

The Profit Show