A successful ERP project needs leadership, management, and drive but, although those are similar things, they are not the same, and they generally can’t all be delivered by the same person and so they need to be considered separately.
The primary, although by no means the only, function of leadership in an ERP project is to provide strategic direction, and that means deciding and communicating what the new system has to do and has to achieve. Implementing an ERP system is more than just changing software and is more than just up-grading from an accounting system, like Quickbooks. It is about fundamentally changing the way the organization works (and, if not, it is probably not worth doing) through a full business transformation. That is a decision that not only must be made at the C-level but is a decision that has to be unanimous. Other alternatives may not be as good or as efficient as a successfully implemented ERP system but they will definitely be better than a failed ERP implementation, and an ERP project will fail if C-level support is not unanimous.
Beyond deciding the direction of the project, an important function of leadership is to define and communicate the scope of the project. Senior management cannot allow ‘mission creep’ because, if it does, the project will lose direction and momentum, and will inevitably either grind to a halt or find itself curtailed when time, money, and patience run out.
An often overlooked but vital responsibility of leadership is the protection of the people being led. Even when people are seconded full-time to the project, there will be occasions when their home departments will want to call upon them to help with emergencies; but good leaders protect their people from unfair and unrealistic demands upon their time and attention because not only will asking them to serve two masters put them under undue stress, it will deflect them from necessary tasks to the inevitable detriment of the project.
Finally; good leaders calm people down when they get over-ambitious and gee them up when spirits fall. They remember that ERP is not a computer system, but a people system that just happens to run on computers. These are all things that only the C-suite can provide.
There are understandable, but not good, reasons why senior management may hesitate to assume their responsibilities and want to leave leadership to perhaps the Project Sponsor (usually the executive heading up the department that has been pushing hardest for a new system). The main reason is probably that many managers simply do not have experience of implementing ERP because it is not something that companies do often. It is, in fact, perfectly possible to reach a senior management position without ever having been through an ERP implementation and so, if pushed into the front line, they can feel exposed. This, however, is a problem easily fixed.
A very good start to an ERP project is for all members of the C-suite to go on an ERP ‘boot camp’. Many independent ERP consultancies can offer a one- or two-day course and going on such a course, together, has multiple advantages:
- it brings all executives up to the same level of understanding
- it gives them the knowledge, and the vocabulary, to challenge anything that they are told by salespeople and external consultants and, not to be underestimated,
- it sends a very clear signal to the project team that the C-level is not only fully committed to the project, but willing to devote valuable time to it. During the implementation phase, the project team is going to be asked to work late and to work weekends, and if they see the C-level declining to spend just a few days off-site, learning about what they will be doing and facing, asking them for total commitment will be hard.
If you’d like to learn more about custom Executive Digital Transformation Bootcamps, contact us here.
Senior management can be tempted to devolve leadership of the project to external consultants, on the basis that such consultants should be the experts, but external consultants cannot be the experts on where the Board of Directors wants the company to go. Yes; they may be able to advise on that, but they can’t be allowed to make strategic decisions. So, companies should use them but should never be ruled by them.
There are many other good reasons why consultants should not lead ERP implementations but perhaps the most important is that, if they do, it will be seen to be “the consultants’ system”. Users will feel no responsibility for it, nor any obligation to help make it work and, when users don’t take responsibility for a new system, it will never get the results that it could have done.
Some companies believe that the project manager should lead the project, especially if that is a project manager with extensive ERP experience, but that also doesn’t work because it is simply wrong for decisions that affect how the company will be running for the next ten years or more to be made at that level. Not only will it range from difficult to impossible for the C-level themselves to accept such decisions, but their staff will be wondering just who is running the company if not their accepted leaders.
If leadership is about defining strategy, management can be considered as concerning itself with tactical issues. Strategy is about deciding what to do and management is about making it happen. So, management gets into detail in order to allow the creation of things such as requirements specifications, implementation plans and resource schedules. Then it moves to the plan, execute, measure, adjust, plan cycle. Planning (and, including in that, scheduling) means identifying the tasks that need to be performed, the resource required to complete them, the time required for their completion, and the sequence in which they need to be performed; and doing this properly needs professional and experienced project managers.
Progress has to be continually and objectively measured against the plan; not only in terms of tasks achieved but also in terms of budget consumed: something that readers with Cost Engineering experience will recognize as “value of work achieved”. In essence; if a project has 50% of its planned work completed on time but has expended 60% if its budget in achieving that, then things are not looking good.
Digital Transformation Team Structure
Turning to the management of the project; clearly, a good and experienced project manager (PM) is essential. It is preferable that the PM should be someone already within the organization because that will allow them to understand internal politics as well as the company ethos and the strengths and weaknesses of the individuals seconded to the project team. Many software suppliers and system integrators sell their own services as project managers but such managers will have divided loyalties.
Looking at who should drive the project; to help understand the options we can say that the C-suite should lead the project and a project manager (reporting to the C-suite via a C-level project sponsor) should manage it, but driving implies making regular and quick decisions, and it will frequently be impractical or impossible to have impromptu meetings of the entire C-suite, so it makes sense to have the project sponsor responsible for providing the push to get the system in.
Because driving requires decisions on speed as well as direction, there are other things to consider. One is understanding what speed is advisable and possible. If too much is attempted too quickly, chaos will result but, if too relaxed a pace is accepted, then valuable time will be lost and there will be a very real risk of the project simply running out of steam.
It was previously mentioned that external consultants, including those from system integrators, are the wrong people to put in charge of leading the project, but they are also the wrong people to drive it, because there will inevitably be conflicts of interest. The primary responsibility of these consultants inevitably is to the company that employs them because their careers rely on that relationship. At the very least, they will be motivated by the bonuses that they earn, and those bonuses are based on chargeable hours. So, at the beginning of the project, those people are heavily incentivized to get as many consultants through the door, and billing time, as soon as possible; even if bringing them in is premature. Once they are in place, they are then incentivized to keep them occupied for as long as possible, even if that means them doing things that are neither necessary nor productive.
An exception occurs, though, when other, perhaps more lucrative, projects open up and it is in the consultant’s best interests to release their staff as soon as possible in order to free-up resource. If that happens, the schedule will be ramped up rapidly, even if that is the wrong thing to do.
Successful ERP projects require leadership, management and drive. It is for the company’s own C-suite to decide how those things should be delivered and, though they can profitably take advice from independent consultants, the decisions and the responsibility are theirs and theirs alone.
Have questions regarding your project leadership? Contact us.