Technical Decision Review
Make the decision before you make the commitment.
Some technology decisions are difficult to reverse.
A new platform. An AI initiative. A major software purchase. A cloud migration. A proposed architecture that will shape the next few years of development.
When the decision matters, it can be useful to have someone outside the project examine it before you commit.
Fern ICT provides short, focused technical reviews designed to help organisations make difficult technology decisions with greater confidence.
How do you make a difficult technical decision?
A good technical decision isn’t necessarily the decision that produces the most capable system.
It is the decision that best balances the requirements, constraints, risks and likely future consequences.
That means looking beyond the immediate attraction of a technology and asking what the decision will mean in practice.
For example:
- What problem are we actually trying to solve?
- What does the organisation genuinely need?
- What constraints cannot be changed?
- What assumptions is the proposal relying upon?
- What are the material risks?
- What alternatives are available?
- What will this decision make easier or harder in the future?
- How difficult will it be to change course later?
The aim is not to find a theoretically perfect answer.
It is to make a decision that is sensible for the circumstances.
Compare technology options on more than features
Technology comparisons often become feature comparisons.
One platform has more capabilities. Another is cheaper. A third has better performance. A supplier recommends a particular product because it fits their existing delivery model.
Those facts can all be relevant without actually answering the question.
We can help compare competing technologies and architectures against the things that matter to the organisation, including:
- functional requirements;
- technical fit;
- integration requirements;
- security;
- resilience;
- performance;
- operational complexity;
- skills and support;
- cost;
- supplier dependency;
- scalability; and
- the likely consequences of the decision over time.
The question is not simply:
“Which technology is best?”
It is:
“Which option is the best fit for what we are trying to achieve?”
Build or buy?
Build-versus-buy decisions are rarely as simple as comparing the purchase price of a product with the cost of writing software.
Building may provide greater control or allow an organisation to solve a specialised problem particularly well.
Buying may provide mature functionality, support and a shorter route to deployment.
But either decision can create long-term consequences.
We can help consider:
- whether the capability is genuinely differentiating;
- whether suitable products already exist;
- the cost and complexity of building and maintaining a solution;
- integration with existing systems;
- supplier and licensing dependencies;
- the skills required to operate the solution;
- the consequences of becoming dependent on a product; and
- how difficult it would be to change direction later.
Sometimes building is the right answer.
Sometimes buying is.
Sometimes the sensible answer is to do less.
How do you evaluate a supplier’s technical proposal?
Technology decisions are often made with incomplete or asymmetric information.
A supplier naturally presents a solution in terms of its strengths. That doesn’t make the proposal wrong, but it does mean that an independent technical perspective can be useful.
We can examine questions such as:
- Does the proposed architecture actually address the underlying problem?
- Are important assumptions reasonable?
- Are dependencies and limitations clearly understood?
- Is the proposed technology proportionate to the requirement?
- What happens if the expected scale or usage changes?
- What are the operational implications?
- Where does the organisation become dependent on the supplier?
- What would be involved in changing supplier later?
- Are there simpler alternatives?
The purpose isn’t to challenge a supplier for the sake of it.
It is to make sure that an important decision is based on the whole picture.
Challenge an architecture without starting a new project
Not every technical concern needs a major transformation programme.
Sometimes a focused review is enough to establish whether a proposed direction is sound.
A Technical Decision Review can be used to examine a particular architectural choice, technology selection or strategic question without taking responsibility for implementing the resulting solution.
This can be particularly useful when:
- a project has reached an architectural crossroads;
- a proposed technology has significant long-term consequences;
- an internal team wants an independent second opinion;
- senior management needs confidence before approving an investment; or
- a supplier’s recommendation needs independent technical scrutiny.
The review is deliberately focused on the decision rather than becoming another project in its own right.
Evidence rather than fashion
Technology changes quickly.
New platforms, development approaches and AI capabilities can create genuine opportunities. They can also create pressure to adopt something simply because everyone else appears to be doing so.
We believe technology should earn its place.
That means asking:
- What problem does this technology solve?
- Is it materially better than the alternatives?
- What evidence supports the expected benefit?
- What new dependencies does it introduce?
- What additional complexity does it create?
- Is the organisation ready to use it effectively?
- What happens if the technology does not develop as expected?
The answer may be to introduce something new.
It may be to retain what already works.
It may be to simplify.
All three can be good technical decisions.
New technology or simpler technology?
There is a tendency to equate technical progress with adding capability.
Sometimes progress means removing it.
An architecture can accumulate services, integrations, frameworks and dependencies over many years. Each individual decision may have been reasonable, while the resulting system becomes increasingly difficult to understand and change.
A new technology should therefore be assessed not only for what it enables, but also for what it adds.
We consider the balance between:
- capability and complexity;
- flexibility and operational burden;
- innovation and maturity;
- resilience and cost;
- control and supplier dependency; and
- short-term benefit and long-term consequences.
Good engineering is not about using the most technology.
It is about using the right amount of technology.
What does a Technical Decision Review involve?
The starting point is the decision you’re trying to make, rather than a predefined checklist.
A typical review involves:
- understanding the decision and the underlying problem;
- reviewing the available technical and business information;
- identifying important assumptions and constraints;
- examining the proposed approach and alternatives;
- assessing material risks and trade-offs;
- considering likely future consequences; and
- forming an independent technical view.
The available information might include architecture diagrams, technical proposals, supplier documentation, requirements, cost estimates, existing system information or previous analysis.
The scope is agreed around the question that needs answering.
A short engagement with a useful outcome
This isn’t a large transformation programme.
A review is deliberately time-boxed. I’ll examine the available material, talk to the people closest to the decision, challenge the assumptions and consider the alternatives.
The outcome is a concise written assessment setting out:
- what appears sound;
- what deserves further investigation;
- the material risks and trade-offs;
- alternatives worth considering; and
- my recommendation.
Where the evidence doesn’t support a confident conclusion, I’ll say so.
A useful review does not manufacture certainty.
It makes the uncertainty visible so that it can be considered properly.
Independent by design
Fern ICT is independent of technology vendors and implementation partners.
That matters because an independent review should be capable of reaching any conclusion.
The answer might be to proceed.
It might be to change direction.
It might be to simplify the proposed solution.
It might be to retain the existing technology.
It might even be to do nothing for now.
There is no requirement to commission implementation work from Fern ICT afterwards.
The purpose is simply to help you make a better decision.
When is a Technical Decision Review useful?
A review can be particularly valuable when:
- a significant technology investment is about to be approved;
- competing technology options are being considered;
- a build-versus-buy decision needs independent assessment;
- a technical proposal has come from a supplier;
- a project has reached an architectural crossroads;
- an organisation is being encouraged to adopt a new technology;
- an AI initiative needs an independent technical assessment;
- a cloud migration or modernisation decision is being considered;
- technical debt is influencing the direction of a system;
- senior management needs an independent technical view; or
- an internal team simply wants a second pair of experienced eyes.
You don’t need to have a fully formed brief.
Sometimes the uncertainty is the thing worth examining.
Further reading
The thinking behind this service is explored in:
Start with the decision
If you’re facing a difficult technology decision, we can start with the question you’re trying to answer.
We’ll establish what is known, what is uncertain, what information is available and whether a focused review would genuinely help.
If it would, we’ll agree the question to answer, the information required and a proportionate scope for the work.
No elaborate discovery exercise.
No sales presentation.
Just a focused piece of technical work intended to leave you with a clearer decision.
Before you commit to the technology, make sure you’re confident about the decision.