The Devil’s in the Details (Based on a True Story)

  • Written By:
  • Published:

In a past life I was a consultant on behalf of an enterprise software company. This is a tale of what happened during one engagement to install a new system.

This involved travelling to different cities every week in order to do implementations and the like. I regularly saw the impact of software selection processes that ought to have been more thorough.

One of the first things impressed upon me during my consulting time was that every on-site engagement represents someone’s job or promotion. Project sponsors and stakeholders are held accountable for the success or failure of a system deployment. So you would think that they’d be as in-depth as possible when signing off on a system worth hundreds of thousands of dollars.

This is not always the case. The Devil’s in the details, after all.

Here’s what happened. During the pre-sales process, the software vendor demonstrated the analytics capabilities of the software, and the client was excited about the feature. This additional line item was added to the overall invoice. My time was duly booked for the five-day deployment, which was scheduled for six weeks later.

Arriving on site, we immediately got started with the installation of the base system, and began with configuration so that we would have some data to apply to the BI module. Unfortunately, once the analytics phase of the implementation came around, it was discovered that some database features used by the BI suite were not supported by the database licensing level that the client had purchased.

An upgrade to the “enterprise” level (from “standard”) was needed in order to make this feature (which they’d paid extra for) work. This was midway through day two—25% of the way into the deployment—and the client would have to find additional budget, or that feature was out.

This situation had several (unsurprising) effects:

  • Tens of thousands of extra dollars for a new database version and license were not budgeted for but had to be spent.

  • The implementation, which was already on a very tight five-day schedule, fell behind.

  • All of a sudden the project was way out of scope and my billable days almost doubled. My billable rate didn’t change. And the continuity that a project enjoys by having a consultant on-site was destroyed, as I had to travel to a different city the next week

  • The project was initially to take five working days and launch internally for testing the following week. Instead it took three weeks to get to that point.

  • The project sponsor was dismissed.

All this drama could have been mitigated with one simple question during the sales cycle: “What licensing level and version of the database do I need for all my selected modules to run?” This is a very clear example of why maintaining a rigorous level of detail throughout the software selection process is very important, most especially for the project sponsor in this case.

Here’s my message to project sponsors and stakeholders: leave no stone unturned in your software selection process. You, the consultant you work with, and most importantly your boss will be much happier (and employed in this case) at the end of the process.

Next up: the case of the most indecisive client to walk the earth—the six-month BPM deployment project.
comments powered by Disqus