“Make it Work Like Our Current System” and Other Requirement Pitfalls

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:

Approach Rebuttal
“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 –

  • There has never been a project where not documenting requirements, for any reason, was the best approach.
  • While proposing to use a product “as is” is well intentioned and seems realistic in theory, it is a rare business that either has the follow through to stick firmly to this approach or has no unique requirements (perhaps even regulatory) that invalidate this approach.
  • “A few minor changes” tend to grow like a snowball rolling downhill. Even if they don’t, these, at the very least, need to be documented up front as requirements.
  • Even if one supposes that the approach is sound and can withstand the project, equivalent (or larger) efforts would need to be underway to document the requirements for changing the internal business processes to work with the “as is” product and implement the organizational change management.
“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.

  • Reverse engineering requirements from anything beyond a trivial solution is a monumental, if not impossible, task, due to typical complexity of screens, workflows, and business rules, and the challenges of inferring from language specific code structures.
  • If it is intended to work exactly like a current system, then what is the business benefit of the change?
  • The likelihood of a new system being developed in the same manner as an existing solution is very low, so even in a best case scenario, you will have underutilized the capabilities of the new platform and created a hybrid that is difficult to maintain and support over time.

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!

For additional guidance with COTS implementations check out some of our other articles on requirements and Investigative Architecture, or drop us a line!

Dan Hughes was a principal consultant and partner at Systems Flow, Inc., where he leads the technology services practice.

Latest posts by Dan Hughes (see all)



Comments

Comments are closed.