A Salesforce Delivery in 15 Days

Problem

A business request came in for a new email capture component that needed to feed data into Salesforce Data Cloud. It was tied to a fixed event date. There was no flexibility on that date and no fallback plan if the component wasn't ready.

The request touched three organisations, Fortescue, the lead technology agency, and a data platform vendor. It also needed sign-off from Legal before anything could be built, because the component was capturing customer data at the point of entry. Fifteen working days doesn't leave much room for anything to go wrong once you add that many parties to a build.

Context

This came in while I was already running the broader Fortescue delivery rebuild, so the team, the agency relationship, and the reporting lines around me were already in motion. But this request sat outside the normal roadmap cadence. It had its own deadline, driven by an external event, and it needed to be treated as its own delivery stream rather than folded into the existing sprint work.

Stakeholders were spread across multiple regions and time zones, which meant there was rarely a single hour in the day when everyone involved was online at once.

Business objective

Fortescue needed the email capture component live and integrated with Salesforce Data Cloud before the event date, with no exceptions. Missing the date wasn't a minor slip. It meant losing the data capture opportunity the event was built around.

Customer/user objective

The people relying on this weren't end customers yet, they were the internal and agency teams who needed a working, compliant component they could point people to on the day. They needed something that worked correctly the first time, since there wasn't a second chance before the event.

Constraints

Fifteen working days, fixed, with no flexibility on the end date. Three organisations had to coordinate on the same build, Fortescue, the lead technology agency, and the data platform vendor. Legal needed to review and sign off the approach before development could proceed, which is not usually a fast step. Multiple regions and time zones meant limited overlap for live discussion, so a lot of coordination had to happen asynchronously.

Stakeholders

Internal Fortescue stakeholders who owned the event and needed the capture data. The lead technology agency, responsible for build and testing. The data platform vendor's team, responsible for the Salesforce Data Cloud endpoint. Legal, who needed to review data handling before deployment. I was the point of coordination across all of them.

Research and discovery

The brief that arrived wasn't fully specified. Before anything could be built, I had to clarify exactly what data the component needed to capture, how it needed to map into Data Cloud, and what Legal would need to see before they'd sign off. Getting that clarity early mattered more than usual here, because there was no time later in the schedule to absorb a misunderstanding.

Options considered

One option was to start build work in parallel with legal review, treating them as two tracks running side by side. The risk was that Legal could ask for changes that meant reworking something already built. The other option was to wait for legal sign-off before starting build, which was safer but risked eating too much of the 15 days before any development began. Given the deadline, I couldn't afford to lose the days to a fully sequential process, but I also couldn't afford rework Legal might force later.

Prioritisation

I prioritised getting the brief clarified and Legal engaged in the first two or three days, before committing engineering time to build. That way, build started against a scope that had already been checked, rather than a scope that might change under it. Everything else, including the finer detail of testing and deployment sequencing across three organisations, was sequenced around protecting that legal sign-off point.

Delivery

I clarified the brief directly with the business stakeholders who'd made the request, then took it to Legal for review and obtained sign-off before development work started in earnest. From there, I coordinated the design, build, and testing of the new Data Cloud endpoint across the agency and the data platform vendor, working across the time zone gaps by keeping written briefs tight and using async updates rather than relying on live meetings that were hard to schedule.

I oversaw deployment of the component across the affected regions and managed the dependencies between the three organisations simultaneously, since a delay from any one of them would have pushed the whole thing past the deadline. Where I saw a risk, whether that was a dependency slipping or a piece of scope that hadn't been agreed yet, I flagged it as soon as I saw it rather than waiting for a scheduled check-in, because there wasn't time to wait.

The component was delivered within the 15-day window.

Decisions made

The decision to secure legal sign-off early, before committing build resource, was the one that mattered most. It cost a few days up front but protected the rest of the schedule from rework. I also decided to manage the three organisations as a single coordinated workstream with me as the central point of contact, rather than letting each organisation manage its own piece and hoping the handoffs would line up. With 15 days and no slack, I didn't think a distributed coordination model would hold.

Trade-offs

Spending the first few days on brief clarification and legal review, rather than starting build immediately, meant less visible progress early on. That was a deliberate trade against the risk of building something Legal would later ask to change. Centralising coordination through me also meant I became a single point of contact across three organisations, which is a risk in itself, but with this little time available, I judged that consistent coordination mattered more than distributing that risk.

Business outcome

The component was delivered to spec within the 15 working days, in time for the event it was built to support. A retrospective was set up after delivery specifically to capture what would make a similar rapid-turnaround request easier to handle next time.

Customer outcome

The teams who needed the capture component in place for the event had a working, legally reviewed solution ready when they needed it, without needing to fall back on a manual workaround or delay their plans.

Lessons learned

Fifteen days across three organisations and a legal review is tight enough that sequencing matters more than speed at any individual step. Getting Legal engaged early, rather than treating their review as a final gate, was what kept the schedule intact. I also learned that when time zones limit live discussion, the quality of written briefs matters more than usual, because there's less chance to clarify verbally before someone starts building the wrong thing.

What I'd improve today

I'd want a standard fast-track process for requests like this one already in place, rather than working out the sequencing from scratch under deadline pressure. That's exactly what the retrospective after this delivery was set up to produce, and I'd want to see it applied the next time a similarly tight request came in.