More resources typically mean a job can be completed more quickly, but when it comes to IT, it seems the reverse is true. With the Auckland Council SAP project as a case in point, why is it that enterprise IT projects routinely take longer and cost more than expected?

While it is easy to point fingers, there is a more complex reality at play and it is one which plagues large companies as much as it does small ones. It isn’t only an issue which happens in public institutions; private companies are just as much at risk of enterprise software projects going decidedly sideways – they are just better at keeping quiet about it.

Importantly, however, while budget blowouts are keenly felt, they don’t necessarily equate to project failure.

Tim Bird, Agilyx GM, has spent his career implementing ERP systems into large public and private sector organisations in the UK, Australia and New Zealand, including replacing a suite of Oracle solutions with Unit4 Business World at New Zealand Post; he said software is often an easy target when projects do not fully deliver on their promise, when in reality it is only one of a number of components that are required for a successful outcome: governance issues, lack of senior management support, inadequate testing, insufficient training, lack of clarity around vision and purpose are far more likely to be the culprit.

“In change and transformation projects, the software is only ever an enabler, supporting people and organisations to do things differently – better, faster, cheaper, smarter or in more customer-centric and user-friendly ways.  And if you are not looking for the organisation to be doing things differently at the end of the project, then why are you dedicating resources to it at all? So at their heart, all projects are change projects.  Difficulties often arise when organisations fail to recognise this and put technology instead of change at the centre of their approach.”

He added that another common project failing is when time and budget become politically sensitive, or set in stone before the scope is fully understood. “A common approach to ensure the delivery of projects on time and on budget is then to remove from scope the hardest parts of the project.  These are often the parts that actually deliver the real benefits. The result is a project that delivers ‘on time and on budget’, something that looks very similar to what was there before.”

It’s not just vast enterprises and big companies that suffer this fate. Chris Wong, director at import and distribution company Pave Brands Limited, has implemented several ERP solutions in his time. “Smaller businesses may not have the turnover and the staff numbers of big conglomerates, but that doesn’t mean our processes are any less complex,” he noted.

“Particularly with rapid implementation methodologies that are light on requirements definition and process modelling, be prepared to significantly exceed the budget that you established at the outset. It is very easy to align system functionality with requirements at the macro level but as always the devil is in the detail.”

He explained that while vendors tend to take the position that these are scope changes, unless there is a detailed requirements definition/prototyping/modelling phase, it is difficult to lock down an exact scope and therefore cost.

It must be noted that when Wong implemented Dynamics NAV, he was spending his own money. It should also be noted that he is satisfied that the outcome is worthwhile, despite budget expectations being exceeded. “I definitely am happy with the system in what it does; the price hurts, but I am confident that we will get the benefits in the longer term,” he said.

Why recalibration of objectives is necessary
At the CIO Summit earlier this year, Westpac CIO Dawie Olivier gave a presentation which provided some insights into the complexity of modernising enterprise systems, and outlined the difficulties involved in delivering enterprise software projects.

Discussing Westpac’s own systems, Olivier explained that over the years, IT heritage delivers systems which, because of changes in the market and the necessary reactions to those changes, result in a ‘hodge-podge, where thighbones don’t connect to hipbones’. Complexity, in other words, which drives up cost and hampers the effective delivery of the services required by the business.

Through analogy, Olivier explained that with large, complex enterprise projects, things change over time; if those tasked with delivery do not change the scope and deliverables, sticking to the original brief might deliver at the end of the project just precisely what was envisaged at the start. But because things have changed, even if what is delivered is on time and on budget, it could no longer be fit for purpose. This requires constant revisiting of the project and the outcome if delivery is to create value.

Bin the big vendor?
Whether or not big name vendors are the right choice for Auckland (or, indeed, any large enterprise) is at the centre of the argument of one of the more outspoken NewCore critics, Wellington-based software specialist Ian Apperley. “The mistake councils make is that they think that a single product can solve ALL their service requirements. It never can. There are always parts of a product set that are strong and parts that are weak. When you buy an ERP, you are buying a product set that may have good bits, but is also guaranteed to have [bad] bits as well.”

The very complexity that council seeks to solve sows the seeds of doom; Apperley reckons rocket science is easier business than running Council. “No other businesses have that breadth of service to provide. I am being serious. Rocket science is nothing on Council ICT planning.”

In his view, a ‘single system’ approach just isn’t going to work. “Any ICT practitioner worth their salt knows that modular systems are where the world is going,” Apperley added.

While he agreed that it is acceptable to revisit scope (“and a good project will have the governance in place to do that”) he doesn’t like what he sees with NewCore. “This isn’t a scope change, this is massive; [it] looks like a total 45 percent variance. It looks like they screwed up the requirements somewhere along the line or got caught by a low bid.”

He has a number of ideas on how to do projects on this scale better: “Throw out the complex methodologies and big consulting frameworks. They don’t work well. Once you have signed the contract, never refer to it again. I can’t stress this enough. Taking a contract to a meeting after you have signed it for any reasons is a massive red flag. Leave that to contract managers.”

Other suggestions Apperley volunteers include the choice of modular systems with agile development approaches. “Modular is king. Buying the best from a bunch of different locations is wise. You’ll need an integrator, but it’s worth it,” he said. And, “Choosing local providers is very smart. You can enter a partnership with them, you can’t with an SAP. Local providers are more engaged, more relaxed, have more to lose, are more likely to create an innovative deal, and are far more agile.”

He even advocates drastic action (to avoid a situation known as the Concorde Fallacy). “If it isn’t working. Kill it. Whatever it is. Don’t persist with things that are stalled and you can’t fix. Just stop doing that. If it doesn’t get a result, stop doing it.”

Or accept that complexity can’t be predicted
Where Apperley doesn’t believe SAP is the right choice for large complex organisations, the vendor itself has built its multi-billion dollar business on delivering software for just those sorts of companies: SAP has a considerable public sector business and runs some of the biggest councils in the world. Andrew Spicer, MD of local SAP partner Realtech confirmed that. “I’m not sure how anyone can say that SAP is not good choice for large complex organisations. This has been their bread and butter for years and the whole ethos is reducing complex environments by replacing multiple modular systems.”

Spicer spent some time in the United Kingdom working for SAP in the local government environment, where the software is used by multiple large local authorities. “In my opinion SAP is a proven solution for Local Government, with relevant and specific functionality available in the core applications.  Around the world, there are many examples of Local Government organisations utilising SAP successfully.  This includes approximately 50 Councils in the UK, from similar size organisations as Auckland Council, up to one of the largest unitary authorities in Europe, Birmingham City Council.”

Spicer noted that the services, issues and complexity of all these entities is the same.

Commenting on scope revision, Spicer pointed out that for any large project, whether in the private or public sector, there is always the possibility of changes. “Unless a substantial amount of time, effort and cost is spent up front to nail down the exact requirements, there will always be variations that will only be discovered as part of any implementation and/or testing.”

And here’s the rub: “However, doing this detailed scoping will delay the project considerably – and as scope will change over the timescale for large projects, it is arguably a better approach to get on with it and use a more agile approach of changing the scope during the course of the project,” he added.

The big question is whether or not the SAP system being implemented by Auckland Council will deliver what was promised, which includes assurances of improved operational performance, scalability to meet Auckland’s growing needs and a platform for digital service delivery. “I would say yes. One of the key elements in large deployments is the ability for them to be supported effectively and by having a platform based around one solution and knowledge set, and avoiding multiple integrations using modular solutions. That will mean less time, cost and complexity,” Spicer concluded.

…