~ By Peter Osborne
IT-led business change programmes and projects continue to fail, yet many of the common pitfalls could easily be avoided by undertaking a 'health check' regularly and acting early on the intelligence it provides.
Peter Osborne examines the early warning signs a health check can reveal and how organisations should respond to the identified issues to achieve a successful outcome.
Performing a review or 'health check' of a project on a regular basis is a relatively simple and inexpensive exercise when compared to the multi-million pounds that are at stake. A health check provides stakeholders; sponsors; those tasked with managing the delivery; and impacted employees with peace of mind that the business benefits will be realised within the given time and resource constraints. Yet in the same way that most people only go to the doctor when they feel ill, the majority of organisations only perform a health check if they believe that something is fundamentally wrong.
Even if the warning signs are visible, there is a tendency to carry on with a project in the belief that issues can be resolved by doubling efforts or by throwing more resources at them. However, unless corrective actions that target the fundamental aspects of a delivery are implemented early, in most cases, outcomes will not be realised or a catastrophic failure will occur. Fear of failure is often an overriding issue, coupled with the reticence of involved staff to flag problems when it reflects badly on themselves or their colleagues. "It is hard to change your eating habits when you only have, in your mind, a few pounds to lose!"
Such political motivations mean that many staff put a positive spin on negative situations, while delivery teams focused on the programme outcomes can miss mitigating factors such as organisational change or external market developments. A project is all but doomed if it does not have the full backing and commitment of a viable sponsor and key stakeholders. There are countless examples of where the means outweighed the needs - the plight of one major mobile phone manufacturer in particular is testament to what can happen if a market takes a major leap forward but product development cycles follow their original course regardless.
Projects can fail in any number of ways - not just in terms of being unable to deliver on what was originally configured once the investment has been made (i.e. a catastrophic failure), but in terms of failing to achieve continually throughout the project lifecycle. A Dynamic Markets survey of 800 IT managers reported by CIO.com revealed that 62 per cent of IT projects fail to meet their schedules, with 49 per cent suffering budget overruns, 47 per cent having higher-than-expected maintenance costs and 41 per cent failing to deliver the expected business value and ROI. This wouldn't be so bad, CIO.com notes, if it weren't for the fact that the numbers haven't appreciably improved over the past decade. In some cases, they've gotten worse.
Statistics from industry analysts Gartner and The Standish Group support these findings, with anywhere between 60-80 per cent of IT-led projects continuing to fail. According to The Standish Group, 2009 marked a low point in particular, with just 32 per cent of all projects succeeding. Meanwhile, 44 per cent were 'challenged' in terms of being late, over budget and/or with less than the required features and functions; and 24 per cent 'failed' in terms of being cancelled prior to completion, or delivered and never used.
There are two major factors that influence the outcome of a project. Firstly, it is essential to have the right sponsorship. Whether conceived to improve business processes, reduce enterprise costs or manage enterprise change initiatives, projects can be initiated by any function within an organisation but without electing the right sponsor, the initiative is doomed. For example, if a new financial system is to be implemented but the CFO is not the primary sponsor or part of the programme board, the chances are that it will fail irrespective of whether or not the system is delivered successfully. For success the CFO must be part of the solution that impacts his finance team.
Secondly, it is just as important to ensure that a project is grounded in business logic. All too often, organisations are unrealistic in their expectations, with the belief that technology provides a 'reach all cure'. Yet there are many other factors at play - such as organisation, management, process, people and environment. A major UK business embarked on a £50-million project to implement a new CRM platform to help combat falling sales, only to find that the real reason was the inability of its sales people to actually sell! Technology is an enabler not a cure for organisational, process or management incompetence.
A project health check examines a wide range of aspects. This includes objectives, scope, approach, plans and management, as well as quality of resource, programme governance and sponsor/stakeholder commitment. Essentially, it enables programme leaders to identify what is working well and why, what is not working well and why and the actions necessary to resolve issues. Ultimately, there are an infinite number of aspects but there are five primary fundamentals core to an effective assessment - leadership, clarity of approach, effective governance, delivery approach and smart processes. The exact nature of a project health check will depend on the type of project being undertaken, the industry or sector the organisation operates in and at what stage of the project it is conducted.
The questions asked and the actions required also change as the delivery progresses. At the design phase for example, there is plenty of scope to adjust a configuration without materially impacting on the outcome but, once a build or delivery has commenced, alterations become increasingly prescriptive until a 'point of no return' is reached. Similarly, the further along the delivery lifecycle, the more pressing it becomes that the resources deployed are relevant for the specific phase and are effectively swapped in and out as necessary. Individuals involved with design are very often different to those who develop and those that build, and without ongoing organisational change these individuals can quickly become a hindrance when operating outside of their area of expertise. Whilst it is hard to put a rigorous measure on this, as a guideline, at least 60 per cent of the resource should be able to perform the roles as configured within the original role descriptions.
If members of the delivery team are unable to clearly articulate their contribution to the project success or are unsure of their role, this is a sure sign that things are wrong. It is also important to ensure that lines of reporting are simple, logical and clearly defined and that the organisational structure is kept succinct. Reporting is fundamental to maintaining a credible and rigorous business case over the course of a delivery and it is crucial that all those involved be able to demonstrate what the genuine status, assumptions, dependencies, risks and issues are at any given point. An active communications programme must be run in parallel to disseminate this information throughout the organisation. Inaccurate reporting and 'positive spin' encourages the wrong behaviours and inspires a false sense of security that can change the entire nature of a project. Regular project updates are a good sign of a well-functioning project.
Breaking down programme success into a small number of fundamentals is helpful in finding ways of assessing hugely complex programmes of IT and business change. But these fundamentals interact very strongly and are mutually dependent not exclusive. Clarity of purpose and effective governance for example, play a vital role in ensuring a good fit with business context; having smart process is much easier in a good delivery culture. The latter hinges on bringing in key individuals for key roles and is achieved both through effective leadership and by active demonstration - i.e. the project manager is first into the office and the last to complain. It's also achieved by a focus on quality. If team members see the project manager is targeting the things they view as being important, then it is possible to drive everyone towards a delivery outcome.
At a strategic level, the board must engage closely with programme content. Action-orientated boards will move on the intelligence they receive and ensure a programme is successful, whereas information-orientated boards report to stakeholders on progress but tend to take a back seat in terms of delivery. Performing a health check provides a set of viable recommendations, but if sponsors and stakeholders fail to implement them, then the exercise becomes almost futile. As the saying goes, you can lead a horse to water but…
Finally, the approach to adopt is one of practicality - i.e. determining what is sufficient to make a project successful. Here, the Pareto Principle applies, because an organisation will typically be resource, time or financially constrained. The results of a health check can be summarised into several themes gravitating around the five fundamentals of project delivery and prioritised according to those that will deliver the greatest impact. At the same time, bringing in a third-party who is independent of the organisation and stakeholders to perform the health check provides a perspective free from the internal constraints discussed.
Performing health checks in an independent and structured manner - e.g. at the end of the design phase and during the build and implementation phases - and taking the right actions at the right time can be an incredibly cost-effective means of ensuring a successful outcome when compared with the cost of a system and the potential price of failure.
Ultimately, there are five fundamentals that dictate whether or not a successful outcome will be achieved. These are: