Platform
Solutions
Owners
Contractors
Engineering/EPCM
Professional Services
Resources
White Papers
Case Studies
Blog
Videos
Company
AboutMost everyone in the construction business will go through a software evaluation at least once or twice in their career, where they’re part of a multi-discipline team appointed to pick the best software solution option on the market for their business. When it’s a smaller system with a limited enterprise footprint that’s being evaluated, this can be a relatively straightforward process. If, however, the requirements for the desired construction software system are such that they are lengthy and complex – and the system impact can span multiple departments – this process can be a significant undertaking.
There can be many people in the organization with differing needs, experiences and wish-lists all hoping the system will make their lives easier and less mundane. There can also be people in the organization who are not bought-in to the idea at all and see no need for a new software system; from their point of view, things are fine as they are. So, the process for software selection needs to not only accommodate this diversity in people and opinions, it also needs to be sensitive to price and timeline. There additionally needs to be a compelling business case for the cost-benefit of purchasing, implementing and integrating the new system.
As a software vendor ourselves, we go through this every single day of the year. Except, of course, we see it from the flip side of the evaluation. What we see from our perspective is that some companies are quite good at it – they’re organized, they ask great questions, they have a solid evaluation process, etc. By contrast, as you would expect, some companies could really use some help. With that in mind we thought we’d put together a brief list of best-practices we feel would help companies prepare and execute a successful evaluation of construction software. Or, really, any other kind of enterprise software.
By ‘enterprise’ software, I’m referring to any centralized system that can touch or affect multiple disciplines across multiple business units and is often digitally integrated with other enterprise systems. Enterprise software is not single-user or single-purpose software, but has data, workflows, processes and users that are interconnected through the software.
Here are the top 7 tips we’d like to share to help you with preparing and executing your software evaluations.
1. Make sure There’s a Business Case and Buy-in From the Top
Before you even start the evaluation process, you must make sure that there is a compelling business case for implementing a new software system. Everyone’s time is precious, so doing some upfront legwork to make sure there are no snags further down the path is time very well spent. It also helps you get organized and more able to articulate the problem and the solution. The business case doesn’t need to be just about saving money – there can be many critical business reasons for onboarding your staff onto a new software platform that can include risk, reputation, efficiency, quality, etc. What’s important is that you take the time to publish these benefits, along with the gaps in your current processes and systems that the software needs to address.
The follow-on from the business case is to ensure that you have buy-in from key stakeholders in the organization. Especially those that will be authorizing the funds for the software purchase. You’d be amazed at how many times we work with potential clients for months and months through rigorous evaluations and demos and negotiations, only to find out at the last hour that senior management was not fully bought-into the need for a system and had never allocated the budget. This can be disheartening for everyone.
2. Be Inclusive, but not Too Inclusive
It’s important to pick a small and focused evaluation team. It’s tempting to want to include many voices from many business units as a show of unity and inclusivity, but the reality is that many voices can create a great deal of clutter and can obscure the end goals. When you think about it, the motive for building a large evaluation team is typically to dilute the responsibility for the decision. No-one wants to be held accountable for the wrong decision, so to spread it across many people will disperse the risk. Too many cooks, however, will only lead to a decision paralysis and dissenting voices. It’s far better to establish a good process that’s well thought-through, transparent, objective, and factors in the diversity of requirements across business units. A small team can follow a good process with objective evaluation criteria, and land at a favorable result without absorbing personal or career risk.
3. Prioritize Your Requirements and Objectives
From our perspective as a construction software vendor, it is exceedingly beneficial to have a prioritized list of well-written requirements to help us prepare our demos and presentations – and to make sure we are actually a good fit for your business. This requirements list is critically important to the evaluation process. It not only helps you understand what you’re looking for, but, as I mentioned, it helps us understand what you’re looking for as well.
If you’re like most companies, you’ll likely build this list by requesting input from a wide selection of people and end up with a list that’s hundreds of items long. This is absolutely fine of course, but you’ll need to now organize and prioritize this list.
Organize the Requirements List
To ensure this list is focused and prioritized, following are a few things you should do:
- Remove any duplicates – different people may have included the same requirement
- Make sure each requirement is worded clearly and in a way that will make sense to people outside your organization. For example, any internal acronyms will likely need to be explained in a glossary.
- Create a priority system to assign to each requirement item. For example:
- Critical
- Important
- Nice to have
- Provide both weighting for evaluation criteria and scoring. A ‘weighting’ is used to set the impact each item will have against the total score. To keep it simple, just give each priority level a weight (for example, Critical=3, Important=2, Nice=1).
Include Your Current Situation and Objectives
It’s vitally important to be very clear and honest about your current challenges, and the issues you’re trying to resolve. Take some time to map out your current systems and processes and think through what you’d like to see as your ideal future state. Bear in mind that your software vendor can ultimately help you architect this as we have a lot of experience with it, but it helps to state your goals and how they will positively impact your business. Understanding your current situation helps us too, as we can then position our presentations and proposals around helping you achieve your stated objectives.
4. Define Your Evaluation Process and Timeline
Clearly lay out the process for how you’re going to evaluate each vendor’s software solution and share that with the vendors.
Prequalify Vendors
To reduce the list of vendors, it’s key to prequalify your initial list of potential vendors by sending them the requirements list (which could be in the form of an RFP, or RFI), and asking them to respond with their ability to meet each requirement. Give the vendors a pre-established self-grading and an area to include notes. Example self-grading criteria are:
- Not Supported
- Will support with customization – provide approximate cost and time
- Supported through 3rd party integration – specify 3rd party tool
- Partially supported – explanation required
- Meets criteria out-of-the-box
Product Demos
You’ll likely need to split up product demonstrations into multiple presentations from each vendor. It’s much more effective if you have a series of 3 or 4 focused demos from each vendor, where each demo concentrates on a few specific areas. Software demos that go on for longer than 2 hours tend to lose focus and it’s hard for your staff to stay engaged for that long. Make sure your staff are clear on the desired outcomes of each product demo and their role in the evaluation.
Provide Scorecards for each Demo
Give your staff a clear scoring system for each requirement or objective that is being demonstrated. For example:
- 0 – Does not meet the requirement at all
- 1 – Partially meets the requirement
- 2 – Mostly meets the requirement
- 3 – Fully meets the requirement
Evaluate More than Just Requirements
Scoring each vendor according to their ability to meet the requirements clearly carries significant weight in the overall evaluation of each vendor, but it’s also important to consider the non-technical side of who you’re evaluating.