A few weeks ago, I wrote about the role of the project manager on system testing. While by no means the sole reason for projects breaking bad, in many cases a misguided or incompetent PM can exacerbate problems. Today I want to focus on end-users kicking the tires of the future system. I’ll offer four tips designed to improve the results of testing.

CRP 101

All major system implementations with which I was involved at some point entered conference room pilot. From Wikipedia, its purpose is:

to validate a software application against the business processes of end-users of the software by allowing end-users to use the software to carry out typical or key business processes using the new software. A commercial advantage of a CRP is that it may allow the customer to prove that the new software will do the job (meets business requirements and expectations) before committing to buying the software, thus avoiding buying an inappropriate application.

Now, I never conducted or participated in a CRP in the context of evaluating a new vendor’s solution against others. (Maybe the projects generally would have had better results if we did, but it’s key to remember that CRM and ERP cloud- and SaaS-based offerings are relatively new.) Instead, I performed CRP after the following had taken place:

• Contracts had been signed
• Money had changed hands
• The business requirements had been gathered
• The system had been configured
• The employees had been trained in how to use the new system

In CRP, the team and I would run scripts designed to simulate real-world activities. Examples included paying vendors, matching a vendor’s invoice, paying employees, processing terminations and promotions, etc.

Getting busy employees to take testing a new system seriously is usually no small endeavor.

As someone who’s written and executed hundreds of scripts in his career, here are five lessons learned–usually the hard way:

Follow the scripts precisely.

This one should be fairly obvious. Run through a script by precisely following directions. Did the vendor’s check clear or not? Check it out.

After completing the existing scripts, go back and intentionally deviate from them.

The goal here is to see if something breaks. Do step 5 before step 4. What happens? Did you cause the system to crash? It’s better to know during system testing than when live.

Make mistakes on purpose.

Try putting an alpha value in a numeric field. Try to cut a test check for $10M. Did existing safeguards stop you from committing the error? If so, then your confidence in the new system augments.

Make up your own scripts.

No, you can’t account for every conceivable scenario, but don’t be afraid to invent a few along the way. What happens if you need to reverse a check or a sale? Is that easily done?

Get employees in a dedicated area.

Trying to do CRP at your desk is unlikely to work. Life intrudes. E-mails come flooding in. The phone rings. The result: Employees test the future system in a half-assed manner.

Simon Says

Getting busy employees to take testing a new system seriously is usually no small endeavor. Remember, they have day jobs and organizations still need to to overcome the practice mentality. Follow the advice in this post, however, and you’ll be more likely to spot issues as early as possible.