Who Documents Business Processes? The Role of a Technical Writer in Process Mapping
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 technical writer has been booked […]
Why SMEs Trust Their Own Bad Documentation More Than Your Good One
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 still using their own version. […]
You Wouldn’t Ship Code Without Version Control. Your SOPs Have None.
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 their standard operating procedures. The […]
🤝 Process Maps and Work Instructions: Why One Without the Other Falls Over
There’s a familiar moment on transformation projects. The maps are finished. They’re clean, colour-coded, signed off by the steering committee. Everyone agrees the new process makes sense. Then go-live arrives, and someone in the operations team asks a simple question. “Okay, but what do I actually click?” The map can’t answer that. It was never […]
“We’ll Document It After Go Live”
There’s always someone arguing documentation can wait until after go live. The logic is hard to fault in a planning meeting. The system isn’t finished. Screens are still changing. Why write procedures against something that’ll look different in 6 weeks. Then go live arrives, the team moves onto the next release, the documentation never gets […]
What Makes a Work Instruction People Actually Use
Most organisations have plenty of documentation. What they don’t have is documentation anyone opens twice. The difference between a work instruction that gets used, versus one that gets written then forgotten, usually comes down to a handful of decisions made before anyone starts typing. Here’s what those decisions look like, plus how to use AI […]
🤝 Building Rapport With SMEs to Get the Information That Matters
As a technical writer or business process analyst, your work depends on other people’s knowledge. Subject matter experts hold the detail behind the diagrams, SOPs and work instructions. They know what really happens beyond the documented process. They know where things break. They know which steps exist only because of history. But getting that knowledge […]
📘 How to Build a Good Knowledge Base Through Collaboration
A knowledge base is one of the most valuable tools a business can have. It saves time, reduces errors and keeps knowledge inside the organisation. But building a good knowledge base isn’t just about choosing the right software. It’s about working with people, drawing out their knowledge and turning it into something structured and useful. […]
📘 Building a Knowledge Base in Confluence
A good knowledge base is more than a set of documents. It’s a system that makes knowledge easy to capture, share and maintain across an organisation. Atlassian Confluence is one of the most effective tools for this job. It combines structure, collaboration and flexibility, making it a strong platform for knowledge bases of any size. […]