Running Three Concurrent Projects for One Customer

What this is

For one high-visibility customer relationship, I managed three separate projects at the same time — not three phases of one project, but three genuinely distinct workstreams, each with its own scope, its own internal team, and its own timeline, all tied to the same customer. Externally, the customer largely experienced one point of contact. Internally, I was running three different projects that could not be treated as one just because they shared a customer name.

How I operated

• Kept each project’s scope, team, status, and risk tracked separately, even though they shared a customer and often shared some of the same underlying platform capabilities. A shared customer is not a shared plan.
• Switched context deliberately between projects rather than letting whichever one was loudest that day dominate my attention — before any conversation or status check, re-grounding in that specific project’s current state: what’s the team working on, what’s blocked, what did the customer last ask for on this one specifically.
• Kept the three projects’ communications distinct with the customer, so an update on Project A never got mixed into a conversation about Project B, even when the same customer stakeholder was involved in more than one.
• Watched for the real risk of running several projects for one customer in parallel: a decision or a dependency in one project quietly affecting another because they touched overlapping platform capabilities. When that happened, I made the cross-project dependency explicit instead of letting it surface as a surprise in whichever project hit it first.
• Prioritized deliberately when the three projects competed for the same internal engineering time, making the trade-off visible to my own leadership and to the customer rather than letting the busier or more visible project quietly starve the others.

Outcome and value

Each of the three projects kept its own scope, team, and timeline, and the customer kept one coherent point of contact without any project’s state leaking into another’s. Cross-project dependencies — the real risk of running parallel work on shared platform capabilities — were made explicit when they appeared rather than surfacing later as a surprise. The value is sustaining several genuinely distinct workstreams under one high-stakes relationship without letting volume, urgency, or a shared customer name collapse them into one undifferentiated plan.

What this shows about how I operate

Running multiple projects for one customer is a different problem from running one project, and it’s a different problem again from running several customers’ single projects. The customer relationship stays constant, but the projects underneath it don’t share a clock, a team, or a risk profile just because they share a name at the top. The actual skill is switching context fast and accurately — picking up exactly where each project stood, without carrying yesterday’s urgency from one project into a conversation about a completely different one.