Microsoft Dynanics Manufacturing and the Conference Room Pilot
Posted on: June 18, 2014 | By: Jim Bertler | Microsoft Dynamics Manufacturing
It is common practice for companies engaging in an ERP project of virtually any size and complexity to execute a Conference Room Pilot (CRP) to achieve a level of comfort that the changes being implemented will fulfill the mandate of the project. An implementation of a Microsoft Dynamics Manufacturing solution is no exception. A CRP, sometimes also known as “End-To-End” testing, is typically viewed as a major stage gate for a “go/no-go” decision on the project plan. Therefore in this article we will examine the Top 5 CRP Project Killers.
There are several characteristics of an insufficient CRP.
1) Development not completely ready, so it’s “black boxed”
Any development included in the scope of an ERP project must be included in a successful Conference Room Pilot. Often, development included in a CRP process script that is not ready will end being a “black box”, where the results of the development are manually mimicked. Clearly this increases the risk that when the project is implemented, the development will not perform as expected.
2) Data not a full representation of the business.
The gathering and loading of data for CRP is a difficult requirement, but is nonetheless important. Unless the data is being manually entered or being converted from legacy systems through a program, users are typically extracting, collecting, and manipulating data in spreadsheets for submission to a team for upload. Because a CRP may be weeks or months before the anticipated go live date, a full dataset may simply not be available. It is imperative that the data that is included be a thorough representation of the scenarios being tested.
3) Scenarios not all inclusive
A successful Conference Room Pilot will not simply address “sunny day scenarios” that follow a particular business process without any glitches. The CRP must include scenarios that may include bad source data, mistakes made by the users that need to be corrected, and even something as obscure as what to do when the power to the server room has been knocked out. The confidence of a team going into an implementation comes from the ability to say that they have tested virtually every conceivable circumstance that might arise, and there is a process to address it.
4) Lack of Participation from NON Core Team members
ERP implementation projects are usually time intensive endeavors for several business members, some investing 100% (or more) of their available time to the project. During testing, it is often useful to involve NON Core Team members to at least observe the testing process. This not only can serve as a very useful training exercise, but the person that is added to the testing may come up with more scenarios and questions that need to be tested that the Core Team had not thought of.
5) Lack of Validation of documented work instructions
When the CRP is being executed, it is common practice to audit process scripts, procedures, work instructions and cheat sheets. A common misstep during CRP is to allow the findings and discoveries of the test process to get into the documentation. There might be short cuts, reports, audits and inquiries that are useful to the end user that would ideally be included in the documentation.
If you want to learn more about successful project management and Microsoft Dynamics Manufacturing implementations feel free to contact Logan Consulting.