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 […]
Getting Time With SMEs Who Genuinely Don’t Have Any
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 end. It’s a design problem […]
Four People Described the Same Process, All Four Were Right
Ask 4 people to describe a process they work on daily. You’ll get 4 different answers. The instinct is to treat that as a problem, something to resolve quickly so you can get on with the map. It isn’t a problem. It’s the most valuable thing you’ll find on the whole engagement. Those differences are […]
Anyone Can Learn Confluence, Getting the Content Out of People Is the Real Job
You can teach someone the mechanics of a knowledge base in an afternoon. Spaces, page templates, permissions, a sensible folder structure. Within a few weeks, a capable person can build something that looks organised, professional, ready to fill. That’s the easy 20%. The other 80% is getting the actual content out of engineers, SMEs, business […]
The Requirements Are in the Conversation, Not the Document
Ask most people what a business analyst does and you’ll get an answer about documentation. Writing specs, keeping the traceability matrix current, running things through a change control process. That’s the visible part. The part that actually determines whether a program lands is much less visible, which is sitting with people until you understand their […]
Technical Writers Are Paid to Notice What’s Missing
There’s a moment in most documentation jobs where an engineer explains something clearly, completely, in a way that makes total sense. You take notes, you thank them, you go to write it up. Then halfway through the third step you stop. What happens if the user doesn’t have that permission? Nothing in the notes covers […]
Running BPMN 2.0 Workshops That Actually Produce a Map
Process mapping workshops have a reputation for being long, tiring, then producing something nobody uses. Usually that’s not a notation problem. BPMN 2.0 is well designed, widely understood, precise enough for developers while still readable by the business. The problem is what happens in the room. Someone puts a blank wall in front of 12 […]
🛠️ From Requirements to Results – The End-to-End Guide for Business Analysts
Good requirements are the backbone of any successful project. But getting them right means more than just writing them down. As a Business Analyst, your role in the business analysis lifecycle is about helping your team get from idea to outcome without missing what matters. Here’s what the full journey looks like from start to […]
🧠How to Conduct Impactful Requirements Workshops That Drive Real Results
Requirements workshops are one of the best tools a Business Analyst can use to gather the right information from the right people. Done well, they save hours of confusion, rework and second-guessing. But without structure, they can also waste everyone’s time. Here’s how to run requirements workshops that actually move the needle. 🎯 Start With […]