Home » Agile Project Management » People, Process, and Tools in an Agile Project – How to Fix a Broken Project

People, Process, and Tools in an Agile Project – How to Fix a Broken Project

The inter-relationship of people, process, and tools in an Agile project is important to understand. It is particularly important when you try to fix a broken project.

People Process and Tools

Typical Traditional Project Management Approach

On several occasions, I’ve been brought in to rescue a project that was in trouble. In many cases, there is an expectation that, as a Project Manager,

  • I will re-plan the project,
  • Get it on the right track, and
  • Perhaps also”ram-rod” the effort to get it moving through to completion if necessary.

That’s the typical expectation of what a traditional Project Manager might do. If a project fails, it is the Project Manager who is typically held responsible.

People, Process, and Tools

The key to turning around failing projects and businesses is to take a systemic view of why it is failing and look at people, process, and tools.

People, Process, and Tools in a Business Environment

There’s was a show on TV that I really liked – it was called “The Profit” and it featured a guy named Marcus Lemonis who goes out and turns around failing businesses. 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 had 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.

People, Process, and Tools in an Agile Project

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.

  • I’ve certainly seen a need to re-plan projects and get them on the right track and it often takes some strong leadership skills to do that; however
  • A more critical role in many cases in an Agile project is developing the right people, process, and tools to make the Agile project teams more effective and self-sufficient.

The irony is that if you do that successfully, you might practically eliminate the need for a Project Manager and put yourself out of a job, but that’s the right thing to do. I think that’s a key difference in an Agile project. In a traditional project, the role of the Project Manager might normally be expected to continue all the way to the end in order to push the project on to completion.

How to Put This Into Practice

I’ve seen several Agile projects that got into trouble because they didn’t have an adequate amount of upfront planning. And, as a result the project didn’t have the right people, process, and tools to be successful. This happens frequently in larger, enterprise-level projects because many people don’t understand or appreciate what it takes to scale an Agile development approach to an enterprise level. Here are a few examples of typical problem areas I’ve seen:


The first and most important area is related to “people”:

  • It takes a lot more skill to organize a large, enterprise-level Agile project
  • The number and different types of people involved are typically a lot more numerous and complex
  • It can be a real challenge to figure out how to organize all of the people (both inside and outside of the project teams) to get the effort done successfully

Here’s an example:

  • I’ve seen projects get in trouble because there was no Project Governance model defined to provide overall direction to the project
  • In many cases at an enterprise level, its not as simple as having a single Product Owner to provide direction. And, without a plan for how all of the stakeholders and decision-makers will participate in the project as it moves forward, it’s very easy for a project to go off-course and get in trouble


The second major area is process:

  • In many cases, there’s also not a clear understanding of what it takes to scale an Agile process like Scrum to enterprise levels.
  • There are typically layers of management needed above the team level and it has to be well-integrated with the company’s primary management structure.
  • It may not be as simple as layering a Scrum-of-Scrums approach on top of a couple of Agile teams.
  • There is also often a need to define a hybrid process that blends together:
    • Some amount of traditional plan-driven project management at a higher level with
    • An Agile development approach like Scrum at the team level.


The third area that it often important in effectively organizing large, enterprise-level Agile projects is tools.

  • In large, complex enterprise-level projects, tools also can be a major problem area
  • The tools that people many times use for small, simple Agile projects, just don’t necessarily scale well to larger, more complex, enterprise-level projects

For example,

  • People might use physical story cards and white-boards for tracking progress of small, single-team Agile projects but
  • Those methods start to fall short very rapidly as you to try to scale the effort to larger, enterprise-level projects with multiple teams that need to coordinate with each other and may not be collocated
  • Managing that type of situation typically requires more sophisticated, on-line electronic tools

Overall Summary

I’ve been in situations where clients might not have the patience to address some of these more systemic issues involving people, process, and tools:

  • In some cases, there might be an expectation that the Project Manager will just somehow “ram-rod” the project to get it moving and get it back on the right track but
  • Taking that kind of approach and ignoring the more systemic factors associated with people, process, and tools is not likely to be very successful,
  • That’s equivalent to just putting pressure on a broken process to make it work better. A more effective approach in most cases is to fix the broken process.

Related Articles

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

Additional Resources

Resources for Agile Project Management Online Training.

Leave a Comment

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

Scroll to Top
%d bloggers like this: