More Meaningful Ways to Describe Digital Goals

The word "digital," in my experience, is pretty ambiguous. It's a very generic term, like many in IT, and is used by different people in different contexts. If I say "digital" to you, you'll likely imagine one thing, while I might picture something entirely different. This discrepancy grows more complex in collaborative efforts like a digital program. With three people, there are six potential misunderstandings. If you have 20 people, that's 380 different variations of meaning for that single word.

Because of this, I believe "digital" isn't a particularly useful word on its own to convey meaning. This reminds me of my English teacher, Mrs. Smith, who used to say, "Nice is a lazy word. Be more specific." Saying Mrs. Smith was “nice” is vague and open to interpretation. But if I describe her as “genuine” or “caring,” you get a clearer picture of what I mean. This principle applies when managing a big transformation program. We need to be specific to avoid ambiguity and ensure clear communication.

This is crucial when you have digital ambitions. You won't achieve much if the 20 people you're working with, including stakeholders, are all pulling in different directions because they have different interpretations of key terms. This can be a major issue. As Lewis Carroll's Cheshire Cat says to Alice, "If you don't know where you're going, any road will take you there."

At the beginning of an interaction with my clients, when I hear the word "digital," I find myself asking a slew of questions, first in my head and then out loud. Questions like:

• Are we talking about all technology here? Is "digital" synonymous with all technology?

• What's the distinction between the words "system," "technology," and "digital"? Are they interchangeable or distinct for us, in this context?

• Are we referring to newer types of technology like web and mobile, as opposed to older systems we used to install on desktops and servers?

• If something is web or mobile-based, does that automatically make it digital, or are there other nuances?

• If there's a web or mobile app that serves as a core system, is that considered digital too?

• Is something digital if we're buying it off the shelf? Or is it only digital if we're building it internally?

• Does digital include or exclude the integration we're developing between different systems?

• If I'm running a digital transformation, does it impact my delivery process? Is there a relationship between "digital" and project management methods?

• Does "digital" have meaning only in the context of certain types of users, or is it applicable no matter who the user is?

• And finally, why are we pursuing this digital initiative? What's our primary goal? Does this goal differ in a digital project? Can we use the definition of digital to clarify our objectives?

Interestingly, when I pose these questions to key sponsors, management, and executives within the context of a digital program, they often don't have clear answers. And that's a problem. It means we're likely to get nowhere fast, as the Cheshire Cat would caution.

Who

Let's talk about the “who.” The people we focus on and work with in a digital program are fundamentally different from those we interacted with in the early days of IT. When I refer to the "olden days," I mean from the 50s through the 90s. Back then, IT primarily communicated with administrators and support staff, who, in a care organisation, would interact with workers and clients through phone calls, emails, and paper documents. These interactions would eventually filter down to the support staff and administrators, making them the main users of the system.

But then digital transformation came along, and we realised that if we were clever (and I underline clever), workers and clients could input information directly into the systems themselves. This innovation allowed us to skip a bunch of needless steps because information was coming in at the source. As a result, we could run operations more efficiently by cutting out unnecessary tasks.

This shift is crucial because it means that when we deliver a digital solution, we're engaging with a different type of person in a different situation than before. These new users have needs distinct from those of support staff and administrators. While we might improve the lives of the support staff and administrators, we often do so by removing them from the loop of certain business processes or altering how they interact with those processes, rather than merely speeding up their tasks.

One mistake we make when applying traditional project thinking to digital projects is focusing on "as-is" and "to-be" processes. This approach is a waste of time in a digital context.

In the digital care world, the key people are the clients, the workers, and other staff directly interacting with clients. Once you move beyond this direct interaction, to internal support roles, team leaders, management, and executives, we start moving away from the core focus of digital transformation. When running a digital transformation program, I spend most of my time with the end users—the clients and the people directly interacting with them. I spend less time, not no time, but significantly less, with internal staff like managers and team leaders. Prioritising conversations with internal staff leads to solutions that cater to their needs, not those of the end users. To build something fit for purpose for the intended audience of digital technology, the focus must be on the people who will be using it directly.

How

As we delve into the “how,” this approach brings about some interesting realisations in terms of our methodology within a digital program. It gives us clues on what should be considered inside versus outside of the “digital circle” from a project management perspective. If our goal is efficiency and we aim to deliver a cohesive experience, we need to organise our work around the end users. By “end users,” I mean clients, workers, and other client-facing staff. This may sound like a minor shift, but it’s actually fundamental. It’s a change in the process—a different project plan entirely.

Instead of starting with the system, trying to fit it into a business process, and then training people (which is a critical point), we begin with the end users. We identify their problems and develop the simplest solution they will agree to use. This approach differs significantly because we can't impose the system on them. If we try to force it, we’ll end up with a system that isn’t adopted, and without their use, we miss out on the intended benefits. Unlike traditional projects where administrators are the primary beneficiaries, in a digital transformation, we aim to bypass traditional administration by engaging end users directly.

The focus shifts from “this is how the system works and how you use it” to “if we make it this simple, would you use it?” The key to achieving efficiency is through user adoption. If the solution isn’t highly user-focused and straightforward, it will suffer from poor adoption, undermining our efficiency goals. If your approach starts with the system, I wouldn’t even call it digital. Such a traditional, big-bang approach is more suited for internal support staff and is not ideal for delivering a seamless user experience to end users.

Another way to think about this is that digital projects should be outside-in. They start from the outside of the organisation, with the clients, and then move to the most client-facing staff, which in a care organisation would be the workers. From there, you might move one step inward to include other client-facing roles. Once you go beyond this point, you should reconsider using the term “digital,” as it starts to become contradictory to the principle of focusing on the end user.

What

Under the "what" category, we need click-friendliness. Instead of making users go through 20 clicks, aim for three. If it's 20 clicks, it wastes a lot of time and leads to manual workarounds, requiring support staff to help. It's not just about buying products; we need to build specialised experiences across them to create a unified, seamless experience and hide the complexity of backend systems. If we don’t, we're forced to manage them ourselves, needing help to do our jobs and focusing less on clients.

For instance, a small company might manage with workers logging into multiple systems, but as it grows to a few hundred employees, frustrations increase. This happens for two main reasons. First, they engage in "swivel chair integration," transferring information between systems manually, often with multiple logins and inconsistent experiences, leading to inefficiencies. Second, each system is usually generic, meant for various industries, making the experience clunky. Users of systems like Salesforce will notice the difference between it and a custom experience designed specifically for tasks like auto processing. The second point emphasises that, besides juggling multiple systems, each individual system is often cumbersome, causing unnecessary time spent navigating them.

A key aspect of a user-centric approach under the "what" category is the need to build integrations to automate user tasks. Integration work is crucial in a digital project, not just a standalone task. Integrations are essential for scaling the user experience we aim to deliver, ensuring it remains click-friendly. Other integrations for internal purposes might be necessary, but they should be considered as part of broader integration projects, not the core digital project.

The final point under the "what" is crucial: in a digital world, we're generally building rather than buying. While building around purchased elements is common, the focus should be on creating click-friendly experiences, and the best way to achieve that is through building. Using low-code tools or extending vendor products often results in a system-first approach, which can lead to complications in adapting the system for user needs. By building a thin user experience and treating backend systems as the system of record, we can prioritise the user experience over system constraints. This approach allows for the integration of systems as a secondary step in the digital project, keeping the primary focus on user needs and the experience.

In most digital projects I've been part of, there's usually some aspect of core system replacement or acquiring a product to meet digital goals. These should be managed as standard, internally focused projects first. Once established, we need to initiate a digital program centred on creating click-friendly, cohesive experiences for a broad user base.

Summary

In summary, digital isn't just about technology. It involves web-based or mobile systems that interact directly with users. More importantly, digital is about philosophy, strategy, and program delivery.

1. Digital is outside-in. It focuses on clients, workers, and client-facing staff, not internal administrators and managers.

2. It’s human-first, not big system-first. This means prioritising user-friendly, click-efficient solutions and fundamentally changing project delivery approaches. It requires a different project plan.

3. It’s about creating seamless, integrated experiences. This avoids the need for users to handle multiple products and “swivel chair” between systems. If users don’t have a cohesive experience, they won’t adopt the solution, leading to manual workarounds, increased support needs, and higher workloads with less effectiveness.

4. It’s about building lightweight solutions that enhance existing systems. The focus is on delivering user experiences around current systems rather than introducing new products. Implementing a new product is not a digital project; it’s about focusing on the solution first and users later. Digital projects, on the other hand, prioritise users from the start and adjust the system to fit their needs.

Ultimately, digital projects aim to deliver more value for the same investment by reducing internal tasks and administrative overhead, rather than automating existing processes. It’s about building rather than buying, emphasising the user experience and delivering efficient, streamlined services.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/