There is a good article on the Requirements Network Group on Modifications to COTS by Bill Flowers. www.requirementsnetwork.com I’ll be talking about Developing Requirements for Purchased Software (COTS) in Atlanta on July 21st at the SPIN (Software Process Improvement Network) chapter meeting. www.atlantaspin.org
These are both important topics for project managers and business analysts. As Bill points out, the big software vendors like SAP and Oracle traditionally focused on large companies as their customers but are now realizing that small or medium size companies have the same needs. As a business analyst in one of these small to medium sized companies, you need to be prepared to discuss the costs and benefits with your stakeholders. Software vendors will sell to your business stakeholders, convincing them to purchase rather than build software applications.
BAs have not always been involved in software selection decisions so if you hear about an evaluation process in your organization, try to get involved. Requirements are critical for selecting the best package and should be done before vendor evaluations. When the business doesn’t have a clear, shared understanding of what they need, they will select a package which looks good and is well presented. The underlying functionality, design, and/or performance may be lacking. We need business requirements (data, process and business rules) along with high level functional requirements, non-functional requirements and transition requirements to make the best selection. The IT group should also have technical requirements for vendor packages. All of these requirements should be presented to the vendors in an RFP. Ask vendors to respond to your requirements rather than choosing the best sales demo!
2 Comments
Barb:
Having worked on the other side of the COTS BA negotiation table, I can say that when I hear the phrase “Ask vendors to respond to your requirements…” I get a chill up my spine. That is guaranteed to send any product manager into fear mode, at least momentarily. I personally would like to hear from you and your readers about what that phrase actually means.
Here’s my main reason for wanting to hear from BAs on this topic: a piece of COTS software has a feature set that is based upon the generalized requirements elicited from multiple SMES (customers), perhaps thousands. Essentially, the development of a single feature may be negotiated over time with those SMEs, and when a potential customer (SME) sits across a new negotiation table asking the COTS product manager to “…respond to my requirements…”, the product manager may be incredibly close to alienating a potential customer who wants to play “hardball” with the sale, demanding modifications to meet their “unique” needs.
There are legitimate times when a BA has to meet generalized business need with a COTS solution, and times when a solution may need to be modified to meet requirements that are truly unique.
Do you, as a BA, know the difference between the two? At what point do you ask the hard questions of your own SMEs regarding business “uniqueness”? How well do you understand your own business domain, both internally and across the industry? And, finally, to Barb’s final point, are you capable of looking beyond the flash of a sales presentation, and see into the real capability of the COTS product?
Those are challenges to the BA community.
Specifying requirements before vendor evaluations is necessary to choose “the best fit”, I don’t think the purpose is to demand modifications to meet “unique” needs.
I’m not saying that they modifications aren’t negotiated, but again, this is not the main purpose of specifiying requirements before evaluation.