This is the final article in in the series for implementing “Custom Off The Shelf” (COTS) solutions; a follow up to our Buy vs. Build Your Software and “Off the Shelf” Implementation Pitfalls articles. In this we want to address requirement approaches that are sometimes proposed, but rarely successful in such an implementation.
In an appropriate scenario, requirements should be done first, before even selecting a product vendor. The requirement process serves to refine the business’s understanding of the need, then the documented requirements can be used to drive a RFP and vendor selection process. Unfortunately, such is often not the case, and an inked contract sometimes launches an implementation with nary a requirement to be found.
Here are two of our “favorite” COTS requirement approaches we have seen in these situations, along with rebuttals:
|“We don’t need to document requirements. We are going to use the product “as is” and use its best practices instead of our current processes. Maybe a few minor changes to handle some of our specific needs.”||I don’t even know where to start. Seems like it might be a joke, except that we have seen this happen more than a few times. So –|
|“We only have one requirement. Make it work exactly like our current system. Plus the new features you have that our current system doesn’t.”||For starters, if a vendor agrees to this approach, you should question their maturity as a delivery organization.|
This approach also rears its head on internal custom development projects as well.
As stated in the previous pitfalls article, the secret to COTS implementations is to follow the same due diligence you would for any other project. If a shortcut seems too good to be true, it is likely too good to be true!