Running an Engagement

A proposal gets an engagement started. What keeps it healthy is the rhythm it runs on afterward. None of this is different in kind from how Systeric runs internally (see Cadence); it’s the same beats, pointed at a client instead of only at leadership.

The cadence with the client#

Two recurring touchpoints carry most of a client engagement:

• The weekly update. Per How Systeric Works, PM sends an update every Monday covering the prior week, to the client and internal leadership at the same time, in the same words. What shipped, what’s in progress with a demo ETA, an honest look at whether recent releases had the impact expected, and any decision or input needed from the client. Full visibility, in under two minutes to read.
• The demo. Per Cadence, a demo happens at every milestone in the release plan: a hands-on look at working software, not a status update. This is where a client sees the thing, not a description of the thing. If a milestone can’t produce something demoable, it wasn’t a real milestone.

Between those two, the client should never be surprised by where the engagement stands. The roadmap and release plan are visible to the client at any time, and they reflect what’s actually happening, not what was originally planned, the same standard Half Strategy holds the internal roadmap to.

Handling change requests#

Engagements change. A client sees the working software and wants something adjusted, or the market shifts, or a new requirement shows up that wasn’t in the original proposal. That’s normal; it’s not a sign scoping failed.

What matters is how the change gets handled, and there are two failure modes to avoid:

• Silently absorbing it. Saying yes in the room without re-scoping costs the engagement later: either the timeline slips without explanation, or something else that was committed quietly gets squeezed out. The client never sees the tradeoff being made on their behalf.
• Silently dropping it. The opposite failure: an ask gets acknowledged and then nothing happens to it, with no decision ever made and no reason given.

Neither is acceptable. A change request gets a decision, out loud, the same way an ad hoc gets handled in the Weekly Product Call: it’s added, with something named as the tradeoff, or it’s deferred, with a stated reason, never a third, silent option. If the change is substantial enough to reshape the scope, it goes back through a lightweight version of Define: what’s the problem this change actually solves, what does it cost, what does it displace. Small changes can be absorbed into the existing release plan if there’s real headroom, but that’s a visible decision, stated in the next update, not an assumption made quietly.

Escalating risk early#

The same standard Communication sets internally applies to the client relationship: a risk flagged while there’s still time to respond is a gift; the same risk discovered after the fact is damage control.

If a milestone is at risk, if a dependency outside our control is slipping, if the approach itself turns out to be wrong: the client hears it the week it becomes true, not at the deadline. This is uncomfortable in the moment and it’s exactly why it matters: the engagements that lose trust aren’t the ones that hit a rough patch, they’re the ones where the client found out about the rough patch too late to do anything about it.

The handoff at the end#

An engagement ends the way any How Systeric Works initiative does (through Launch and Learn), with the client on the receiving end of both.

What the client should have in hand when an engagement closes:

• Working software, deployed and demoed, matching what the proposal and release plan said would ship: see Launch.
• Release notes, in plain language: before, after, what changed and why it matters. Not internal jargon dressed up for an external audience.
• Documentation and knowledge transfer sufficient for the client’s own team, or whoever picks the work up next, to understand how it works and why it’s built the way it is, the same spirit as the knowledge artifact Learn requires internally: what would someone need to know to work in this area with confidence, written down rather than left in one person’s head.

None of this should be assembled at the last minute. Release notes are drafted in Define and refined throughout Build, the same as any internal initiative: see Define. By the time an engagement closes, the handoff is mostly already written; closing it out is confirming it’s complete, not producing it from scratch under deadline pressure.

Related: Cadence, Handoffs, Weekly Product Call, Launch, Learn