How many times have you heard this statement (or something like it)? Sometimes it seems so much easier to buy a software package than to spend the time thinking about what we need and how we want it to work. “There must be a package out there somewhere that we could use.” In many cases this is just wishful thinking. Although there are thousands of software packages for sale, more every day, the chances that a package will support your true business needs without customization is low. Of course, there are applications that follow standard processes like many accounting/bookkeeping applications. Those are great opportunities to use something that is already written. But even in those cases, we still need requirements.
I know that I am preaching to the choir when I tell Business Analysts that we still need to analyze and document requirements, even when we know that we are going to buy a package. How can we help others see the value? How can we convince our business stakeholders and management that they should give us some time to do some research, document requirements and find the package with the best fit for our organization? My answer is with questions. BAs are excellent at posing questions that help their stakeholders realize the importance of analysis. How well does the XYZ package support your underlying business function? How many users will it support? How much data can it hold? Are the reports useful? Easy to generate? Will our procedures/organizational structure have to change to use the new software? How much training will be required for users?
You know the drill, develop lots of questions and keep asking. When you see hesitation on the face of your executive sponsor or manager, quickly jump in and offer to help. “How about if I put together some ideas and try to answer some of these questions before we start the contracting process?” We continue to help our organizations understand the value of requirements analysis (and the value of Business Analysts!) when we ask good questions and then offer to help find answers.
4 Comments
Great point, Barbara!
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.
The key is to gather the requirement prior to purchasing a package. These requirements should serve as your guide in determining if a package will meet your needs prior purchasing it. This approach should identify customization issues up front, thus giving you an accurate picture of budget issues and package constraints.
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 recently went to an auto dealer agency to check up on few mid-segment cars and was “handed over” to a sales consultant for furthering the interface.
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.
Jimmy, I enjoyed your story at the car dealership. I just had a similar experience at a shoe store. The clerk was having a hard time ringing up my order due to their new software. She had to use the mouse for some things, then use a touch screen for others and she complained that it was really slowing them down. She said that on Saturday they had a long line of customers waiting because they had not been given any training. They want the old system back!
They need a BA!!