I’ve worked on programs with excellent methodology that went badly.
I’ve worked on messy ones that landed well.
The difference was never the framework.
It was who was in the room, how they got on, whether anyone was willing to say the difficult thing out loud.
That’s not a soft observation.
On a program with 6 workstreams, 3 vendors, hundreds of affected staff, the technology is usually the most predictable part.
People are the variable.
The lesson that took me longest to learn is that people skills alone aren’t enough.
You can be excellent at managing stakeholders, excellent at resolving conflict, still end up with a design that misses things.
Because the quality of the work depends on who you’ve got around the table in the first place.
👥 A mixed group beats a comfortable one
The best project team I worked with had a graduate 6 months out of university, 2 people in their 50s who’d been at the organisation for decades, a contractor who’d done 12 rollouts elsewhere, plus a team leader who’d never worked on a project before.
Plenty of diversity across the group, with experience levels ranging from 6 months to 30 years.
On paper it looked like a mess.
In practice it was the most accurate work I’ve been part of.
Here’s why that mix mattered.
- The graduate asked the obvious questions nobody senior wanted to ask
- The long timers knew why a strange rule existed, which stopped us removing something important
- The contractor recognised patterns from other rollouts, so we avoided 2 known traps
- The team leader kept pulling us back to what her staff would actually do on a Tuesday morning
- People who’d worked overseas flagged where our assumptions were local rather than universal
Every one of those contributions came from a difference, not from a shared view.
Homogenous teams move faster in the short term because everyone agrees.
They also miss the same things, because everyone agrees.
Diversity of background, tenure, discipline, point of view, all of it adds a different angle on the same process.
If your working group looks like 5 versions of the same person, you’ve got a blind spot you can’t see yet.
Worth saying that diversity only pays off if people feel able to speak.
A mixed group where only 2 voices get airtime performs exactly like a homogenous one.
So watch who hasn’t spoken in a session, then go back to them individually afterwards.
🧠 Learn how each person prefers to be dealt with
You don’t need a personality framework for this.
You just need to pay attention for the first 2 weeks, then adjust.
Broadly, you’ll meet a few types on any large program.
The detail people.
They want the document before the meeting, they’ll find the 1 inconsistency on page 14.
Send material 2 days ahead, never spring anything on them, thank them for the corrections.
The decisive ones.
They want the summary, the options, your recommendation, all in 5 minutes.
Don’t walk them through your reasoning unless they ask.
Lead with the answer, keep the detail in an appendix.
The relationship people.
They need to trust you before they’ll tell you anything useful.
Spend the first 10 minutes on their week, not your agenda.
You’ll get more from them over 3 short chats than 1 long interview.
The cautious ones.
They’re not blocking you, they’re protecting something.
Usually a risk, an obligation, or a memory of a rollout that went badly.
Find out what it is, take it seriously, then they become your best ally.
Communication style varies with background too, not just personality.
Some people say no directly, others say “that might be difficult”, meaning exactly the same thing.
Reading that correctly saves a lot of confusion later.
None of this is manipulation.
It’s just meeting people in a format that works for them, rather than the one that suits you.
🗣️ Slow down when things get tense
When disagreement shows up, the instinct is to argue faster.
More facts, more evidence, more explanation.
It never works, because facts don’t land on someone who feels unheard.
The better move is slowing everything down.
Steady voice, shorter sentences, longer pauses.
Repeat back what the other person said before you respond to it.
Then check whether you’ve got it right.
“So the concern is this adds an approval step for your team, without removing the manual check at the other end.”
If they say “that’s right”, you’re finally in the same conversation.
If they say “not quite”, you’ve saved yourself from solving the wrong problem.
That distinction matters more than it sounds.
“You’re right” means someone wants the meeting to end.
“That’s right” means you’ve described their situation accurately enough that they recognise it.
Only 1 of those leads anywhere.
⚔️ Handling 2 teams who both think they’re correct
This is the most common conflict on a big program.
Operations says the process works 1 way.
Finance says it works another.
Both are describing reality accurately, because both have been doing it differently for years without anyone joining the dots.
Here’s what I’ve found works.
- Meet each team separately first, never together, until you understand both versions
- Write both down without judgement, in their own words
- Name the difference plainly, then show what each version costs
- Give the decision to whoever owns it, rather than deciding yourself
That last point is the one new analysts get wrong.
Trying to arbitrate between 2 teams puts you in the middle of something that isn’t yours.
Making the choice visible, easy, well-evidenced is where your value sits.
You also need to say the awkward thing before they think it.
Something like “you’ve probably explained this to a project team 3 times already” takes the sting out of a conversation before it starts.
People relax when the obvious objection is already on the table.
🤔 Ask questions that hand over control
When someone’s dug in, avoid questions with a yes or no answer.
They just harden the position.
Ask something that requires thinking instead.
- “How would you make this work if it were your call?”
- “What am I missing about how this really operates?”
- “What would need to be true for this to work for your team?”
- “How do I take this to the steering group without misrepresenting you?”
That last one is useful in a stalemate.
It puts you on the same side of the table, working on a shared problem.
Most people soften once they realise you’re trying to represent them accurately, rather than talk them out of something.
🙅 Make it easy to say no
Chasing agreement is a trap.
Agreement given under pressure disappears the moment you leave the room.
It’s better to let people refuse things safely.
“Would it be a problem if I wrote it up the way I’ve described?”
Saying no to that is easy, low effort, almost automatic.
The correction usually arrives with it, which is what you actually wanted.
People who feel free to say no end up telling you far more than people who feel cornered.
⚖️ Fairness is the word that defuses most conflict
A lot of resistance on programs isn’t about the process at all.
It’s the feeling that a decision was made elsewhere by people who won’t live with it.
So say early that you want their team treated fairly, then follow through.
Ask them directly what feels unreasonable about the current approach.
Then change something small in response if you can.
Word travels quickly when a design actually shifts because a team spoke up.
You stop being another project person collecting requirements.
You become someone worth talking to.
🤝 What it comes down to
Big programs succeed when 2 things line up.
The right mix of people, then enough trust between them to be honest early.
Managing stakeholders well won’t rescue a group that all think the same way.
A varied group won’t help either if nobody feels safe enough to disagree.
So build a team with real diversity across ages, backgrounds, experience levels, points of view.
Then do the harder work of making sure all of them actually get heard.
The methodology will be different at your next organisation.
Those habits will still work.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
