August 30, 2017
We all know that IT projects have a dubious track record. Some are cancelled mid-way; many overrun yet still fail to deliver all the anticipated benefits, but only a minority are deemed an outright success.
In 2016, the Harvey Nash / KPMG CIO Survey (the world’s largest survey of its kind) noted that IT project success rates were declining. The recently published survey probes project performance in more depth and unpicks what to many may be a surprising rationale for project failure:
Project failure is mainly due to lack of ownership or clear objectives, rather than a lack of project talent or budget.
One may think that the increasing complexity of projects; the amount of external change, and the difficulty in securing budget and people are the key reasons for IT project failure. While they all play a part, they are over-shadowed by these top three concerns:
- Weak ownership
- Over-optimistic expectations
- Unclear objectives
Figure 1 – ‘What are the main reasons IT projects fail in your organisation?’ from the HarveyNash / KPMG CIO Survey 2017
To many, this is extraordinary as at the very outset of any project considered attention is given to all three of these factors. Few organisations would countenance starting a project unless there was a signed off Project Initiation Document (PID) which, amongst other things, gives a clear articulation of ownership, roles, responsibilities, business benefits and project objectives.
Perhaps one fundamental cause which underpins this is internal project change. While most IT projects are oriented at tackling external change (introducing a new system; streamlining processes; ensuring legislative compliance, etc.), how many of us pay sufficient attention to what happens as the project itself changes? We appreciate that the PID is supposed to be a ‘living’ document that is constantly revised as project change occurs, but in truth once a project is in-flight the focus is usually on attending to the here and now of scheduled and slipping activities and the latest batch of risks and issues. Who has time to edit the RACI matrix, or review whether updates are required to that stakeholder map or communications plan which was drawn up in those heady days when the project was starting up, when project completion looked like a distant dream and penalty clauses an anodyne abstraction?
It would be wise to acknowledge that not only does the external environment undergo constant change but so too does the internal project environment. Project and programme managers come and go, which we know brings disruption, yet seldom is it fully anticipated and rarely is the impact scrutinised. It matters, because aside from the additional effort required for handover (which is usually the extent of planning for this eventuality) a change in project leadership can have far-reaching consequences. Perhaps the incoming project manager is not quite as experienced. They may not understand their Terms of Reference quite as well as their predecessor, and being unclear on their authority they could face difficulty exerting proper influence. Conversely, the incoming project manager may be very switched on and yet bring with them split loyalties or hidden agendas because of who hired them (another part of the business, a third party, and so on).
Project managers, like all stakeholders, are usually carefully identified at the start and prove invaluable in championing the project, spotting and resolving issues. When any stakeholder leaves, a hole is created. If they were a key stakeholder or sponsor, then delays in finding a suitable replacement can obstruct the communication of important decisions in the meantime, which in turn swiftly erodes a project’s success rate. Even a change with a non-key stakeholder can undermine a project. To assert that it doesn’t matter as they were ‘just a user’ or ‘just a member of the testing team’ and therefore nothing to worry about, could be a monumental misjudgement. All stakeholders are pivotal, and many prove to be essential in the early identification and resolution of issues, not to mention the influence they have on other stakeholders.
Another internal factor that can trip up a project is the handling of change requests. It’s commonly understood that people usually resist change. That is unless they are a supplier of project management! Suppliers may well have a vested interest in generating change requests that promise greater influence and/or revenue. Similarly, the project manager usually has a personal stake in growing a project so their eagerness to embrace change needs tempering somewhat.
Making design changes; adding new functionality, and so on, may all be justifiable and sometimes even essential. That said, processing change requests should involve more than writing a one-pager on options and getting some estimates back. Often, change decisions zoom in on two factors: the financial impact, and whether the change can be absorbed in the current timeline. This narrow focus is perhaps crucial to the understanding of how projects can unravel despite all the best efforts up-front.
Firstly, the time taken to consider a change request is usually at the cost of scheduled activities. While some project managers will plan from the outset the scheduling of Change Request Boards, only the most astute of project managers also set aside time for themselves, the solution architect, and whoever else is involved in considering change requests to work on option papers, estimates, and any other necessary inputs.
Secondly, whereas the main project will very likely have assessed in some detail project ownership, roles, responsibilities, and so on, such consideration infrequently applies to change requests. And it should. If the project is to accommodate change, then deliberation should be demanded on how the change impacts the anticipated business benefits and what additional effort is needed to maintain stakeholder commitment. It may just be that some additional education is required on what the change entails, but even if that is all, at a minimum some realignment of the project against the original PID is usually called for. If a project is allowed to absorb change without a corresponding alignment to its original purpose and strategy, then no wonder IT leaders complain that projects end up with weak ownership; over-optimistic expectations and unclear objectives.
Figure 2 – The need for regular project performance reviews
In summary, it is not just the business environment that faces constant change but also the project environment. Hence, to improve project performance necessitates relentless alignment of the business case against both the business and the project environment. Whereas many projects face challenges with complexity, budget issues, access to talent, etc., they are overwhelmingly undone by weak ownership and a lack of clarity around expectations and objectives. This undoing is rarely a fault at Project Initiation, but creeps into a project environment through a failure to reassess ownership, expectations and objectives as change occurs. This review of project performance should not be left to a wrap-up workshop on ‘Lessons Learnt’ or you risk having it thrust upon you in the form of an unwelcome and unscheduled ‘Project Recovery’ phase! Instead, project performance reviews should be a regular and planned activity, especially when new changes are introduced.
Alistair Johnston, Programme Management Director at NashTech, shares tips on how to increase the success of your outsourced IT programmes.