Early Signs your SAP Implementation is failing, part 2

In part 1, I discussed the warning sign of team members with nothing to do during the Blueprinting / Analysis and Design phase of the project.  The second early warning sign to watch out for will come from the consulting team leadership during the Blueprinting phase.  The warning sign is the “down-playing” of design deliverables.

The ASAP methodology, and other ERP methodologies have a plethora of design side deliverables that can be used to define the configuration and customization needed for a successful implementation. Nobody uses all the deliverables. When the project was planned, a subset of deliverables is normally identified and described; setting expectations for the blueprint phase.

I’ve served on project teams as the client project manager, as the consulting project manager, and as a PMO manager reviewing project progress.  Over time I’ve seen and worked on projects setup with detailed deliverable descriptions and ones where the deliverables were somewhat vague. Certainly detailed descriptions, samples and the like, help better set expectations with the stakeholders.  But good descriptions are not key to a successful project. Completing those deliverables is key.

This second warning sign is noticeable when consulting team leadership begins to change expectation that were set at project start.  Here are some examples I’ve heard, and their effects on the project:

 “We don’t need to complete that deliverable to finish the design phase, we’ll keep working on it during configuration”.

Translation: We didn’t give this deliverable enough attention to complete it on schedule, and rather than finish it, we’ll just go ahead and setup the ERP solution with what we know now.

Result if statement accepted:  The design deliverables give implementers a clear picture of how and why to configure modules and how the business processes interact across the ERP solution. Delaying completion of a design document while major configuration begins means it is likely some work will have to be redone when the design is completed and it doesn’t match with the implementation alread in progress.

 “This is going to change as we go forward anyway, so no need to worry about it now”.

Translation: We didn’t do a thorough or complete job on this deliverable, and I want you to ignore existing errors or omissions in the design.

Result if statement accepted: Projects do change, but the existing errors in the design most likely will not be covered by those changes.  At testing, the same errors will re-appear, but the cost to correct them will be much higher at that point.

 “This really doesn’t add that much value to the project; by skipping it we can put more resources on configuration”.

Translation: We are over budget and behind schedule; the project is beginning to cut into our (the consulting company’s profits).  Yes, we told you this was an important deliverable, but now we’re just looking to get finished as fast and as cheeply as we can, so forget what we said at project kick-off.

Result if statement accepted:  The project moves from a planned and controlled group of related activities to a free-for-all implementation jamboree; with some consultants doing very good work, and others not doing so well.

In summary, you should watch out for leadership attempting to change expectations on Blueprinting / Design deliverables.  Giving into these informal changes drastically increases the probability of rework, and its associated costs, later in the project.