Home » Process Improvement » How to Gracefully Degrade Your Project Management in a Crisis

How to Gracefully Degrade Your Project Management in a Crisis

It is going to happen. A crisis will ensue, and all that good management stuff we do, some of it will have to go out the window.  Huh?  Shouldn’t we always do everything right, all the time?

Not at all. Some things add more value than others. I’ve often said that I don’t like to do anything unless there are multiple good reasons to do it. However, not all activities add the same level of value.

Not everything we do adds the same value to a project

Planning is a good example. We need to plan everything up front, right?  Ideally … maybe.  Some of my best project successes came from just diving in and doing it–learning as we go. That learning by doing was much more valuable than what we would have come up with in planning without the benefit of also doing.

But we now have a great project management process. Everything is well managed. The quality assurance team says we are following our process with integrity. Nothing can go wrong… until it does.

We will have a crisis in our project

Now, for example, we need to fix a problem at our customer’s site. Our normal process for making a defect fix and delivering a rock-solid update to the customer takes weeks. Oops, that was way too long. They are dead in the water right now. What do we do? Free the engineers to hack away at our customer’s site until it works? No, that is equally scary. The resulting “fix” can be so fragile that as soon as they restart their system, it falls over again (been there, done that). This hacking is, at best, a great way to demonstrate herculean efforts and provide opportunities for people to work around the clock and demonstrate their dedication! But that is about it. It is amazing how many managers and customers, after we’ve done something chaotic like this, sang our praises and forgot the silly things we did to get us into the situation in the first place. But I digress.

We want to do something smart when dealing with a crisis

Instead, we should handle any situation with a high awareness of what we do well and why, and then employ those insights in a crisis. In another tough situation, I had the programmers focus on code quality first. If they changed a line of code, it should work. While we also had steps for planning, analysis, quality assurance, and documentation, these we went light on (i.e., we did them only when we thought they would help) in order to get things done quickly. We went from buggy to rock-solid code, fast, by focusing on what we were best at, which was writing code.

Smart is understanding what it is we do that adds the most value

So, on the occasion where things do go bad and we have to react swiftly, knowing what makes a difference in our team allows us to gracefully degrade the process—skipping steps or spending less time on them than we usually do—and make progress faster. I’ve had some folks argue that if we really do this, then those other process steps were not really needed. I’ve not seen that being the case. Often, I will see that the team is relieved to get back to using these other steps. This is one of the better indicators that a process step is seen to add value.

We go back to the full process when the crisis is over

Once the crisis is under control, we then go back to our full process. It is important again to repeat that this kind of dynamic works best in an organization that knows how they do business. Degrading the process is no different than improving the process or making any other process change. It is done with an awareness of what it means. If our organization is a CMMI level 1 (or other measure indicating low process maturity), then this idea of degrading the process has little real meaning. This is because such an organization may not have the insight to make these kinds of decisions in an effective way. Of course, they still have to make some kind of decision when things go bad, but it can be almost akin to randomness (e.g., “Try this. No, try that. What are they doing? Who told them to do that? “)

Degrading a process uses the same discipline as improving it

Degrading our established project management process is often necessary when a true crisis is encountered. Degrading it gracefully based upon our knowledge of what adds the most value and what can be temporarily suspended can make a huge difference in quickly resolving a major problem.  Not every process step adds the same value, so understanding and smartly suspending such steps can give us the extra time and resources needed to overcome the current crisis and complete our project successfully.

Can you identify process steps that could be reasonably suspended to save time or free up resources in a project crisis?

Thank you for sharing!

4 thoughts on “How to Gracefully Degrade Your Project Management in a Crisis

  1. Bruce Benson says:


    Absolutely. The one humorous catch is when I’ve done this — planned for contingencies/risks/etc. — I was told I was “planning to fail” and that sent the wrong message to the team!

    Of course, this was not a good project organization and they consistently performed poorly.

    The reminder for all is that when we do these kind of things, we can still get well intentioned but unenlightened push back.

    Thanks for the comment.


  2. Hal says:

    This principle is hard to argue against. Regardless of how a project is initially planned, the time will come to trade off priorities because something unplanned has happened. As always, the key is to do this “on purpose” and/or “under control” rather than just tossing out process because you have awakened new urgency. Failing to do this when a crisis arises is just as bad (or worse than) as having poor process to begin with. In my experience, the best process is one wherein you’ve thought of degradation ahead of time, and make the “degradation process” part of your initial process. Then when you need to degrade, everyone understands how to do it.


  3. Bruce Benson says:

    Comments from around the web:

    Andy Rozylowicz • This is a pretty slippery slope, and I think most project managers don’t know how do this in any systematic, data-driven way. In a well-designed and efficient software development process, most of the software development process is about creating the right product requirements, ensuring that is what is developed, and removing the intrinsic defects that are an inevitable part of any creation process.

    There was a comment stream on a very related topic about 6 months ago (trading off time vs. quality).

    Bruce Benson • Andy,

    I argue that “degrading” the process needs to be as systematic as improving one. We are constantly “improving” our processes (though a lot of it does not result in any improvement) and few folks will call that a slippery slope (though it is).

    We also constantly “degrade” but don’t think of it as that (“it has to be ready by Friday!”). Since we do this anyway, we should do it in as thoughtful a way as we do improvements (when they are done thoughtfully). A change is a change and should be managed smartly.


  4. Bruce Benson says:

    Comments from around the web:

    Caroline Duncombe • Bravery comes in all shapes and forms! Rachel

    Bruce Benson • Rachel,

    Bravery is a great attribute, one we need to encourage. Too many good things just don’t happen because the culture makes it hard to speak up or take action. Of course, we also need to work on these cultures, but sometimes if we want to improve things, we just have to take a risk and take action.


Leave a Reply

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

Name *
Email *