Several recent high-profile ERP failures have suggested that they were projects out of control, and that causes many people to query what the client's senior management team was doing. ERP failure can largely be mitigated by clearly defining the project sponsor’s role on digital transformation initiatives.
All textbooks recommend having a project sponsor and a steering committee to monitor and control progress, but these appear, in these instances, not to have successfully fulfilled their function. This article considers the roles and responsibilities of the project sponsor in the belief that the incumbent is, or should be, the primary conduit for information to and from the steering committee and, as such, has a major influence on the outcome of the implementation.
The project sponsor is generally the member of senior management who instigated the project in the first place but, if not, will at least be the member of senior management who obtained approval for the expenditure from the Board of Directors. The role necessitates that the holder sits at the most senior level of management within the company for three main reasons.
One is that the spend on the new system will, depending on the capabilities of the system being bought, typically be around three per cent of the company’s turnover; the second is that failure of an ERP project can be severely damaging, and the last is that implementing a new ERP system means profound change, and senior management needs to both understand that and to drive that or the project will be an expensive failure.
Having initiated the project, some sponsors believe that their role then is to merely chair meetings, sign-off invoices and arbitrate on decisions, but a successful project requires them to do much more than that. They (and the project manager) must be seen to be treating all departments evenhandedly. This gives the project sponsor an immediate problem as she or he is almost certainly the head of a functional area that is part of the implementation.
If members of the team believe any area to be having an unfair or undue influence on the project, they will become demotivated and no longer see the system as a company system but as a departmental system to which they will have to contribute to but to which they will have second-rate access. At that stage, a second-rate implementation is the absolute best that can be achieved.
There is no easy way for the project sponsor to gain the trust of the team that is essential to the success of the project, but openness and honesty are good starting points. If there are disagreements that the project sponsor has to adjudicate on, he or she must make visible efforts to listen to all sides, especially if the decision is going to go in their department's favor. Decisions should not be handed down as if they were tablets of stone: the project sponsor should take time to explain the reasons behind them so that the team does not start to fragment.
Specific responsibilities of the project sponsor include the following:
Having built the team, it is the responsibility of the project sponsor to define their remit. Does the implementation of a new ERP system include the acquisition of hand-held input devices for the sales team, or a new warehousing system, or even a new warehouse? All manner of people will try to slip in pet projects as part of the new system implementation, including projects that have previously been rejected. The project sponsor is responsible for excluding these from the project scope and for ensuring that they stay excluded: a major cause of projects running late, going over budget and missing deadlines is what military types call 'mission creep'. That does not mean that the scope of the project cannot change: only that there should be a formal change control system in place.
The project sponsor, being in a senior management role, will know things about the future direction of the company that the team will not. Strategic decisions, such as acquisitions and divestments for example, may be under discussion and it may be premature to make these known in detail to the selection team, so it is the sponsor’s responsibility to ensure that the chosen system has the ability to cope with these changes.
It is the job of the project sponsor to protect the team from undue interference. As mentioned before, there may be calls on their time that conflict with project responsibilities. There might be, for example, other major projects that are happening simultaneously (something to be avoided) or departmental emergencies. The project manager should deal with these matters on a routine basis but should be able to escalate to the project sponsor any problems that she or he does not have authority to resolve.
The project sponsor should be the final arbiter on decisions that cannot be agreed by the team. If the team works as a team these should be few, but some decisions will cross departmental boundaries and will have to be taken at senior management level, even if some of these decisions need to be taken back to the Board.
The project sponsor, having ultimate responsibility for the success or failure of the project, must satisfy her or himself that the project will meet the company’s goals. These goals may shift during the life of the project and it is the sponsor’s responsibility to re-target the project should unexpected change occur.
During the life of the project, the team will experience highs and lows. It is the sponsor’s responsibility to pull them back if they get too excited and to gee them up if morale drops. This will necessitate, with the help of the project manager, keeping a finger on the pulse of the team. The project sponsor’s role is not reactionary: on the contrary, the project sponsor needs to be proactive and this will necessitate close co-operation with the project manager so that the line between involvement and interference is not crossed.
Because the sponsor assumes ultimate responsibility for the project, he or she must main-tain contact with the project via the project manager. Brief daily meetings (15 minutes maxi-mum) backed up by more-formal, minuted weekly meetings work well.
The project team will be delegated responsibility to recommend a solution that is the best achievable fit against the requirements specification that circumstances (i.e. budget and time) permit. The final decision on implementing that decision will rest with the project sponsor and the Board of Directors.
When the project team has delivered the project, it is the sponsor’s responsibility to ensure that the delivered solution is taken up by the company as a whole. Packaged software is a compromise and, even though they signed off the requirements spec, some departments will drag their feet when it comes to moving onto the new system. The project team can help to 'sell' the new system internally within the company but, in the face of resistance, it is the responsibility of the project sponsor to ensure, via the Board of Directors if necessary, that the new system is embraced by all departments.
Meanwhile, something not always considered is that a critical role of the project sponsor is to remove from the project any team member who is not adequately contributing. Reasons why team members don't always pull their weight are generally:
So, as can be seen, the project sponsor is much more than just a figurehead: the role is critical to the success of the project and must be carried out accordingly.