How To Avoid the Biggest Mistakes in Software Selection

How To Avoid the Biggest Mistakes in Software Selection

Why do so many enterprise software implementations fail? This was yet another week with a few publications on the topic. Most try to assign blame to one party or another. In my opinion, most get it plain wrong. If there is blame to be assigned, there are a few who do get it right (see for example these articles by Shaun Snapp and Lora Cecere ). Personally, I think at least 90% of the blame lies with consultants, industry analysts, and software vendors. This coming from someone who for his entire career has been a consultant and/or software vendor. But that does not excuse the customer. Often the cause of project failure lies in details the customer cannot be expected to know. These are cases where the other parties involved, if they acted in good faith, should have spoken up. However, a surprisingly large number of failures can be traced back to a degree of trust in clearly biased advisers that can only be called naive. Then there are the cases of unattainably high expectations, ill-preparedness, and - counter-intuitively - over-preparedness.?

But this is not an article about blame.

This article aims to arm the prospective customer with enough insight to avoid the biggest mistakes in software selection to maximize the chances of project success.

When Do We Qualify a Project a Failure

Success or failure is not a black-or-white verdict. There are degrees to which a project can be qualified as such. Many would call a project that exceeds budget and time targets a failure. Frankly, where it concerns enterprise software implementations (especially ERP implementations) having one finish on time and within budget is rare as a unicorn. If that was all that was wrong, in my opinion you may still call it a success, unless the original estimates are exceeded by a large margin. In the extreme, an increase in cost may cause the promised ROI (typically the key justification for the project) to never be met, if there is any ROI at all. The combination of increased cost, increased time to go live, and partial attainment of value will often drive ROI negative. Unfortunately, this is a common situation. There can be no doubt that this constitutes a project failure.

Sometimes, not all promised functionality is implemented, or it is not implemented as requested or expected by the customer. If these are not mission-critical functionalities these may still not disqualify the results. Oftentimes, functionality is de-scoped in mutual agreement because the effort is not worth the benefit. But when the missed request causes indefinite ongoing manual effort or causes the need for functionality to be performed outside of the system this will qualify as at least a partial failure. If mission-critical functionality requires part or all of the task to be done outside of the system purchased for this, it will again qualify as a complete failure of the project.

The 8 Causes Of Project Failure

The below causes of project failure are listed in descending order of pervasiveness and gravity of impact. The list is not exhaustive, but contains the worst culprits.

1. Trusting Biased Advisers

This is by far the leading cause of project failure. Most prospective software buyers are justifiably wary of software vendors, especially the sales person of the vendor. Sure, the software vendor wants a sale, and the sales rep is personally commission-driven to make a sale. A healthy level of skepticism is indeed warranted. But the same level of skepticism is typically not given to consultants and industry analysts. These parties however are typically similarly biased towards one vendor or another, and it is rare to get a recommendation that is not self-serving from these parties. If that recommendation happens to be in the best interest of you, the prospect, it is only by chance.

2. Bad Industry Fit

Your company is unique within your industry, and your industry is unique compared to other industries. On one end of the software customization spectrum is software that is custom-built for your business. But this is the ultimate dead end. It will be impossible to upgrade, except for the same high cost at which it was provided in the first place. At the opposite end of the spectrum is software that is standard across industries. Here you will either get the infamous 80% fit (it is the other 20% that will kill your business) or customizations built by consultants at high cost that again put you in the predicament of not being able to upgrade, except at high cost. The best software is both dedicated to your industry and allows customizations to your unique business requirements that do not prevent a zero-cost upgrade path. If this cannot be found it may be necessary to pick software that is either dedicated to your industry but requires some minor customizations that will need re-implementation and testing during upgrades, or software that allows customization without diverting from standard product but may not be dedicated to your industry. In both these gray areas take great care.

3. Bad Scale Fit

If the company is small, purchase software targeted at small companies. If the company is large, purchase software intended for large companies. Some large companies are cheap, and purchase software intended for small companies. As a result, they will almost assuredly run into scalability issues, and often miss critical functionality. The software becomes impossible to use in practice and any cost savings are undone many times over from missed value. Conversely, it is amazing how many small companies purchase software intended for the largest of businesses. These companies will have projects that all but break the bank, and then end up with systems that are bloated with functionality that is non-critical, require staffing beyond the ability of the company, and the cost of upgrades become an insurmountable barrier.

4. Prioritizing Technical Requirements Over Business Requirements

Enterprise software is purchased to solve a business problem. It is mind-boggling how many companies in their software selection will put equal or even greater priority on technical requirements than on business requirements. As a result they often end with systems that run like a charm, keep a whole army of IT people fed, but do not address the business issues that they were meant to. Welcome to Excel hell! Every business user is bypassing the very expensive system and performing mission-critical functions in spreadsheets, then keying them manually into the system that was supposed to automate this. The IT department will call the project a success. Everyone else will recognize its complete failure. Technical requirements should not be ignored, but they should be supporting, not leading.

5. Under-Qualified Resources

Enterprise software implementations provide steep learning curves for everyone involved. At the end of every implementation you will hear a few people express "if we only knew at the beginning what we know now...". Some of these unknowns at the onset are difficult to avoid. The customer does not know the software. The consultants and vendors do not know the intricacies of the customer. But some unknowns can easily be avoided by staffing people that have solid experience with enterprise software implementations, and at least a few that have vast expertise in the particular software that has been selected. These people have already climbed the steep learning curve prior to your project. Generally, consulting firms are hired to cover this gap in the skill set available at the prospect. What many prospects do not realize is that most consulting firms staff with inexperienced people that you pay to train on your job. Some at least try to hire the brightest young people, but I have seen far worse long-term errors made by exceptionally smart inexperienced consultants than by mediocre but experienced ones. There is no substitute for experience.

6. Being Overly Prepared

Yes, being over-prepared is not just a cause of failure, it is a bigger cause than being under-prepared. In this situation, extremely detailed Requests For Information (RFI) or Requests for Proposal (RFP) and demo scripts are created. It all but guarantees any selection will be outdated and middle of the road. There is not a chance any innovative solution will be selected. But those are exactly the kind of solution that will take your company beyond where it is today (the situation you are trying to get away from) and beyond your competitor. See for example the article "Forecasting: Do We Really Need Faster Horses? " for a detailed explanation of the problems with RFI's and RFP's.

7. Being Ill-Prepared

If you do not prepare enough, you are at the mercy of the opinion of advisers that may not be trustworthy. You have no way of sanity-checking any recommendation they give. Additionally, if you do not have the right people ready to go, trained, and given enough free time to fully participate in the project on top of their normal workload, chances of project success drop dramatically. This includes key stakeholders from every affected part of the organization and key support personnel. If even one group does not fully buy into the project they will cause delays, cost overruns, and sometimes overall failure. It is pretty common one department does not believe in the project's ultimate success and it becomes a self-fulfilling prophecy. Finally, every successful project has a clear and mutually agreed project plan and a project manager with enough clout to keep everyone else on track.

8. Overly High Expectations

When you embark on a software selection process, it can get exciting. There are so many options. so many promises made by vendors. But you need to stay grounded. There is a budget that limits what you can buy. And realize that every software has made trade-offs. Some provide deep but narrow functionality, others broad but shallow. Each has its area of strength and areas of weakness. If you have many varied requirements there will not be a single software on the planet that can provide it all out of the box, fit perfectly for you. If you ask vendors, they will say yes, since they do not want to lose the sale, and expect they can talk reason into you after the ink is on the paper.

What You Can Do To Avoid Failure

First and Foremost, Protect Yourself.

Do your own homework. Before the sales reps and consultants come in, even before the analysts, if any, are approached, know what you need. Look at your business in depth. Where is the pain? What is causing that pain? There may be many pains and many causes. Rank them. Do this very thoroughly and completely before trying to find a cure. You may otherwise find yourself on a path to a cure of an early discovered pain only to later find there are more severe pains or root causes that need to be addressed first. This is where scope starts to grow where instead it should be redirected. Having a complete image of all the business pains also allows you to select software that not only addresses the first pain, but provides a viable path to addressing the others later. If you bring in vendors or consultants too early they will drive the conversation to all the extra functionality they want to sell you, or to that which differentiates them from their competition, rather than the ones you really need.

IT Department is a Key Stakeholder, But Should NOT be a Decision Maker

Like external parties, if you involve your IT department too early the discussion will be diverted from the main objectives. Map out all the business pains first, and then get IT involved to help determine underlying causes and pains they may have that play into those business pains. Remember, unless you are in the IT business, the IT department's purpose is to enable, empower and support your core business. In this sense IT is an internal advisory group. Where it concerns business systems any IT objection should be considered real seriously, but will always need to be secondary to critical business functionality. IT is also a key stakeholder in any systems project. They will need to support whatever system is selected. They need to remove the pains they had with prior systems and avoid creating new ones, just like the business. As such they have a say and a vote, but unlike the business, IT should not have final or veto power. Like the business pains however, IT pains need to be mapped and prioritized. And IT solutions are only a means to an end, not the end itself - just like the business solutions - so they are optional, not to be mandated upon the business. In this regard, experience with an existing vendor or system does not make it a qualifying criteria, except as a tie breaker if all other things are equal. If increased headcount is needed, it becomes just another factor in the cost-benefit analysis. It is always better to train people on new systems that solve the business issues than have a bunch of experts on a system that does not do what is needed. This applies to both business and IT people. It may be painful for experts to become novices again, but nobody ever improved themselves without getting out of their comfort zone.

Do Your Own Market Research

Next you want to explore what is available on the market. In today's world you can find everything on the world wide web, for free. Don't look just for vendors. Look for approaches, both time-tested and new innovations. At this stage it is essential to keep an open mind. Do not go in with preconceived ideas of what your cure looks like. Look at everything from the perspective of what can remove your pain. Read blogs, ask questions in discussion groups or look for the same questions others may already have asked. Look for the right level of innovation that fits your problems and your company culture. Some problems need sturdy, tried and tested functionality (typically systems or record, such as ERP). Other problems require innovation (typically systems of differentiation, such as forecasting and planning systems). If you want to out-compete your competitors you will need some level of innovation.

If you find some early candidates, look for free trials. Software that does not provide free trials are typically too complex to try without supervision. That is not a disqualifier, but it is a warning sign. Look for tutorials even if a free trial is not available. How easy and intuitive does it look. If you can, try and load some of your own data. This will not only give you an idea of what is missing and what to ask more detailed questions about for that particular software; it also helps you determine what to look for in other software. At this point you are still just exploring, but you may start to create a list of absolute needs and absolute disqualifiers, as well as start to separate some possible candidates from the many non-starters.

Look For a Close Fit to Your Needs

Every software makes design trade-offs. Systems that perform and scale well are usually more complex or cumbersome to implement, or require a large head count and hardware stack to keep them running. Systems that are user-friendly often do not scale well. Systems where the logic is easy to understand are typically not accurate. Systems that are highly customizable often cost more to implement. Systems that are highly standardized generally provide a bad functional fit. These are just common trade-offs, not hard rules. Be aware of the trade-offs in any software you select to ensure it is strong where you need it to be strong and weak only where it is not important.

The two most common misfit decisions are size and industry. Look for systems that are targeted specifically at your company size and industry. Prefer a system that targets fewer industry verticals and a tighter range of customer company sizes. Naturally, systems that will operate on processes close to your core competency, will require a better industry fit. For some business issues, industry fit may be irrelevant.

Who Can You Trust?

Also at this stage you may form educated opinions of vendors, consulting firms and analysts. Look for their motivation. Who is paid or incented how, and by whom. How do their existing customers talk about these companies. Does the company have a reputation for over-promising and under-delivering, or low-balling estimated costs to later wildly exceed budget. If the vendor has a target market, does it stay faithful to that market, or does it promiscuously sell to anyone. One negative or positive voice could be an outlier, so look for patterns. Determine how much it makes you trust them. It is natural to not fully trust an unknown entity online, but a strong distrust is almost always a bad omen. It will be hard to form a successful team if distrust is present. It is better to go with your gut feeling on distrust at the risk of passing up a good fit, but avoiding a bad fit.

If you do decide to bring in external parties. Make sure there are no conflicts of interest. If a consulting firm is helping in the selection process, make sure neither they, nor an affiliate of theirs would benefit from any given selection. At the very least the consulting firm should not also be the implementing firm. They will assuredly recommend the software they are experienced in or get most royalties or billable work from, regardless if it is the best choice for you. The same applies to industry analysts. Unfortunately, most are funded by software vendors. Whoever are their biggest providers of funds will get recommendations where they should not. Look for red flags that the adviser holds their interest above yours. If you are small and they suggest candidates that are targeted at large companies: red flag. If the pain you are addressing has uniquenesses to your business or industry and they suggest industry agnostic software: red flag. These are not necessarily disqualifiers, but the argument in their favor needs to be exceptionally strong to make it valid.

Do Not Dictate the Solution

Once you are ready to approach some vendors, avoid RFP's. Every vendor will answer YES to every question if they can even remotely get away with it. They see this as the resume stage and just want to get through it so they can make it to the interview stage. It is a complete waste of time for both you and for them, and will lead to a bad selection. If you do want to cull the list of candidates remotely before inviting in a smaller group, use a different approach. List your pain points, and ask open ended questions as to how the system addresses this and how or why this is better. Ask ballpark numbers of cost and time and which answers are deluxe options that may also have more basic and cheaper or faster alternatives. Be prepared that vendors will usually require some basic information from you in return, such as how many users will be using that functionality. Provide that upfront. Do not forget to ask for the final mandatory disclosure whether any of the answers provided conflict with other answers provided. It should be made clear that omitting any such conflicts is cause for disqualification of the vendor if discovered later. Keep them honest.

Keep Cost Low Until Level of Risk Has Been Determined

Note that the duration of an implementation is a big cost and risk factor. The longer a project lasts, the longer before value can be assessed. Most software failures are not signaled until very late in implementation. By that time cost has accrued. Shorter implementations (and lower consultant head count) can dramatically reduce cost and risk of failure. Free trials are a great way to reduce both. Maybe some vendors offer a path where a pilot can be run at lower cost, before a decision needs to be made whether to go forward with a full blown solution. This pilot may be limited in terms of a subset of data such as products or locations, or maybe offered to a smaller group of users. This approach does not avoid failures, but it allows you to fail fast and small if failure is unavoidable, rather than late and large. Vendors that offer such a route or any other means to reduce your risk and cost until value is proven should be highly preferred over those that do not.

Let the Vendor Determine the Demo

If a short list of candidate vendors is invited to give a custom demo, do not dictate the script. List all the pain points you want to see the solutions to, highlighting critical pain points. Often there is not enough time to show everything or demo databases do not contain every scenario requested. By highlighting the critical ones, no vendor risks being disqualified simply because they picked the wrong subset to show. Request that the vendor gives you their script in advance and that they highlight where it maps to your listed issues. This way the flow will be more natural and the experience much better for everyone involved. Note that the functionality shown should be aligned with the answers provided by the vendor if it was preceded by a selection round of open-ended questions. By stating what you want to see addressed, rather than a preconceived notion of how you want it seen addressed every vendor can do justice to their strengths, and any weaknesses will be easy to spot. Naturally, if you were able to create your own demo using a free trial version, it would streamline the selection process, but also provide you with a higher degree of trust that what you saw is real and not smoke and mirrors by a crafty sales person.

Vendor Cost to Sell Needs to be Much Lower Than Your Cost To Purchase

For smaller companies seeking more affordable solutions the free trial is often the alternative to the demo stage. Demos are a big investment in time (and sometimes money) for both parties. Whether you should have them depends on your company size and the budget you intend to spend on the software and its implementation. If you insist on a demo round, do not be surprised if the vendors with more affordable offerings choose to pass on the invite to partake, leaving you only with expensive options, regardless of whether they may be a better fit for your business. If total license fee and cost to implement are low, custom demos by the vendor are prohibitively expensive and should not be part of the sales cycle. The lower the budget, the more you may need to rely on self-service qualification of vendors. In the extreme case you may never speak to the vendor personally before making an online credit card transaction.

Check References

Experiences of existing customers of candidate vendors are the best indicator of what will happen to you. The earlier in the process you can determine how pleasant the vendor is to deal with after they secured the sale, and how well the system performs its functions, the better. Find these experiences online if you can, during the market research phase. If this information cannot be found online, it will typically be the very last thing you will be able to do before signing a contract. Customers of your prospective vendor are very busy too and cannot field too many reference calls or visits from too many prospects of their vendor. The vendor will be protective and not be eager to provide you access until it is the final hurdle before contracts can be signed. This is not because they have anything to hide, but because references are a precious asset to a vendor.

Vet if the references the vendor offers are meaningful. They should be in the same or similar industry as yours. They should be solving a similar set of problems with the same software you are considering to purchase. They should be similar size, and ideally in the same country or on the same continent as you. It is not common to be allowed to speak to more than three references.

When you do speak with a reference come well prepared with questions to not waste anyone's time. But do also allow time for the reference to speak freely about their experience. One question to always include is how much functionality was custom built versus standard out of the box product. Combined with the promiscuity assessment mentioned above you get a good sense of how bad the vendor wants to sell to you as opposed to staying true to their core focus to ensure a mutually good fit. Note that references are typically the vendor's very best customers. They are not generally representative of the average customer. You will seldom hear anything explicitly bad, so read between the lines and place much more weight on negative feedback than positive.

Staff Appropriately and Empower The Team

Having the right resources on the implementation project is critical. Ensure the team is set up for success. For your internal personnel pick experts for each impacted area to be the point person for their area. Make sure they are given enough spare time at the appropriate points in the project to participate to the extent required. Assign others to cover parts of their regular work to create this extra time for the project. Give them authority to make decisions for their area. Free up enough time of supporting personnel from each department. Subject matter experts (SMEs) for all the impacted areas of the company are key resources. They need to be accessible but not necessarily deeply involved. And ensure they have full support for the project from their management. If using an external implementation firm (consultant or vendor), require them to provide resumes of all the people that would be assigned to the project as well as a commitment of which portion of their time they are assigned to your project. Whilst it is fine that some consultants are junior or even straight out of college, there should be sufficient seniority across the team to make success plausible. Naturally the experienced consultants can demand a higher rate than the junior ones. Realize that what it may take a novice a week to figure out an expert could do in minutes.

Follow Good Project Management Practices

When it comes time to implement have a complete and detailed project plan. This plan needs to specify critical milestones and key deliverables at set dates, and key people ultimately responsible for achieving each. All parties expected to participate need to fully buy into the plan. It is common that negotiation occurs over timelines, budget and scope. Whilst it may seem in your best interest to haggle hard and get the best possible deal, in practice it usually leads to failure if it causes the plan to be unreasonably aggressive or burns out personnel, yours or the external party's. At best, there will be cost and time overruns and oppositional conversations that can sour otherwise good relationships. Assign a project manager whose only responsibility in the implementation is project management. If one person is required to perform both implementation tasks and management tasks, time overruns are highly likely.

Stick to the project plan and the agreed scope as closely as possible. If you can get ahead of the plan, do so. You may need that extra time later in case unexpected situations occur. And they will. Every good project plan has some buffer time built in. But if you let scope increase as new needs or wants are discovered along the way it will be gone before you realize it. And when the next unexpected delay occurs you are over time and often over budget. Every increase in scope needs to follow a formal agreement process with all parties involved. Some scope increase may be significant and require an extension of timeline and increase in budget. The pros and cons of adding onto the existing project or postponing to a follow-up project need to be weighed. The key criterion is whether either inclusion or exclusion would increase or decrease risk of project failure.

Conclusion

Software project failures do occur. And some have gotten lots of press over the years. Prospective customers are understandably skittish about embarking on big projects with unknown return on investment at the end. The power to make these kind of projects a success however are to a large degree in your own hands. It is all about preparation, readiness, fit, alignment of objectives, and keeping a level of control over the process.

I have listed the most common mistakes and how to avoid them. If I have missed any important causes or remedies please comment below. Also any general feedback, questions, or critique are welcomed!

Find all my articles by category here . Also listing outstanding articles by other authors.

Stefan de Kok

? Supply Chain Innovator ?

6 年

a must-read new article by Lora Cecere?on this very subject:?https://bit.ly/scc-9steps-sc-selection

Murphy Wang

Planning Supervisor, at SMTC

6 年

Look forward to this, Stefan. Thank you

Ashwin Warrier

Product @ Incorta

6 年

Nice article, Stefan de Kok!

Rupa More

Senior Project Manager at Capgemini

6 年

Superb article listing down the reasons and also mentioning what clients should do to avoid them but what if consultants suggest or give correct advice to client and client is manipulated by the software vendors?? Any thoughts on this

Andrew Lenti

I help C-Suites turn strategy into action on a real-time PDCA dashboard | SaaS for Change Management & Sustainable Execution

6 年

Fantastic piece of written content which hits close to home. Fyi - Our most recent installation at our newest client is being managed by their IT department. So far so good and they are quite involved with all the other stakeholders.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了