Hi,

While we normally focus heavily on technology when optimising workstreams, today I want to take a step back from the tech and focus instead on the process of iteration.

Coming from an infrastructure background, I’ve always followed a fairly traditional, mainstream project approach:

1. Clearly define functional and non-functional requirements
2. Propose a possible technical solution
3. Build a proof of concept
4. Discuss, tweak and decide on go/no‑go
5. Set up the solution in production
6. Create documentation and transfer knowledge
7. Migrate to the new environment
8. Handover to operations

There are always variations, but the essence is the same.

And while this waterfall approach is trustworthy and predictable, it’s also undeniably outdated.

It takes a long time before any real business value is delivered, and there’s very little agility in how the project is executed. Once the train has left the station, you can sometimes choose another track — but you can’t suddenly decide you should’ve taken the bus instead. It’s already too late.

Recently, we ran a series of workshops on iterative approaches, and I want to share some takeaways.

Why an Iterative Approach Makes Sense

Using an iterative method means breaking down the project into smaller, manageable iterations.

Each iteration must contain at least two elements:

1. It delivers actual business value
2. It provides learning or experience that improves the next iteration

1. Early Business Value

This is the obvious one — the sooner we deliver something tangible, the sooner we can collect feedback and adjust where needed.

We’ve all experienced situations where requirements were misunderstood or the business changed direction halfway through. When you have something to demonstrate early, you avoid spending months on a full-blown solution only to discover at the end that it’s not what was expected.

2. Built-In Learning

A project, by definition, is something we haven’t done before in this exact context.

Yes, there are similar experiences, but every project differs. If it weren’t, we’d call it operations.

That’s why every iteration should include a learning component: something we can carry forward into the next one.

A Practical Example

We recently faced a challenge: we needed to upgrade workstation firmware to support an upcoming security patch.

With multiple hardware vendors and no central management solution, we kicked off a project.

The traditional approach would be:

• Define requirements
• Build a PoC in integration
• Create design documents
• Implement in production
• Involve the servicedesk
• Prepare operational procedures
• Onboard everything to the environment
• And finally start updating firmware

Realistically: 5–6 weeks before any firmware is actually updated.

What We Did Instead

We still defined requirements, but we quickly outlined iterations.

The servicedesk was involved from day one.

Given the diversity of models and vendors, we structured it like this:

Iteration 1

• Set up PoC in integration
• Build in production
• Define basic monitoring
• Define tiering approach (max 4 tiers)
• Onboard Tier 0 for one device model
• Collect feedback and adjust

Iteration 2

• Onboard remaining tiers for first model
• Manually onboard Tier 0 for two additional models
• Implement more advanced monitoring
• Create operational documentation
• Gather feedback and adjust

Iteration 3

• Automate dynamic onboarding per device model
• Onboard more models
• Integrate firmware update process into device staging
• …and so on

The result?

We delivered actual value much earlier — we started updating firmware on real devices significantly sooner than the traditional timeline would have allowed.

A Few Pitfalls to Watch Out For

1. Iteration ≠ no documentation.
   Documentation is still required, but it can evolve. You don’t need a fully polished 40-page document before starting.
2. Feedback is critical.
   Each iteration must feed into the next. If you skip this step, the approach loses its purpose.
3. It requires a mindset shift.
   Teams accustomed to waterfall methods need time to adapt. That’s normal — but the benefits are worth the transition.

Thanks for reading, and I hope this inspires you to experiment with a more iterative way of working.

It’s faster, more flexible, and often delivers better results with less frustration — both for IT and the business.

Enjoy!