Four Horrible and Eight Good Ideas in a Project Crisis

In my last post I described a project restart, a simple, generic process for handling a software project when there are too many things left to do a few months before deadline. In this post I’d like to get more hands-on and talk about what actions you might actually consider in this unpleasant situation.

My experience is that some ideas that people consider sound great but are really, really bad ideas. And some suggestions, that many people may be unaware of, could have a positive impact.

Be warned, though! There is no magic dust you can sprinkle on a team to make them considerably faster in the short term. If you can help them become just 10-20% more productive you should feel proud. You have more leverage reducing scope on every level and modifying the system in which they work.

Four Horrible Ideas

1. Add more people (“resources”)

This is the classic, just add more people. It rarely works. Whenever a new person arrives to a team, at least three things must happen:

  1. The new person needs to learn a lot of stuff to become productive. Typically, this takes time, 1-2 months is typical in my experience.
  2. The team needs to allocate time to introduce and teach the new team member.
  3. The team spirit takes a hit and must be rebuilt again.

This makes them fall back even further. Hence, we got Brooks’s Law: Adding manpower to a late project will make it later. This is basic knowledge today, but it’s worth repeating since I still see managers trying to “throw brains” at late projects.

2. Delay the release

Delaying the go-live date may be possible, but often the costs of delay are prohibiting. There is often some business event connected to the date. And even when it is possible it’s demotivating to the team. You will always feel like a loser if you move the ship date, even after you ship.

3. Crunch mode

Going into crunch mode, i.e. mandated overtime over an extended period of time, is just bad practice. Apart from the almost slave-like conditions, pressure, and psychological violence you would submit people to, it makes your product quality suffer. The green pastures of crunch mode may look inviting but only because of all the manure. Defects will grow like weeds. Tired people get sloppy and sloppy people insert defects.

4. Lowering quality standards

Lowering your standards is worth considering for a week or so. Longer than that it costs too much in the long term. You may claim you’ll fix it later, but most people won’t. There are always other priorities then. Often, the software design becomes so injured in the process it cannot be recovered without rewriting most of it. This is expensive so it won’t happen. This will shortens your product lifetime, which means it will need to be replaced in a few years at great expense. Add to that the psychological effects of creating a low-quality product.

Eight Good Ideas

1. Sit together

Nothing breeds collaboration like the time-old practice of working together, side by side. Get everybody in the same room: Development team, product owners, user ambassadors, domain specialists. Everybody. It doesn’t sound like much but afterwards you’ll wonder how you survived so long without it.

2. Borrow specialists

I just explained Brooks’s Law above. Adding people is a bad idea. But consider this: A team where the bottleneck isn’t software programming. It’s more common than you know, but it could be hard to see. It could be that the lack of UX specialists on the team is the reason why lots a stories returning due to UX problems. Or it could be lack of test automation. Or whatever. Adding the missing link to your team could improve your speed, especially if that work is fairly independent from the rest.

3. Move to weekly cycles

Try moving to a one-week cycle, including planning, demonstration/review, and retrospective. This sounds like a lot of meetings, but my experience is the contrary, because each meeting takes less time, proportionally. What I like about this is that the increased pulse will feel like crunch mode although there’s no overtime involved.

4. Active product leadership

Feeding the development beast the right food is hard work. The development team should be the bottleneck now. They should never have to wait for stories, sketches etc to get started. Not only that, get involved in more steps of the process; collaborative design workshops, GUI design, executable specifications, exploratory testing, usability testing, etc.

5. Basic solutions first

No, I don’t want to imply you should be lowering quality. I just told you above. Technically, it should be great. But what you could do is to stop making everything perfect from the start. One thing is to remove all the bells and whistles, stuff that is just nice-to-have.

You can do more. You should avoid everything that isn’t completely necessary before the first release. “Is this really a show-stopper?” is clarifying question I like to use. Look for basic solutions that can be quickly developed and will support basic user interaction.

Teach iterative thinking. Remember it’s not iteration unless you revisit your solution or feature. Refining basic solutions is for after the deadline, in this situation. This is easy for developers to see, but are you sure your stakeholder know this is possible? Many people are used to just having one shot at air time with the team so they may not be used to the idea.

6. Use story mapping

Story mapping or similar technique can be used to find use cases that cover as much as possible of the users’ needs and processes with as few features as possible. Typically, a few scenarios are much more common than many other. If we could cover the most common scenarios we could cover most things users do every day and handle more unusual scenarios after the deadline. This helps with de-scoping.

7. Limit WIP

Work on no more than one or two things at a time. This seems to go against intuition, but Little’s Law explains why. It’s not difficult to understand: Would you like your waiter to serve five tables at the same time, or just yours? He will serve five tables faster by focusing on one at a time than by running between them like crazy. Furthermore, the first table served may give valuable feedback to the kitchen.

8. Deliver frequently

Unless you’re doing this already, this is the time to get started. A crisis is also an opportunity for change. It’s great to be able to say that you are “in production”, even though the product is still not ready for a wider audience. Getting into the habit of releasing something valuable every week will be very beneficial to your team and the stakeholders. Keep piling up the deliveries until the deadline passes. Most of the drama will be gone by then.

Those are some things I’d try. I’d love to hear yours.

One thought on “Four Horrible and Eight Good Ideas in a Project Crisis

  1. It was almost 40 years ago Brooks coined his law. And still nine women can’t make a baby in a single month. No wonder project managers are dissatisfied.

Comments are closed.