Are you, or your project team suffering from the symptoms of project fatigue? In this article I am going to provide you with a fresh perspective on this all-too-common problem, along with some ways to get your project back on track.
I recently re-read “Zen and the Art of Motorcycle Maintenance” by Robert M. Prisig. It was written in the 1960’s, and has remarkably little to do with motorcycle maintenance, and everything to do with the philosophy and meaning of the word “Quality”. The book is structured around a series of lectures (Pirsig calls them Chautauqua’s) that the author narrates to himself whilst riding across America with his son. In the spirit of the book, I’d like to present a Chautauqua of my own about Project Fatigue.
There is a section in the book that often comes to mind when I am trying to do something hard. It is one of the rare sections, where Pirsig directly addresses motorcycle maintenance. Pirsig makes the claim that “if you’re going to repair a motorcycle, an adequate supply of gumption is the first and most important tool”, describing gumption as “a reservoir of good spirits” which “is the psychic gasoline that keeps the whole thing going. If you haven’t got it there’s no way the motorcycle can possibly get fixed. But if you have got it and know how to keep it, there’s absolutely no way in the whole world that motorcycle can keep from getting fixed”. Putting this into the context of a project environment, I can relate to the sensation of being filled with gumption. Often it happens at the start of the project, at the point where everyone is excited about the decision to go ahead, and what it will mean when we’ve delivered the change the project will bring. It brings forth that sense of assurance that “we can do this”!
Whilst Pirsig is frustratingly vague on how to fill your gumption tank, he does describe what he calls “gumption traps” that “drain off gumption, destroy enthusiasm and leave you so discouraged you want to forget the whole business”. I can relate too to this feeling! It is even more complicated in a project environment where it is the collective gumption of everyone involved that drives the project forwards. A gumption leak even for one person, can have an impact on the project overall. In my experience, this drop in gumption can happen at any stage in the project and left unchecked can lead to a self-fulfilling cycle of project fatigue.
Pirsig concludes that there are two broad categories of gumption traps: the set-back which happens to you, and the hang-up, which is caused by you. Setbacks are dependent on what you are doing, but hang-ups however show commonality across projects, often exacerbating the impact of setbacks.
I’d like to build on Pirsig’s work by contributing some common hang-ups that I have observed in projects:
- The Purpose Trap – at the start of the project, everyone is very clear on why the project is necessary. This can become less clear as time goes by. This lack of clarity about “why are we doing this” is like a slow puncture in your project’s gumption tank, reducing your team’s resilience in the face of project setbacks. This is why a clear business case is so important. It is something that the project can use to re-centre and reassess the purpose of the project.
- The Milestone Trap – in technology projects, the focus is on “Go-Live”. Project setbacks are discussed in terms of the impact of “go-live” because that is when the project’s benefits start to be realised. The impact of these setback can accumulate, and the goal of go-live can begin to feel unattainable. Recognising intermediate milestones in projects help the team achieve incremental wins and refill their gumption tanks on the way to go-live.
- The Tacit Knowledge Trap – IT projects are hard because we are not building something physical. We are building a set of capabilities embodied in a digital product, that few fully understand. To cope, we build mental models to relate our past experiences and knowledge to understand what the project is creating. These mental models are hard to articulate and are often different for everyone, causing miscommunications and welcoming setbacks. The antidote to this trap is to ensure that the project documents a “shared understanding” of what the project is trying to achieve and agrees this upfront. This is most often expressed in a functional specification, that describes a project’s products in a way that everyone in the project can understand, contribute towards, and use to measure the outcome of the project.
Project fatigue is something that creeps up on teams and creates a vicious cycle that saps morale and reduce the speed that you make progress. The good news is that once a team has recognised that project fatigue has set in, they can easily break the cycle by identifying the gumption traps that are affecting them and act. Sometimes it is as simple as getting everyone together for a “project reset” meeting.
