Looking back, one of the projects that shaped my delivery style most was a Phase 2 justice-sector IT and infrastructure upgrade (project name de-identified). It was a classic “technology + system integration + heavy on-site implementation” effort: large-scale video surveillance and storage, network switching and security devices, extensive cabling and removal work, and compatibility / protocol integration with an existing platform.
From day one, we were working against a hard constraint: a 60-calendar-day delivery requirement, with on-site construction time limited to a fixed number of hours per workday. The client was used to a traditional waterfall-style approach—understandable for projects like this, where stage gates and rigid plans often feel safer.
My goal wasn’t to overturn their habits. It was to make delivery more controllable: fewer “late-stage explosions,” more visible progress, and risks surfaced early—when there was still time to respond.
If We Ran It the Traditional Way (A Thought Experiment)
Under a traditional approach, the pattern is usually predictable: spend substantial time up front on investigation and design, then move into concentrated procurement / installation / commissioning, and push system integration, joint debugging, and acceptance to the later stage.
Given the 60-day external commitment, my planning assumption would be a team of up to 20 people, roughly split like this:
- Project manager: master plan, stakeholder coordination, risk tracking, schedule control
- Solution / integration lead: technical roadmap, integration strategy, key decisions
- On-site implementation crew: removal, cabling, installation, rack-and-stack, site coordination
- Network & security engineer(s): switches / firewall configuration, network connectivity, security policies
- Platform integration & commissioning: existing platform integration, protocol alignment, joint debugging and issue isolation
- Testing / acceptance support: functional checks, regression checks, acceptance documentation
- Vendor / manufacturer support: delivery coordination, defect handling, warranty and service alignment
This model is highly sequential. When one stage slips, everything behind it compresses. And risks tend to cluster around the end:
- Compatibility and protocol integration risk (e.g., connecting to the existing security platform and required standards) — if issues surface late, rework spreads across many endpoints
- Procurement and delivery timing risk — incomplete deliveries stall the site plan
- On-site window constraints — limited daily hours amplify waiting and coordination waste
- Late-stage integration risk — problems emerge together near acceptance, increasing closure pressure and documentation churn
Finishing in 60 days isn’t impossible in this model, but it usually depends on late-stage overtime and accepting higher rework risk.
Why Rework and Delay Happen So Easily
Traditional delivery isn’t “wrong,” and it’s not that it ignores risk. The real issue is feedback speed.
In on-site integration projects, small variations (site conditions, power and cabling realities, device batches, configuration drift) can quietly accumulate. If key integration paths—platform access, protocol compliance, security policies—aren’t validated early, they often reveal themselves right before acceptance, when there’s little buffer left.
It’s not the planning that fails first. It’s the delayed confirmation.
What We Did Instead: Weekly Cadence, Incremental Delivery
When we decided to run this project with an Agile delivery mindset, I set a simple rule for myself:
Don’t wait until the last two weeks to discover the hardest problems—surface and close risk continuously.
So we moved to a weekly cadence. Each week was not “do a lot of tasks,” but “produce a deliverable slice that can be checked.” With on-site time restricted, we pushed preparation forward:
- Standardize configurations and templates as early as possible
- Pre-configure and pre-validate what can be done off-site
- Use the on-site window only for what must be done on-site: installation, connectivity, validation, and records
- End each week with visible progress, a clear list of open issues, and an updated priority order
We also adjusted roles while still keeping the overall team under 20:
- Me (delivery lead / Agile PM): weekly planning, cadence control, acceptance alignment
- Key technical lead(s): bring forward the riskiest integration paths and unblock early
- On-site crew split into small squads: work by area / building / zones to reduce waiting
- Testing & acceptance support embedded early: check and document continuously instead of dumping paperwork at the end
- Vendor support pulled in “just in time”: use specialists at the moments they matter most
What Changed in Practice: Time and Resource Shape
With this approach, delivery reached a usable, acceptance-ready state in about 50 calendar days, within the contractual 60-day requirement. In other words, we bought ourselves meaningful breathing room—not by cutting corners, but by shortening feedback loops and closing risks earlier.
On resourcing, a traditional plan would typically lean toward a near-20-person setup to absorb late-stage integration pressure and rework risk. With the weekly cadence and smaller deliverable slices, we were able to keep the team closer to around 15 people without losing control of quality or progress. The main difference wasn’t “working harder”—it was reducing waiting, surfacing issues sooner, and preventing rework from piling up.
Just as importantly, the client no longer had to wait until the end to see “the whole thing.” They saw tangible progress every week and could make priority decisions based on real outputs. For on-site integration projects, that shift alone changes the entire delivery dynamic.