When the client is not heavily involved, expect plenty of project surprises and no ownership in the plan. The ingredients for optimal success require active client participation at every stage of the project – from project planning to project closure.
Anyone that has been around ERP long enough understands meaningful client involvement in the project is critical for success. However, it never ceases to amaze me how many implementation projects start with the software consultants behind closed doors developing a project plan in a vacuum. They later unveil the plan as some artful piece of work and present it to management for sign-off.
Interestingly enough, even some of the best software consultants are guilty of this, and there are two big problems with this approach. First, it 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 “blessing” something is very different than “owning” something. When the consultants develop and present the plan (with only token client input), it is now the consultant’s plan, not the clients. This is often reflected in senior management’s message to consultants; “great, go forth and make it happen” and by the way, hurry up.
Though the plan is endorsed by senior management, in the meantime the internal project manager, project team, key managers and employees in the trenches are not buying it. The reason: They have legitimate concerns that no one cares to hear or address. This has very real 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 out of the process key people within the organization that play a big part 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, it will contain statements of project objectives, scope, responsibilities, schedule, resources, risks, consulting cost, assumptions, etc. However always remember, the acceptance of the sales proposal signifies the end of the sales process and it is just that; a sales pitch not anything close to a project plan (we can actually use or believe). At this stage of the project the sales pitches are over, it is now time to deliver!
Also keep in mind when some consultants develop a project plan (project charter, etc) they use “templates” and then attempt to fill in the blanks. Nothing wrong with templates as a starting point, but the plan could end up a lot of hollow words, pretty gantt charts and formality, with very little substance. This is about lack of project management experience and templates will never make up for that.
ERP Project Scoping and Planning Phases to Refine Project and Implementation Plans
Once consultants are selected and the client project team 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 in the form of rework, delays, and cost overruns.
The consulting project manager can help lead and facilitate the planning process working closely with the client team. 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 benefit is getting the client project manager, executives, and the entire client project team 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, reality, and is understood by all key stakeholders. In other words, it is now a plan we can 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 is tossed out the window and we are now operating in the blind or with a totally different reality. Worse yet, we start making dumb project decisions to “catch up” to a schedule that was bogus to begin with.
It has been my experience the project planning deliverables of scope, schedule, and the consulting budget have the most influence is setting 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.
- project planning phase in erp