A technical decision you can defend, and a plan you can act on.
You leave with documented requirements, your options compared against evidence, and a reasoned recommendation sequenced into an implementation plan — before a contract or a budget commits you to a path.
Options against the criteria that matter.
- Criteria firstRequirements are written with example checks before any option is scored.
- Evidence marksFilled marks are verified; hollow marks must be tested or estimated before they count.
- Operating costSubscription, configuration, and maintenance sit alongside the purchase price.
- Decision conditionThe essential integration is proven before a platform is selected.
When the decision is unresolved.
Use consulting when several technical approaches appear plausible but their consequences are difficult to compare. You might be replacing a system, selecting a platform, or defining a project whose requirements cross several applications and business teams.
Bring the decision, the people who will use and operate the result, and the constraints you already know. Existing contracts, data formats, access rules, budget boundaries, and implementation timing matter alongside features. Gaps in this information become explicit questions to investigate, rather than assumptions hidden inside a recommendation.
Compare options with evidence.
Choose a home for requests that currently arrive everywhere.
Suppose equipment requests arrive through email and spreadsheets. The business is weighing three approaches: configure an existing tool, adopt a specialist platform, or build a focused application. Each could collect a request, but they differ in approval rules, inventory connections, exports, and the work required to operate them.
The comparison begins with representative tasks. Can a requester correct missing information? Can a reviewer approve without changing the original request? What happens when an inventory connection fails? A polished demonstration is useful evidence only when it exercises the business rules that matter.
The recommendation records which requirements are met, which need adaptation, and which depend on unverified vendor capabilities. If an export or integration is essential, testing that assumption may be the next step before selecting a platform. The implementation plan then sequences configuration, data preparation, a pilot, and adoption.
Example decision evidence
- Requirement
- A request retains its approval history after correction
- Existing tool
- Test whether configuration supports the required roles
- Specialist platform
- Verify export format and inventory interface
- Focused application
- Estimate development and ongoing operating work
- Decision condition
- Resolve essential integration evidence before selection
Define the output. Check the behavior.
Representative deliverables
- A problem statement, requirements, constraints, and unresolved questions.
- An options comparison with supporting evidence and a reasoned recommendation.
- An implementation plan with priorities, dependencies, decision points, and proposed acceptance checks.
Acceptance to agree
- Trace the recommendation to the important requirements and documented constraints.
- Review tradeoffs with the people who will use, authorize, and operate the result.
- Identify unverified assumptions and assign the next investigation or decision.
Prepare for operation.
An actionable plan explains the first stage of work, what it depends on, and how completion will be judged. It should be useful to the person commissioning the project and the person implementing it, with decisions recorded alongside their rationale.
The recommendation reflects the evidence available at the time. Material changes to requirements, vendor capabilities, or costs should trigger a review of the affected decision. Agree who owns that review and which questions must be settled before implementation begins.
Requirements and tradeoffs.
Requirements or preferences?
Separate conditions that prevent the work from being done from features that improve convenience. Describe each important requirement with an example and an acceptance check. This makes competing options easier to compare without relying on feature counts.
What is the full operating commitment?
Consider licensing, configuration, migration, integration, training, and maintenance. A lower purchase price does not establish lower overall effort. Cost comparisons should state their assumptions, sources, and uncertainty rather than present unsupported savings.
Which dependencies limit the options?
Existing identity systems, vendor interfaces, data quality, and internal ownership can constrain an otherwise attractive design. Identify those dependencies early and distinguish a documented capability from one that still needs a trial or vendor confirmation.
How reversible is the choice?
Examine data export, integration boundaries, configuration portability, and the effort of a later transition. An exit path belongs in the decision even when there is no immediate plan to use it.
Before we begin.
Do we need a shortlist before starting?
No. Start with the task and the decision you need to make. A shortlist becomes useful after the essential requirements and constraints are understood; otherwise it can narrow the discussion too early.
Can a recommendation include keeping our current system?
Yes. Retaining and configuring an existing tool should be considered when it meets the requirements. The comparison should explain the limitations and operating work of that option just as it does for a replacement.
What if an important capability is uncertain?
Define a focused test, trial, or question for the vendor. Record what evidence would resolve it and whether the wider decision depends on the answer. Do not treat an assumption as a confirmed capability.
What technical decision are you weighing?
Tell us the decision you are weighing, what prompted it, and which options or constraints are already on the table. An existing plan or requirements outline is a useful starting point.