How to Assess a Technology Programme Before You Start Building

A practical workflow for turning strategy into an executable engineering plan.

Most technology programmes don't fail because teams can't build things. They fail because execution starts before everyone actually agrees on what problem is being solved, what constraints really exist, and what success is even supposed to look like.

That's why the first step in our From Strategy to Execution approach at m-tech1 is deliberately simple: Assess & Align.

Before touching architecture, migrating workloads, or building a new platform, we build a shared view of the current environment, the business priorities, the technical constraints, and the delivery risks. Here's roughly how that works.

Step 1: Start with the business outcome

Don't start with technology. Start with the actual reason the programme exists in the first place.

A cloud modernisation initiative, for instance, could really be chasing very different goals depending on who you ask:

• reduce infrastructure cost
• accelerate product releases
• improve resilience
• retire legacy systems
• support international growth
• improve security
• prepare infrastructure for AI workloads

Each of those leads to a fairly different set of technical decisions. A simple first workshop should be able to answer:

                What needs to change?
        ↓
Why does it matter?
        ↓
What happens if we do nothing?
        ↓
How will we know it worked?
              

Tools like Miro or FigJam work well for the collaborative workshop itself, Confluence or Notion for documenting the decisions afterwards, and PowerPoint or Google Slides when it's time to align with executives.

The output of all this should fit on one page. If explaining the objective needs 20 slides, it's probably still not clear enough.

Step 2: Map the current environment

Next comes understanding what actually exists today, not what the architecture diagram from two years ago claims exists.

For a cloud or platform programme, we usually look at applications and their dependencies, infrastructure, cloud accounts and subscriptions, Kubernetes environments, CI/CD, identity and access, networking, observability, security controls, operational ownership, and cloud cost.

A useful architecture map might look something like:

                Applications
     ↓
Runtime / Kubernetes
     ↓
Cloud Infrastructure
     ↓
Networking + IAM
     ↓
Observability + Security
     ↓
Operations
              

From there we mark dependencies and the spots where friction shows up. Tools that help here include AWS Config or AWS Resource Explorer for cloud inventory, Terraform state for infrastructure visibility, Kubernetes dashboards or kubectl for platform inventory, Grafana, Datadog or CloudWatch for operational behaviour, and Jira for spotting recurring delivery problems.

The goal isn't perfect documentation for its own sake. It's understanding where complexity actually lives.

Step 3: Find the constraints

This is usually the most valuable part of the whole exercise. We simply ask each team: what's stopping you from moving faster right now?

The answers tend to sound familiar:

• environments take days to provision
• deployments require too many approvals
• platform engineers are overloaded
• architecture decisions are inconsistent
• cloud costs aren't really understood
• ownership is unclear
• observability is fragmented
• security reviews happen too late

From there we classify what we're hearing:

This is roughly the point where strategy starts turning into something you can actually execute.

Step 4: Separate facts from assumptions

Technology programmes are full of assumptions dressed up as facts.

"We need Kubernetes." Maybe. But why exactly?

"The problem is we need more engineers." Maybe. Or maybe senior engineers are actually spending 40% of their time on repetitive platform work that shouldn't need them at all.

"We need to migrate everything to AWS." Perhaps. Or perhaps some workloads should be modernised, some replatformed, and some just left alone.

We usually build out an assumption list to work through this properly:

                Assumption
   ↓
Evidence
   ↓
Risk if wrong
   ↓
How to validate
              

Something like:

This step alone tends to save organisations from making expensive architecture decisions based purely on gut feeling.

Step 5: Prioritise by impact, not technical interest

Engineering teams naturally gravitate toward the technically interesting problems. Business programmes really can't afford to work that way though.

Instead, we usually prioritise initiatives across three dimensions: business impact, engineering effort, and risk.

That produces a much more useful conversation than simply asking "what technology should we implement first?"

Step 6: Turn findings into an executable roadmap

The assessment shouldn't end with a report sitting in a drive somewhere. It should end with actual decisions.

A practical roadmap tends to look something like this:

                0-30 days
→ Fix visibility and ownership gaps

30-90 days
→ Automate recurring delivery workflows

3-6 months
→ Modernise high-impact platform capabilities

6-12 months
→ Scale the operating model across engineering
              

Every initiative on that roadmap needs an owner, an expected outcome, its dependencies, an effort estimate, a risk level, and a measurable KPI attached to it. Typical KPIs worth tracking include deployment lead time, platform ticket volume, environment provisioning time, change failure rate, MTTR, cloud cost per workload, and developer waiting time.

What Assess & Align should produce

By the end of this phase, we want to walk away with five things:

1. A shared view of the current environment
2. Clear business and technical priorities
3. Known constraints and risks
4. A prioritised set of initiatives
5. An executable roadmap

That's really what turns "we need to modernise" into "these are the three changes that will create the most value first."

The real test

Before execution kicks off, there's one simple question worth asking: can engineering, platform, security, and business leaders all explain the first three priorities in the same way?

If they give different answers, the programme probably isn't aligned yet, and starting implementation at that point usually just makes the problem more expensive down the line.

At m-tech1, this is exactly why Assess & Align comes before execution. Not to slow programmes down, but to make sure engineering effort actually goes toward the problems that matter most.