Delivery benchmarks, measured honestly
We are building methodology papers and software delivery benchmarks grounded in engagements we have actually delivered. Nothing publishes until the data can stand behind it, so this page shows you the method first and the numbers when they are ready.
How we benchmark delivery metrics
Research, for us, means numbers a client could audit: defined metrics, instrumented sources, and published segmentation. Here is the method every future paper will follow.
Measured from real engagements
Every metric comes from instrumented client projects, not surveys. We pull sprint data from our own delivery tooling: commits, pull requests, CI runs, and sprint review outcomes, so a number like cycle time reflects what actually happened, not what a team remembered happening.
Three core delivery metrics
We benchmark sprint predictability (the share of committed sprint scope that ships and passes review, tracked per two-week sprint), defect escape rate (bugs found after release per hundred shipped changes), and cycle time (calendar days from a task entering a sprint to running in production). These three together describe whether a delivery process is honest, safe, and fast, in that order.
Normalized before compared
A fintech platform under SAMA compliance review and a school management system in Pakistan do not have comparable raw cycle times. Before we compare anything, we segment by project type, team size, and regulatory load, and we publish the segmentation alongside the numbers so you can see exactly which bucket a benchmark came from.
Published only when it clears the bar
A benchmark goes public only when it covers enough projects and enough sprints that one outlier engagement cannot move the median. Until a data set clears that threshold, it stays internal. That is why this page currently lists work in progress instead of papers.
What's coming first
Three studies are currently accumulating data. Each will publish with its full methodology, sample description, and limitations.
Sprint predictability benchmarks
How much of a committed sprint actually ships, across project types, and how predictability changes between sprint one and sprint ten of an engagement.
ERP vs custom: 3-year cost of ownership
A structured ERP vs custom software comparison using real licensing, build, and maintenance figures from both sides of our own delivery work, run out over three years.
GCC compliance overhead study
What TRA, SAMA, and NCA requirements add to delivery timelines in practice, measured as the delta between comparable regulated and unregulated builds.
Questions about our research program
A delivery benchmark is a measured baseline for how software work actually progresses: for example, the median share of committed sprint scope that ships, or the number of defects that escape to production per hundred changes. We compute these from instrumented project data across our own engagements, segmented by project type and regulatory load, so a prospective client can compare a vendor's claims against measured reality.
Because a benchmark built on too few projects is marketing, not research. We publish a data set only once it spans enough engagements and sprints that a single outlier project cannot move the median. Several data sets are accumulating now; the sprint predictability benchmarks are furthest along.
Yes. Like everything else in the resources library, the methodology papers and benchmarks will be published openly on this site, with no email gate. The methodology itself, including how metrics are defined and how projects are segmented, will be published alongside every number.
Yes. If there is a delivery metric you want benchmarked, such as cycle time for ERP implementations or defect rates in compliance-heavy fintech work, contact us. Client data is only ever included in anonymized, aggregated form, and never without agreement.
Want early access, or have a delivery metric you’d like us to benchmark?