Don't get COT[s] by your package!

From the Requirements Blog
Effective requirements collection, management and traceability plus smart PM practices equals project success.

About this Blog


Recent Posts

Caution: Agile Surface May be Hot

Organizational Change Management: The Most Critical Requirement of All!

Rethink Requirements: The Natural Language Processing Approach

Quality - Consider it in all Knowledge Areas!

Don't get COT[s] by your package!

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?


Posted on: July 07, 2016 03:00 PM | Permalink

Comments (2)

Please login or join to subscribe to this item
Thank you for sharing. After working from both sides of the desk talking about package (mainly ERPs) I could say that the reasons because a package is selected are complex and when you are in the vendor side you take advantage of those reasons to sell the package (I am not a seller. I allways was people who have to make real the seller´s promises). Generally speaking all is about business requirements as you mentioned. But if business requirements are getting as a result of an enterprise analysis (now named "needs assessment" or "strategy analysis" depending on the PMI or the IIBA. I mean, if your business requirements are getting by creating the actual enterprise architecture and the desire future architecture and performing a gap analysis. The result of gap analysis will show the business needs that we need to transform into business requirements.

Thanks , an Interesting article

Please Login/Register to leave a comment.


"Try not to have a good time...this is supposed to be educational."

- Charles Schultz