Decision Experience

What was being claimed?What supported the decision?

Four historical professional situations show a recurring pattern: the decisive question was rarely where the official status suggested it would be.

These situations are anonymised and based on the founder’s recollection; the fields of work are consistent with his documented career. They are not SPQR client engagements, formal case studies, or a claim that today’s branded SPQR methodology was used under that name at the time.

Green, green, green — then red.

A CIO wanted to understand why a data warehouse programme had repeatedly reported Green and then suddenly requested more budget and time. The mandate was to determine independently what was actually happening.

What was being claimed?

The programme was on course; the repeated status colour conveyed confidence.

What actually mattered?

The solution was fragmented, architecture capability was insufficient, planning was not a reliable management baseline and status depended too heavily on subjective judgement.

What decision changed?

Do not merely add time and budget. Materially change capability — especially architecture — and the programme setup.

What happened next?

The CIO intervened substantially in the team and setup. According to the founder’s recollection, the programme situation then improved materially.

Decision lesson: status is not evidence.

The critical date was not May.

A CFO function needed monthly management information. Quarterly reporting arrived too late to recognise deterioration, initiate corrective action and assess its effect within the financial year. Monthly reporting was regarded as unavailable in the existing setup.

What was being claimed?

The required information frequency could not be delivered in time through the existing approach.

What actually mattered?

A pragmatic first version was sufficient — but infrastructure had to be installed and accepted in early April. Guaranteed lead time forced a contract decision in January.

What decision changed?

A May business deadline was translated into an immediate executive decision in January.

What happened next?

According to the founder’s recollection, the infrastructure partner and a team of approximately five delivered; monthly management information was available from May and improved thereafter.

Decision lesson: the visible deadline is often not the date of the critical decision.

Deliberately omitted: recalled budget and hardware figures and the technology supplier’s name. They are not needed for the decision lesson.

The application was delivered. The management control loop was missing.

A budgeting solution existed, but Controlling could not use it as an effective management instrument. Different management levels needed reporting, completeness checks, bottom-up consolidation, top-down targets and variance analysis.

What was being claimed?

The budgeting application had been implemented and the technical assignment was complete.

What actually mattered?

The business outcome was not the application; it was a functioning management and controlling loop.

What decision changed?

Direct access to Business and Controlling specialists and a focused task force connected requirements, architecture, interfaces and implementation.

What happened next?

According to the founder’s recollection, the solution went live at the beginning of October — deliberately as a useful first version with room to improve.

Decision lesson: delivered is not the same as achieving the business outcome.

A global standard must absorb local requirements — not accumulate local exceptions.

A regulatory trigger required one global security solution across several divisions. The programme included provider evaluation, architecture governance, independent security testing, remediation and substantial stakeholder dependencies.

What was being claimed?

One division regarded its situation as fundamentally different and resisted the global standard for an extended period.

What actually mattered?

The concrete local options within the common solution had to be visible; a blanket exception would have weakened the global architecture.

What decision changed?

Instead of escalating politically at once, the real choices available inside the standard were reviewed together.

What happened next?

According to the founder’s recollection, resistance ended after that meeting and the common solution could proceed.

Decision lesson: global standards hold when legitimate local requirements are made explicit and solved within the common architecture.

Deliberately omitted: the specific regulation, alleged penalty amounts, organisation and provider. These details are either not independently verified or unnecessary to the lesson.

The recurring pattern

What does the evidence actually support?

Today’s Critical Programme Decision Review does not reuse old solutions. It brings a judgement perspective sharpened over decades to a new programme.

“Impossible”Which dependency determines feasibility?

“Delivered”Has the business outcome actually been achieved?

“Green”What evidence supports the status?

“We are different”Which local requirement is real?

See the SPQR methodology

SPQR Knowledge

Historical experience applied to current decisions.

Next step

Which decision in your programme is not yet assured?

In a confidential 20-minute fit call, we clarify the situation and possible review scope.

Request a fit call