I recently read an interesting blog post from Gartner summarising the results of a study that they undertook into why projects fail. The results aligned nicely with my own views:
Our recent Gartner Research Circle survey asked clients about project failures. No respondent chose “technical skills” as the cause of IT project failure. What this illustrates is that IT practitioners know that non-technical skills are always a factor in project success. Yet many organizations ignore the development of non-technical skills.
At work I’ve always contended that we focus on the wrong things in projects. Our focus has often been on identifying the small number of project tasks that can be highly standardised, whilst neglecting the rest. In effect we have put our emphasis into the areas that needed “technical skills” whilst neglecting the areas that needed people skills.
I’ve written a lot about this over the last few weeks, so this Gartner piece provided a nice stimulus to summarise:
- Projects often go wrong before they’ve even started because they build the wrong leadership team and project operating model. There are many ways to improve this, but the simplest I’ve used is this simple framework based on the concept of common ground
- Projects often artificially constrain themselves, because they don’t challenge assumptions and rules
- Once they get going projects want to get struck into tangible activities, and so neglect the critical stuff like getting a thorough understanding of their scope and objectives and conceptualising the solution and make the mistake of trusting that customers know what they want.
- Once they get going projects do a bad job of judging their progress and assessing the health of their project and team
- One of the most powerful techniques for project delivery is to use incremental delivery or daily builds (more here). Combining this idea with getting the project team to use their own deliverables or eating their own ‘dog food’ is the icing on the cake, here’s an example of projects going wrong if you don’t
- Projects often have too much focus on deliverables when they should be focussed on user experience, I recommend the discipline of Experience Design to address this
- It’s import t remember to avoid over managing or staffing activities, by carefully thinking about the type of teams you need
- Finally remember that projects are complex and unpredictable, so you need to be agile
Obviously every project is different and I’m not a Project Manager, so these articles can in no way be prescriptive, but they should stimulate discussion and debate about how to design and deliver projects more effectively.
My last tip is to make sure that if you use templates for project documentation take care not to just fill in the blanks. Project documents should focus on what’s special/unique about your project, not the standard boiler plate content that’s common to all.
The picture is of the harbour wall at Whitby, just up the coast from Hull where I did some of my most complex projects, an agile approach was definitely needed!
