Second Opinion
A better estimate begins with better assumptions.
Before approving a material implementation commitment, examine the assumptions behind the delivery model.
Purpose
The purpose is not automatically to replace the incumbent provider.
This is not
“We have already decided the current vendor is wrong.”
This is
“This commitment is important enough to challenge the assumptions before we approve it.”
The decision model
Six legitimate outcomes
Is the initiative broader than the evidence currently justifies?
- Approve
- Modify
- Decompose
- Stage
- Supplement
- Reconsider
A second opinion challenges the delivery model, not merely the price.
Before you approve the old approach, see what the new one can do.
The deliverable
Challenge the delivery assumptions. Then decide with better inputs.
- Assumption review
- What the proposed timeline and cost assume about team structure, sequencing, coordination overhead, and how much of the scope is genuinely novel engineering.
- Model alternatives
- Where an AI-native delivery model would change the shape of the work — and, just as importantly, where it would not.
- Risk and reversibility
- Whether the first commitment can be made smaller without weakening the outcome, and what evidence would justify continuing.
- A clear recommendation
- Proceed as planned, proceed with a modified model, or start smaller. If the existing plan is sound, we will say so plainly.
Illustrative Second Opinion — Executive Output
What the deliverable looks like on one page.
The example below is constructed to show the shape of the output. It is not drawn from any client engagement and contains no real scope, pricing, or outcome.
Illustrative Second Opinion — Executive Output. Constructed to show the shape of the deliverable. Not drawn from any client engagement; no real scope, pricing, or outcome.
Current commitment
- Proposed scope
- A full replacement platform delivered as one programme.
- Delivery model
- Sequential phases, discovery completed before build begins.
- Timeline
- Measured in quarters, with first working software late in the sequence.
- Staffing structure
- A large blended team sized at the start and held constant.
- Integration assumptions
- All systems of record integrated before any user sees value.
Assumptions under review
- Staffing
- Does team size reflect the engineering work, or the incumbent delivery model?
- Architecture
- Which commitments are needed now, and which could remain reversible?
- Sequencing
- Could useful capability reach a real user before the full programme?
- Integration
- Which dependencies are genuinely required for first value?
- Timeline
- How much elapsed time is engineering, and how much is coordination?
- Dependency
- Which elements create avoidable long-term dependence?
What Septiva may challenge
- Whether full scope is justified before evidence exists.
- Whether team size reflects the actual engineering work.
- Whether some architecture decisions can remain reversible.
- Whether useful capability can appear materially earlier.
- Whether long-term dependency is avoidable.
Possible recommendation
- Approve
- Modify
- Decompose
- Stage
- Supplement
- Reconsider
Stage is highlighted only as an illustration. Approve is a legitimate outcome, and a sound plan should be confirmed as sound.
Decision logic
| Current assumption | Evidence needed | Recommended next move |
|---|---|---|
| The full platform must be committed as one programme. | Whether a bounded slice can produce real usage from real staff. | Stage the commitment: fund the first slice, define what would justify the rest. |
| Team size is fixed by the delivery model. | What the first slice actually requires of engineering. | Let team size follow the problem once the work is observable. |
| All integrations precede user value. | Which integration is load-bearing for the first useful outcome. | Sequence integration behind first value rather than in front of it. |
The decision, not the implementation
Build vs. Buy is no longer enough.
Modern enterprise software decisions have more than two answers. Naming the right decision can be more valuable than negotiating the price of the wrong one.
- 01Buy
A commercial product already solves the problem well enough.
- 02Build
The problem is specific to the organization and worth owning.
- 03Co-Build
The software matters, and so does the internal capability to continue it.
- 04Automate
The work is a workflow problem before it is an application problem.
- 05Integrate
The capability already exists in systems that do not yet talk to each other.
- 06Modernize
The system is sound in intent and constrained by its implementation.
- 07Retire
The system persists out of habit rather than value.
- 08Defer
The evidence does not yet justify a commitment of this size.
Our objective isn’t to build more software. It’s to make better software decisions.
Read: Build vs. Buy is no longer enoughSecond Opinion or Challenge Septiva?
Two different questions. Two different starting points.
Second Opinion
A specific commitment is already on the table.
A proposal, estimate, or contract is under review and a decision date is approaching. The review examines the delivery assumptions behind that document so the approval is defensible in the boardroom.
Challenge Septiva
Not yet at the proposal stage?
If you have an important initiative, backlog item, workflow, or idea but not yet a defined implementation proposal, start with Challenge Septiva. The conversation is about what would need to be true for it to move materially faster.
Challenge Septiva