Get it right the first time: How not to waste money on your digital tools

What’s the problem?

Selecting technology for your organisation is hard. Sometimes it’s hard because the challenges you’re facing are truly complex. Most of the time, however, organisations struggle because they don’t have a good way to uncover what they really need from their software, or a process for truly differentiating between the options available to them.

Also, moving from evaluation to implementation can feel overwhelming, especially if the core use-cases for your technology are not clear. New software never solves underlying process problems — in fact, switching technology without having a deep, human-centred understanding of how your organisation operates tends to exacerbate issues, not solve them like the silver bullet many people wish they would.

It’s this lack of a clear, human-centred process that causes technology projects to fail, or at least fail to meet their objectives and deliver value to the organisation. In this article we’ll show you a better way, applying a design thinking process to the task of selecting technology.

By the way, a human-centred, design thinking approach is valuable not only for technology selection and implementation but also for hiring and working with services firms such as web design agencies or app developers, and even for designing the services your organisation offers. More on that later.

We help organisations by acting as project leads for technology selection projects, driving the process and adding much-needed capacity. We engage with stakeholders and conduct the early research, drive the process forward and facilitate selection team meetings. Hiring an outsider to lead the process properly is a lot cheaper than buying the wrong thing. We’re not affiliated with any technology vendor and don’t have pre-packaged solutions to sell so our only goal is to help your organisation select and build the best technology stack for your needs. email hidden; JavaScript is required if you’d like to discuss how we could help you make the right technology choices.

Common problems to avoid

There are some recurring mistakes we see organisations make. All of them are short cuts that individuals tasked with selecting or implementing technology fall back on in the absence of a process to guide them.

They are:

1. Using software you already have, just because it’s easy
2. Falling in love with a demo
3. Single peer recommendation
4. Feature checklists

Mistake 1: Using software you already have, just because it’s easy

Just because you already have some software available in your organisation doesn’t mean it’s a good fit for a new use case. Your IT team will want to reuse things they already have — it’s less work in the long run for them to maintain and manage — but don’t just give in.

Configurable, platform-style products such as Microsoft Sharepoint are particularly prone to being offered up as solutions to new problems since one can easily imagine, naïvely, that they can be simply configured to fit your new use case. Most of the time such systems don’t yield a powerful, easy-to-use end product and take longer to configure than first thought. They make it too tempting to short-circuit the design process and good project management that go into a good technology implementation.

Mistake 2: Falling in love with a demo

Vendors love to give demos, both pre-recorded and in-person. Demos are designed to impress. They focus on those features the vendor wants to highlight and the best-case outcomes one might hope for.

They encourage you to ignore the hard graft that will go into implementing the technology and to start dreaming of the magical future they describe without ever helping you understand the long, hard road between your current situation and the nirvana they describe.

In short, demos can be distracting hyperbole — they give a false impression that their technology is a silver bullet, broadly applicable and that the features they tout are the things that will truly impact your organisation.

Mistake 3: Single peer recommendation

We often hear leaders justify their choices based on the experience of a trusted peer, or of themselves in a previous job. This practice of taking as instructive a single data point from someone with whom we have a connection is a common bias well-known to psychologists. I once read it described as akin to dismissing the conclusion of rigorous industry research that Volvo was the most reliable car brand on the basis that you once had a brother-in-law whose Volvo was always in the garage.

Whilst your peer’s industry and even organisation may be similar, their particular challenges, ways of working and members of staff will certainly not be. So assuming what worked for them will work for you is a mistake.

Mistake 4: Feature checklists

Feature checklists are the most common mistake we see, in part because they feel methodical. The story usually goes like this:

1. You get some business analyst to go around and interview users and stakeholders.
2. She makes a long list of features and categorises them in Excel. Excel’s limitless rows encourage her to note every detail.
3. Someone realises the features need to be prioritised so the analyst goes round again and asks stakeholders to rank the features. Everyone ranks everything as a ‘must have’.
4. Some bright spark wants to look good by making the analyst tie each requirement to the business case, so the analyst spends days making the already long Excel file even more complex with cross references to the business case document that no-one has thought about since it was first drafted.
5. The spreadsheet is now so complex as to be entirely useless. Stakeholders begin to fall back to gut feel and whatever feels familiar.

There are two core problems with feature checklists. First, they take something that should be human-centred and turn it into a soulless, mechanical exercise. Once that happens, the whole thing starts to look straightforward and boring so stakeholders and leadership mentally check out of the process and the project gets delegated to someone wholly ill-equipped to tackle it.

Second, feature checklists are really bad at differentiating between technology options. Every vendor has figured out how to look good against a checklist and you can’t tell from a check in a box how good a fit that vendor’s solution is for your people and workflow. They encourage you to emphasise comprehensiveness over business value.

Bonus mistake: Leaving it to IT

All four mistakes we see are short cuts, a natural tendency towards getting to a selection quickly rather than making sure the right choice is made. It’s common to see such projects delegated to a central IT team and these mistakes are much more likely to occur when leaving it to a technically-oriented team who is separate from the team(s) who will actually use the technology.

IT teams have enough on their plate already and are usually ill-equipped to lead such projects along. Obviously you must include them — they are, after all, your organisation’s technology experts and you need them — but they should be part of your team (see later section, ‘Build your team’), not left to somehow make the decision alone.

In fact, it pays dividends to bring IT closer to the business and treating them like expert internal consultants rather than a service-providing group off in the corner of the organisation. Our engagements with clients often aim to build processes and culture that develop a stronger collaboration between IT and other areas of the business. Ideally, IT should be working with your business units, driving innovation by bringing their knowledge of new technology to bear and contributing to business strategy (in particular, helping develop customer-centric rather than product-centric strategies).

If you’ve got strong people in your IT team they are already capable of doing this. In our experience it’s usually their workload and a siloed organisation structure which prevents them operating in the much higher-value consultative, strategic capacity they’re capable of.

A better way

To approach technology projects better, we use a design process called “design thinking”. Design thinking is a process for designing solutions that revolves around a deep understanding of the users we are designing for. It aims to challenge our assumptions and biases and instead uncover the best solutions(s) through research, prototyping and testing. In many fields it’s useful for tackling ill-defined problems; in this context it’s useful for re-framing the problem space in a human-centred way rather than a technically-oriented way.

As with any discipline, there is a whole world of knowledge behind why it works and how to do it well, but for the purposes of this article we’ll cut straight to the mechanics of the process since they are useful even without understanding the background.

The process in depth

So, let’s see how we apply design thinking to technology selection engagements. If this sounds like overkill for your project, note that the process can be scaled down and still be useful (if you scale it down the right way).

Step 0: Build your team

Before doing anything, we need to get your team together. As we saw in don’t leave it to IT, leaving things to the IT department means asking people outside of your team to make decisions about what would be best for your team. You need to build a team that represents the interests of the various stakeholders — not just IT and leadership. In the software development world, talking to the wider organisation and aligning your software choices with your people is so important that whole books have been written on the subject (including practices we follow in our software development work).

The team needs to be organised and have sufficient capacity to meet regularly and run the project as a hands-on design project, not a quick checklist exercise. This likely means freeing them up from some of their day to day tasks during the project, especially during the particularly hands-on latter stages.

The team also needs authority to make and implement decisions. There’s nothing more demoralising than the CEO swooping in at the 11th hour and dictating the solution.

Step 1: Empathise

Business case

Here we're aiming to build a better understanding of your organisation. Don’t assume you know the organisation’s objectives and the interests of everyone involved. Take this opportunity to build consensus amongst the team around what the business case and organisational objectives are for the project.

We tend to structure business cases around a combination of efficiency, risk reduction, income generation or the development of new, marketable capabilities. Developing the business case together also helps us discuss the roadmap for their technology so that neither us nor our clients get distracted by opportunities which don’t directly drive ROI.

Stakeholders & understanding

Empathy means understanding, so take time at the start of the project to truly understand your stakeholders, especially the people who will use the technology. Again, don’t assume you know their context, their motivations, their process or their pain-points.

Governance

Think about your decision-making process early on before you get into the weeds of the selection process. This is very dependent on your organisation, but consider the broad approach. Will you aim for consensus (our recommendation since it encourages discussion and buy-in) or does your culture require something more ‘scientific’ such as voting? Try hard to avoid allowing one individual (usually the most senior person) have overall power to make a decision as that makes it hard to get others on board later.

Having a process for decision-making also adds legitimacy and a certain tempo to your project, saving you from questions and grumbling from others later on and keeping the work moving forward. This is especially true if your organisation already has governance structures.

For complex projects involving many stakeholders, we sometimes recommend splitting your team into a steering committee and a selection team. Just make sure you update the committee regularly.

Measure capacity & readiness

Be honest about your capacity. We often see clients getting over-excited about all the things their new technology can do without seriously assessing what they have the capacity to leverage. Technology is a tool; rarely does it provide value autonomously. These projects often fail because the organisation couldn’t sustain the processes or ways of working that an ambitious piece of technology requires.

Other times, things go wrong — or the project overruns — because the organisation’s data is in a mess. Migrating data to a new system is always painful, even with cleaned and well-structured data. Data cleansing and migration often forms a large component of our client engagements. Since new technology tends to drive towards greater automation and use of data, having well-structured data is a requirement.

If you're doing this process with a partner like us, have them assess the state of your data, technology, processes and human resources at this point. You may find you need to do some groundwork before continuing with the project and it’s better to have an outsider give you an honest appraisal early in the process than to find out the hard way later on.

Step 2: Define

Research

Here you or your technology partner will conduct plenty of research to understand how your organisation works and what it needs. See our article, “Research methods for technology selection” for a summary of the methods we use.

Scenarios

After the empathise and define stages, you’ll end up with lots of raw information. We need to turn this into something tangible that sits at the centre of your selection process. This is where clients often expect us to start writing feature checklists, but there’s a better way, again stolen from the design world: user stories (or ‘user scenarios’).

A user scenario is a short, real-world narrative that tells the story of:

• what the experience of a user working with a system should be like;
• what they’re trying to achieve; and
• what the end-to-end process looks like.

They are lightweight, cover the whole experience (not just technical features) and are narrative, focussing on journeys, actors and context. They should also describe the ideal future state without being prescriptive. You’ll soon be taking these scenarios to software vendors so leave them room to offer creative solutions to your scenarios.

User stories or scenarios are important because:

• They help you think about the inputs and outputs of a system. Where does this data come from originally? What triggers this process? What is a donor doing before they enter our database? How will I want to get data out of this process?
• They help you think about the people involved and their context, not just the technology.
• Most importantly, they are testable. This is key to being able to differentiate between your options — we’ll see later how we use stories to test which technology is best.

Once we've developed stories or scenarios from your research we can co-write an RFP (request for proposal) with these stories being the meat of that document.

Filter the market

Now you have the core of an RFP based on user stories we need to decide which solutions you want to look at and, ultimately, which vendors we’re going to talk to.

Choosing the right market is important. Look at what’s core to your process and use that as a heuristic for choosing which market to focus on. For example, if your core data is transactional records we might want to explore project management and workflow markets. If it’s video and photo files, we’ll look to structure workflows around digital asset management tools.

Note that these core pieces of software won’t constitute your whole technology stack and you won’t necessarily store all the relevant data in the systems being selected here. The process we're discussing here is part of larger enterprise architecture thinking and other enterprise services should form part of the solution. Jamming too much into any one vendor solution is a sure-fire way to deliver sub-par customer experience and limit your flexibility as an organisation, as we’ve previously discussed.

Filter down to 8–12 options based on:

• Region & timezone — for complex technology you need access to the vendor’s support team.
• Budget & complexity — vendors tend to cluster around three tiers of cost and complexity: cheap/free, moderately complex and expensive enterprise.
• Platform vs. product — products give short term ROI at the cost of long-term flexibility. Platforms are better for capacity building. Products are better suited to low-capacity teams; platforms can give you an edge in the hands of a capable team.

Next, we’ll look at your scenarios and cut your list in half leaving only solutions with a good fit. Discerning an option’s fundamental scenario is useful. For example, products might both offer the features you need for a donor portal, but one might be fundamentally a portal application whilst the other might be fundamentally a web CMS with user accounts bolted on — it’s obvious which one has a better scenario fit if you’re looking to add a customer self-service portal to your stack.

Also consider fit in terms of vertical specialisation. For example, healthcare systems of record are highly specialised, whereas something purporting to be a “healthcare marketing automation platform” is little more than a marketing position. Digital asset management is another category which can benefit from industry specialisation as there are so many use-cases in the space.

You might also need to look at multiple categories of technology to fulfil your use-cases, in which case you’re going to need someone to think about how these systems fit together from a technical perspective. You may find it valuable to engage a services firm (that’s what we are) to help you design a solution made up of multiple systems rather than picking a single system yourself. We’ve previously discussed how to use design thinking and the customer experience to guide the development of your suite of technologies.

Step 3: Ideate

You should now have 6–8 serious contenders. Now you get to the fun part: sending out your RFP and evaluating the solutions that come back.

We'll bring your team together and hold a formal narrowing-down meeting in which we the review vendors’ proposals using the decision-making structure agreed in the process. We'll jointly assess them on their scenario fit along with any pros/cons of the technology that are applicable to your context. We'll help you evaluate the vendor themselves as well; things like support capacity, consulting capabilities and size (counter-intuitively, smaller players may be safer) are relevant here.

We also use this time to start planning what we need to see in the demos that follow in step 4 using the content of these discussions to develop demo agendas that actually help your decision making.

This is also a good time for us to dig into any discrepancies in your selection team’s rankings. They may be indicative of different understandings or objectives amongst the team. If there is serious disagreement and you’re not all on the same page and we’ll take you back to the empathise stage.

Step 4: Prototype

Here you get to move to a higher level of fidelity and see the vendors’ real-life solutions in practice. We'll invite those vendors that passed the last narrowing-down meeting to demo their solutions to you. Rather than letting vendors demo whatever they want, we work with them ahead of time to design demos that address your specific needs, concerns and criteria.

This is where the hard work of developing those scenarios really starts paying dividends. It’s easy to see if a vendor has a well-fitting solution or whether they’re trying to squeeze your scenarios into their system. The scenarios prevent demos becoming a dry, boring sales pitch where the vendor tries to wow you with features you don’t care about. However, we will segment the demos so the vendor has a chance to show off what else you might find valuable in their offering as well as addressing your written use cases.

Depending on the complexity of the software being demoed we might separate your team for parts of the sessions so relevant technical and business teams can spend time with each other in parallel.

Step 5: Test

By now we’ll have a much shorter list of really strong contenders — maybe 2 to 3. The next step is to work with them to conduct a proof of concept. Here we facilitate your team (or us, if we’re also going to work with you on implementation and configuration) actively working with the vendor on a small piece of real implementation using your use-cases and your data. This gives you a chance to see what it’s like to work with that vendor and their technology in a real way.

You will likely need to pay the vendor for this. Some will say this stage is a waste of time and money — one could just pick the best demo — but it is actually extremely valuable:

• It de-risks the whole project because we get to actually try the system. It closes the gap between what we think will work and what actually works.
• It engages your team in the process which helps keep them on board during implementation (which can be a painful process). It also engages stakeholders since they can see something tangible.
• Testing your requirements in reality gives us a chance to learn and course-correct before getting locked into any particular option.
• It speeds up implementation because all this work is usable going forward. You’ll show value more quickly after committing to buy which is great for organisational support.
• It gives you time to plan around any difficulties we experience before starting the bigger job of actually implementing the technology.
• You will understand real implementation costs and your realistic readiness to buy, meaning you can budget better and avoid buying something you’re not ready for.
• We remain in a competitive environment for longer which is good for negotiations.

After this proof of concept stage we’ll be in a very strong position having developed your business case, taken time to understand your context and success criteria, outlined the context in which the technology is going to be used, and actively verified that the vendor's technology is a good fit. The final decision can now be made with the best information possible.

Scaling this down for smaller projects

The process as we’ve portrayed it here is quite rigorous. For mission critical technology we’ll advise you to follow the whole process — we might work together for as much as 6–12 months start to finish. Smaller projects don’t warrant such an involved process and may only need 2–4 months, but the design thinking approach is still valuable so we don’t cut out any of the steps; we just scale them down depending on:

• The size and complexity of your organisation — smaller organisations won’t need as many people from your side to be involved.
• The importance of the technology — this determines the amount of rigour we’ll go through in writing and evaluating vendor proposals and the length of your prototyping and testing stages.
• The amount you’re spending on the technology itself — if it’s very little (or zero) we may act as a vendor proxy, writing proposals and conducting demos with technology ourselves rather than attempting to engage the vendor’s team to do so.

Applying this to existing technology

Selecting or implementing new technology doesn’t happen all that often so it’s important to be intentional about learning from your experiences. Project retrospectives should be your project plans — no matter what the project — and you shouldn’t move on to the next project until the previous project’s evaluation, write up and dissemination is complete.

If you’ve done a technology selection or implementation project before, we suggest leveraging your concrete example and doing a mini version of this process internally as a case study of how to approach things in future. Not only will that show you where you might have done better and help you learn, you’ll end up with a tangible document that shows a real-life example from your organisation which can then act as a playbook for others in future. This carries much more weight than generic outside advice, especially if it’s wrapped up in narrative that tells the story of what you actually did, what things weren’t great, how you could have approached it, and what that alternative approach would have gained you.

Project retrospectives obviously need objectives to benchmark against. If you can’t find the document that defines success criteria for a previous project then there’s a different conversation to be had about how your organisation conducts projects in general.

You can also use the early stages of this process (empathise and define) to uncover where your existing solutions fall short and then use the latter stages (ideate, prototype and test) to guide a project to extend or adjust your technology.

Using the process to select services firms

Depending on the complexity of the technology you’re looking at, you’re likely to need to engage implementers. When you need to hire firms for work such as branding, web design, development and consulting, use this process to select them too.

Parts of the process are still the same: it should be iterative, you should have a good process and an organised team to drive it. However, user scenarios probably won’t make sense, at least not in the selection process. (The project work itself is different. We heavily leverage design thinking and user scenarios for our clients’ web and application development projects, for example.)

Instead, try asking them to explain how they’d approach the sorts of work you need, and explain how they’ve done that in the past. As before, don’t be prescriptive — explain what you need and let them be creative in addressing that.

You also still want to get an idea of what it’s actually like to work with them, so instead of proof of concepts look to conduct small pieces of example work with them. Amongst other things, this will get you past the sales people and directors and get a feel for what it’s like to work with their team.

Don’t assume you need to replace your technology

If you’re unhappy with your current technology, don’t immediately try and replace it. Most technology has APIs so we may be able to build small additions or features on top of what you already have. Replacing incumbent technology is an expensive, risky process so building new capabilities on top of your core systems is sometimes the best course of action.