Draft for Tamir's review. Not published.
Find where the growth comes from
Classify past change orders by cause: new needs, defects, regulation or vendor-driven work. Add up related orders, options and follow-on commitments, including those split across subsidiaries or purchase orders. Compare the combined scope with the approved business case.
When a final contract costs more than the approved proposal, ask for a line-by-line explanation before signing. Check whether added items were included or excluded in earlier commitments, and whether the revised case still holds.
Put boundaries on what comes next
Require milestones with written acceptance criteria and payment on acceptance. Fixed price and time-based terms can both fail when assumptions are unclear, so write the assumptions down. If requirements are unfinished, sign for the smallest complete business capability and decide the rest at a gate.
Set a change process: an independent estimate above a threshold, approval by a business owner and a yearly cap. Require documentation and knowledge transfer with every change, so another party could change the system later.
Depending on your seat
If you're on the board, establish what was committed and who had authority before you approve more. Counsel assesses authority and contractual effect. Your question is whether the combined commitment, seen whole, still serves the business.
If you're the CEO or director general, expect the next audit to look for the same pattern. Review all changes with business owners each year. For a core system, ask whether the work can be split into smaller migrations, each accepted on its own.
What to check before you decide
- Classify past change orders by cause: new needs, defects, regulation or vendor-driven.
- Add up related orders, options and follow-on commitments, and compare the total with the approved case.
- Require milestones with written acceptance criteria, and pay on acceptance.
- Get an independent estimate for any change above a set threshold.
- Set a yearly cap and have business owners review all changes.
- Require documentation and knowledge transfer with every change.
- Ask counsel to review authority, spending controls and exit terms before further approval.
Questions people ask
Board approving an ERP implementation contract on the integrator's time and materials terms, what should we require?
Require milestones with acceptance tests and payments tied to them, named key staff, a cap or a mechanism for overruns, and ownership of all configuration and documentation. Time and materials can stay for defined parts if the rest is fixed. It depends on how well the scope is defined and on what the integrator will accept.
Should directors approve technology commitments made outside the agreed approval boundary?
Establish what was committed and who had authority before considering further approval. The technology recommendation depends on business need and alternatives, while legal advisers assess authority and contractual effect.
Should a board approve ERP spending split across subsidiary purchase orders?
Assess the combined economic and operating commitment before approving further scope. Authority and contractual effect need legal review, while technology scrutiny establishes dependencies and realistic alternatives.
Should a financial board approve agile contracts without fixed completion milestones for core systems?
Never approve core financial system replacement contracts that lack fixed milestone gates and binding delivery commitments. Agile development frameworks work for digital customer interfaces but create catastrophic budget overruns when applied to core transactional ledgers. It depends on core banking migration scope.
Our system's cost tripled through change orders over ten years, how do I stop the pattern?
Change orders grow when the vendor is the only party who can price and build changes. Put a change process in place with an independent estimate, a business owner approval and a yearly cap, and start building the ability for others to change the system. It depends on how much of the system's knowledge the agency holds and on what the contract allows.
Should we accept a construction software quote based on unfinished requirements?
Define the smallest complete business capability before accepting change-based uncertainty. Signing depends on explicit assumptions, workable acceptance, and responsibility for unresolved requirements reviewed with legal owners.
Should we sign when a fleet charging contract costs more than the proposal?
Reconcile the change against the approved scope before signing. It depends on whether the increase reflects necessary work, changed assumptions, or different commercial terms, and whether the revised business case still holds.
Should we sign an ERP services contract with no clear spending boundary?
Require a defined next commitment, decision gate, and acceptance basis before signing. Fixed-price and time-based arrangements can both fail when assumptions are unclear; the right structure depends on uncertainty, scope, and retained authority.
How I can help with this decision
- Ask or talk (Free)
- I give my view on what your change-order pattern usually shows, and which term or process change would stop it first.
- Review (Pay if it was worth it)
- I write an independent assessment of the contract, the change history and your dependence on the vendor. I recommend the terms to require, a change process with a cap, and whether to sign, bound or stop further commitments.
- Retain (When it makes sense)
- I stay close through the first year to review change requests above the threshold, and acceptance evidence before payment.