One of the most common excuses I’ve heard clients use to explain why a commercial off-the-shelf (COTS) product implementation was not successful is that “the vendor misled us”. While there certainly are a small percentage of vendors that might purposely mislead prospects during the sales cycle in order to secure a sale, the court of popular opinion combined with natural selection helps to keep their numbers in check.
The more common root cause of this perception is the expectation gaps between what the vendor sells and what the client is expecting.
The challenge is that it is rarely possible to create a requirements specification for an enterprise application to a level of detail required to ensure that a vendor’s product will meet all critical requirements (e.g. functional, performance, technical). Even if you could create such a masterpiece, vendors have enough problems with completing RFI/RFPs, so a comprehensive specification would likely result in no better end result.
Another challenge with many COTS implementations is the significant upfront capital investment in hardware and software if an on-premise solution is procured and implemented. To secure the best discount on licenses, procurement departments may prefer to do a bulk purchase even though this does imply significant up front cash outflows. Now you might say that software contracts can be designed with an easy walkaway clause if requirements are not met – unfortunately, the same may not be true for the underlying hardware that was purchased. Also, once an internal team has invested significant effort over the course of many months in a vendor implementation, it is very difficult to convince the team (or the end users) to consider a different solution even if that is the right thing to do.
Agile principles that are normally applied to application development projects could also be adapted for use on COTS implementation projects to partially address these challenges.
1. Emphasize working functionality over documentation – instead of spending tremendous effort on developing RFPs or detailed requirement specifications, have your end users with facilitation from business analysts define the business processes being automated using stories or use cases. Augment these stories or use cases with the bare minimum of performance or usability requirements (e.g. user should be able to complete story X with less than 10 clicks). This requirements documentation will be used to both short list vendors and to guide learning and testing efforts.
2. Minimize up front investment – the focus should be on demonstrating working functionality with a minimum purchase of licenses and supporting hardware. You want to be able to address all required business processes, so ensure you have representation from all end users/stakeholders but do this with the bare minimum required to prove whether the end user stories and performance/usability requirements are satisfied or not. A reduced up front investment is one of the benefits of going with a SaaS solution over an on-premise one, although that benefit may be offset by limitations on feasible customizations to the solution.
3. Apply an iterative approach to fine-tuning and validating requirements – have your end users work with the vendor and the project team to configure, learn and use the software in a production mode during the first iteration. Each subsequent iteration should be time boxed, focused on a prioritized list of stories or use cases, and should ideally allow for a walk-away clause at the end of the iteration if either the requirements for that iteration cannot be met or if the business feels that their needs for the overall project have been met.
