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.

Share This

Comments

David Smithstein on 4 November, 2010 at 8:21 pm #

You have got to be kidding. What kind of software vendor would do that to a client who is spending hundreds of thousands of dollars on their system? The client doesn’t know all the details of the new system, but the vendor should and be looking out for the client from the very beginning. This seems more like a cautionary tale of how poor the servicing is going to be with those “Enterprise monstrosities.”


jc on 4 November, 2010 at 9:16 pm #

pardon me. i m disappointed to read this - as I really thought there will be some insightful point of view by reveal the “Devil”,

i only see poor project management and unqualified “professional” services


Jeana Lawrence on 4 November, 2010 at 9:18 pm #

Wow, this is not the client’s issue. It’s more of tale about a poor software vendor. Why wouldn’t the vendor point out the need for the extra licensing needed to enable the analytics package they were already paying extra to receive. I hope the vendor’s salesman was similarly dismissed.


marus brogna on 4 November, 2010 at 9:24 pm #

This is the most unhelpful article I’ve ever read on this site. This is simply proof that picking the wrong software vendor could potentially screw you over - not because of their feature and functionality set, but because they won’t own up to their own mistakes in the proposal and comp the database license. Why would they sell something (BI package) that depended on a module they were not selling?

The project manager should not have been fired, the vendor should have been fired for baiting and switching.


Gloria on 5 November, 2010 at 2:09 am #

I have learnt the hard way that vendors will gloss their product and give you the impression that it meets your requirements and suits your environment 200% - for the sake of making a sale. Sometimes they have no clue how their product will address your requirements and should it fail to do so, they are quick to pass the blame on what the client should have known or done. I think we have lost professionalism and integrity in IT and vendors are more interested in selling you a software than providing a solution for your business.


Fabio on 5 November, 2010 at 3:47 am #

You should talk about the Integrators that sell themselfs as experts and when it comes to the implementation they just screw up the software and at the end the blame the software. I’ve seen it many times with “top integrators” company.

If you are in the process to buy any software that will require installation, customization, integration and so on and you are thinking of contract Integrators to reduce the the cost, make sure you also contract someone from the Vendor professional service team to guarantee that the Integrator are not screwing up.


Andrew Robertson on 5 November, 2010 at 3:57 am #

This is not an uncommon scenario to find. I would not go done the road of the blame game, as all the parties concerned had a part to play in the mistakes that were made. Those being the authors of the software who should be managing their product channel, the software implementer who should have asked all the relevant and pertinent questions and the client who should have had the appropriate skills and expertise internally to be able to ask the correct questions. The question to be answered is - how does a potential purchaser of such a software solution avoid such a senario? If you do not have the relevant knowledge available within your organisation, hire a reputable independant third party who can advise you, as the client, on what to look out for and what questions to ask. You can only ask relevant questions about a subject matter that you have the relevant knowledge of.


Michael on 5 November, 2010 at 8:29 am #

Hear, hear, Andrew. In these types of projects, particularly those with a larger scope, there can be hundreds or thousands of tasks that must be managed and projects of that magnitude rarely go exactly as planned. As often as not, there is as much managing the plan to reality as there is managing the project to the plan.

There is always plenty room to blame others. Except to identify positive corrective action for the project and to identify lessons learned for other projects, I don’t see much value in looking back. What is done is done - learn from it and move forward.

In the case of this sponsor, it is hard to believe that this single item was the only thing that led to his dismisal unless the company was so small that it was a huge risk to undertake this project in the first place and the cost of the additional license was enough to dramatically affect the year’s bottom line.

A reminder from time to time of the myriad of items that can derail a project can be a help to a novice project manager or a sponsor trying to mentor a novice PM, particularly in a corporate environment rife with assigning blame that eats their young.


David Smithstein on 5 November, 2010 at 8:58 am #

Just wanted to suggest to Gloria that if you buy software from the same person who actually has to handle any technical support calls, the level of integrity and professionalism will be what you expected in the first place.


Dan on 5 November, 2010 at 11:24 am #

The software supplier was at fault for not indicating that the added module required an upgrade to the base software. The project manager would not even know to ask the “right” question. Yes, due diligence is required, but the implementation should never be a surprise if the software company has any integrity. Do you still work for that company?

Simple solution: get rid of the added module and everything is back on track. Then talk about adding the module later on down the road when there is budget for it. Why didn’t you say that, Chris?


color on 7 November, 2010 at 12:08 pm #

Right now we are dealing with such a vendor. The sales lines are fantastic the service sucks big time and everytime I have a question they get back to me after consulting with their staff in India. By now we have spent twice the budget and have not gotten anywhere except confusion.


David on 7 November, 2010 at 2:44 pm #

Color, who’s the Vendor and what kind of application is it?


Chris Tanner on 8 November, 2010 at 11:15 am #

Thank you all for your comments voicing your opinions. This is an illustrative tale about how a seemingly small detail can slip through the cracks during a software selection initiative. The point is to show how vital it is to examine every single detail prior to signing a contract. I don’t believe there was any malicious intent on the part of the vendor’s sales team. You wouldn’t expect a salesperson to be well versed in the ‘guts’ of a system. The client saw functionality that they identified as critical to their operation but didn’t use a magnifying glass to examine the minutiae.

The hurdle was overcome but the project timelines became out of scope and there were cost overruns.

The important thing to remember is that the project was still completed successfully. As we know from the statistics we see on a regular basis, many aren’t completed at all.


David Smithstein on 8 November, 2010 at 11:35 am #

Chris, you’re standards for “success” seem a little low, and your focus on the customer seems a little out of focus. Just my opinion.


Tyron on 8 November, 2010 at 12:15 pm #

Sometimes in large organisations, sponsors may not necessarily have an IT background, but may inherit the portfolio because of the exigenicies of that organisation. In such cases there should be competent IT personnel on the evaluation team to guide the process. This still does not absolve the vendor from providing necessary third party involvement information. The Vendor’s team should also have someone with the technical knowledge of the system and not leave this solely to a ’salesman’.
Famous words - “we never have the time and money to do it right, but we always find the time and money to do it over properly.


jc on 8 November, 2010 at 1:05 pm #

from trigger project to select software to perform project management and so on… at any stage, we need to fit the right person in the right place

it is common that vendor on one hand perform professionally and on the other hand, seeking addition income by creating VOs. The art & science of managing the entire project/ program is essential for the success.

this case is not useful to address the root problems but view it very narrowly which can’t lead us to conclude the value we going to receive.


marus brogna on 8 November, 2010 at 1:13 pm #

Chris, Your explanation is wildly off. I don’t think you get the point. The customer is not the one that should dig into that minutiae. How would they know to ask if their database would need to be upgraded to accommodate the analytics?

They requested the analytics package and it’s up to the vendor to make sure they have everything they need to run it.

We’re really setting the bar too low when we start putting the ball in the customer’s court to figure out every detail. The software vendors need to step up, be consultative and guide customers through the process.

Otherwise, they are selling vaporware and need to go the way of the dodo bird.


Chuks on 11 November, 2010 at 8:19 am #

If Chris had bothered to ask the right questions before arriving for deployment, this problem would have been discovered and addressed before his arrival. Those of us in the business understand the process: What needs to have happened prior to our arrival at the scene or any stage in the development process. If Chris had gone through his check list during the six-week period before his arrival, he would have been able to alert the client, thereby helping to avoid the unnecessary delays and extra expenses. However, Chris tight schedule prevented him from taking the time to do his due diligence prior to his arrival.


*Name:
*E-mail (private):
Web site:
*Comments: