I’m sitting in the Denver airport just after what they hope is their last major snowstorm of year. I was brought in this morning to help a company evaluate BPM software. My BPM evaluation meeting was cancelled due to the snow (I thought everyone here drove 4 wheel drive vehicles) and had some time to think about the processes different customers take when evaluating BPM products. Brandon Dean previously wrote a blog post on preparing for a BPM POC and having helped companies conduct over 40 Proof of Concepts (POC) in the last few years, here are a few tactical items I’ve learned while engaged in POCs.
- Begin with the end in mind – You don’t have to be the quickest bunny in the forrest to realize the process you select is the foundation of a BPMPOC. My absolute least favorite process is doing “Employee Termination” process (what message are you trying to send to your employees). My second least favorite is the ubiquitous “Conference Room Scheduling” process (while this might help one or two administrators – it does not provide the strategic business value you’re after). The process you select either gives a good first impression or a poor one that trivializes or creates a misunderstanding of the value of BPM. My favorite processes for POCs I’ve done are client onboarding and order management. Both of these provide strategic value and will have the strong executive sponsor you need to help bring in BPM. The process needs to be interesting (e.g. parallel activities, external notifications) and it needs to integrate with representative services and databases. Be careful to scope the process correctly. Having the vendor create a process with 100 activities adds little value. Having a process with 15 activities is about right if interesting rules and process design patterns are associated with it.
- The Goldilocks Phenomenon– One or two days is too short for a POC. In a short POC, the vendor has to drive the entire way. The vendor is an expert at making their BPM software look easy, but all your evaluation team will only remember will be a blur of screens popping up in a two day POC. Anything over 2 weeks is a pilot project. POCs that are too long ties up your staff and will needlessly cost you more money (you will typically have to pay the vendor to conduct the POC if it is over 2 weeks). As Goldilocks would say, a POC of about one week is just right. You won’t be an expert, but at the end you’ll have quality time with the vendor, have some hands-on experience with the tool, and have time to learn quite a bit about the product. If time is managed well, you can see everything you need to see to make a fair evaluation in one week.
- Creating the Evaluation Team – Keep your evaluation team to about 5 people. The mix should include a leader, someone from IT, someone from the business and an architect. I’m a huge fan of companies who involve end users in the evaluation process. Everyone thinks of including the enterprise architects, business folks and technical wizards on evaluations. When I see an end user in the mix, I know that this company is doing their best to get their buy-in from the very beginning. When carefully selected, this end user will become a consistent and much needed advocate during the first project. Try your best not to go over 5 people on the evaluation team. Most time it results in chaos.
- Keep an Eye on the Vendor – You can go to every BPM conference Gartner or the BPM Institute offers this year, but you will still not gain the practical hands-on experience you would have gathered during an on-site, one week POC. I hate to say it, but some vendors are rascals who will do work out of a hotel room during off-hours to bump their productivity. Your staff needs to stay engaged and in the room with the vendor during the entire POC. Have the vendor create a schedule before the POC starts. This will help you determine the times when the business representative absolutely needs to be present (e.g. process modeling, business rules). Similarly, you’ll know when the technical people on your team needs to be present (e.g. integration, logic, BAM, UI). I’ve conducted POCs when no one from the company was present during the entire time. Use this time to help get a running start for your first project.
- Make the Installation part of the POC – Run the software from hardware inside your firewall. This will make it much easier to ensure the software is a fit for your hardware environment. Integration needs to be a key element of your evaluation. Unless the software is installed inside your firewall, integration to your components is not going to be possible.
- Follow the Leader – A strong POC leader needs to be present during the entire POC. You want people on the evaluation team who are not afraid to express their opinions or ask questions. This means that sometimes a leader needs to step in to help the vendor manage her team’s questions and make sure things stay on track. The leader absolutely has to be someone the team respects and someone who management will listen to once the POC is complete.
- Why Can’t Everything Just Work the Way It’s Supposed To? – POCs are a small microcosm of how a real first project will go if you move forward with a vendor. There are going to be things that go wrong during every POC. What’s key is to note how the vendor responds during the POC. It’s a pleasure when you’re working with the best. When something goes wrong, they know where to look and take pleasure in showing you how they debugged the problem. This also lets you see how well the tool helps you to diagnose problems. Problems during a POC also let you learn more about the team you’re working with. How did the team get along? Did they help each other? Problems during a POC are great opportunities.
- Final Presentation – I like it when the evaluation team delivers the final POC presentation on the last day of the POC. Here’s why I like the team delivering the presentation instead of the vendor. First, your team will be infinitely more engaged during the POC if they know they will be presenting to their managment on Friday. Second, the presentation you give will be fair to each of the vendors but will not have the marketing slides that drives most executives absolutely nuts. Most vendors will simply do a feature dump and a click-by-click demonstration of the solution (preceded of course by their marketing slides). Your team will instead focus on how this tool solves specific pains your company currently has and how it will help achieve your company’s strategic objectives.
- Do it! – I’ll always encourage a company to conduct a POC during a BPM evaluation. I’ve seen BPM software brought in that turns into shelfware because the company did not understand its capabilities or ease of use. While RFPs and vendor demonstrations are a necessary part of enterprise software procurement, I recommend including a POC as final evaluation hoop.