Lesson Learned: Show Me, Don’t Tell Me
An important lesson I learned long ago in dealing with software quality was the concept of show me. Simply having someone tell me that a task was complete is not good enough – show me what it looks like and how it works. With my software architect hat on it does not stop there – show me how you coded it is my final litmus test on a work product. This can be very tedious when you have 5-6 people working on disparate work products that all have to come together, but it is imperative that inspection takes place at that level.
When dealing with vendors, the concept of 'Show Me' has become even more important. Competition is rough out there and there is a tendency to oversell a product. When working with vendors to evaluate a potential product purchase, not only do you want to ask "Does it do X" but you need to see it in action and know whether that functionality is out of the box or not. On a recent project, we knew many of our use cases and queried the vendor with those that we knew. In a couple of cases, we were presented with responses that the product meets that requirement – and in one particular case a blog entry even contained a short movie clip demonstrating one of the use cases. The gotcha was the screen cap was only a partial screen (you could not see that the user was using Firefox) and there was no indication of whether this was out of the box funtionality or not. I was quickly able to determine that it was not OOTB and required a GreaseMonkey Firefox extension (we are an IE shop).
Supporting GreaseMonkey and the extension for 35,000+ potential users was not something we wanted to take on without vendor support. By the time I determined that some smoke and mirrors were in play, the cat was out of the bag and people were looking at the wow factor. Clearly defined product boundaries are essential when looking to integrate software off the shelf with your environment.
You may ask, "how do you mitigate this risk?" I think the main lesson here is that IT needs to go through the use cases with the vendor without the business representatives there initially. There needs to be a common front presented when the business interests are viewing the product and any grey areas should not be answered in a manner that sounds definitive – rather they should be tabled for investigation and response offline. Establishing this type of protocol between the IT specialists and vendor should lead to less confusion downstream with the business team. And at the end of the day, that is why the business team brought you in the loop.