Exploring the Who, What, When of Conference Room Pilots
I'll first start by saying this article addresses the mid-implementation conference room pilot. Many people talk about a conference room pilot as an activity in the sales cycle where you try before you buy. We tend not to do that because it's unlikely to be tailored enough to be a good experience for potential clients. If we did present something during the sales cycle we'd call that a "Hands-On Lab."
When do you host a Conference Room Pilot?
So if it isn't during the sales cycle, when do you host a Conference Room Pilot? At Stoneridge Software, a Conference Room Pilot (CRP) comes near the very end of the Create phase of the project when you are wrapping up requirements and custom development. It is done after the rounds of Joint Process Design sessions where you've gathered requirements and presented solutions for those requirements. It's really the last chance to get into the system and make suggestions before you lock in on the design with which you plan to go live.
Who participates in a CRP?
The CRP is administered by the implementation functional consultant which significant help from the technical consultant, who makes sure the environment or environments are ready to use. The functional consultants walks the users through the steps they should follow during the pilot and then sets them free to start going through the system. The users are typically the client project team plus key subject matter experts. If this is an enterprise implementation, you may want to seek participation from a wider range of team members with expertise in this area.
What do you cover in a CRP?
You would run separate CRPs for each process category that's in scope during the implementation. For example, you'd have a CRP on Quote to Cash which may include salespeople, warehouse staff and accountants who will participate in that process. The goal is to make it through the system end-to-end in a way that makes sense. You wouldn't invite your purchasing team to the Quote to Cash CRP - you'd have a separate session for Procure to Pay.
What do you hope to accomplish in a CRP?
The main goal is to find any last minute design flaws or changes in the system before you head into the deployment phase of the project. This is usually your first time to put the process flow together from end-to-end so you want to make sure the handoff between sales and warehouse or purchasing and accounting work as expected. You are seeking to validate the end-to-end process before it's too late to make changes to it.
What data is used during a CRP?
You usually haven't finished the data migration process by this time so you want to use a sampling of client data. By sampling, I mean a small, representative set of data using examples from production. The more breadth you can get in your sample, the better. You will not get a chance to test the full dataset until User Acceptance Testing.
What happens if you find problems in a CRP?
That is to be expected - you can start to identify bugs if you find them during the process but you're mostly on the lookout for design changes. You will still have a little bit of time to change your designs before they are set in stone, so you'll want to make those adjustments at this time. If you have to radically rethink a process, your timeline may be at risk, so let's hope that doesn't happen.
What happens after a CRP?
The next immediate step is to review the design feedback and schedule any re-configuration or new development work right away. Once that is all complete and you are code complete, you move to the deployment phase of the project.
What is the difference between CRP and UAT (User Acceptance Testing)?
They look very similar - and are very similar. In both case you're testing the process end-to-end with project team and subject matter experts in the system. The difference is the CRP happens during the design phase where you can still make some fundamental changes to the system if necessary whereas the UAT is during deployment where your primary aim is to validate the system and raise any bugs you find. In both cases, it's good to try to break the system to expose any potential issues that an end user might encounter in production. As mentioned in the data section, the CRP data is typically a sampling of the client data whereas the UAT is the full client dataset.
CRP can often be seen as an optional part of the implementation and we don't do it every time. I encourage clients to build it into the project plan as it accomplishes some important objectives as part of the project - 1) it gives the team a chance to practice the end to end process before UAT, 2) it helps with usability to have the team review the solution while you still have development time left and 3) it raises the confidence of the team if they have the chance to put the system through its paces before UAT starts. It's a valuable part of the implementation process and should be part of your next project.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.