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.
In practice, your job is to get thirty busy people who don’t report to each other to tell you the truth about how their work actually gets done.
That’s a much harder problem, and it’s not solved by better templates.
After a few of these programs, you start to notice the analysts who do well aren’t the ones with the most detailed maps.
They’re the ones people actually want to talk to.
🧭 Big programs aren’t really process problems
Most large-scale digital transformation work isn’t held up by a lack of process knowledge.
The knowledge is already sitting in people’s heads.
What holds it up is politics, fatigue, and the very reasonable suspicion that a program will change someone’s job without asking them first.
So when you walk in as the process analyst, you’re not walking into a blank page.
You’re walking into a room where people have already decided whether this is worth their time.
Your first real task is shifting that decision, and you do it one person at a time.
☕ Rapport comes before requirements
I know how that sounds.
But the fastest way to get an accurate process map is to be someone people don’t mind seeing in their calendar.
Learn what their week actually looks like before you ask them about approval steps.
Find out when month-end hits them, when their team is short-staffed, and which system they’ve been complaining about for four years.
Ask about the workaround they’ve built, and then don’t act shocked when they describe it.
The moment someone realises you’re not there to dob them in, you stop getting the tidy version of the process and start getting the real one.
That gap between the tidy version and the real one is where every failed program lives.
🎯 Targeted questions beat blanket questions
There’s a habit in this work of turning up with a generic list and asking people to describe their process from start to finish.
It’s exhausting for them and it produces mush.
Do your homework first instead.
Read the old procedure documents, look at the system screens, check the last audit findings, and build a rough draft of what you think happens.
Then turn up with three or four specific questions.
Something like whether the credit check happens before or after the quote is sent, and who does it when the usual person is on leave.
Specific questions get specific answers.
They also tell the person you’ve done some work already, which changes the whole tone of the conversation.
You’re no longer asking them to educate you from scratch, you’re asking them to correct you.
People love correcting you.
⏱️ Short meetings work better than big workshops
Workshops have their place, usually for making a decision that needs everyone in the room at once.
But for gathering how work actually happens, they’re a blunt instrument.
The loudest person sets the version of events.
The person who knows the exception handling sits quietly because their manager is in the room.
Two hours disappear and you leave with a whiteboard photo and a headache.
Fifteen or twenty minutes with one person is worth more.
You get the unvarnished answer, you get the exceptions, and you get it without eight other people’s calendars to wrangle.
Book them back to back if you need volume, and keep each one tight.
Send a short note afterwards with what you heard so they can correct anything before it hardens into a document.
Short, frequent, and specific will beat long, rare, and broad every time on a program this size.
🔁 Show your work early, and show it rough
Don’t disappear for three weeks and come back with a polished swimlane.
Send the messy version at day two.
A half-finished map with question marks on it invites people in.
A beautiful final draft makes them feel like they’re being asked to rubber-stamp something.
Rough work also protects you, because errors get caught while they’re cheap to fix.
🤝 Working across teams that quietly disagree
On big programs you’ll often find two teams who each believe their version of the process is the standard one.
Neither is lying.
Both have been running their own way for years because nobody joined the dots.
Your value here isn’t picking a winner.
It’s naming the difference clearly, showing what each version costs, and handing the decision to the people whose job it is to make it.
Analysts who try to arbitrate get burned.
Analysts who make the choice visible and easy get invited back.
✍️ The quiet skills that carry you
Turn up on time.
Remember what someone told you last fortnight.
Write in plain language so a new starter can follow it.
Say when you don’t know something.
None of this is glamorous, and none of it appears in a methodology.
But across a program with hundreds of people and a very long timeline, being consistently easy to deal with compounds.
That’s really the whole trick.
Be accurate, be human, and make it cheap for people to help you.
