Twenty-five years ago, a mate of mine made a colossal mistake. As a civil engineer in his first job out of university he designed a bridge that didn’t join up. Now for all of us who were his mates, this was a great laugh. For Mark however, this wasn’t so funny. And it was a long time before he was allowed to submit another design. But he never made the same mistake again. Conversely, we in the technology game are slow learners. Perversely, it’s almost expected that root causes that have plagued projects in the past will manifest again in new projects. Even more interesting is that regardless of whether the project has been delivered under a traditional waterfall model or whether it has been delivered under an agile framework, the same root causes are commonly found. Here’s the top five from my experience.
Scope Creep
In my opinion the most common root cause in troubled projects. However, scope creep is often driven by people, not technology or process. Having all decision makers in the room at the start of the project to define the scope is the single best action that can be taken to avoid future conflict, misalignment and unforeseen changes. The second-best thing is to ensure that all critical stakeholders are acquainted with the product or service being implemented and are cognisant from the outset of any limitations.
Poor Project Planning
I’m hearing more and more that planning and scheduling are no longer required for technology projects. That they’re a relic of the past that constrains flexibility and imposes unnecessary overhead to the project. Recently, whilst executing project health checks for a client, I’ve heard from more than one project team; ‘We don’t do project schedules. We’re agile!’. What transpired was that each and every one of those projects required rescuing. They had misinterpreted the fourth value of the Agile Manifesto, i.e. ‘Responding to Change Over Following a Plan’ to infer that planning is not required. In fact, there is no reference in the Manifesto to abolishing planning. Quite the contrary. Agile is not an excuse to ‘suck and see’. Planning is critical for agile projects. But don’t build a granular single master plan from ‘soup to nuts’ and take a punt that it will still be valid months later. Instead chunk it up in to smaller digestible portions using quality data inputs to create a highly reliable estimate, with a predictable outcome, from which you can test, review and quickly learn from the results.
Poor Communication
Lack of a project plan, an understanding of the delivery approach and the discipline to adhere to it frequently results in inconsistent communication and increased speculation and rumour. Poor communication practices are exacerbated in challenged projects due to team members’ uncertainty, denial and concerns about being held responsible. It’s the job of the recovery project manager to turn this around and instil a sense of confidence back into the team and protect them from any conflict targeted at the project.
Poor Engagement
Three key relationships need to be fostered from the outset of any project: Sponsor & Project Manager – this is the most important relationship. The sponsor should ‘ride shotgun’ and handle the business side whilst the project manager focuses on delivery. It’s imperative that there is a mutual trust between these two individuals. Sponsor & Stakeholders – there must be unequivocal clarity between the sponsor and the stakeholders around what is being delivered. Consistency of message and universal evangelism is critical to business adoption and enthusiasm around the end product or service. Project Manager & Delivery Team – this relationship is strongly influenced by the sponsor. The team must maintain trust in the project manager and know that he/she has their back. Avoidance of project fatigue is critical. Another very common problem is team member selection. Often the project manager is either allocated a team member or allowed to pick from a limited resource pool; rather than allowed to cast the net wider for individuals with the best skill set. Money is saved by using a cheaper resource … but that is soon eroded when the resource in question is unable to deliver against the schedule.
Poorly Managed Risks and Issues
Far too often risks and issues are captured in a register … and forgotten about. These need to be actively managed and measured from the outset with metrics around quantity, severity, age-profile being very good indicators into the health of the project.
But It Doesn’t Need to Be Like That
We don’t need to wait until the symptoms of these problems show themselves. They’re all very predictable. And because of that they’re also very avoidable. In fact, you only have to Google ‘Top causes of failure for ERP projects’ to realise that the problems, the impacts and the recommended approach to prevention are already well understood and documented. The key word here is prevention, as stopping the problem happening in the first place is far better than mitigating the problem to reduce its impact. So why do we as IT professionals think we know best? Why do we think we can beat the odds?
Ego … maybe. Inexperience … possibly. Lack of capability … perhaps. A more likely reason is poor initiation. The project hasn’t been set up for success from the start*. It is probable that the right people haven’t been brought together to define:
- What are the project’s scope, objectives and outcomes?
- What success looks like and how it will be measured?
- Who do we need to work with to get this done – both stakeholders and other initiatives?
- What are the quality expectations of the stakeholders?
- What are the key risks of the project and how will they be managed?
- How will the project communicate with stakeholders?
- What change management activities are needed?
- What are the project’s tangible and non-tangible benefits?
- How will those benefits be delivered?
- What are the specific tasks that need to be completed?
- What is our best estimate of how long these tasks will take and what they will cost?
- And given the above… do we have a valid business case?
(* See the recent article by Aaron Dowling for insight into Initiating a Project for Success).
By understanding the common root causes for failure and examining these at the very outset of the project, you will greatly enhance your likelihood of success.
