Conference Room Pilots (CRP) are a great way to give end users hands-on time with a system or new software before it is fully developed. CRPs are often used in information system implementations, such as Manufacturing Execution Systems because it gives users an idea of how the new software will work. This provides many benefits such as catching any missed requirements, including new people in the process, and preliminary testing.
Conference Room Pilots should be held when end users need to “touch and feel” the system to understand it. It is easier to give feedback and let the developers know if a screen will work in real life if they can see an example. CRPs are also a good tool to use to help engage end users or outside team members. Information systems are not developed in a bubble. By showcasing the work in a CRP, any trouble areas are made transparent between teams, making them easier to fix.
5 Steps to a Successful Pilot
Be prepared with “real life” data
The implementation team understands that the system is still in development at the point of the pilot and test data may be the only data in the system. However “real life” data should be used to help the end users know what they are looking at and to help them confirm that the system will work for their needs. For example, if your system is around finance user numbers and categories that resonate with the users instead of any made up numbers used in testing.
Understand who the attendees are before the conference room pilot starts
CRPs are for larger audiences than the core project team. They involve the end users who most likely will not get to see the new system until training. By understanding who these end users are you can ensure they are attending the right sessions. You can also prepare the exercises according to their skill level.
Make sure all attendees understand the purpose of the CRP
The conference room pilot should have a flow, where the beginning session explains the outline of the CRP and the system overview. The following sessions become more detailed as the pilot week continues. Make sure the attendees understand the flow of the whole week so they do not show up only to certain sessions. This will help to cut back on repeating the same information over and over, keep content fresh, and attendees from becoming bored.
Ask prompting questions
Many times end users are not sure what comments to make about a new system. They may think that “what I see is what I get so I just have to deal with it”. Not so! Make it clear that the purpose of the CRP is to hear their feedback and to make the system as easy to use and efficient as possible.
You may also have one person speak out and everyone else agree with them instead of voicing their own thoughts. By promoting the group with questions it will help to open discussion and make way for attendees to voice their own opinions.
Schedule it at the right time
Make sure you schedule the CRP where the most people can attend. Also, make sure the CRP happens at a good time in the development process so as not to mess up the development team.
*Bonus Tip* bring chocolate. Seriously.
Photos from today’s post come courtesy of #WOCtechchat