Blog · Aliso Digital
Practical thinking on digital transformation, process, documentation and the people side of change.
No articles found. Try another word or topic.
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
There’s a line I keep coming back to when people ask whether AI is a threat to technical writing. Producing text has become cheap. Deciding whether that text is right, whether it’s needed at all, whether it’s in the right place, has not. Those were always different skills. They just
Every knowledge base project runs into the same wall eventually. The person who knows the most has 40 meetings a week, an incident to manage, plus 3 other projects asking for their time. Your request sits in their inbox, unread, for a fortnight. This isn’t a motivation problem on their
There’s always someone arguing the customer journey map can be built in a workshop. Get the right people in a room for a day, sketch the stages, agree the pain points, done. It produces something. It just produces the version the organisation already believes about itself, which is the one
Nobody’s knowledge base has too little content. Every one I’ve inherited has too much, usually by a factor of about 3. Hundreds of articles, several versions of the same procedure, material describing a system that was decommissioned in 2021. The complaint is always that people don’t use it. The diagnosis
