Going to be Guilty!

I had a conversation recently with someone who had a need for a software package to handle a series of transactions similar to those found in a law firm. In fact, the operation he ran was aligned with a legal department that used just that software package, and it appeared to be a perfect “fit” for his needs as well. He just needed to get his own license, installation, and training. So he found some funding within the larger organization for his needs.

But, before he could execute his contract with the software provider, a Information Technology Director interfered with the process. I purposely did not say an Information Services Director as you’ll see in a moment. This IT Director was “pulling rank” as they say, and claiming to take the funding for his own department, which would “build” a suitable application, instead of purchasing the off-the-shelf, good fit software package.

To me, this seems a purpose case for a system headed straight for “Guilty as Charged.” The amount of money was a small fraction of the logical cost for developing a system as robust as the desired package. The path for custom (“bespoke”) software is clogged with failed system development projects of all sizes and shapes. On top of that, the Director’s stated reason was that he had staff that needed to be kept busy. Bad idea.

The correct service option for that IT Director would be to put on a customer service hat, and understand that the software package firm would indeed install the package, convert the data, and provide ‘training’ to the end users. But an experienced and open minded Director would also know that packaged software vendors have a limited budget for training, and that end users typically need much more training to fully integrate a new software package into their policies and procedures, even when it’s providing all the needed functions. The missing piece is a “business analyst” (or BA) that is “embedded” and “lives” in that line of business operation for a long enough time to accomplish that deep integration of the software package into the daily business operations and reporting.

So there are two critical functions needed for the success of the highly functional packaged software offering:

Sufficient analyst time to understand and document the business requirements, learn the new package and work with the vendor’s trainings to envision and document how it will be used, and what training is needed; and then deliver and reinforce (and adjust) the training until the package is fully adopted and successfully integrated into daily use. This will take far longer than any software vendor will be on site (or you can afford to hire them).

Most packages today have extended feature for reporting and analytics that never get deployed because they are not used on “day one” and you don’t have the business analyst on staff to take on their learning and deployment after the initial go-live. This is the second area where the BA is extremely useful. The BA will work with the “super users” – those most adapt with the software – and with managers to understand how to best use the data being collected in the system as information to improve the business processes and results.

So, when you’re working with packaged software, and the “IT” department says they can “help” you, ask them to help you with #1 and #2 above. It will transform the relationship into of service, and everyone will be far more satisfied with the result.