Guide to Digital Transformation: Discovery Part 2 - Methods and Processes

By Steve Yatson on 18 February 2021

In Part 1 of this series we stressed the importance of setting clear end goals, based on detailed information on a company’s present state. In this blog, we look at the process and methodology involved in charting a digital transformation during a Discovery engagement with our clients.

There are several elements we’ve used during the Discovery process that have proven successful, whether it’s been for a deep company-wide evaluation or a tailored look into a specific project:

  • Formal and semi-structured interviews with key stakeholders, including customers, as necessary.
  • Market reviews including competitive and market-based influences.
  • Existing operational reviews comprising data, architecture, user experience and automation opportunities.
  • Proof of concept mock-ups as required to determine clarity of tone and manner of user experience.
  • Landscape diagrams, an executive level overview of the operational system and personas involved.
  • Quantitative business analysis of expected project results.
  • Project plans including time, cost, and talent resources necessary to deliver the project.

In modern software development data collection is imperative. Every mobile app, desktop app, kiosk or device gathers and stores data in some way. That data storage is known as the back end. The user-facing application or front end connects through API’s to transfer data back and forth. The challenge often lies in using the collected data to provide value to an organization and its customers. It’s easy to collect massive amounts of data quickly. It’s difficult to attach value to it.

There is an art form to minimizing cost and maximizing the value of data collection, transfer and storage. We’ll dig into this later in the series as seemingly straightforward choices are in fact complicated and can affect scaling ability, performance, and cost.

To help with these decisions we create a high level view of the platform architecture and data flow similar to what’s shown below. We use this to facilitate collaborative engagement among all stakeholders, regardless of their level of technical knowledge. This aligns technical decisions with business imperatives and keeps everyone informed of the implications of their choices. This is a living document that evolves as the project progresses.

Example of a data platform architecture chart

Let’s now touch on the front end of a user-interactable system. In some cases device data is collected through indirect user interaction or no user interaction whatsoever. In those cases the persona shown in Part 1 of this series and the journey map below may be tailored to admin interfaces as necessary. For this example a user journey map was created by the user experience (UX) team through a number of research techniques such as interviews and on-site behavioral observations. This combines emotional elements with behavior to provide recommendations to the organization from the incredibly important user perspective. This is not a “we should do this” approach but meant to be combined with market data, competitive research and other known business needs to inform decisions and create the best solutions possible.

Example of a user journey map used to detail end-user or customer touch points and emotional aspects

At productOps we consider ourselves more a consulting firm than a software development firm. We are fortunate to have on staff expertise in strategy, design, UX, data, systems architecture, and workshop facilitation to drive the production of these foundational, actionable plans in the shortest possible time.

In closing, if the following crucial information can be gathered during the Discovery phase, success is attainable:

  • Are we building a leverageable foundation for further development of features, apps, and services?
  • What do the users of this product or system really need, expect, and what will absolutely delight them?
  • How will data be collected, stored and accessed?
  • What insights do we need to extract from our data to better serve our customers?

Having clear visuals as shown above of the proposed solution —which will also most likely include other documents—sets the stage for Part 3 of the Discovery process, Statement of Work (SOW) and Deliverables.

Let’s Solve Your Hardest Problem

Contact us so we can find a time to learn if we can help solve your data challenges.

We use cookies and similar technologies. By using this site, you are agreeing to our revised Privacy Statement including our Cookie Policy contained therein.