This individual seemed most informed about his domain, knew exactly what he needed to present to the prospect and kindle her interest further, knew exactly how he could make purchasing of the car easy for the prospect and even knew the art of striking an emotional consonance with her(My six -month old was ushered with half a dozen of astute compliments). On returning to his seat, he started to work on his computer terminal to enter data pertinent to the prospective lead scenario that my visit had generated. He seemed to be having a hard time figuring out the application’s navigation logic, and asked for the assistance of a few other sales representatives who also took a while to figure out the way to enter prospective ecustomer details and aspirations in the application. They apologized for the inconvenience that had been apparently caused to me and informed that this particular application had been brought aboard since a month ago and the sales team was still undergoing a learning phase. I was further informed that the way the earlier application worked was much different than the way this one worked although the advantage of this system was that it integrated with the auto dealer’s billing system.

The whole point here is that If a project sponsor fails to observe, understand and analyze the ways of work of the very individuals who contribute largely towards making a sale to the end customer, they are probably preparing to negatively effect the whole customer experience. The soft skills that these “agents of sale” inculcate need to be defintively complimented with system’s skills/capabilities. So much has been preached about usability aspects of applications today, and yet their exist some decision makers who do not account for this crucial aspect while purchasing an application to meet their operational needs.

This drives home the point (albeit the umpteenth time) that it is very crucial to do a requirement check before the management takes a final plunge at buying a software for its operations. The message to the buyers of COTS here is that they should not just swap systems because there is an impressive vision statement that their stakeholders have vetoed. The mandate to plant a new system in their organizational system should be backed by a clearly defined strategy to compliment and support the ways of working of their customer-facing personnel.

Many companies purchase packages prior to identifying their requirements. This method in my opinion is not the best as it may lead to budget problems, security issues, and resource considerations. It is still important to perform your analysis to ensure that you have done your due diligence in ensuring that the package will meet the business goal and objectives.

I remember an enterprise software project where someone asked “Why are we documenting the(se) requirements? We already purchased a package – isn’t it a bunch of wasted effort?”

People were questioning the value of documenting requirements that the purchased product would meet without modification. No one argued about documenting the requirements for things that required customization of the product.

The needs to establish context, provide perspective, and assure that the product/customizations didn’t evolve away from the underlying business goals ultimately won out. We not only had documented requirements, we had buy-in and exec support for them.

As a bonus, the requirements provided a framework for process re-engineering post-deployment.