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:
- You get some business analyst to go around and interview users and stakeholders.
- She makes a long list of features and categorises them in Excel. Excel’s limitless rows encourage her to note every detail.
- 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’.
- 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.
- 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, 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.
So, what’s the solution?
The antidote is to follow a process that encourages a human-centred approach to uncovering true business needs and embodies a practical methodology to differentiate between competing options.
Learn how to use this human-centred approach to avoid these mistakes in your organisation: “Get it right the first time: How not to waste money on your digital tools”
