Why Software Agency Projects Disappoint: An Evidence-Based Buyer Guide

Missed expectations, defective releases, delayed delivery, and disputed invoices can occur in outsourced software work. They do not establish that agencies as a category are bad. A useful review separates evidence about one supplier and project from assumptions about a delivery model.

Outcomes depend on the problem, supplier capability, customer decisions, contract, dependencies, evidence, and operating environment. The buyer and supplier can both create or reduce risk. This guide turns those factors into questions that can be answered before selection and during delivery.

Use constraints as a planning conversation, not a law

Time, cost, scope, and quality are useful planning dimensions, but the familiar triangle or quadrangle is a heuristic, not a formula that predicts a project. A change can affect several dimensions, yet the direction and size depend on architecture, sequence, skills, automation, dependencies, and risk.

Use the model to record trade-offs. Which date is fixed? Which outcomes are essential? Which quality attributes are risk-critical? What budget range and uncertainty are authorized? Which assumptions would change the plan? Do not promise that spending more automatically improves quality or that adding people automatically recovers a schedule.

Define outcomes and acceptance evidence before comparing suppliers

Describe the user or business outcome, current baseline, affected users, constraints, and accountable owner. Then define how each increment will be accepted. Evidence can include working journeys, automated tests, security findings, accessibility checks, performance results, reconciled data, operational runbooks, and stakeholder approval.

The UK Government's current Sourcing Playbook recommends outcome-based specifications, early market engagement, should-cost modelling, testing, piloting, risk allocation, and performance measurement for public-service sourcing. It is not a universal contract template, but its questions are useful for commercial software buyers.

Make progress reviewable in small increments

A status report is not the same as evidence of usable software. Agree a review cadence that exposes working increments, decisions, blocked dependencies, forecast changes, defects, and acceptance results. The cadence should match project risk and delivery shape rather than an arbitrary weekly ritual.

The US Government Accountability Office describes Agile as incremental development with continuous evaluation for functionality, quality, and customer satisfaction. Its Agile Assessment Guide is written for government assessment, but supports the broader principle of frequent reviews and customer feedback. Incremental delivery reduces some risks; it does not guarantee schedule, budget, or product success.

Treat quality as a risk decision

More testing does not produce a universal exponential cost curve, and fewer defects cannot be inferred from hours alone. Verification effectiveness depends on requirements, design, test selection, environment, automation, review quality, threat exposure, and operational feedback.

Define the quality attributes that matter for the product: correctness, security, privacy, accessibility, performance, resilience, maintainability, and recoverability. The necessary evidence differs between a low-impact internal tool and safety-, finance-, identity-, or rights-relevant software. Avoid treating aviation, Web3, or any other sector as one uniform risk class.

NIST's Secure Software Development Framework is outcome-based and explicitly intended to be customized to business needs, risk tolerance, and resources. It advises considering risk, cost, feasibility, and applicability rather than following one checklist unchanged. Security verification is one part of quality, not proof of total product fitness.

Estimate uncertainty instead of hiding it

An estimate should name scope, assumptions, exclusions, dependencies, method, confidence, and update conditions. Separate the estimated work from identified risk exposure and from management decisions about additional funding. Do not assume every project must use exactly three budget buckets or that adding a reserve reduces the underlying technical risk.

NASA's Cost Estimating Handbook is designed for NASA programs, not ordinary agency projects. It is still a useful authoritative reference for documenting estimate basis, risk, uncertainty, ranges, and updates. Adapt the method to the project's scale instead of copying aerospace governance wholesale.

Allocate risks to the party able to manage them

Create a risk allocation matrix before pricing. For each material risk, record cause, consequence, early signal, owner, mitigation, residual exposure, decision rights, and commercial treatment. Some risks belong with the supplier, some with the buyer, and some require joint control. Transferring a risk in contract language does not give a party practical control over it.

The UK Government's current Risk Allocation and Pricing Approaches guidance says risks should sit with the party best able to manage them and that pricing should distinguish inputs, outputs, and outcomes. It also says supplier performance measures should be objective and limited to results the supplier can influence. Apply local procurement and contract law to the actual engagement.

Choose pricing for the uncertainty and control structure

Time-based, fixed-price, milestone, capped, and outcome-linked arrangements allocate uncertainty differently. None is inherently honest, efficient, or aligned. A fixed price can work when outputs and acceptance are stable enough to price. Time-based work can fit discovery or changing scope, provided spend, priorities, and stopping rules remain visible. Outcome pricing requires measurable outcomes and a fair account of dependencies outside the supplier's control.

Compare proposals on the same scope and evidence. Ask what is included, excluded, assumed, change-controlled, warranted, supported, licensed, and handed over. Model the buyer's internal work, third-party charges, cloud services, security review, data migration, operations, and exit, not only the supplier invoice.

Make change control useful, not punitive

Software discovery changes what a team knows. A good change record states the trigger, affected requirement, options, impact on evidence, cost and schedule range, decision owner, and approval. It preserves the baseline while allowing a deliberate change.

Do not classify every clarification as billable scope growth or treat every new request as included. Agree how defects, missing acceptance, regulatory change, dependency failure, and new product scope are distinguished. Review accumulated changes against the business case rather than approving them one by one without a portfolio view.

Ask for operating ownership and an exit path

Delivery is incomplete if nobody can operate, secure, support, and change the system. Define repositories, access, environments, deployment, observability, incident response, backups, recovery, data export, documentation, licenses, credentials, supplier dependencies, and knowledge transfer.

Set authority explicitly. Who accepts work, changes priorities, approves production access, accepts residual risk, and can stop release? A senior adviser, product owner, engineering lead, or fractional executive can help, but no title automatically aligns incentives. Contract classification and employment-status questions depend on the real working arrangement and jurisdiction, not the marketing label.

What should a buyer inspect?

Warning signs need context

• A proposal states a precise cost or date without assumptions, discovery, or confidence.
• Acceptance depends on subjective satisfaction without observable criteria.
• The supplier cannot show working increments, failures, or forecast changes.
• Important risks are contractually transferred to a party that cannot control them.
• Security, privacy, accessibility, data migration, operations, or exit are absent despite being material.
• The buyer has no empowered owner for priorities, acceptance, dependencies, and decisions.

These are prompts for due diligence, not proof that a supplier is unsuitable. Ask for the missing evidence and judge the response against the project's risk.

How should Wavect's model be evaluated?

Evaluate Wavect with the same framework. Our custom software development and Fractional CTO services describe different types of support, but service names do not prove fit, outcomes, independence, or legal classification. Request a proposal that states scope, assumptions, team, authority, pricing, evidence, risks, dependencies, handover, and exit.

Selected case studies and testimonials are evidence about selected work, not a complete success-rate dataset or a guarantee. Verify current references, relevant experience, conflicts, availability, security practices, and who will actually perform the work.