7 Factors to Consider when Selecting Software

1 Star2 Stars3 Stars4 Stars5 Stars (6 votes, average: 4.33 out of 5)
March 25, 2018

We collected Top 7 pitfalls to avoid in your Selecting Software Process

With any decision come risks. However, when selecting a large, expensive cloud software solution for your company, we know the stakes are even higher. In fact, we know that over 50% of software selections and implementations fail. In order to minimize and remove those risks, we have put together a list of the top seven enterprise software selection risks that are faced during the decision process. As we mentioned in our previous article on Software Selection Best Practices, the main reason for failure is not because of the vendors or because of product feature sets. Ultimately the main causes of software selection mistakes are rooted in the lack of collaboration across groups, with vendors, among stakeholders and others involved. Through a collaborative and transparent discovery process, many of the risks listed below can be averted.

1. Lack requirements or inadequate requirements

We all know the feeling. Scope creep. Being disappointed after an implementation that something we thought would work would. Realizing that a full function was never discussed or written out in the statement of work. This is a critical time where users should detail the depth and breadth of all functional areas that should be reviewed in the purchase. It’s been said that when planning the timeline of a project, allow for 30% of that time to be focused on listing out all use cases and edge cases. This is a critical time to include and communicate with all groups. Each team in the company will have a different stake in the game so each should be tailored to them. Start with collaboration at a high level to go over what the key purpose of the solution will be and how it will affect their day-to-day jobs. From there, ask questions to understand how they currently interact with the product along with any pain points or issues they may want to solve for. Do research to see if there are any basic requirements that other companies use and use that as a starting point. With that said it is critical to not be rudimentary with requirements. Overstate. State the obvious. There is nothing too small to note in requirements they are laying the foundation as well as picking the molding in the needs that will be filled with a solution.

2. IT Governance – security and / or compliance regulations

Everyone’s favorite words to hear—governance, compliance, and security. While these elements of any project are often known to cut back exciting features, marketing messages, and add red tape, we all also know that they are in the business of protecting our company’s name, brand and overall value prop. Because of this it is critical these departments are looped in to these software purchases from the beginning. If we are being honest, they would like to be part of these exciting projects rather than be the naysayers as the end. By collaborating with these groups we will better understand what is needed to eliminate any products or vendors that are not available within the company’s guidelines or protocol off the bat which will ultimately help speed up the process of approval and purchase.

3. Pressure from management or biased colleagues

Because of the outdated process that we have been funneled through as B2B buyers, we are often pressured into making biased purchase decisions due to other colleagues or upper management suggesting to purchase a particular product. This leads to obvious concerns as it may have worked for another company or a different area of a business. This does not take into account what your business needs are in terms of requirements, budget, etc. Here is where we think it is important to collaborate and take the feedback and opinions of different stakeholders seriously, but only at the level to which their expertise is relevant. By allowing them to rate and vote on as well as state their opinion based on the area that is relevant to their line of work, you will help to ensure that it is not only biased, but used only as far as appropriate in the review selecting software process.

Top factors to consider when selecting software4. Bleeding edge and end-of-life technology

Yes. We understand that bleeding edge and end-of-life are the exact opposite of each other. One involves a company promising what is coming in the pipeline and being released soon and the other involves the acquiring of another company which allows feature sets to be unaccounted for or no longer developed.

These sorts of risks are often found when working with larger vendors that continually have a large pipeline of enhancements or a large acquisition department to continue to grow their book of business as well as try to monopolize the market. This doesn’t mean that the solution is not right for your company.

However this is often a risk that many companies face as they believe that they will have the capability to XYZ when they later find out after implementation that either the feature is extinct or still not available when it was promised. Because of this we suggest that you purchase products based on the features that are already available to the public or have been available for some time under the vendor that you are purchasing from.

5. Accelerated or moving-target timeline

The due date for this project December 31st—that is final, no exceptions. March 15th comes around and the implementation is still with development in QA. Sound familiar? Or… September 15th the due date is now November 15th while designs are still being reviewed in staging. Ah, yes this one burns more. Due to changing business needs, budgets, resources or priorities both of the above are likely and normal shifts that we as the purchasers and decision makers have to be able to accommodate while selecting software.

Pivoting may happen due to change in budget or change in timeline. The key thing that needs to be understood and accepted when these date shifts happen is that everything that was originally in scope may shift. Yes, collaboration here is key. Sometimes this goes all the way to creating a baseline around what is the minimal viable product that is acceptable for launch while other times it just means that additional features will be rolled out in a later phase.

Whichever is the decision, projects fail when the slack in the project plan and key dates don’t shift with the end due dates change. Collaborate, communicate and distribute updates frequently to keep all those in the loop and on an agreed page to know what is coming when and why any feature sets may have shifted.

6. Underestimating implementation needs

The time and cost of any expensive purchase and implementation can often daunting at the initiation of the project in order to get buy in and budget approval. However, many of us know all too well that the resources, cost and timeline of the actual implementation just about never go according to plan. Between technical limitations, integration difficulties, the potential inadequate requirements that resurface later in the project and other obstacles, there are always things that can go on.

While we would like to say that collaboration could help solve this problem, that isn’t quite the case. Instead here we suggest that continuous and consistent communication will help to manage the expectations of those who are collaborating within the project. Some obstacles are inevitable, but there is nothing that will make a troubled implementation satisfactory by hiding it from those that are involved.

Therefore we recommend baking in around an additional 20% of cushion in the timeline and budget to allow for the inevitable. Should you deliver within this allocation; the implementation will be closer to be categorized as a success during your selecting software.

7. User buy-in and insufficient training

So your company is buying a software solution that costs tens of thousands of dollars? Cool! So what? How will impact the bottom line of the business? How will it affect the day to day lives of users? Collaboration throughout the project to address these elements is key to not only raising awareness, but increasing acceptance and hopefully, ultimately excitement for implementation of the software solution. We are lucky enough to live in a world where the majority of solutions on the market are capable of fulfilling the majority of our basic needs and then some. Software selecting criteria follow the same 80-20 rule as other elements in our life—that 80% of what we use in a solution is only utilizing 20% of the tool’s capabilities.

With that said, there is nothing wrong with that, however, implementation and onboarding is the key time to learn about the other features that are capable and may even help you and your team improve their processes to avoid classic mistakes in software project management.

Overall the key to minimizing and eliminating the main risks in software selection process steps that many companies face is through collaboration. Collaboration throughout requirements, governance, implementation, and training is the key to success.

We understand that this may sound like common sense, but we know that often it is easier said than done. By using tools and solutions that foster collaboration, there is hope to better streamline and feel confident in making an empowered and collaboratively informed decision. Feel free to use our 7 common tips as your own software selection process template.

For more information on how to leverage this information and make your software selection process efficient with a free tool, visit www.omnibased.com or contact us through this Form:

[hubspotform portal_id=”3015276″ form_id=”2b562f0b-6212-4968-86f3-f89f51fd6cea” css=””]

Free WordPress Themes, Free Android Games