Client Training or Formal Testing?

Late last year, I had a meeting with a client that we had geared up and planned as an early training meeting. Unfortunately, when I went through the training with the client on the day, we faced all sorts of problems including bugs, software errors and not to mention a delay on the server. Ultimately, this experience was costly and ended up leaving the client questioning us, and us feeling a lack of professionalism. During a later review of the meeting, we discovered that the meeting was actually very productive. The meeting had allowed us to uncover the errors that could only be properly found through the exploration in primary user scenario testing.

We were also able to reevaluate our own management processes and discover that our project charter hadn’t properly considered some very important tasks. This allowed us to deliver a more refined product. We then decided that the meeting was important, and to keep it, but the trick was renaming and thus reframing the meeting context for the client so that expectations were properly met .

Instead of labelling the meeting an ‘Early Training Session’, we decided to label it a ‘Formal Testing Session’. Reframing the meeting context reframes the expectations of the client. As a Formal Testing Session, we’ll still be able to meet our goal which is Training the Client, and just as importantly, the client would be able to help us go through the project as an administrator, and iron out the bugs encountered in that particular and very important user scenario.