Parts one and two were about capital and scale: funding growth without mistaking early traction for proof, and then managing what breaks internally once an initiative scales up or down. Part one made the case for staying reversible until a bet is proven. Part two argued for taking internal scaling risks as seriously as outside competition. Part three covers risks that arise mid-negotiation or mid-build, threaten to freeze a deal or rollout, and must be resolved without delaying the deal or the initiative. This is about figuring out how much downstream work is actually gated by the emerging risk and reducing the scope of its impact.
A Risk May Not Stall Everything Downstream
We were two weeks away from closing a large-dollar, three-year contract with a customer. Commercial terms were finalized, and legal review was clean. Then the customer’s deployment team flagged that they wanted to add a new location to run their workloads. The proposed location did not have sufficient compute capacity, nor were any capacity additions planned. Fortunately, this risk surfaced before the 52-week lead times we are seeing now in the supply chain, so getting capacity to the new location would take us 3 months, including procuring new systems, deploying them, and bringing up the services.
The deal team’s first reaction was, “We don’t have it,” and the customer’s was that the deal had to wait. Suddenly, this requirement became a binary go-or-no-go for the whole contract. I asked the deal team to go back to the customer and see if they were willing to change the new requirement. They were not, and I was not ready to give up, so I asked the team to take a look at the deal through a different lens. Split the deal into two parts. What can we sign up for now using the capacity we have, and what can we sign up for a future delivery, basically the new location the customer added? Of course, we cannot get revenue from future deliveries, but we can get revenue from all locations other than the new location.
It turned out that 90% of the first-year revenue sat in locations where we had capacity and was part of the original requirement. Nobody had separated that, because the customer just gave us a new requirement that included the new location. So we worked with the customer to split the contract into Phase one, going live at locations with capacity and yielding 90% of the revenue. Phase two, the location that needed new capacity, was written in with a hard date, and with service credits given to the customer if we missed it.
Phase one revenue started forty-five days after signature. We then did a full-court press, including my reviewing progress and removing roadblocks twice a week to deliver additional capacity to the new location the customer wanted to use. We delivered the new capacity ahead of the deadline and ensured the customer could deploy their workloads ahead of schedule.
The part I’d do differently is that I would have asked the team to consider splitting the contract into two, in parallel with asking the customer if they could remove the requirement. That cost us a few days of back-and-forth.
A lot of enterprise risks get treated as a single gate that stalls everything downstream, when usually only a fraction of what’s downstream actually depends on the risk under review. Normal review processes rarely distinguish between a hard requirement that creates a stall and one that was just bundled in for convenience. A compliance gap or a supply constraint need not stall all the downstream activities. Untangling that increases your growth velocity. You have to be careful, though: if you stage a commitment as reversible when it isn’t, or promise a customer a date the team can’t hit, you will disappoint internal stakeholders and customers.
What’s At Stake
It is the bundling of many things as a complex risk that stalls most projects. Splitting a risk into what’s actually the blocking issue and what can be mitigated later without losing momentum takes more effort up front, but is better than waiting for the bundle of risks to clear. This kind of risk scope reduction is the difference between maintaining momentum and losing weeks on a project or losing a quarter.