Marking Their Own Homework – 30 Years of SIs Being Paid Twice

System integrators (SIs) have long played dual roles in enterprise technology projects: not only do they build and deliver software solutions, but they are also responsible for testing their own work—fixing the bugs required to achieve a production-ready state.

This practice—where SIs essentially “mark their own homework”—has persisted for over thirty years. Yet it remains an anomaly in our sector, creating unusual incentives and risks for clients, as SIs get paid twice: once for developing the code, and again for verifying and correcting it.

It does seem odd that nobody really talks about it—rather like vendor roadmaps not being delivered—but perhaps this is more about who’s in the conversation than any deliberate client “tacit” acceptance.

The Double Payment Cycle

For a long time, system integrators have been engaged under contracts that include both software delivery and the testing and remediation needed to ensure deployment readiness. A single “throat to choke” is often the ambition from clients, but SIs frequently recoup extra fees or billable hours for test phases, bug fixing, and further refinement of their own work—a structure that means clients pay twice for one outcome: working software.

While some organisations attempt to carve out “final acceptance” testing as a separate milestone, the reality is that in most projects, the same SI team is responsible for writing code, performing integration tests, and resolving their own defects.

This arrangement stands out when compared to manufacturing or construction, where independent quality assurance functions or external inspections are mandatory before payment is released. In the tech sector, however, this process is self-contained—and the risks of lowered standards and shifting blame are significant.

Accountability and Conflicts of Interest

When SIs both write code and evaluate whether it “passes muster”, a clear conflict of interest emerges. Without separation between development and testing, there’s reduced motivation for rigorous bug diagnosis, deep integration testing, and challenging edge cases. Developers may resist comprehensive testing and reporting when it exposes their own mistakes, undermining the essential purpose of a software QA function.

Furthermore, the lack of external accountability weakens client confidence and often leads to higher defect rates post-delivery.

In our experience, the very best outcomes occur when there is genuine tension between those creating code and those testing it—the quality simply improves 🙂.

Industry Standards and External Auditing

Many industries are governed by standards requiring rigorous, third-party validation. Sectors such as medical devices, automotive software, and railway safety mandate ISO or IEC compliance, and independent code analysis is often required before deployment. Software testing standards like ISO/IEC 29119 also emphasise independent processes and clear separation of development and testing activities to ensure quality and reduce risk.

External auditing, widely used outside of technology project delivery, ensures objectivity and industry benchmarking. In the context of software development, engaging external specialists to conduct testing—not just internal project teams—provides unbiased feedback, enhances credibility, and often results in fewer post-implementation issues.

While internal audits prepare organisations for compliance, external reviews carry greater authority and minimise the self-serving risks that come with allowing SIs to audit themselves.

The Path Toward Reform

Advances in continuous integration, automated code analysis, and evolving standards offer mechanisms to improve accountability and separate concerns. Adopting clear, independent QA frameworks and leveraging external certification—together with robust internal peer review—can mitigate the risks of SI self-certification.

Organisations that actively carve out third-party system integration testing or require independent acceptance criteria tend to experience fewer deployment issues and lower total cost of ownership over time. Industry best practices recommend:

• Insisting on external or at least functionally independent QA, especially for critical or legacy projects.
• Following structured testing standards (like ISO/IEC 29119) to ensure processes are documented, transparent, and traceable.
• Benchmarking outcomes with external audits to introduce best practices and objective feedback.
• Creating transparent, milestone-based contracts that separate delivery, QA, and acceptance payments.

Conclusion

This isn’t rocket science, and yet huge sums of money are spent creating software that simply isn’t good enough to release—because the industry persists with a flawed commercial model.

It’s time to change.