Start every engagement with clear agreements

• Read the actual contract - don't just skim it. Look for payment terms, IP ownership, and termination clauses
• Talk to the sales team - ask them what the client really cares about (it's not always what's written down)
• Check for red flags early - if the budget doesn't match the scope, that's a conversation to have now, not three months in
• Note any verbal commitments - if someone promised something in a meeting, write it down here so it doesn't get lost

• Get the executive sponsor on record - this person is your safety net when decisions stall. Make sure they know their role
• Identify who you'll actually talk to daily - this isn't always the person who signed the contract
• List everyone who needs to stay informed - even if they're not directly involved, leaving them out causes political problems
• Don't skip the blockers question - it feels awkward, but knowing who might resist the project early saves you weeks of frustration later

• Walk through scope line by line with the client - don't assume they read the SOW as carefully as you did
• Be explicit about what's NOT included - "out of scope" items prevent 80% of scope creep disputes
• Write down your assumptions - things like "client will provide data within 5 business days" or "existing systems won't change during the engagement"
• Define what success looks like together - vague goals like "improve efficiency" cause arguments. Get specific numbers or outcomes agreed upon now

• Name your project lead - this person owns the relationship day-to-day and needs enough experience to push back when things get tough
• Be specific about team roles - "we'll assign a team" isn't good enough. Name people, list their skills, and clarify their availability
• Get client resource commitments documented - who from their side will be available, how many hours per week, and who's their backup
• List every system and data source you'll need access to - getting IT access at large companies can take weeks, so start this immediately

• Pick a meeting frequency that fits the project pace - early phases usually need more check-ins than later delivery phases
• Agree on the format for status updates - some clients love dashboards, others want a one-page email. Ask them what they actually read
• Choose a primary channel and stick to it - scattering conversations across email, Slack, and text means things get lost
• Set expectations for response times - does the client expect same-day replies? Within an hour? Make this explicit so nobody's frustrated

• Identify the decision-maker clearly - and make sure that person knows they're it. "I didn't realize I was supposed to approve that" kills timelines
• Set up a change control process - even a simple one. When the client asks for something new, you need a way to evaluate it without just saying yes to everything
• Document an escalation path - if things get stuck at the project level, who do you go to? Write it down so nobody has to figure this out during a crisis
• Keep it proportional to the project size - a 6-week engagement doesn't need a steering committee with monthly meetings. Match governance to complexity

• Focus on your top 3 risks - don't list 20 things. Pick the three that would hurt the most and focus your mitigation there
• Be honest about client dependencies - if your timeline depends on the client delivering data by week 2, that's a risk. Don't pretend it isn't
• Write actual mitigation plans - "we'll monitor it" isn't a plan. What specifically will you do if this risk materializes?
• Agree on what happens if the timeline slips - this is an uncomfortable conversation now, but it's 10x worse when it actually happens and nobody's discussed it

Now that scope and governance are locked in, you need to agree on what success actually looks like. Without clear metrics, you and your client will end up with different definitions of done - and that causes problems at review time.

Work with your client to pick 3-5 KPIs that are specific and measurable. Tie each one to a project goal. Document a baseline (where things stand today) so you can show real progress later. Set a realistic target for each metric and note when you'll measure it.

Keep this list short. Five solid KPIs beat a sprawling dashboard nobody reads. Once you've written them down, share the list with your team and the client so everyone's working toward the same outcomes.

Before your team digs into the work, everyone needs to know where files live, how you'll track tasks, and what tools you're using. Getting this right at the start saves you from the chaos of three different versions of the same document floating around in email threads.

Decide where you'll store project files and confirm both sides have access. Set up a shared project space - whether that's a folder, a project board, or a dedicated workspace. Send access credentials to both your team and the client. Confirm everyone can log in and knows where to find things.

Keep it simple. Pick the tools your client already uses where you can. The goal is to remove friction, not add a learning curve on top of the actual project work.

The last thing you do before the work starts is send a written record of everything you just agreed to. This protects you, it protects the client, and it makes sure nothing gets lost between the meeting and Monday morning.

Write up a brief summary covering: scope confirmed, team members and their roles, success metrics, how you'll communicate, governance decisions, and any risks you identified. Keep it to one page if you can. Send it to your team, the client, and anyone else who'll be involved in the project.

Ask for a reply confirming everyone's read it and is on board. That confirmation is your green light. The project is officially underway.