One of the things that I’ve noticed over the past few years of working on software delivery projects is that the most challenging projects, the ones that most people hate working on, tend to last the longest yet teach you the most although maybe not immediately.

The problem is that a lot of the time we are in a state of frustration with all the things that are wrong about the project and therefore don’t focus on the things that we can do to make our situation better and improve the chances of the project to deliver.

I came across a really cool video which shows a giraffe going through the five stages of grief on the Kubler Ross Grief Cycle after getting stuck in some quick sand and although there is perhaps not a direction correlation between the emotions that people feel towards a project and the grief cycle there certainly appear to be some similarities to me.

(Graph from changingminds.org - this shows the full cycle although the giraffe video only covers five of these)

The first thing that tends to happen is that we learn that we’re going to be working on a project which has been deemed to be quite challenging by some of the people already working on it but we don’t quite believe it and convince ourself that it’s probably not that bad - in a way we are in denial.

At this stage we still have enthusiasm and are providing lots of suggestions of ways that things can be improved so this isn’t a bad stage to be in since we are trying to have a positive impact.

The problem is that at this stage we might be lacking context on the situations, what ideas have already been tried and which are actually suitable in the given context.

It is useful having people doing this though because sometimes they will come up with a new idea which can help improve things.

The key for the rest of the team here is not to discourage new members too much so that they stop suggesting new ideas because they keep getting knocked back.

I discussed this with some colleagues and it was suggested that a more effective approach at this stage might be to reassess the current situation with the team (including new members) and work out whether there is actually an opportunity to try again to introduce ideas which may have previously not worked.

After a while having gained a better understanding of what is going on there tends to be a move to a stage of frustration and/or anger where we can’t really believe the project is the way it is.

This might be because we think we have a better solution to the team organisation, architecture or methodology being used.

The underlying theme seems to be that a decision was made to do something in a certain way, that decision was (probably) out of our control and we believe that decision is the reason that the project is such a struggle for us.

We seem to move quickly to the next stage where we start to ponder/negotiate small changes which we could have done earlier - perhaps ensuring a different methodology was used for example - or that we should start doing now and will revolutionise the project.

This is bargaining in a way and I think we need to be careful to remember that there is no silver bullet and that (to paraphrase my colleague Rob Hunter) had we taken a different approach there would have been a whole set of different problems to solve instead.

At this stage overly simplistic solutions to problems may be suggested so we need to be aware of this and ensure that we think through the trade offs of new ideas before diving into them.

If we take the time to do this then we can certainly come up with some useful ideas when we are in this mindset.

A stage of apathy or depression at the situation is likely to follow where we feel demotivated because we are unable to be as productive or make the same impact that we normally can.

The symptoms of depression suggest that it can come about either through a loss of interest/pleasure in what we are doing or from a feeling of helplessness amongst other reasons.

I think the natural inclination during this stage is to fall into working on our own and not be as communicative as we were previously.

This might actually be the most dangerous stage because we run the risk of creating a siloed team if everyone is working in their own bubble.

Eventually we decide that we’ve had enough of feeling sorry for ourselves and we finally move to the stage of acceptance where we can start working on solutions to the problems that we can solve instead of focusing on the things that are out of our control.

We can finally start to make things better for ourselves instead of focusing on all the things that aren’t the way that they should be.

I think at this stage we should also be ensuring maximum learning from the situation so that we are able to handle something similar more effectively in the future.

I’m still not sure whether we need to spend time in each of the stages on every project - I imagine that it would be beneficial to get out of the passive states quickly but some time in the other active states might be useful.

The goal is certainly to try and reach the stage of acceptance although that doesn’t mean that we should stop trying to improve the project at a big picture level but instead that we don’t need to get so caught up in doing so that we forget that we still have control over smaller things which can make a difference too.