Problem Solving by Failing

The project runs on smoothly, until one day, you see a problem rising. Maybe it’s something that is clear to someone technically oriented but harder to spot for project management. Maybe it’s something that you have experience of and recognize earlier than anyone else. The first reaction in this case is often to try your best to mitigate the problem before it makes any real harm.

That’s my usual reaction too, but I’ve come to the conclusion that sometimes it’s much better to step away and leave the problem, causing part of the project to fail.

It might sound odd to recommend deliberately failing some work in the project, but it’s actually sometimes productive. That’s because a controlled failure of some part of the project brings attention to the problem. When everybody’s attention is on the problem, it is much easier to point out the real reason that the problem occurred and fix that reason. That’s the real problem that should be fixed.

On the contrary, if you fix the problem yourself to save the project nobody else notices. Even if you tell everybody at the next project status meeting, nobody will probably notice because the problem is too abstract to them. They didn’t experience a failure. If you have the experience of similar situations, you are aware of the potential outcome. That’s why you pay attention to it and mitigates it.

Unfortunately that leads down the one (wo)man mission road. Handling the problem becomes your mission because you know the potential failures. Over time, the other project members will get more and more confident with the current process, because it has never failed. When you get tired of handling the problem and try to get attention to fix the reason that the problem reoccurs, it’s already too late. The process has never failed and thus must be stable. There’s only really good opportunity to handle a problem and that’s the first time it occurs.

When you see a problem coming in a project I think that it can be classified in one of three categories. Each category requiring a different strategy.

Minor, non Reoccurring Problem

A minor problem, caused by a one time only reason is the simplest. Just fix it. If you feel like telling someone you did, that’s fine, but it doesn’t really matter, because they probably don’t care.

Before fixing it make sure it’s so minor that it won’t affect all the other things you have to do today. Also make sure that it’s really a one time issue. If the problem is the result of any kind of failed routines, technical setup etc don’t fix it yourself.

Well Understood Problem

If the problem isn’t minor, or it is caused by failing routines or a bad technical setup it has to be communicated. In the best case, the other project members understands. The project manager will be willing to set a side time for you to fix the real problem. The other project members will be committed to help you.

That’s great. Go on and fix the problem.

Ignored Problem

If the problem is major, or caused by something that has to be changed and it is ignored by the team you have a real problem. You are there, seeing it coming and nobody else care. It looks like they are just ignoring it.

Are they really ignoring it? Isn’t the chance rather that they lack the required technical knowledge, experience or whatever is required to understand the problem? In that case trying to talk about it will just make you a pain. It is in this case I suggest a controlled failure.

A Controlled Failure

To get the maximum attention to a problem there are some things focus on:

  • Make the failure public. To get the best effect, try to make the problem visible in front of the entire project team, including the project manager.
  • Pick a reasonably harmless example. You want to make a statement, not make real harm to the project.
  • Don’t fail something that is your direct responsibility. That will only be embarrassing. If it’s your responsibility, you have to fix it.
  • Make sure that you’ve warned about it beforehand. Send a mail to the project manager where you state what the risk is and what should be done to mitigate the problem. If it isn’t your responsibility to handle it, nobody can blame you for not taking action. But if you saw it coming and didn’t even tell management about it, then you’ll be seen as guilty.
There are also some dont’s:
  • Don’t make something fail in front of customers. You’re trying to send a message to the project team that there is a problem to be handled. You’ve got nothing to win by telling the customers that there are problems.
  • Don’t make something important fail that can’t be repaired. You’re incurring the cost of a small failure to save the project from the larger costs of repeated failures. Make sure that the cost of the failure is significantly smaller than what’s gained by preventing repeated failures.

An Example

I once worked on a project. We used scrum to plan the work. Initially, I created a product backlog to start with from the requirements known. The intention was that I would help another person to get started taking role of product owner and take over the responsibility of updating the project backlog.

It was clear early in the project that being product owner was a hard task for him. I had a hard to time get the appointed product owner even understanding the issues. It was even harder to get him to prioritize the items.

During the early phases of the project that wasn’t too much of a problem because it was very clear what had to be done first and in what order. At each sprint planning meeting I presented the backlog that “we” had created together. I took initiative to picking out the most prioritized items. I saved the product owner from the humiliation of not being able to present the product backlog.

I tried to talk to the project manager about the problem, but it was hard. I had not yet gained enough trust from him to communicate such a sensitive issue. Instead I continued to do the work of the product owner just to keep the project going.

Finally, when I was about to leave the project I realized that there was no way I could get the product owner to take his responsibility. Instead, I sent out an invitation to the next sprint planning meeting, where I clearly stated in the agenda that the product owner and not myself was to present the remaining backlog.

At the meeting I briefly talked about the last sprint and the overall situation of the development efforts. Then I said that “it is time for the product backlog presentation by the product owner”.

Then I fell silent.

The product owner was silent (as I anticipated he hadn’t prepared anything and had no clue about what was in the backlog at all).

The project manager was silent.

The other people present were silent too. We all sat silent for a bit more than a minute until someone talked and brought the meeting out of the dead end.

At that point I was of course helpful in trying to get the meeting moving because I had made my point. For anyone in that room, it was obvious that the product owner hadn’t done his job and didn’t know what to do. It was obvious to the project manager that he had to do something about it, that he couldn’t rely on the product owner doing his work.

I could never have got that message through by just talking. I had to show the problem in person.

I only wish I hadn’t saved the product owner for so long. I shouldn’t have covered up during the months before that meeting. Nobody had asked me to cover up and nobody thanked me for it. Instead I had been in a very challenging situation where I had to take decisions to get the project moving, without really having the authority to do so.

Next Time I’ll Let it Fail

The next time I’m up to a similar problem I’ll let it fail early instead. When I have a product owner not producing a backlog, I’ll go to the sprint planning without anything prepared – deliberately failing the sprint planning. If I do it early in the project, there’s time to catch up.

In the long run it will be of benefit for the project. The failed sprint planning caused by the missing backlog will surely get everyone’s attention. That will force management to take action and make sure that there is a well prepared backlog for the rest of the sprint plannings in the project.

  • Leave a Reply

    Your name as it will be displayed on the posted comment.
    Your e-mail address will not be published. It is only used if I want to get in touch during comment moderation.
    Your name will be a link to this address.
Software Development is a Job – Coding is a Passion

I'm Anders Abel, an independent systems architect and developer in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

Code for most posts is available on my GitHub account.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.