The Technology Side of GRC

Pravin Kothari

I hope I made it clear in my last blog the difference between true OOTB and Pre-Assembled applications, which often require development to meet your needs.  Sometime it is very difficult for a customer to tell the difference during the product selection process.  Applications requiring customization can be made to look very slick, like a movie trailer.  It’s amazing what a good sales engineer can do – they are not any less skilled than Hollywood artists.   So how can you determine if a vendor is selling OOTB or Pre-Assembled application?  The easiest way is to just go with an authoritative source if available.  In the IT GRC space, take a look at reports like Gartner’s MarketScope for IT-GRCM.  If you want more details, place an inquiry call with the analysts that wrote the research.  In Gartner’s case, you would want to talk to Paul Proctor.  Remember that analysts like Gartner will never outright endorse a vendor for a number of reasons, however, they can help  you determine what type of technology is best for you, whether OOTB or something else.  They can also tell you which vendor is really in which category.  As part of their research, they talk to many customers who have actually used the products and can give you examples supporting their recommendations.  If you have access to these analysts, you should not hesitate to request for an inquiry call.

The most bullet-proof way to validate this is to get your hands on the product.  There are many different ways you can do this as well.  Proof-of concept (POC) is a popular way.  In a POC the customer gives vendors use cases and ask them to come back and show that the tools can meet the use cases.  It is debatable how useful is a POC if a vendor is willing to invest in building customization for the POC and represent it as standard product functionality.  Another approach is a Sand Box.  This requires a vendor to provide an environment to the customer where they can play with the software without the vendor looking over their shoulder.  This can be effective if it is done correctly.  There are two wrong ways to do this.  If you give a vendor detailed use case and other data so they can provide you a custom sand box, then you are not that better off than just a POC.  If you just ask for the generic product and play with it without any training, you will likely get frustrated and not be able to explore some of the more advanced functions.  Anything you can use without any training probably doesn’t have enough flexibility to meet your needs.  The recommended way of doing this is to go through the vendor’s standard training course and ask for a generic evaluation copy for two weeks.  Go through a fruit-fly version of the deployment experience on your own and see what exactly is OOTB.  Allow a vendor to hold your hands along the way and even make recommendations on how to do things, but don’t let them do anything for you.  Some people call this the “touchless POC”.  You may have to pay to attend the training and you will have to have technical resource available to support this, but it’s a pretty small price to pay if you see how much effort some customers put into their RFP and POC processes.

Another good acid test is to look into upgradability of the product.  We’ll discuss that next time.