Applying agile principles to COTS implementations

From the Easy in theory, difficult in practice Blog
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Six reasons to not punt kickoff meetings

Justify yourself!

Projects are like springs…

How effective are your agile ceremonies?

“Medium” is another way of saying “Don’t make me choose”

Categories: Agile, Project Management

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 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.

(Note: this article was originally written and published by me in October 2009 on my personal blog,

Posted on: March 07, 2018 06:59 AM | Permalink

Comments (9)

Please login or join to subscribe to this item
Good post Kiron. The last part sounds like iteration zero. I like the idea of a walk-away clause.

Thanks Sante - procurement processes and policies also need to evolve as part of an agile transformation.

Very interesting, thanks for sharing

Thanks Eduin!

Good article, Kiron.
I just kick started a COTS implementation project and as you mentioned above one of our challenge is the upfront capital investment.

Very informative. I know that up front cost is a major factor. But the sustainment tail can easily increase in money, time, and cost. It may be of value to think about the next iterative use of the product immediately after the planning of the first wave to give an idea of future use and sustainment requirements. This may help identifying if starting with COTS is the best option over time. I may turn out that the best move is to start with a small COTS and begin to build organic processes, flows, delivery platform, and people with skills for the long term as those can become organizational assets instead of recurring cost. Just a possible thought.

Thanks Anish & great addition Ronald!

Good points, Kiron. I certainly would hope that the customer (organization seeking COTS) would do their due diligence up front to determine what is actually required and what will be needed to provide value and delivery on the intent. And like you mention, that does not have to be through full-fledged detailed requirements. With this, they are better educated prior to the procurement efforts.

Thanks Andrew!

Please Login/Register to leave a comment.


"I'm sick and tired of hearing things from uptight, short-sighted, narrow-minded hypocrites. All I want is the truth. Just gimme some truth."

- John Lennon