Nowadays any initials thrown together from the name of an organization, a person, or a process is referred to as an acronym. I guess I’m old school, because I remember at least a few of my middle school lessons, where I learned the difference between an acronym and initialism. In order to be an acronym, it has to be pronounceable. Otherwise, it’s just initialism. So, FBI would be initialism. NASA would be an acronym. And if your Conference Room Pilot (CRP) has crossed the threshold from initialism into an acronym, meaning you find yourself pronouncing CRP either loudly or perhaps under your breath, your project is in trouble.
Understanding the purpose of CRP, and a few basics about how to run one efficiently, will help keep your project on track.
CRP vs UAT
Your Conference Room Pilot serves a specific function. It’s an opportunity for your users to test both the design of your Product Lifecycle Management (PLM) system and also to provide input for modifications. This activity occurs after the initial design phase and configuration. Hopefully you’ve documented the design requirements including object types, attributes (fields), list attribute values, and page layouts. While these are being deployed, you should write out use cases and/or test cases/scripts that will be used to verify that the system works as expected. Once the design has been implemented, it’s time to let your test users loose on the system. How much time depends on the complexities of the new or updated design, as well as how compact or lengthy the timeline is for the project.
An overly aggressive schedule might mean skimping on your CRP, which you will likely pay for later in your UAT (User Acceptance Test) phase. All the suggestions and unspoken requirements that weren’t specified during the initial design phase or CRP will raise their head at UAT.
A prolonged schedule invites a never ending cycle of changing requirements and new input. But that false sense of security, the idea you have plenty of time, could put your schedule and design at risk if you don’t lock it down. All changes should be in place and verified before a complete system UAT is performed.
As with Goldilocks, it’s best to find a sweet spot in between.
Your UAT happens after all the input and modifications have been addressed. Your verification scripts get updated accordingly, and are executed to confirm the system meets your documented requirements. Most schedules don’t allow for changes at this point, so requests for design changes could put your timetable at risk. This makes it doubly important that your CRP be as thorough as possible.
How to Conduct an Orderly CRP
Your test users will use scripts and/or use cases to assess the system and log their findings. They’ll record expected behavior vs. actual behavior, as well as pass/fail information. Many companies divvy up the scripts and send the users off to do their part. Ideally, your CRP should be performed in an actual conference room, where the users can discuss and learn from others around them. When you have several testers running through the same scripts, or are performing different roles in the same script, it helps to have a leader to direct the users through the use case together. When I say leader, I mean a drill sergeant, calling out the steps one by one, keeping everyone focused and on queue. You’d be surprised how quickly and efficiently you can get through the scripts when you have someone acting as the guide. It also means there’s someone there to answer questions if the test users run into an unexpected result, list of values, or process step.
Defects and adjusted requirements can be logged by the users into a single, central location. I highly recommend that a designated super user, business process owner or project manager review the log to confirm the appropriateness of each request. Recently I had a set of list values that, as soon as I updated it per a user’s request, someone else would ask to change it back, or make some other updates to it. By the third round, I told the PM they needed to approve all changes before they would be deployed. The defect log is not the place to hash out differences in needs or preferences regarding design elements. The business process owner(s) need to align competing requests before your implementer, whether an internal resource or a partner, makes configuration updates.
Include Time for a CRP2
Some schedules may allow for both a CRP1 and a CRP2 phase. This second pass provides time to test any corrections or design changes before heading into UAT. Previously missed gaps or defects can be addressed, and end-to-end demonstrations of business processes can be demonstrated. It’s also a great time to make sure all of the necessary validation scripts or use cases have been updated include the input from CRP1.
The Rewards of a Well-Run CRP
The time you invest in a thorough, orderly CRP has multiple payoffs. It provides training and input opportunities for your core users. Business process owners can ensure their needs, whether data collection, reporting, approval steps, or feeding downstream systems, have been addressed and incorporated. Communication between the business team and the implementers has a formal process that improves accuracy and timeliness for design deployment. All change requests are tracked and reviewed, with an easily identifiable status. The implementer and project manager can ensure that all feedback is responded to and closed in a satisfactory manner.
All of this leaves you well-prepared for a smooth, expedient UAT. Which is exactly what you want. No defects. No new input. Just the pathway to a greenlight for launch.
And hopefully, there won’t be any need to mutter CRP under your breath.
Sign up now and make 2024 your year of breakthroughs in Agile PLM!
Disclaimer: The views and opinions expressed do not necessarily reflect the views and opinions of Domain Systems. The author takes full responsibility for the views expressed here.
