A case study of an ERP implementation (Young 2005) highlights a paradox. The project is widely reported as a success because it was one of the world’s fastest implementations of this particular ERP system. However, the benefits promised to the board were not realised. The business case stated that a minimum of $6 million of benefits were to be delivered over five years and that the ERP would be upgraded to underpin the organisation’s long term strategy. The project ended up delivering only $3 million of benefits and the organisation lost confidence in its ability to realise benefits and deferred the upgrade indefinitely. The disappointment was compounded because management considered that they did everything right: they had formal governance structures (project sponsors, steering committee), formally documented and signed off individual responsibilities for each of the targeted benefits, followed a proper project management methodology, selected appointed a highly motivated high calibre project team, and they had the benefit of experienced consultants to guide the project.
The case study was titled ‘how to fail successfully’ because it was both a failure and a success depending on ones perspective. The problem it highlights is choosing which perspective to emphasise. Until now the IT vendors, IT professionals and project managers have had the loudest voices and they consciously or unconsciously dominate by abusing their so-called expertise (Thomsett 1989). By claiming to know what was wrong and assuring stakeholders the next technical solution would be the right one (Currie and Galliers 1999), for the last 20 years, the discussion of success has been confined largely to the issue of whether a project has come in on-time on-budget and whether it met specifications (Grindley 1995).
From a governance perspective this is wholly inappropriate. Governance is about both performance and risk (Standards Association of Australia 2003, Australian Stock Exchange 2003) and Hilmer captures the objectives well when he states that the objective is ‘to ensure management is focussed on above average returns taking account of risk’ (Hilmer 1993). Organisations do not invest in projects so that they can come in on-time on-budget or even to meet specifications! Projects are undertaken to realise benefits e.g. increased revenue, decreased costs, ability to respond faster to changing customer demands, etc. This governance perspective of whether a project is successful or not has been largely ignored. It has been overshadowed by the loud chorus of self interested vendors/professionals (wanting the next project) who claim projects were successes because technical objectives were met, users were satisfied or they came in on-time. A common practice is to choose success criteria only after a project has been implemented and to declare it to be a success based on whatever criteria of success has been met (Boddie 1987). In one perverse example a project team claimed a project was a success because they ‘learned not to do that again’. Where is the governance voice asking ‘where are the benefits you promised me?’
The pity of this situation is that many reputable people over the years have correctly pointed out why projects fail (Cooke-Davies 2002, Baccarini 1999, de Wit 1985, Markus et al 2000, Lucas 1975). They need to be heard because their perspective is consistent with good governance and they show quite clearly that achieving on-time on-budget or any of the lesser criteria for success (Delone and McLean 2003) does not strongly relate to the realisation of benefits. This has very important implications because the majority of IT prescriptions are focussed on how to do project management better or how to solve a technical issue. These prescriptions alone will not lead to success from a governance perspective; at best they will tend to lead to on-time on-budget. This is illustrated in Figure 1. Almost all the project advice that exists is focussed on the circled aspects of project management labelled 2–Planning, 3–Development or 4–Implementation (Yardley 2002). This advice has value but the emphasis at a governance level needs to be on clarifying what benefits are being targeted and whether they are being realised (i.e. 1–initiation and 5–benefit). There is very little guidance in this more important area, and what there is, tends to be directed at the project manager. This is wholly inappropriate because a project manager tends to leave at the end of a project, but the benefits of a project (IT projects in particular) tend to be realised some time after a project has been implemented, and is usually related to some degree of organisational change (Markus 1996). The implication is that for a guidance to be effective, it has to be directed at business managers, the owners of a project’s outputs.
The final section will build on this discussion and present the best advice currently available for boards, top management and executive project sponsors. This audience has the largest impact on whether a project will succeed or fail (Young 2005) and is the right audience for any IT project governance guideline.