“Off the Shelf” Software Implementation Pitfalls

This is the long-awaiting (or at least long-promised) article on implementing “bought” products; a follow up to our Buy vs. Build Your Software article.  Many large organizations rely heavily on external vendors for large scale software implementations of “Off the Shelf” packages – very frequently modified for competitive advantage and/or to align with internal business processes. These are some common pitfalls to these Custom Off The Shelf (COTS) implementations.

Pitfall #1: Substituting marketecture for architecture

Those pretty pictures in the vendor sales presentation are not architecture diagrams. They look nice and highlight the benefits of the architecture to assist with the sales process, but do not focus on the aspects of the architecture that are important for a successful implementation – especially those specific to integrating with your organization.

• If a vendor does not have architecture designs that match your standards or provide equivalent information to your satisfaction, engage an architect from your side to make it right.  If you don’t have diagramming standards – shame on you! – try our Investigative Architecture for your System Architecture Diagrams.
• Even if you think the vendor diagrams are appropriate, you are often best redoing in your standard format for your internal stakeholders.

Pitfall #2: Adopting the vendors’ PDLC

It often seems most expedient to let the vendor run the whole project using their own implementation process and “why not?” – they have installed their software countless times before. This is a mistake for multiple reasons:

• Any process the vendor drives is by definition going to be designed to ensure the best outcome for the vendor.  An aspect of that will be customer satisfaction, but the primary goal will be vendor profit. This is not a negative comment about vendors, in fact, you want profitable vendors.  They will be around longer!
• There is no guarantee the process will integrate appropriately with your organizations governance, nor that the process will produce the documents your stakeholders are comfortable receiving.

You should execute projects within your enterprise using your standard methodology. You can modify to handle product-specific optimizations during project inception.

The secret to COTS implementations is to follow the same due diligence you would for any other project and not assume that buying an off the shelf product provides any other shortcuts than… well… an off the shelf product.   I have some additional requirement-focused pitfalls to share, but those deserve their own article, so stay tuned!

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

Comments