Building a digitisation strategy – how to start and what to expect
This article was written for and first published in the RICS Property Journal and is reproduced here with permission.
The events of the past 12 months have accelerated the adoption of digital technologies; culture shifts that would previously have taken years have been implemented in a matter of weeks. From the public sector to hospitality, organisations have had to rethink the way they operate and how they serve their customers. Amid so much change, it’s tempting to cling to what you know. However, the bigger risk for an SME in today’s market is to think that digitisation isn’t relevant to its business.
An example I like to use to illustrate this is the banking sector. Historically a market with significant barriers to entry and powerful incumbents, banking looked impervious to disruption a decade ago having weathered the financial crisis. Today, however, it’s clear it was inexcusably slow in understanding the potential for change that digitisation represented.
Challenger banks such as Monzo are running rings around establishment players by better using technology and data to make life easier for customers. The data these brands are using isn’t novel – the incumbent banks were sitting on it all along – but the challengers better understood the opportunity it represented. Now the establishment banks are digital followers, pedalling frantically to keep up with challengers they should have seen coming.
The SME owners I meet don’t wish to stick their head in the sand and ignore digitisation. They have digital ambitions – to use technology to develop, extend or protect their competitive advantages. Unfortunately, many organisations still find themselves stuck in the starting blocks when it comes to their digitisation strategy.
Don’t be afraid to ask for help
The question that’s most often asked of me about developing a digitisation strategy is where to start. As a business, how do you go about identifying the digital opportunities open to you?
In my experience, there are two ways to do so. The first is by working with a specialist organisation to conduct wide-ranging, early-stage ideation workshops. These are designed to generate original ideas about how technology could add value to a business. They’re usually broad in scope and involve a variety of skill sets and views, from staff at all levels of an organisation as well as external specialists and even customers. There are many frameworks to help with this process, and each practitioner or organisation will tend to have their favourite. For example, here at Browser, we like the Design Thinking process.
Once an opportunity has been identified, a digitisation strategy can be developed to create appropriate systems, typically in conjunction with the organisation that helped run the workshops.
As you can no doubt guess, such an approach isn’t cheap. I can’t even promise that it’s always quick or easy either. However, when compared to the cost of not finding out how digitisation could improve your company, it starts to look like much better value.
Starting small is better than not at all
The second, and more common, way digital opportunities are found is when a team within an organisation identifies a process that’s viable for digitisation. This may be because they find a task they can’t complete effectively and they think technology may be able to help, or in response to customer feedback – ‘We’d prefer if we could submit this online’ – or to keep up with a service introduced by a competitor.
This approach can initially appear a little less valuable than the first; it seems less worthy and ‘big picture’. Yet for many SMEs, the best way to begin digitisation is to start small and build confidence. The focused, task-based opportunities that arise in this way are perfect for that.
In fact, our biggest recent project started this way. Analysts at a security and risk consultancy were unhappy with the way they were asked to share sensitive reports with clients. Everything was email-based, and this caused frustrations and delays; sometimes messages went undelivered because they hit spam filters, or an address was mistyped.
The product we created, Portal, remedied these complaints by providing a secure digital space for transmitting information. Aside from making analysts’ jobs less stressful, this also had a commercial side effect – streamlining the system reduced the time it took to deliver a report, enhancing efficiency across the business.
You’ll notice that I haven’t said any kind of technical experience is needed to kick off a digitisation strategy, and that’s an important point; you can buy technical expertise in. What you can’t buy in as easily, however, is the experience of the way your business functions and an understanding of what your customers want. If you can supply this information, chances are you’ll have some ideas about how you can improve your business. This is all you need to start the digitisation process.
Success is built on research
Once you’ve identified an area you’d like to improve with technology, the next step is to work out how you’re actually going to do it. Most digital projects, therefore, start with a research phase, sometimes called a discovery phase – the most important phase of any project.
This process provides space and time to research users and markets, and analyse data. This information then enables later exploration of design approaches, mapping user journeys, and even the creation of prototypes to test technology options.
A discovery phase will culminate in a research report detailing exactly how your digitisation strategy should proceed, including identified risks, justification of technology choices, and an outline of milestones and outcomes. In the case of the Portal, our discovery phase started with a series of user interviews and workshops with three key groups: customers, analysts and project managers.
This user research process differs from project to project, but typically it involves work shadowing, recorded task assignments and benchmarking of useability. This process allows us to see for ourselves how users accomplish a task, where the so-called pain points are, and whether there is any duplication or repetition.
In this case, the research showed us that users had three key jobs they wanted to do: launch projects, store documents, and visualise project data. Ensuring these tasks were easy to complete became a touchstone throughout the project.
User research can prove valuable in unforeseen ways, too. For example, while working on Portal, our interviews revealed that analysts were wary that the security processes built into the new platform would be draconian. They thought it could prevent their quick retrieval of information from the system. Because we uncovered this concern early, we were able to mitigate it with good design. We undertook multiple phases of prototyping and user feedback to develop a login process that users felt was efficient, without compromising the client’s security-conscious brief.
Quantitative data can be useful too
Assessing hard metrics, such as web analytics or other quantitative data, complements the qualitative information gathered in the user research phase. For Portal, this data informed our assessment of engagement and efficiency, such as time spent on tasks or transaction frequency. This data helped highlight times where users’ engagement dropped off or there were bottlenecks; we were able to correlate these with points raised in the interviews to provide an holistic view of the way the process worked and where there were opportunities for improvement.
It is important to remember that we must resist the temptation to focus on a solution too early. The aim of this first round of research is merely to understand what the problem is, and get an idea of the direction in which to go.
This keeps the project flexible and gives us room to pivot quickly should we need to once we move into prototyping, mock-ups and an eventual alpha build. It also means we avoid trivial sticking points – these can often be misunderstood as being critical, when in fact they may be part of a bigger problem that can be solved once all components are addressed collectively.
A trip to MoSCoW
With your initial research understood and digested, we can then collate a backlog – which is just a techy name for a list – of what needs to be developed, such as a sign-up form or a password reset function. The most effective way of doing this is to write down everything the system or product needs to do in the form of user stories. Each of these simply describes a requirement that a user may need to execute; for example, ‘As an admin user I need to log in.’ In my experience, most normal-sized projects generate around 300 user stories.
Using each story as a descriptor of what needs to be built enables us to estimate the time required to develop the product, which will in turn dictate the cost. Typically, this first estimate will be eye-wateringly huge – we don’t usually share it with the client – because at that moment we only have a list of absolutely everything all stakeholders want the system to do.
If you happen to have an unlimited budget for your digitisation strategy, lucky you, you don’t need to prune this estimate and can move on to the build process. But, back in the real world, it’s usual to narrow these requirements down into just the most important user stories. This is done through a prioritisation process called the MoSCoW method.
All key stakeholders should be present for this process. It commonly involves writing user stories on to sticky notes before discussing them individually and sorting them into one of four categories: must, should, could, and won’t, hence MoSCoW.
All the user stories in the ‘must’ category – or, sometimes, the ‘must’ and ‘should’ categories – form the basis of a minimal viable product (MVP) brief. This represents the least amount of development required in order to provide the desired service.
Prioritising only the core functions in this way avoids wasting valuable budget on elements that are either desired but not actually required, or functions that are not required just yet. The result is that the product gets built and deployed quickly using as little budget as possible, after which we can begin gathering valuable data and feedback about the product from actual users.
A lot of discovery phases end with the MoSCoW process. For particularly complex projects, however, there may be some extra stages between creating your MVP brief and actual development.
The most common is a user experience (UX) prototyping process, which aims to map the way users move around and work within the proposed platform, app or system. This helps put the features outlined in the MVP brief into a framework, showing where they will be located and how users will move between them. These user interface designs can then be tested with users, and feedback incorporated before the build starts.
Taking stock of your digitisation strategy
Digitisation strategy documents come in all shapes and sizes. The important thing to remember is that bigger isn’t always better. If you don’t know where to start that’s fine, just ask for help – you can see how to get in touch with us on our contact page. As long as you can stay focused on what’s best for your customer then your risks should remain low.
Once you’ve established an area that can be improved with digitisation, a discovery phase will help you create a focused strategy. Whether it’s the introduction of a new digital product or perhaps a larger infrastructure overhaul, you can be confident that this approach will identify an appropriate solution – leaving you to breach that new market or maintain your competitive advantage.