Decisioning Tools

When every project claims to be a priority, the Effort/Reward matrix cuts through the noise. Score each candidate initiative on two axes — effort (cost, time, complexity, risk) and reward (savings, revenue, risk reduction, strategic value) — and plot it. Where it lands tells you what to do with it:

• Quick Wins (high reward, low effort) — do these first. They build momentum and fund credibility for bigger bets.
• Major Projects (high reward, high effort) — worth doing, but plan them properly: phased roadmaps, executive sponsorship, and clear milestones.
• Fill-Ins (low reward, low effort) — do them when capacity allows; never let them crowd out the top half.
• Money Pits (low reward, high effort) — decline or defer. Saying no here is where prioritization earns its keep.

I've used this with stakeholders to sequence everything from datacenter exits to platform roadmap investments — it turns "everything is urgent" conversations into a shared, visual decision.

ITIL gives technology operations a common language and a connected set of processes — so incidents don't just get fixed, they feed permanent improvement. The flow I've run teams on:

• Incident Management — restore service fast. Every incident is matched against known errors and existing solutions before reinventing the fix.
• Problem Management — find the root cause behind recurring incidents and log it as a defect / known error so the same fire never gets fought twice.
• Change Management & Approvals — fixes and improvements enter production through controlled, approved changes — protecting stability while still moving fast.
• Asset Management & CMDB — the backbone. Knowing exactly what you have and how it connects is what made sequencing 12,000+ server migrations possible.

Service Level Management wraps around all of it, tying every process back to what the business was promised. I've applied this running payment platform operations at Wells Fargo and in building WGU's disaster recovery and platform reliability programs.

The risk assessment matrix turns gut-feel risk conversations into a shared picture. Score every identified risk on likelihood (rare to almost certain) and impact (negligible to severe); the product places it in one of four bands:

• Extreme (16–25) — stop-the-line risks. Escalate to leadership; work doesn't proceed without a mitigation plan.
• High (10–15) — actively mitigate with named owners and dates; review at every program checkpoint.
• Medium (5–9) — mitigate where economical; monitor for movement.
• Low (1–4) — accept and note. Not every risk deserves budget.

In datacenter migrations, every application cutover got scored this way — it's what let us defend sequencing decisions to risk partners and auditors with a straight face.

TOGAF's ADM is the discipline behind sound architecture decisions: a repeatable cycle that moves from vision to business, information systems, and technology architectures — then into planning, governed implementation, and managed change. Two things make it powerful in practice:

• Requirements sit at the center — every phase checks back against what the business actually needs, so architecture never drifts into art for its own sake.
• It's a cycle, not a project — Phase H feeds the next iteration, which is how architecture keeps pace with change instead of becoming shelfware.
• Governance is built in — Phase G ensures what gets built matches what was designed, closing the gap where most architecture efforts fail.

I used this structure for enterprise architecture planning and cloud migration assessments — Phases E and F (opportunities, solutions, and migration planning) are where datacenter exit sequencing and wave planning live.