SDLC/PDLC Governance Expert Witness: When Software Projects Fail, Who Is Responsible?
Systematic governance analysis benchmarked against ISO/IEC and IEEE standards.
Governance Is Where Causation Lives
Every software project failure has a governance chain. The SDLC and PDLC define the systematic processes by which organizations design, develop, test, and maintain software. When projects fail — over budget, behind schedule, below quality, or causing harm — the failure trace runs through governance.
Bruce Weiner applies Function Point Analysis (IFPUG ISO/IEC 20926:2009) to objectively classify and size software systems. In a federal district court dispute involving technology consulting billing, this framework revealed a 7:1 to 9:1 overstatement ratio in claimed hours, supported by ISO 20700:2017, learning curve theory (Wright 1936), and professional billing standards.
With 37 years of governing SDLC and PDLC practices across financial services, air travel, and platform technology — including Certified Advanced Scrum Product Owner certification — Bruce provides opinions grounded in practitioner-level governance experience.
Disputes Addressed
- Failed software implementations and project delivery disputes
- Agile vs. waterfall methodology disputes
- Scope creep and change order disputes
- Software vendor performance failures and service level disputes
- Technology consulting billing substantiation (Function Point Analysis)
- Build-vs-buy decision disputes and technology selection governance
Analytical Approach
Establish the Governance Framework
Identify which SDLC/PDLC model was specified or implied — waterfall, Agile, SAFe, DevOps — and what governance obligations that model creates.
Apply Function Point Analysis
Use IFPUG ISO/IEC 20926:2009 to objectively size the software system and benchmark claimed development hours against industry productivity ranges.
Review Sprint Artifacts and Planning Records
OKRs, epics, sprint logs, backlog documentation, velocity metrics, and retrospective records establish what governance was actually applied.
Benchmark Against ISO/IEC 12207
Measure the development process against internationally ratified software lifecycle process requirements.
Trace Causation Through Governance Decisions
Identify the specific governance decisions or failures that caused the project outcome at issue — linking evidence to opinions.
Standards Applied
| STANDARD | APPLICATION |
|---|---|
| ISO/IEC 12207:2017 | Software lifecycle processes — primary SDLC/PDLC benchmark |
| ISO/IEC 25010:2023 | Software quality model — quality criteria for delivered systems |
| ISO 20700:2017 | Management consulting guidelines — deliverable substantiation |
| ISO/IEC 20926:2009 | Function Point Analysis — system sizing and labor benchmarking |
| FAR 31.205-33 | Professional and consulting costs (applied by analogy) |
| PMBOK | Project Management Body of Knowledge — planning and governance standards |
| Scrum Guide | Agile/Scrum governance framework — sprint and backlog management |
Relevant Credentials & Experience
- Governing SDLC/PDLC at a globally recognized financial institution since 2012
- CTO of United.com — managed $380M GDS fee portfolio, 300+ executory contracts through bankruptcy
- Certified Advanced Scrum Product Owner — Scrum Alliance (since 2015)
- 37 years of waterfall, Agile, and DevOps governance across Fortune 100 companies
- Applied Function Point Analysis to identify 7:1–9:1 billing overstatement ratio in federal court matter
Ready to Discuss Your Matter?
Confidential. No obligation. Responses within 24 hours.