Put your IT leading activities under continuous improvement

In a fast-paced environment with an endless list of “must-haves” to implement — if you keep only one process in mind, let it be this one. After nearly two decades orchestrating IT transformations, I can tell you: continuous improvement isn’t methodology. It’s survival.

The Pressure Point

IT managers must tightly organize their activities under constant pressure. The challenge? An huge list of “must-haves” to implement in a short timeframe.

Security patches, compliance requirements (GDPR, SOC2, ISO 27001), new features demanded by business, infrastructure upgrades, cost optimization mandates — all competing for the same limited resources.

I’ve been in war rooms where teams faced impossible deadlines. The difference between success and chaos? A disciplined approach to continuous improvement.

The One Process That Matters

Continuous Improvement.

Formalized by Edwards Deming as the PDCA wheel (Plan-Do-Check-Act), this process brings improvement little by little — to everything around it. The Japanese call it Kaizen: small changes that compound into transformation.

A Reality Check

Continuous improvement sounds simple until you try it in a real organization. Then you discover resistance, politics, legacy systems, and the eternal question: “Why change what’s working?” The answer: because “working” today doesn’t mean “adequate” tomorrow.

The PDCA Framework — Deep Dive

To move fast, here’s a comprehensive checklist for each stage:

📋 PLAN — The Foundation (50% of Success)

Most teams rush planning. Don’t. A poorly planned initiative fails regardless of execution quality.

1. What are my objectives and constraints?
   Changes come from internal company vision (new services) but also external factors: regulators (GDPR, AEOI, PCI-DSS), business partners, challengers (hackers). Consider, sort, and categorize all of these.

   Practical tip: Use a RACI matrix to clarify who’s Responsible, Accountable, Consulted, and Informed for each objective.

2. What’s my budget to maintain and update/upgrade infrastructure?
   Even if obvious, projects often fail due to budget underestimates. Always keep a minimal contingency budget “on top” — I recommend 15-20% for unknowns.

   Hidden costs to consider:

   • Training and skill development
   • Downtime during migration
   • Parallel running periods (old + new systems)
   • Integration complexity
   • Ongoing operational overhead
3. What is the most suitable deployment strategy?
   Study from both user perspective and IT teams — this overlaps with DevOps.

   Common strategies:

   • Big Bang — All at once (high risk, fast)
   • Phased — Module by module (balanced approach)
   • Pilot — Test with subset first (lower risk, slower adoption)
   • Parallel — Run both systems simultaneously (safest, most expensive)
4. What are the most judicious technologies?
   No silver bullet here. Inquire IT professional advice — ideally through an advisory board with internal and external consultants.

   Technology selection criteria:

   • Alignment with existing infrastructure topology
   • Team skill availability and learning curve
   • Community support and ecosystem maturity
   • Total cost of ownership (not just license cost)
   • Vendor stability and roadmap alignment

   Avoid brand evangelists and lab testers — they sell dreams, not solutions.

5. Do I have adequate resources to implement the targeted infrastructure?
   If not: is recruitment feasible within an acceptable timeframe (while changes remain relevant)?

   Resource gaps often hide in:

   • Niche technical skills (Kubernetes, security, data engineering)
   • Project management capacity
   • Business analyst availability for requirements gathering
   • Stakeholder time for reviews and decisions
6. What is the possible schedule — and is it acceptable?
   Better to split monolithic delivery into smaller stages. This increases driving reactivity and reduces error margin.

   I’ve learned: optimistic schedules are lies we tell ourselves. Add 30% buffer minimum, then negotiate down from there.

🔧 DO — Execution with Discipline

• Does every actor know exactly what they must deliver, by when, with which dependencies?
  Ambiguity kills projects. Document everything. Use visual tools (Gantt charts, Kanban boards) to make dependencies visible.
• Do you have progress metrics for each deliverable?
  If not: bring implied actors together to define these metrics before work begins.

  Recommended metrics:

  • Percent complete (with clear definition of “complete”)
  • Burndown/burnup charts for agile teams
  • Milestone achievement rate
  • Budget burn rate vs. planned
  • Risk exposure over time
• Is communication flowing?
  Daily standups, weekly status reports, stakeholder updates — choose frequency based on project criticality.

🔍 CHECK — Validation Without Illusion

• Are result metrics within tolerance defined during “Plan” stage?
  Compare actual vs. planned for: schedule, budget, quality, scope.
• Is testing automation possible for quick, reproducible quality checks?
  Automated testing isn’t optional anymore. Unit tests, integration tests, end-to-end tests — build the pyramid.

  I’ve seen teams skip automation to “save time” initially. They paid for it tenfold later in regression bugs and deployment fear.

🔄 ACT — Learning and Adaptation

• What are the lessons learned?
  Conduct a proper retrospective — blameless, honest, actionable.

  Ask:

  • What went well? (Repeat it)
  • What went wrong? (Fix it)
  • What surprised us? (Understand it)
  • What would we do differently? (Change it)
• How to make it better for the next iteration?
  Translate lessons into concrete process changes. Not “we should communicate better” but “we will add daily 15-minute sync at 9 AM”.
• What metrics need adjustment?
  If you’re measuring the wrong things, continuous improvement becomes continuous optimization of irrelevant outcomes.

The Compound Effect

I’ve watched teams apply PDCA religiously for 18 months. The results? Deployment frequency increased 10x. Lead time decreased from weeks to hours. Bug rate dropped 80%. Not because of magic — because small improvements, iterated relentlessly, compound into transformation.

A Warning

Continuous improvement without continuous learning is just busywork. Take time to understand why things work or fail. Surface-level fixes create technical debt in your processes.

The Takeaway

Continuous improvement isn’t a luxury. It’s the only sustainable way to navigate complexity without being consumed by it.

Nearly two decades in IT has taught me:

The organizations that survive aren’t the ones with the best initial plan. They’re the ones that learn fastest, adapt quickest, and never stop improving — even when things are working fine.

Little improvements, iterated relentlessly — that’s how you stay ahead. That’s how you build a career that lasts.