Stop Starting and Start Finishing

Have you ever seen an airport where the tarmac was so full of airplanes that there’s no room for another airplane to land? I haven’t either. The reason is that airports plan takeoffs and landings so that every day, the number of takeoffs and landings are roughly the same. Could this concept help a struggling PMO manage the flow of its projects?

One of the areas where I see this lack of maturity is when there are no policies for when a new project starts. Every project is a #1 priority and an emergency, so almost every new project is started immediately, even before the business case and requirements are completed.

It’s as though organizations have an addiction to starting work instead of finishing work. I see different nuances of this on the business side and the IT side. On the business side, the thinking is often, “The sooner we start a project, the sooner we’ll finish the project.” Thus, there is a culture of demanding that IT start new projects immediately, even before the business case or requirements are completed. At the same time, IT genuinely wants to support the business and not let people down, so they’re motivated to always say, “Yes! We’re working on it!” This cultural paradigm leads to a reality where many projects are in progress, and many people legitimately can’t remember the last time that a project was actually completed.

While there are many practices for getting work done more quickly, by far, the most effective practice is to limit WIP (work in progress). I began to talk to people about “Stop starting and start finishing” or “Favor finishing over starting.” I used a few different metaphors, including that of a marathon.

Marathon 01

People agree with this concept, but quickly dismiss it. After many conversations, I finally found the missing link: People couldn’t picture in their minds what it would actually look like to “Stop starting and start finishing.” I had to find a way to show them what it would look like to limit their WIP, to “Favor finishing over starting” so that projects could actually make it across the finish line.

Here’s What We Did

We had already put all of the projects on an EPMO Kanban board and prioritized them. Of course, since every project on the Kanban board was in the “In Progress” column, we were only able to prioritize projects that were already in progress.

Mountain 01

We already had a solid foundation with the enterprise Kanban board and project prioritization and the next step to reach our goal was to consider how we could limit our WIP.

Coin 01

If we’re really going to prioritize some projects so that they get done more quickly, the only way that can happen is if we limit work on other projects. Conversely, if we’re getting overwhelmed and need to limit the amount of work in progress, the only way to do that is to prioritize the work so that we can identify the low-priority work to put on hold.

Airplanes 01

Airports must limit the number of airplanes inside the airport, or eventually bad things will happen. Like an airport, if we don’t limit the number of projects in progress, what bad things could happen to us?

Kanban 01

Letting work pile up in the “In Progress” column, results in overburdened people, constant context switching, and projects getting completed much more slowly. What would happen if we let projects pile up in the “Approved Business Case” column instead? If doing this, there would be fewer projects in progress. The WIPs would get done more quickly because the teams would be focused and not constantly switching priorities. Then when IT has capacity, they would pull the highest priority project from “Approved Business Case” into “In Progress.”

Key practices that helped this be successful:

  • Visualize work
  • Start where you are
  • Powerful questions
  • Evolutionary change, not revolutionary change
  • Limit work in progres
  • Make policies explicit
  • Improve collaboratively

How would IT staff feel if they weren’t constantly switching priorities? If people become less overburdened, how would it affect the quality of their work? How much trust would you need to have with IT to let them tell you when they have capacity for more work? If the number of works in progress is limited, it results in less overburdened people, increased project quality, and projects getting done more quickly.