Technology projects are usually very good at describing what will be delivered.
They are often less disciplined about describing:
- the condition that needs to improve;
- the evidence showing that the problem exists;
- the causes behind the current state;
- the baseline against which success will be measured;
- and how the organisation will know the improvement lasted after the project closes.
That is where I find the overlap between Lean Six Sigma and technology delivery particularly useful.
DMAIC — Define, Measure, Analyse, Improve, Control — is not a replacement for Agile, PRINCE2, PMBOK, product delivery or an organisation's project-management framework.
It answers a different set of questions.
A delivery method helps organise how the change will be delivered.
DMAIC helps maintain the evidence chain between the original problem and the operational outcome.
That matters because a project can be delivered on time, within budget and to its agreed scope while still failing to improve the condition that justified the investment.
The overlap in one view
A typical technology delivery lifecycle might look like:
Initiate → Plan → Design → Build → Test → Deploy → Transition → Close
DMAIC can sit around that lifecycle:
Define → Measure → Analyse → Improve [delivery] → Control
The overlap is not exact, and it should not be forced to be.
The practical value is that DMAIC adds a persistent set of questions:
What problem are we solving?
How do we know?
What is causing it?
Does the proposed change address the cause?
How will we prove and sustain the improvement?
Those questions work at project level, but they also scale up into programs, portfolios and strategic roadmaps.
Define: make the problem clearer than the solution
A common technology project begins with a solution statement.
Examples:
Replace the CRM.
Move the platform to the cloud.
Implement a new service-management tool.
Automate the onboarding process.
Those may all turn out to be appropriate interventions, but none is a problem statement.
A stronger starting point is:
Customer interactions are fragmented across sales, service and marketing platforms, making it difficult to maintain a reliable customer view.
Or:
Manual onboarding requires multiple hand-offs and re-entry of the same information, resulting in long cycle times and avoidable errors.
Or:
The current technology estate has duplicated capability, inconsistent ownership and increasing support cost.
The distinction matters because once the solution has been embedded in the problem statement, analysis tends to become justification for the chosen answer.
In technology delivery, Define can include
- business outcome;
- problem or opportunity statement;
- scope and boundaries;
- stakeholders;
- users/customers;
- critical outcomes;
- high-level acceptance criteria;
- benefit owner;
- constraints;
- initial assumptions.
This overlaps significantly with a project charter.
The difference is emphasis.
A project charter may quite reasonably describe the delivery initiative.
The DMAIC lens asks whether the charter also explains what measurable condition should be different when the initiative succeeds.
Measure: establish the current state before claiming improvement
If a project is intended to improve something, there should be a baseline.
That sounds obvious, but it is easy to lose once delivery gains momentum.
A baseline might include:
- transaction cycle time;
- application count;
- vendor count;
- run cost;
- incident volume;
- mean time to restore;
- failed change rate;
- manual effort;
- error rate;
- service availability;
- customer satisfaction;
- adoption;
- licence utilisation;
- security exceptions;
- end-of-support exposure.
The measure does not have to be statistically sophisticated to be useful.
The important point is that the team knows what the current state actually looks like.
Example: service desk improvement
Suppose the proposed project is:
Introduce workflow automation to improve the service desk.
Before building anything, useful measures might include:
- average resolution time;
- queue time before assignment;
- number of manual hand-offs;
- percentage of tickets requiring rework;
- top incident/request categories;
- first-contact resolution;
- automation rate;
- user satisfaction.
Those measures may reveal that automation is useful.
They may also reveal that the largest delay is not the service desk at all — perhaps requests are waiting for approvals, identity verification or a specialist team.
Measurement prevents the project from optimising the wrong part of the process.
Analyse: resist the urge to jump from symptom to implementation
This is where DMAIC can add a lot to technology planning.
Technology teams are trained to solve problems. That is useful, but it can also mean solution design begins before the cause is well understood.
Analyse asks:
- Which symptoms are being mistaken for causes?
- Which issues create most of the impact?
- Where does delay occur?
- Which dependencies create failure?
- Is the problem technology, process, data, ownership, capability or some combination?
- What would happen if nothing changed?
Tools can be simple:
- 5 Whys;
- Pareto analysis;
- fishbone / cause-and-effect analysis;
- process mapping;
- value-stream mapping;
- FMEA;
- dependency analysis;
- data analysis;
- capability-gap analysis.
Example: fragmented technology estate
Imagine the visible problem is:
We have too many applications.
A quick response is an application-rationalisation project.
Analysis may show the deeper causes are:
- decentralised procurement;
- no consistent application ownership;
- weak retirement gates;
- project success measured at go-live rather than decommissioning;
- duplicated business capability;
- inconsistent architecture standards;
- poor visibility of licences and contracts.
That changes the improvement.
The answer is no longer simply:
Remove applications.
It becomes:
Rationalise the estate and improve the controls that allowed the duplication to accumulate.
That distinction is the difference between reducing the problem once and reducing the likelihood that it returns.
Improve: this is where delivery methods do their best work
Improve is where the intervention is designed, tested and implemented.
For a technology initiative, that may include:
- process redesign;
- automation;
- system configuration;
- application consolidation;
- migration;
- architecture changes;
- integration;
- security controls;
- vendor changes;
- operating-model changes.
This is also where Agile, waterfall, hybrid or product delivery can sit naturally.
DMAIC does not prescribe how software must be developed or how project governance must be run.
A team could use:
Define → Measure → Analyse
to establish the problem and evidence, then deliver the Improve stage through:
Backlog → Sprint → Test → Release → Measure → Adapt
The improvement can be incremental.
In fact, iterative delivery can strengthen DMAIC because the team can test whether a proposed change actually improves the measure before committing to wider scale.
Improvement should connect to cause
The important test is:
Which identified cause does this change address?
If the project team cannot answer that clearly, there is a risk that delivery activity has become disconnected from analysis.
Control: project close is not the same as improvement sustained
Control is the stage that maps particularly well to operational readiness, BAU transition and benefits realisation.
A project may finish when:
- scope is delivered;
- testing is complete;
- production deployment succeeds;
- documentation is handed over;
- the project board accepts closure.
The improvement is sustained when:
- service ownership is clear;
- performance is monitored;
- benefits are measured;
- operational thresholds exist;
- drift can be detected;
- changes are incorporated into normal governance;
- the organisation does not quietly recreate the original problem.
Technology controls can include
- service KPIs;
- monitoring and alerting;
- architecture standards;
- automated validation;
- runbooks;
- lifecycle reviews;
- licence utilisation reviews;
- vendor scorecards;
- access reviews;
- post-implementation reviews;
- benefits dashboards;
- named operational ownership.
The useful question is:
What mechanism will tell us if we are drifting back toward the original condition?
That is a different question from:
Has the project been closed?
DMAIC does not need to become bureaucracy
There is an obvious risk with frameworks: turning them into more forms, gates and meetings.
That is not the intention.
A small initiative might capture the whole DMAIC evidence chain on a few pages.
A major transformation may require much more.
The level of method should be proportionate to:
- business impact;
- risk;
- investment;
- uncertainty;
- reversibility;
- regulatory exposure;
- customer impact.
The point is not to make every project look like a Six Sigma certification exercise.
The point is to preserve enough evidence to make the decision and outcome credible.
Where the overlap becomes broader than a project
The same model scales upward.
Strategy
Define: What business or capability problem matters?
Measure: What does the current state look like?
Analyse: What strategic gaps, constraints or systemic causes exist?
Improve: What target state and strategic options are appropriate?
Control: How will strategy outcomes be reviewed?
Roadmap
Define: What planning horizon and outcome are in scope?
Measure: What is the current technology/capability estate?
Analyse: What gaps and dependencies constrain the path?
Improve: What sequence of initiatives moves toward the target state?
Control: How will the roadmap be refreshed as evidence changes?
Portfolio
Define: What investment themes and decision criteria apply?
Measure: What are we already spending and delivering?
Analyse: Where is there duplication, imbalance or concentration?
Improve: What should be funded, deferred, stopped or rebalanced?
Control: Are benefits and capacity reviewed after approval?
Program
Define: What outcome requires coordinated change?
Measure: What is the cross-project benefit baseline?
Analyse: Which causes and dependencies span multiple projects?
Improve: How should coordinated initiatives deliver the outcome?
Control: Are benefits realised after individual projects finish?
This is why I see Lean Six Sigma as a useful decision discipline across technology management, not simply an operational process-improvement method.
A practical example: from problem to roadmap
A useful roadmap sequence is:
Problem → Current State → Evidence → Root Cause → Capability Gap → Options → Prioritisation → Roadmap → Delivery → Benefits
That sequence is materially different from:
Requests → Projects → Budget → Delivery
The second can still produce a portfolio of good projects.
The first makes it easier to explain why those projects deserve to exist.
Consider a technology-estate rationalisation scenario.
The visible problems are high run cost, duplicated platforms and support complexity.
A DMAIC-led path could be:
Define
The estate has become fragmented and expensive to operate.
Measure
Baseline:
- applications;
- vendors;
- support cost;
- licence utilisation;
- incidents;
- integration count;
- end-of-support exposure;
- ownership gaps.
Analyse
Identify:
- duplicated capabilities;
- decentralised procurement;
- weak architecture standards;
- no retirement gate;
- unclear ownership;
- poor contract/utilisation visibility.
Improve
Create a roadmap:
Stabilise → Simplify → Modernise → Optimise
This may result in multiple programs and projects.
Control
Introduce:
- application ownership;
- lifecycle governance;
- architecture review;
- licence utilisation monitoring;
- benefit tracking.
Now the roadmap is not just a list of consolidation projects.
It also addresses the mechanisms that created the problem.
The distinction I find most useful
For technology delivery, I reduce the idea to this:
The delivery method organises the work. DMAIC protects the evidence chain between the problem and the outcome.
They overlap, but they are not competitors.
Agile can still be Agile.
A project manager can still use the organisation's existing framework.
Architects can still use established architecture practices.
Service teams can still use ITSM.
The Lean Six Sigma lens simply keeps asking:
What are we improving? How do we know? Why will this intervention help? Did it work? Did it last?
Those are useful questions regardless of the delivery method.
I have published the broader framework, diagrams, templates and a worked technology-estate example here:
Lean Six Sigma for Technology Strategy & Delivery
https://github.com/rakeshranderia/lean-six-sigma-technology-strategy-delivery
The repository maps DMAIC across technology strategy, roadmaps, portfolios, programs, projects, operations and benefits realisation.
