Let’s talk about the WMS Conference Room Pilot. We’ve seen literally hundreds of them over the years and have played different roles in those from software vendor to consultant to customer. The one thing in common across all of those projects is that a poorly executed WMS Conference Room Pilot makes your path going forward infinitely harder than a well-executed one. Why is that?
First, let’s define a Conference Room Pilot (CRP). We believe the CRP is really a sales process where the core project team’s objective is to get buy-in for the proposed future state solution (that it will satisfy the needs of the business). During the CRP process, anywhere the business is not comfortable with the proposed solution is called a gap. A gap does not necessarily mean a software change; a gap can also be solved by a procedural or requirements change. The job of the CRP is to present a mostly working future state solution, identifying any potential gaps in software or processes and giving the business a voice and opportunity to buy into that future state solution. If you have a bad CRP and fail to instill confidence in the business for the proposed future state, the change management necessary to get the system accepted in User Acceptance Testing (UAT) and, ultimately, installed at go-live will be significantly greater than if your CRP is well-executed.
So how do you have a good CRP? We believe it is all in the preparation.
Before we go any deeper, let’s get some of our assumptions out in the open. Prior to a CRP, we are assuming that there have been three steps already taken. First, is there a well-defined Business Requirements Document that does a very good job of identifying all critical requirements of the business? If your future state solution is based on bad, outdated, or even unknown requirements, your CRP is going to be more of a discovery vehicle than a design validation vehicle. If you are doing significant discovery in the CRP, that means you are not really ready for it and the business is going to be left with the impression that you really don’t understand their challenges and how to solve them.
Second, is there a complete Current State Description that fully describes all current state processes necessary to carry out all of the functions of the business, in either the Warehouse in the case of a WMS, or in the Transportation Office in the case of a TMS? This will be very helpful to review with the business itself to level set what is done today before you move on to what will be done in the future. The rest of the business will have confidence that you understand what’s currently occurring if you can accurately explain it to them. You should never conduct a CRP if you have not conducted a current state review with the business.
Third, is there a Future State Description where the Business Requirements Document and the Current State Descriptions are combined into a plan for how the new system(s) will handle the business processes? Ideally, there has also been a Proof of Concept session(s) to model and validate some of the more critical or complex processes so those are flushed out well in advance of the formal CRP. Remember, we don’t want to be discovering new things during the CRP, only validating the future state.
More simply stated, if you know what the business needs, you know what processes are necessary, and the CRP is to demonstrate a working system with those processes as they may be performed in the future. If you have pre-identified gaps between what the future system can do and what the requirements dictate must be done, you will also have some ideas of workarounds or changes that can be done to the software or processes and you have also validated the requirements are necessary.
Assuming the proper preparation has been done, we’ve found that the most essential item in making a CRP successful is good scripting of how the CRP will be executed.
As we like to say, “We’ve never seen a good CRP performed without proper CRP scripts – and we’ve never seen a bad CRP happen with proper CRP scripts in place.”
Using the CRP Scripts, have your presentation team hold dry runs of the CRP sessions until they can execute the scripts without issues. The scripts will allow you to practice the flow of the CRP before you have a live audience – and the scripts will also help you keep your CRP presentation focused and on track and not dragged into too many different directions. Practicing is critical to not only understanding how much time it will take to present (multiple by 2 for Q&A, gap discussion, bathroom breaks, etc.) but also confidently presenting the information to the business.
Armed with your well-oiled CRP scripts and an understanding of how long it takes to run through them, you can now determine how best to hold and conduct the CRP. Keep in mind that people have a limited span of attention and they each have day jobs that don’t stop for a CRP. We’ve found that one of the best ways to proceed is by holding several CRP sessions focused on a specific set of functionality, inviting only the people you need for buy-in each time. This might mean that the CRP session to cover inbound dock scheduling is held for only 2 hours and has a different attendee list than the CRP session held to cover picking which might last 6 hours. Or you might have a very simple operation where it’s possible to have a continuous CRP and cover all functional areas in a few solid days. We strongly feel the focused sessions approach is superior to the marathon approach; by breaking up your CRP into sessions it will keep your audience better tuned in and get people to fully pay attention to what you are presenting.
In our next post, we’ll talk about what to do with the gap list that comes out of CRP sessions.
Missed Part 2 of How to Have a Great WMS Conference Room Pilot? Click here to read Part 2.
Missed Part 3 of How to Have a Great WMS Conference Room Pilot? Click here to read Part 3.
Missed Part 4 of How to Have a Great WMS Conference Room Pilot? Click here to read Part 4.