My Observations on Digital Transformation

A few months ago, I was approached by a group of professionals who were doing a series of case studies of different organizations undergoing digital transformation, and asked to participate. Unfortunately, the studies were sponsored in a way that participating did not play nicely with our status as a charitable organization, but they were kind enough to share the writeup with me, and it's perfectly fair game for me to share some of what I learned....from other people talking to me, hopefully in a way that synthesizes for others what we do and how we do it well. Many of these are encapsulations of every presentation at every networking event in the history of IT, and others are, at least to me, surprising findings that I've had over my (almost) decade in this role.

The first is that laying a foundation for future deployments is far more important than the success of any one project. While this may seem straightforward, the real challenge is to take a deep breath and spend the time on proper requirements, stakeholder journeys, and design when there is a fire drill coming from levels far above. I freely admit that I have a mixed record of being able to sell stakeholders on the ROI of doing this, particularly when the success is dependent on factors I may have no control over, but I do think that the ability to do this is a key sign of a healthy team or organization. I have seen lots of presentations at Gartner (and other) conferences that the outlay to support a newly developed tool over its lifecycle will be 10, or 100x the cost to build it, but I don't recall seeing numbers on the technical debt that a quickly built tool creates. Surely it's a similar order of magnitude, the only difference is that it increases exponentially based on OTHER existing tools or processes that it crosses.

Secondly, so much is made of the sexy tech out there, (I've seen it from object-oriented design, through ERP systems, CRM systems, everything in "the cloud", predictive analytics, robotic process automation, AI, and soon (more) quantum computing), but 70% of digital transformation has nothing to do with the digital part, just like 70% of my job (you can see my title here) has nothing to do with technology. What this means in my world is that while developers are incredibly valuable, the most indispensible people on a project tend to be the ones who can help the stakeholders (all of them) come together to articulate, and more importantly, hold to, the scope and business requirements, so that everyone has a clear direction to the work that they already know how to do. One does not need to look far in the news to see striking counterexamples to this. That person is not necessarily a project manager, often it's not even an official role at all, rather an informal leader who can (sometimes subliminally) keep everyone's eyes on the prize. This is why I am incredibly proud of my current team's expertise not only in (many) technical areas, but their deep understanding of the two dozen teams that we support. The best compliment I've seen our team receive was when someone was surprised that we weren't only working with their group, because we knew their needs so well.

Third, I've gotten a lot of questions from various levels (above and below) about the value of rebuilding an organizational data dictionary. "Why are we making a list of fields that aren't all being used?" (Knowing the problem is the first step to solving it?); "Why are we doing this when we are just going to refactor this tool or program?" (This helps us see any requirements we may have missed?), but invariably, the quieter voices in the room, usually the ones who have most or all of their time tied to the project in question, are extremely happy to see a unified record of all of their data, very possibly for the first time. Ideas start flowing almost immediately, not only for their program, but for others with similar processes. Reporting gets easier, leadership status briefings get easier, and their minds have just that tiny bit of extra space to be able to think strategically, rather than trying to operate in an ambiguous space.

Lastly and most importantly, don't make assumptions. The best example I have seen for this is smartphone literacy. Our organization works for and with older adults living with low income. It's sometimes too easy to assume that working with that demographic means you don't have a tech savvy audience. But in reality, there are thousands of older adults that we work with who are not only smartphone savvy, but prefer working that way. Conversely, the assumption that employees and business partners prefer technical solutions over "the old-fashioned way" is not always a safe one either. In one program, we were trying to figure out a way to serve as many people as possible/at scale. We found that about half were comfortable transacting through a web site, but the other half wanted a voice to guide them through. More experimentation is needed to see if an automated voice can suffice, but that knowledge was a tremendously important step to everything in the second item here, all because we just asked, rather than assumed a one-size-fits-all solution that works for the organization, rather than those we serve.

I've never stayed in one role this long, and it's amazing to think of both how far we've come, but also how many opportunities have opened up as a result. With those opportunities and any others after them, the focus will be clear. As my last quote in this piece stated - "The digital side of transformation is the easy part. Transformation is the hard part."

The image (credit to Robert Greiner), other than being for the algorithm, resonated with me for how we are trying to bring order to the chaos of working in a matrixed environment with competing priorities, definitions, and resources, all with a very powerful goal in mind.

If y'all want more missives from me, feel free to start a conversation in the comments!