If you read articles and blog posts on enterprise software projects, it won’t be long before you see tales of blown budgets; slipped schedules; lack of realised benefits and even litigation. Too often this class of project is the victim of poor delivery and, because of the costs involved, readily attracts poor press. Regardless of whether these projects include software suites from SAP, Oracle, Infor or any other vendor, they are substantial and tricky undertakings for any organization.
In a recent pre-cursor to their now published 2012 ERP report, Panorama Consulting (panorama-consulting.com) cite that nearly half (44-percent) of all ERP implementations fail to deliver at least half of their expected business benefits; 54% (down from 61% in 2011’s survey) run over schedule and over budget by 25% on average. It’s true that the occurrence of failure is publicised more often in the press than success, but even so, why does the occurrence of failure seem so prevalent?
Plenty of time and blog-space is devoted to the topic of critical success factors (CSF) for successful projects. Usually the list will include leadership, data, scope control, requirements management and managing the impact of change on the organisation – you can add your own 6th, 7th or even 8th CSF! This might be vision or governance or testing – all very sensible, easy to understand and advice that has been repeated numerous times over the past decade and half that I have been involved in these programmes.
So surely, the majority of folks are not ignoring or neglecting this sage advice? And hopefully the World is not completely stocked with incompetent project managers and leaders.
There has been a steady stream of articles, discussions and blog posts, including from Bill Wood at R3Now.com, highlighting that the lack of using a strong methodology is a contributory factor to project failure, and that project managers (in Bill’s case he was highlighting SAP Project Managers specifically) are ignoring the assets that vendor methods, such as ASAP, offer, in favour of developing their own accelerators because they either do not know these methods or “have a financial motive not to” use ASAP. Whatever the motivation, the consequential lack of adherence to a rigorous method is contributing to failure and missed expectations.
To test the “state of the nation” @LIBACAS conducted a poll across several, relevant LinkedIn Groups to ascertain the extent to which SAP Project Managers have been formally trained and are keeping up to date with the ASAP method, by way of an example for vendor prescribed implementation methods. The results are somewhat disappointing, but probably not all that surprising.
Out of a sample of 29 project managers who responded:
- Only 10% had undertaken formal ASAP training within the last year.
- For 31% it has been more than five years since they were formally trained in ASAP, so they may not be aware of the latest additions or how to navigate the method roadmap, access its repository and run an SAP project using Solution Manager – SAP’s recommended way of using the method to its fullest.
- 17% have only ever been trained in their employers’ methods, which align, incorporate or, at best, pay homage to ASAP. Again, potentially missing out all the available support and aids that the vendor method could provide. And, perhaps most revealing,
- 42% have learned everything they know about ASAP “on the job”.
Now, it’s probably fair to assume that many project managers will have had training in a formal project management standard – PMI or Prince2, but these do not offer the same extent of guidance and support for enterprise software implementation projects that vendor specific methods will. So, it is highly likely that project managers are missing out on useful tools, disciplines and accelerators due to a lack of formal training. That’s certainly not going to help the situation, but is method the root cause of a high percentage of project failures?
Ken Koch, from BRMOnline.com – responded in a recent discussion on the topic “My experience has taught me that it isn’t the methodology for an ERP system [that gives success] it is the company’s ability to adapt and adopt.”
Again the “adaption” theme has been often repeated and leads to the “we will stick to vanilla” and “change the process not the package” mantras of every client Steering Board. However, this is easier said than done, with 53% of Panorama Consulting’s respondents admitting to “some”, “significant” or “extreme” amounts of customization in their projects. In my experience, at least 20%-25% of a project’s budget will be consumed with development effort, as opposed to configuration, as the business changes the behavior of the software to fit their processes, rather than the other way around.
The “adopt” conundrum – getting the business to change to fit the application – is obviously the territory of organizational change management, communications and training. Again an understandable feature of all lessons learned reports; CSFs for successful projects and high on the list of every ERP related consultant worth their salt. While many businesses do underestimate the difficulty of getting their organisations to change, to understand, adopt and accept the new processes, practices and applications, most do at least plan for activities in this arena as part of their overall project. So, is a failure to address business change really the main factor in project failure?
Or perhaps all of the above are guilty parties, accomplices to the crime, and the problem that needs to be managed is the inherent complexity of these projects, the breadth of scope, the business and IT dimensions, the impact on people, data, processes and infrastructure. Is complexity the root cause or at least the main driver of failure?
The breadth of their potential capabilities, their tightly integrated nature and the anticipated benefits of deploying commercial enterprise software suites often leads companies to “plan big”. Wanting to implement to the fullest extent, there is a tendency for projects to bite off a lot (too much?) in one go. Review the scope of most of ERP-enabled business change projects and it is likely to encompass a large proportion of an enterprise’s core business processes. That’s a lot of activities, functions, transactions and people to consider, even in a small business.
It’s true that the native integration; the ability to replace whole swathes of legacy applications, and to deliver standard, end-to-end business processes, is a powerful lure for any business. Keeping the scope intact and delivering the new processes and applications in a “big bang” to the business, promises to keep technical implementation complexity down and more quickly realise improvements in business efficiency.
According to the Panorama Consulting survey, 57% of organisations that responded took a “big bang” approach across the whole company, or phased total process scope by geography or business unit. On the flip-side, the larger the scope, the more resource is required from the organization to support the implementation; the more business change needs to be absorbed by the business and the more integration and coordination is required within the project to keep everything joined up and inter-dependencies under control.
Review the proposals from the vendors and their consulting/SI partners and you could be led to thinking that the bigger the scope the better from an integration and implementation perspective; that the risks are entirely manageable, and you can still get everything you want Mr/Ms Client within your budget (aka “the selling price”).
As Dave Heafield, a seasoned SAP HR and Payroll Programme Manager commented in response to our poll – “my experience has shown that if clients take [the vendor’s] sales pitch with a huge pinch of salt and as a balance take advice from experienced PMs, then they’d allow longer for the transformation and agree up front it’s going to cost them more than [the vendor or SI] told them. They can still justify it with a sound business case but they go in with eyes wide open and avoid the “it’s late and costing more than planned” discussions later when they’ve already spent too much to stop.”
So, to conclude, after 15-20 years of ERP implementations, the rate at which projects fail, judged in terms of time, cost and benefits realisation, is still too high. Any list of CSFs is probably right. All those areas need to be addressed and factored into any project from the outset, but the top three things that will make or break a project are:
Experienced Project Leadership
Experienced leadership will obviously help. Make sure your programme and project management has proven experience from a business and project delivery perspective. They need to be able to implement a formal and disciplined project methodology; know about and be able to access current, best practice tools and accelerators. Above all they need to convey the method, expected standards and the use of tools to the team, then stick to the disciplines.
C-level executives want results, the quicker the better. They will (usually) rationally expect a fair cost, proportional to the expect return, with minimised risk and disruption. Above all, they do not want surprises. Heed the advice and data points in the public domain. Challenge the basis for estimations; identify the areas of uncertainty and the gaps from today’s way of working or organisation. Assess risks and mitigations, and budget time and costs accordingly. Invest in the planning and preparation stage, but do not expect to plan the end-to-end programme in detail. Build in contingency, but work to an aggressively realistic schedule and manage expectations of those that “just want the thing to be implemented”.
Above all, any programme needs to address complexity upfront. The scope and implementation plan for your ERP project needs to be divided into manageable chunks – balancing scope, costs, time, risk and benefits, of both technical and business delivery. Fundamentally, smaller independent or loosely coupled projects will be easier to manage and have a better chance of success than large, complex and overblown, multi-multi-million dollar/pound programmes. Use Enterprise Architecture approaches to scope you projects and plan out your programme roadmap to deliver in releases and phases.
If it’s planned to take 18 months, two years or longer to deliver the project, whether your actually successful or not will be a moot point, the business will have moved on by the time that the shiny new ERP system hits the streets.
Delivering agreed capabilities, over a series of successful 6-9 or at a push 12 month projects, will be received far better than returning to the Steering Board to ask for a 6 month extension and an additional 30% to the budget, assuming that you still have a job in the first place!