Who designed your data model? 😱

Your client tells you what they need. Not how to build it. And here's what happens when those lines get crossed.

Hi there,

Last Friday's #ZenClub session was one of those ones where nobody was looking at the clock. 🥰

We had a real situation land in the room - no fictional case study, no "imagine you're in this scenario." Just a consultant in the middle of a bit of a mess, asking for help and it turned into one of the most useful conversations we've had in a while.

So I wanted to share the big lessons here, because I promise at least one of them is sitting somewhere in your current project right now. 😬

Let's call him "D".

The data model that wasn't supposed to be a data model

D had been brought onto a project three months in. Discovery hadn't been done properly - not enough time, not enough depth (sigh - it's a story we've heard many times, haven't we?)

What was interesting was that instead of articulating requirements as in the functions required, the client was dictating the data model 😱

I mean the actual internal database structure!

As in... The hierarchy.
The parent-child relationships.
The architecture of how everything sat together.

And that, friends, is a massive 🚩🚩🚩

"But shouldn't your client tell you what they want?"

Of course - Your client should absolutely tell you what they need.
"I need to see monthly commission payouts broken down by territory."

This works because it's a requirement that we can build from.

Your client should not tell you how to build it.

Not the structure.
Not the table design.
Not the object hierarchy.

It's your job as the trusted advisor to design the solution.
To figure out the how.
Becuase you're the one with the expertise and the platform knowledge to make the right decisions when architecting the solution.

This is the consulting equivalent of building a car chassis before deciding whether it needs to be a family saloon, a lorry, or an amphibious vehicle. 😅

If you don't know what it's for, you cannot build it correctly.

The Dress Analogy (I do love to mangle my metaphors!)

I always use this one and I'm not stopping now. 🤣

Think of yourself as a seamstress. You have exactly enough material to make the dress well. No more.

Before you cut anything, you measure. You ask every question. Wedding or dance? Zip or buttons? How many pockets, and where? Short or floor-length? 👗🥻👚👖

Because once you cut, you can't uncut. ✂️

The discovery phase is the measuring. 📏

The statement of work is the pattern. The user stories are the specifications that tell you exactly what you're building.

Skip the measuring, and you'll be making alterations forever. 

And the real cost isn't just the re-work.
It's the trust.
It's the goodwill.
It's your reputation as someone who delivers.

And I value my reputation deeply.

The Three Types of Difficult Client PMs

There was another layer to D's situation: the PM on the client side was a contractor.

And not a great one. 😕

And I've known my share of sub-par project managers.

He was the buffer between D and the business — and he kept saying "it'll be fine, I'll talk to them" while not actually fixing anything. Classic cover-your-back behaviour.

When I hear this, I always ask: which type is he?

Because there are broadly three:

Type 1: The political operator. Out for themselves. Any failure gets shifted elsewhere. They'll let the project suffer to protect their position. You'll see it in how they talk about others, who they throw under the bus in meetings.

Type 2: Over their head. Not malicious. Just not up to the complexity. They're blustery because they're scared. They say "it'll be fine" because they don't know what else to say.

Type 3: Insecure but well-meaning. They know something's wrong but won't admit it. They don't want to look like they don't know. They need to feel like they're still in control.

Each one needs a different approach.

For Type 1: find an ally elsewhere in the client org. Don't go around them overtly. Build genuine rapport with someone who sees what's happening. Not to stage a coup — just to make sure the project has a friend.

For Type 2 and 3: make them feel safe with you. Let them hold some of the credit. Nobody blocks the person who's helping them look good. 😊

In D's case, the PM had actually been replaced by the time we spoke. (Which tells you everything.)

And we don't know too much about the new one...
Which brings me to the most important thing.

CYA* is not cynical. It's professional.

(CYA = Cover Your Derriere 😬)

When you're a freelancer or contractor dropped into a messy project, you cannot always fix what went wrong before you arrived.

But you can (and should) protect yourself. 

Everything in writing. Every concern you raised. Every risk you flagged. Every time you said "I'll do what you're asking, but here are the consequences."

Make sure it's black and white - especially when requests have been made verbally, in the hallway, outside the meeting room or zoom call where it's likely to be transcribed.

Because when things go sideways - and in this kind of project, something will - you need to be the person who saw it coming and said so. 

And if you haven't seen the statement of work? 📜
Ask for it without the commercial section (such as day rates, payment terms, etc).

Just say: "I want to make sure I can fulfill what we've promised."

It's really very hard for anyone to say no to that.
And then you have clarity as to the end goal, and you know what you need to do to get there.

Much better than trying to drive in the foggy dark.
Like here in England 9 months of the year 🙄

The L.I.S.T.E.N. framework when you're thrown in at the deep end

One of the things I shared on the call was what I'd do if I were parachuted into a project in crisis.

And it maps straight onto L.I.S.T.E.N:

L - Locate your stakeholders and all existing documentation. Status reports. Emails. Meeting notes. Read everything.

I - Investigate by reviewing the statement of work against what's actually been delivered. Where are the gaps? What was promised that hasn't landed?

S - Scope the current reality. What's in? What's out? What's been promised verbally but not written down?

T - Test your understanding and assumptions. Have the informal reset conversation with the client. "Let me make sure I understand what we're delivering to you, in very clear terms. Tell me if I've got it wrong."

E - Empathise with the resistance. The client is probably just as frustrated as you are. They didn't sign up for this mess either.

N - Navigate expectations. Help them see a path forward without blame, without drama. Just: here's where we are, here's what we can do.

This is also a fantastic way to use the honeymoon period when you're new to a project. You have a small window to reset things before you become fully accountable for them. Use it. 🙏🏼

Anyway we will dive into UAT at our next #ZenClub the next few weeks. Some of you may remember that I designed 34 unique workshops that covered the Business Analysis exam topics before the exam actually came out.

There were three topics on User Acceptance when the exam was first released and constitued 5% of the exam questions.

It's now 12% of the exam (more details here):

Development Support and User Acceptance: 12%

• Support and validate project delivery to ensure the solution meets the requirements.
• Support and validate user acceptance testing (UAT) to ensure the solution meets the requirements.

A few of our #ZenClub members are in the middle of sticky UATs at the moment, which is why we are focusing on this topic and working through scenarios and discussing in detail through role plays and thoughtful exercises.

If this sounds like the kind of session you want to be in every week, come and join us.

#ZenClub is weekly group coaching and training on the skills certification and Trailhead doesn't teach - stakeholder management, discovery, navigating the political stuff, having the difficult conversations.

Piyusha Pilania (MVP, Golden Hoodie) brings the technical depth - Slack, Sales & Marketing Cloud, Agentforce.

And if you know me by now - I bring the human side ❤️. 

🍩 £169/month for four live sessions a month
🍩 Two expert facilitators
🍩 Real scenarios from working consultants
🍩 A community that gets what you're going through

Join ZenClub here 

See you next Friday!
x Pei 💜

P.S. The most-asked question from last week's session: "What do you do when you have limited power on a project but you can see everything going wrong?" The short answer is: document everything, find your allies, and frame every concern as being about quality and delivery rather than blame. The long answer? Come to ZenClub. We practice exactly this. 😊

P.P.S. If someone forwarded this to you and you'd like it landing in your inbox every week, you can subscribe here. It's free and I'd love to have you. 🥰