Angelo Silva, CISSP, SSCP, CCSP, discusses what he describes as the Delivery Assurance Gap, the structural discontinuity between what is commercially committed and what is technically validated. It is not a failure of individual engineers. It is a failure of the process he has time and again.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Think of the pipeline in any service company: commercial, pre-sales, sales, post-sales, operations. If something goes wrong at the beginning, what is the probability of success at the end? The project gets delivered eventually, because the post-sales engineer makes it happen under enormous pressure. But the cost of that effort, in time, in rework, in reputation, in the mental health of the team, is paid entirely by the people at the end of the pipeline.
I want to start with a project I worked on a few years ago – although I’ve seen precisely the same thing repeat across different organizations, different countries, different products and different teams for more than 14 years.
In this case, a security architecture project had been sold after a three-month commercial cycle. The solution was designed according to network diagrams shared by the client during that phase. The contract was signed, the product was purchased and the project landed on my desk.
In the first weeks, I discovered that the network topology in the proposal had very little to do with what existed in the client infrastructure. There were undocumented segments, devices were end-of-life or running firmware without support and security controls assumed in the design simply did not exist. The DNS servers were positioned in the cloud with no on-premises resolver, causing the new solution to produce unexplained delays and timeouts even though the old solution worked fine. The dimensioning calculations were wrong.
However, I didn’t escalate this as a process failure. I simply adapted, redesigning it during execution. I absorbed the complexity, the extended hours and the client pressure. When the project was delayed, I became the visible face of the problem – even though none of those conditions were created by me.
The memory of that project has stayed with me – surprisingly, really, because this was not unusual. In fact, it was completely usual: over the course of 14 years working in system integration across Europe and Latin America, I’ve watched the same failure repeat in almost every complex project. I call this the Delivery Assurance Gap, or DAG: the structural discontinuity between what is commercially committed and what is technically validated.
Resolving the Delivery Assurance Gap
While studying for my security certifications, I came across something that gave a formal name to what I’d been observing. Boehm’s Curve describes the relationship between when an error is discovered in a project lifecycle and how much it costs to fix it. Simply: the later an error is found, the exponentially more expensive it becomes to correct. Fixing a requirement error during the requirements phase costs roughly one unit of effort. The same error discovered at deployment can cost one hundred times more.
When I looked at that curve and thought about the projects I had lived through, the connection was immediate. In system integration, the equivalent of the requirements phase is the pre-sales assessment, the structured technical discovery of the client’s actual environment. That is the lowest-cost intervention point: a gap found before the Statement of Work (SOW) is signed can be addressed with a conversation or a revised scope. The same gap, but detected by the post-sales engineer in week one, may require multiple weeks of rework (and often, someone’s reputation).
Figure 1. What I call the DAG Intervention Zone sits at the lowest point of the cost curve, between Requirements and Design.
Trying to Combat the Gap in Seven Steps
So, based on my years of observation and the connection to Boehm’s work, I undertook the building of build a seven-step framework for my own practice, with the intention of detecting gaps at the earliest – and cheapest - opportunity.
I apply my framework whenever I take on a new integration engagement. The steps are not bureaucratic checkpoints; they are evidence-creation moments that ensure every material assumption is validated before it becomes a contractual commitment or a delivery constraint. Here, for any reader facing similar issues, are my steps.
Step 1: Opportunity Assessment
Before anything else, I classify the type of engagement and the initial risk profile. Not every project needs the same level of scrutiny. A simple renewal with a known client is different from a multi-vendor integration in a new environment. This step produces an intake summary and a risk flag that determines how deeply the following steps need to go.
Step 2: Risk and Complexity Classification
Based on the initial assessment, I assign a governance tier and define the resource path: how much discovery time to request, who needs to be involved and what level of client access is needed before architecture decisions are made. The output is a risk classification matrix.
Step 3: Structured Technical Discovery and AS-IS Assessment
This is the step that changes everything. I validate the client’s actual environment: network topology, device firmware versions, security controls, DNS configuration, integration dependencies and anything else that could affect the proposed solution. I hold direct conversations with the client’s technical team and compare what I find against the assumptions in the proposal and document every gap. The output is a discovery report and a gap log.
When I started doing this consistently, I found that almost every complex project had significant gaps between the proposal and reality. The difference is that now I find them before deployment, when they cost almost nothing to address.
Step 4: Architecture and Threat Validation
With the real environment data in hand, I validate the target architecture against what exists. I also produce a threat model at this stage. If the gap log from Step 3 revealed problems that invalidate the original design, I redesign it here before anything is locked commercially. The output is a validated architecture blueprint and a threat register.
Step 5: Commercial-Technical Lock
Only after the architecture is validated against the real environment do I support locking the commercial scope. The SOW is aligned with confirmed technical facts and confirmed sizing. Every outstanding assumption is documented explicitly.
This step produces a locked SOW, an assumption log and a dimensioning sign-off. This is the gate that prevents the situation I described at the beginning of this article.
Step 6: Delivery Readiness and Handoff
Before execution begins, I confirm that the delivery team has received and accepted all validated inputs. In practice this is rarely done formally; a readiness checklist and a handoff brief ensure that whoever picks up the project has everything they need and has explicitly acknowledged it.
Step 7: Post-Implementation Value Review
After delivery, I measure outcomes against what was expected and document the lessons. This feeds back into how the next engagement is classified in Step 1.
The output is a summary of what worked, what did not and what should be done differently. Over time, this creates an institutional memory that makes each project better than the last.
When I started applying my approach consistently, there were clear benefits:
- I had answers before a project even started
- I could forecast where the problems would be
- I could raise questions internally before arriving at the client site; and
- I could identify components in the legacy environment that would not work with the new solution before the client discovered it themselves.
I also noticed how this changes the way senior engineers are used. In many integrators, the most experienced people are constantly pulled into crisis situations that originated before they ever joined the project; they become permanent firefighters. When the preventable problems are removed from the delivery phase, those engineers become available for work that needs their expertise. Perhaps worse, plenty of good engineers have been damaged by the constant pressure of absorbing structural failures that weren’t their responsibility.
I developed my framework because I was tired of watching the same pattern cause the same damage to the same kind of people. Boehm’s Curve makes the cost more visible, and my framework makes the issue resolvable. In my 14 years of doing this work, I have not seen a single complex integration project fail because the assessment was too thorough, but I’ve seen plenty fail because it never happened at all.
Angelo Silva, CISSP, SSCP, CCSP, has over 14 years of experience in financial services, energy, healthcare, telecommunications, manufacturing and retail. He has held technical and architecture leadership roles, with responsibility for designing enterprise security strategies and zero trust transformations. His cybersecurity work spans global multi-vendor environments, cloud security, identity, detection engineering and AI security.
