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:
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 ThisYou 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.”
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
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.
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.
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.
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.
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.
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.
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.
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?
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.
Color, who’s the Vendor and what kind of application is it?
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.
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.
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.
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.
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.
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.