I’ve been part of digital transformation work for close to 20 years now. Some of it went well. Some of it didn’t, which is more instructive. Looking back at the ones that struggled, the causes were rarely technical. The platform usually worked. The methodology was usually sound. What went wrong
There’s a question that comes up early on most programs, usually as a scheduling problem rather than a role question. Who’s actually documenting the process? The business analyst assumes it’s covered. The change team thinks it’s a project deliverable. The process owner assumed someone did it years ago. Meanwhile the
This comes up in almost every process analyst interview. How do you handle resistance to change. The honest answer is that most people aren’t resisting change itself. They’re resisting being changed by someone who hasn’t asked them anything. There’s a difference, though it takes a while to see it. Once
The default way to run a current state session is to get everyone in a room, put a blank wall in front of them, then build the map live. It’s the accepted approach. It’s also the reason process mapping workshops have the reputation they do. Three hours disappear, the loudest
Here’s a situation that plays out on most programs. A team has a procedure they wrote themselves. It’s a Word document, slightly out of date, structurally messy, missing the prerequisites. You produce a properly written replacement. Clear steps, verified against the system, tested, well structured, findable. Six months later they’re
Big programs have a way of swallowing people. There’s a program board, five or six workstreams, a systems integrator, two vendors, a change team, and somewhere in the middle of it all sits you. Your job, on paper, is to map the current state and help design the future one.
Ask any engineering team how they manage change to their codebase. You’ll get a confident answer. Version control, branches, pull requests, code review, a deployment pipeline, rollback if something breaks. Every change attributable to a person, a date, a reason. Now ask the same organisation how they manage change to
Every knowledge base I’ve inherited has the same problem. Too much content, not too little. Hundreds of articles, several versions of the same procedure, material describing systems decommissioned years ago. Everyone agrees it needs cleaning up. Almost nobody actually does it. The interesting question is why, since the fix is
Spend enough years around documentation work, you start recognising the same characters in every organisation. Different industries, different platforms, same cast. None of them are difficult people. They’re all responding sensibly to incentives nobody designed on purpose. Recognising which one you’re dealing with tends to be more useful than any
