Piloting the Digital Journey: The Path to Successful Digital Adoption

Embedding successful digital working in our organisations can streamline our methodologies, reduce costs, allow us to focus on other technical challenges, and grow new and exciting workstreams.

This article is written to help those who are considering building (or commissioning) new digital applications or workflows and have not yet got the experience. Many of the terms can be easily looked up on the internet, where greater detail can be found.

What is digital?

Digital isn’t all about stand-alone application development (e.g. mobile apps); in IA it is often about putting a digital ‘wrapper’ around or between existing workflows, optimising not only your own work, but also how well your work connects with the work of others. So, digital very much needs to encompass both the reporting (e.g. Digital Environmental Statement websites) and also the actual assessment itself.

For example, at Atkins we regularly run automated distance calculations during Environmental Impact Assessments (EIA), where in seconds we have the distance of all environmental designations to a development site boundary. Previously these distances were measured more manually in a GIS package. Now a coding engine (Python or FME) uses opensource environmental designations and engineering design datasets stored in the Spatial Common Data Environment (sCDE).

This represented the transfer to digital of a relatively small task but achieved significant cost savings thanks to the iterative nature of design. To have success in other similar digital methodologies there are two components required. Firstly, there was a willingness from the task holder to make improvements; the job of manually measuring hundreds of designations to the site boundary is tedious and error prone. Then there is the demand from the (internal) client. Development site boundaries often change during the iterative design process and automated distance calculations can overcome this challenge by being run multiple times in very short timescales, to rapidly supply environmental decision makers with the evidence they need to inform design and IA.

Go agile

For managing the creation of digital workflow or applications we would recommend using the Agile project management methodology. At its heart, this entails those developing the application regularly checking in with key stakeholders and not having to define the whole product at the start. Typically, this is done by working in two-week sprints where development tasks are clearly defined. At the end of the two weeks, a review takes place and development can change as successful or less successful application aspects are discovered. This approach is different to what would be considered traditional where review periods occur after a lengthier development phase, allowing problems to build up and potentially snowball.

Objective, method and requirements

When considering the building of a digital application or digital workflow, the starting process is to determine your objective. Recent examples of objectives for us have been “capture great habitat data” or “convey a non-technical summary (NTS) for an EIA”. With your objective determined a method is required, for example “use GPS enabled devices to collect habitat data which can be used in biodiversity net gain calculations”.

While determining your objective and method, the audience must always be a consideration. Who is going to use the application or workflow and what do they need in order to succeed in using it? We can all relate to the experience of being handed a shiny new tool which doesn’t, in some way, work with our methodologies or simply isn’t explained to us. Then who is going to be instrumental to make development successful? Identifying key stakeholders and budget holders will push development through the finance channels. Super-users and digital champions can also play a part in the mass adoption of an application.

Requirements gathering is the next step and forms part of the business case. The MoSCoW prioritization technique is a tried and tested framework helping stakeholders reach an understanding of what form the digital application will take. MoSCoW stands for must, should, could and would:

• Must – Must have this requirement to meet the key objective of the application
• Should – Should have this requirement, but the application does not necessarily have to have it.
• Could – Could have this requirement.
• Would – Would have this requirement but perhaps not during an early rollout.

MVP

With the requirements gathered you can set your minimum viable product (MVP); an agreed minimum level that will enable full testing and demonstrate digital workflow value. An example of this MVP for the distance calculations is a semi-automated application where a GIS data expert runs the processing and the actual measure of distance is automated. The next step to automation is where an environmental discipline expert is able to select some environmental data inputs and then press GO! They then receive a file telling them distances measured. This information then informs the wider judgements that the environmental discipline expert might make.

Pilot, roll out and maintenance

Piloting your application or digital workflow avoids a large untested rollout, which if technical problems occur is a sure-fire way to prevent mass adoption. A pilot application must go to selected individuals who are suitably removed from the application development team and who will give unbiased independent feedback. From this pilot phase you will get enough feedback to adapt your MVP and integrate into your next development stage.

Once your application is ready for a full roll-out training is vital to ensure users get the most out of what has been developed. A plan for future maintenance and upgrade also needs to be put in place, to keep the application current and useable.

Final Word

Following the guidance above will help you create successful digital solutions to resolve a wide variety of problems or identified opportunities. One overarching aspect we need to ensure continues when becoming more digital is that the technology we create complements the skill and judgement of the professionals working in IA. Our projects after all are about people and the environment.