Ever been on a project where your client has already chosen a package solution? How many times has it been based on a solid set of business requirements, complete with all those great models you can read about in PMI’s Business Analysis for Practitioners: A Practice Guide?
In my experience, and I won’t mention any names or locations to protect the innocent and avoid shining a light on the guilty, business requirements for packages can be very sketchy, often based on a document listing many unsorted and uncategorized sentences meant to represent requirements. In the worst cases business requirements can even be overlooked entirely.
Why do you suppose people feel that because it is a package, it will have all the necessary functionality for a business, and that if it does not, the business can adapt? Or that the package can be modified to meet requirements at little cost?
Familiar with the famous term “fit gap”? This is where requirements, however they are documented, are compared to package functionality, and the package with the highest score wins. Sadly, such analysis is often performed at far too high a level. And worse still, the number of requirements that cannot be met are often presented as the inverse of “percent fit”.
Sadly, the cost of changing a packaged solution to meet the 10% of requirements it doesn’t meet can often be greater than the cost of developing something to meet all requirements from scratch. Or, the 10% some other package didn’t meet could possibly be met at a much lower cost, or even eliminated altogether if they were a low priority.
It’s a bit of a conundrum, isn’t it? Do you spend time and money defining your business requirements in advance of making a build or buy decision when you know quite well that you are going buy a package regardless of what requirements are discovered? Are you just going through the motions? Or maybe you think your organization can adapt to the business model upon which a package was built, thinking that the package represents best practices in the associated business.
I believe no matter the route you are choosing, eliciting business requirements from the beginning and defining and managing the detailed requirements will bode well for any organization so that they can measure the success of whatever decision they make to achieve their business goals. After all, if you don’t ask the questions, you will never know the answers!
What has been your experience with the installation of packages that have been installed to satisfy specific needs? What about ERPs? Have your clients/users been satisfied with the result? Were requirements sufficiently defined prior to package purchase and installation so that a baseline comparison could even be done?