15. Unclear contents for templates---No Standards

Symptoms: The SAP ASAP methodology is replete with templates and implementation partners will offer a plethora of templates for testing, drafting test cases, gathering requirements, documenting specifications, etc. Providing or handing down a template from one team to another does not address a critical issue what level of detail is necessary to fill out the contents of a template? 

Given this issue it’s natural to see how even the best templates fail to capture the necessary information for requirements, specifications, and test cases. 

As an example one of my previous projects had templates for drafting detailed requirements, and specifications which were deliverables during the blueprint phase and the various functional teams drafted the detailed requirements and specifications to their best of their abilities.  

When independent reviews of these deliverables were conducted the auditors determined that many of the functional teams had deficient and insufficient contents and information for their specifications and detailed requirements. 

The independent reviewers determined that the templates did not meet minimum criteria, and the deliverables needed to be re-written. Much time was wasted in re-writing the specifications and requirements which delayed the blueprint phase and increased project costs.  

Suggestions: Templates are terrific for helping the project team collect and document information. However a better approach to just handing out templates would be to provide standards, guidance and instructions for filling out the contents of the templates. 

Set up a kick-off meeting where all affected parties get specific instructions for filling out the contents of the templates. Provide samples of well constructed templates to the audience. Also provide the criteria that will evaluate the quality of the filled out templates.  

Do not wait until the due date to review all the templates. Templates should be evaluated early and gradually as they become available which allows for corrective action without much impact to the project schedule in the event that team are not complaint with the established standards for filling out the templates.  

Conclusions:

The author exposes and reveals perils to the SAP implementation that need to be addressed as early as the requirements management phase. The suggestions for overcoming these perils include involving SMEs for capturing requirements, scrubbing requirements, end user hands on execution during UAT testing, transport management tool, and advocating the use of automated test tools. 

The author based on his experiences has witnessed how one or more of the perils above has crippled other ERP projects and believes that planning for these risks with proven techniques will increase the chances of success at most ERP implementations. 

This article has covered 15 risks to your SAP Implementations. We hope you found it interesting and useful. Please post your questions on the messageboard.