Danger in failure to define objective
WHEN you don’t recognise a project spiraling down the drain, it is a killer. Whichever way you want to look at it, the biggest issue with unsuccessful IT and transformation projects is the failure to clearly define your objective — your business objective for investing hundreds of thousands, millions perhaps.
Worse, when you don’t have direct control of the program under which the projects fit, the project and your invested dollars are doomed to fail. So, what mistakes must we avoid? What can we do right?
Do not abdicate project ownership.
Don’t let the technology, the software, the implementation consultant, or the system integrator define what success looks like.
There is inherent bias in that approach. And it’s not necessarily intentional. You must define the key business processes independently of those influences.
It is essential that you define your objectives and set your priorities. Too often the influencing parties dictate what your strategy, priorities should be, what best practice is.
And all too often, it’s tightly coupled and aligned with their own software functionality.
The biggest offenders include ERP systems, core banking systems and supply chain solutions.
The track record globally for letting them lead your business goals and contorting them to their software structures and capabilities results in millions of dollars in blowouts.
Why do you throw good money after bad?
Why is this not typically recognised early? Why do some of the most respected organisations in the private and public sector continue to throw good money after bad?
Experience suggests that they are already heavily committed, there is a reluctance to admit the project is off the rails because of a decision they made.
In many ERP and core banking programs, the organisation abdicates strategic direction and operational control of the program to the system integrators because the belief is that the system integrator knows best.
What they know best is their own technology platform, the software. Not your business, not your operational goals.
Even if they did, there is no profit in their setting you right particularly if it doesn’t align with their technologies. At least not initially. Usually later, when it’s going to cost significant amounts of money in changing the requirements and customising the application.
The crucible of no return
By then your project has entered the crucible of no return, you cannot turn back. At this point, if you asked them who owns the program and who is running the projects, you will typically get some very interesting responses. The right answer should be that the organisation owns the program, the organisation runs the program, and the system integrator manages the project. What should be done? Rather than continue to throw money down the drain, review the program. Take some tough decisions. What will it cost to keep going as is? Stop the bleeding. Reassess. How much longer will it take? What went wrong and what would be done differently? Now there’s a question worth addressing urgently. My experience in the past and recently has been that same issue with the system integrator having control. In one case a senior executive clearly demonstrated how they had been just as effective, if not more effective using their manual spreadsheet-based processing before the ERP solution was installed. At least business processes were understood better, and they didn’t spend 80 per cent of the time understanding and fixing the application and only 20 percent of business processes.
The biggest issue — no one owns data migration
Another had stop-start evaluation of software and implementation timeline that extended more than twice the projected time frame.
Also, there was no one responsible for migrating the data from the old environment to the new system, which it appears struggled over the finish line, or perhaps still hasn’t completed. Millions wasted. Lack of proper data migration can kill your project and is a constant source of frustration and leakage of funds.
Program structure
Project organisation — in fact, it should be program organisation — can be done significantly better.
First the program organisation structure must have at its head a program manager who is part of the public or private sector organisation.
This program manager must not be an outsider such as the system integrator.
The program manager is directly responsible to the leadership, the board, Cabinet, the steering committee and not to any technology or software vendor or systems integrator.
This is not a technical role, it is a role that understands business objectives of the organisation, is aligned with the business processes of the organisation and will give priority to organisation change management, quality assurance, human capital leverage, and data leverage.
Program team
The recommended program structure for large programs, would comprise a program team and structure with the following roles
Program manager (internal) reporting to a steering committee
■ A quality assurance officer as a peer to the program manager, also responsible to the steering committee
A business process lead and a business focused system architect in close consultation and constant engagement with the program manager.
A data lead and a change manager responsible to the program manager.
These can be roles and not necessarily individuals, with one person with the right experience and capabilities in multiple roles.
Technical project manager
And finally, the technical project manager with strong knowledge of the application, software and technologies being implemented.
Subject matter experts would report to the technical project managers typically provided by technology vendors and system integrators.
The budget, project plans, program objectives and priorities should be based on the above structure rather than on the technology-first project forecasts and vendor budgets.