When the client is not heavily involved, expect plenty of project surprises and no ownership of responsibility. The ingredients for optimal success require active client participation at every stage of the project– from project planning to project closure.
Anyone who has been around ERP long enough understands that meaningful client involvement in the project is critical for success. However, many implementation projects start with the software consultants developing a project plan in a vacuum behind closed doors. They later unveil the plan as an artful piece of work and present it to management for sign-off.
Even some of the best software consultants are guilty of this. Unfortunately, there are two big problems with this approach.
First, this method prevents the client from getting heavily involved to take more ownership of their project from the start. Secondly, it involves a blind leap of faith in your software consultants, which is never a good idea. No matter how much analysis consultants do, they will never be aware of all the subtle aspects of the organization or project that could have a major impact on the validity of the plan. This is one reason why ERP projects “fail to meet expectations” in the areas of software, time, and cost.
ERP Project Ownership and Business Participation
The fundamental problem is that approving something is very different than owning something. When the consultants develop and present the plan (with only token client input), it now belongs to the consultant, not the clients. This is often reflected in senior management’s message to consultants: “great, go forth and make it happen.”
Though senior management endorses the plan, the internal project manager, project team, key managers and employees in the trenches likely do not. The reason: They have legitimate concerns that no one cares to hear or address. The project will experience consequences not only in the quality of the planning deliverables (plenty of project surprises), but also from the standpoint of managing change and internal commitment to the project. In other words, we have cut key people out of the process that play a large role in implementing the plan.
First, many confuse the sales proposal (from the consultants selected) as a project plan (fixed price contract or not). As ridiculous as this may sound, it happens all the time. No doubt, the proposal will contain statements of project objectives, scope, responsibilities, schedule, resources, risks, consulting cost, assumptions, etc. However, always remember that the acceptance of the sales proposal only signifies the end of the sales process. A sales pitch not anything close to a project plan. At this stage of the project, the sales pitches are over; it is now time to deliver!
Also, keep in mind that when some consultants develop a project plan, they use templates and then attempt to fill in the blanks. Templates are fine as a starting point, but the plan could end up a lot of hollow words, charts, and formality with very little substance. Ultimately, templates will never make up for a lack of project management experience.
ERP Project Scoping and Planning Phases to Refine Project and Implementation Plans
Once consultants are selected and the client project team is somewhat formalized, every project should have a separate and distinct “scoping and planning” phase with specific deliverables. This represents the opportunity to analyze the business processes, scope, current systems, and many other aspects of the organization in greater detail. I am by no means recommending “paralysis through analysis,” but you must do your homework or pay the price later through rework, delays, and cost overruns.
The consulting project manager should lead and facilitate the planning process. In fact, if the consulting project manager does not add value in this area, he or she will probably not add value anywhere else. When done correctly, the client project manager, executives, and the entire client project team are heavily involved and more committed to the plan. In the end, this improves the quality of the plan and ability to execute it.
A good project planning process results in a final baseline for project scope, schedule, budget, etc., that reflects project objectives and reality. In other words, it creates a plan we believe and support. It also becomes a tool to measure progress and a “handle” to manage and control the project. A bad project planning process results in a plan that we toss out the window, which causes us to operate in the blind or with a totally different reality. Worse yet, we start making poor project decisions to catch up to a schedule that was bogus to begin with.
I have found that when the project planning deliverables of scope, schedule, and consulting budget have the most influence, they set the wrong project expectations. Therefore, in my next three blog entries I address these topics with the goal of helping the client avoid the subtle pitfalls while becoming more knowledgeable and engaged in the ERP planning process.
The next ERP Project Planning blog topics in this series include:
Part 2: The Twelve Dimensions of Project Scope
Part 3: Developing a Project Schedule (We Believe and Can Support).
Part 4: Ways to Estimate or Validate the Software Consulting Budget.
~~~~~~~~~~~~~~~~~~~~~~~~~
Author Steve Phillips runs a Blog entitled Street Smart ERP – Visit his site for more great insight and commentary.
