DEV Community: Rakesh Randeria

DMAIC for Technology Delivery: From Business Problem to Operational Outcome

Rakesh Randeria — Wed, 23 Sep 2026 03:55:37 +0000

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.

File Share Access Reviews: Why Ownership Matters More Than Another ACL Export

Rakesh Randeria — Mon, 21 Sep 2026 03:14:28 +0000

File Share Access Reviews: Why Ownership Matters More Than Another ACL Export

Traditional Windows file shares are easy to underestimate.

The permissions are visible. Active Directory groups exist. NTFS ACLs can be exported. On paper, that can look like access governance.

In practice, the difficult question is usually not:

Who has access?

It is:

Who is accountable for deciding whether that access should still exist?

That distinction is what turns a permissions report into an access-governance process.

The problem with ACL-only reviews

A typical file-share review starts with an export of directories, groups and users.

That is useful, but it quickly runs into familiar problems:

groups have no clear owner;
the listed owner has left the organisation;
permissions are inherited through several layers;
users appear directly on ACLs rather than through governed groups;
IT understands the technical permissions but not whether the access is still appropriate;
review spreadsheets are produced, emailed and then quietly become evidence of activity rather than evidence of a decision.

The technical visibility is there. The accountability often is not.

Treat ownership as a control

The approach I prefer is to treat ownership as a first-class control.

IT or IAM should operate the technical process: discover permissions, resolve identities, validate ownership records, package reviews and implement approved changes.

But the access decision should sit with a verified business or data owner.

That creates a much cleaner separation:

IT discovers and operates the control.

Owners decide whether access remains appropriate.

IAM/IT implements approved remediation.

Evidence records what happened.

This avoids turning a quarterly access review into an IT-owned exercise where the people with the least business context are effectively deciding who should retain access.

A practical operating model

For traditional Windows file shares, I use the following pattern:

Discover → Resolve → Validate Ownership → Monitor → Certify → Remediate → Evidence

1. Discover

Enumerate the file-share scope and collect the relevant NTFS ACLs.

The aim is not to scan everything forever. It is to establish a reliable access register that can be refreshed when needed.

2. Resolve

Translate ACL principals into meaningful Active Directory identities.

That includes handling security groups, users, unresolved SIDs, nested group relationships where required, and direct permissions that fall outside the preferred model.

3. Validate ownership

Do not assume that an owner reference is valid just because a field is populated.

A useful ownership check verifies that the referenced object exists, is the expected object type, is enabled, has a usable identity, and has enough information to participate in the review workflow.

For Active Directory groups, managedBy is a good authoritative starting point when it is maintained properly. An extension attribute can provide an organisational fallback. A structured value in the group description can support legacy environments, but I would treat that as a fallback rather than the target state.

4. Monitor

Ownership should not only be checked during the quarterly review.

A lightweight daily or overnight validation can detect missing owners, disabled owners, deleted accounts, groups that no longer resolve, and ownership conflicts.

This turns ownership hygiene into an ongoing control rather than a quarterly surprise.

5. Certify

Verified owners receive only the access within their scope.

Their decision should be simple:

Keep
Remove
Investigate

The review does not need to become a large GRC workflow to be useful. It needs clear ownership, understandable data and an auditable decision.

6. Remediate

Approved changes should flow back to IAM or IT for controlled implementation.

I deliberately prefer the discovery/review process to remain read-only against permissions. Automatic removal sounds efficient, but separating the business decision from the technical change gives better control over mistakes, exceptions and evidence.

7. Evidence

The final control is not the spreadsheet.

The evidence is the chain:

what was discovered → who owned the decision → what they decided → what was changed → when it was completed

That is much more useful operationally and from an assurance perspective.

The useful boundary

This pattern is specifically useful for traditional Windows file shares using NTFS permissions and Active Directory identities.

It does not govern SharePoint Online, Teams, OneDrive or every modern repository. Those platforms need their own discovery and control models.

That boundary matters. A governance tool becomes less trustworthy when it claims broader coverage than it actually has.

The broader lesson

The same idea applies beyond file shares:

access visibility is not access governance.

A list of permissions becomes governance when the organisation can answer:

Who owns this resource?
Is that owner still valid?
Who decides whether access is appropriate?
How often is that decision revisited?
How are changes implemented?
What evidence remains afterwards?

If those questions do not have clear answers, another ACL export probably will not solve the problem.

I have published the Windows file-share implementation pattern, PowerShell baseline, review model and sample evidence structures here:

GitHub: https://github.com/rakeshranderia/FileShare-Access-Governance

The project is intentionally scoped to Windows file shares and is designed as a safe baseline to test in a representative environment before enterprise deployment.

Data Classification Without Turning It Into Bureaucracy

Rakesh Randeria — Sun, 13 Sep 2026 03:41:43 +0000

Data Classification Without Turning It Into Bureaucracy

Data classification is easy to make complicated. A more useful question is: what decision should this classification change?

A classification should affect access, sharing, storage, encryption, retention, monitoring, third-party handling and AI use.

Start with impact, not the label

Classification should be risk-based rather than driven only by content type. Ask what happens if the data is disclosed, changed incorrectly, unavailable or used outside its intended purpose.

A simple model may be enough: Public, Internal, Confidential and Restricted. The exact labels matter less than the decisions behind them.

Classification sets the minimum baseline

The label should define the minimum handling expectation, not the full risk decision. Regulation, contracts, system criticality, external sharing or AI use may require stronger controls.

The important part: propagation

Consider:

CRM → API → Data Platform → Report → AI Retrieval Store

My default position is:

Downstream data should inherit the source classification unless there is a documented reason to change it.

That reason might be verified aggregation, masking, tokenisation, de-identification or removal of sensitive fields.

Classification tells us the control requirement.

Lineage tells us everywhere that requirement has to follow.

A practical decision record

Rather than ending with only "Classification: Confidential", capture owner, primary drivers, minimum controls, lineage status, AI implications and review triggers.

Operating flow

Identify → Assess Impact → Classify → Apply Controls → Propagate → Review

That is the difference between classification as a label and classification as an operating control.

Related resources

12 Questions to Ask Before You Call an AI Use Case Ready

Rakesh Randeria — Mon, 07 Sep 2026 21:51:19 +0000

A practical readiness check covering data, controls, human oversight and ongoing operations.

Responsible AI can become abstract very quickly. Policies and principles matter, but at some point a project team needs to answer a more practical question: are the foundations actually strong enough to proceed?

I have been using a simple 12-question readiness check to make that discussion more concrete. It is not a certification or compliance assessment. The aim is to expose obvious gaps before a use case moves from experimentation into operational use.

The 12 questions

Data ownership
Is there a clearly accountable owner for the data used by the AI use case?
Data classification
Is the information classified, and is its use permitted in the proposed AI platform?
Data quality
Is the data sufficiently accurate, complete, timely and fit for the intended purpose?
Access control
Are permissions limited to the people, systems and services that genuinely need access?
Data lineage
Can you reasonably explain the main source, movement and downstream use of the data?
Purpose and value
Is the business problem clear, and is there a measurable reason to use AI?
Risk assessment
Has the use case been assessed for privacy, security, legal, ethical and operational impact?
Approved platform
Is the AI platform approved, and are supplier, data handling and retention arrangements understood?
Human oversight
Is meaningful human review defined for consequential or material outputs?
Testing and evaluation
Have quality, failure modes, hallucination or bias risk and acceptance criteria been considered?
Monitoring
Are owners, metrics, incident paths and review triggers defined for ongoing use?
Shadow AI controls
Are users given clear guidance on approved tools, prohibited data and escalation paths?

Looking beyond one overall score

An overall readiness score is useful, but it can hide where the real weakness sits. I have therefore grouped the same questions into four dimensions:

Data Foundations

Risk & Controls

Human Oversight

Monitoring & Operations

This makes the result more useful in practice. Two organisations can have the same overall score while having very different problems: one may have weak data foundations, while another may have reasonable data controls but little monitoring or human oversight.

What happens next?

The assessment deliberately produces only three overall outcomes: Ready, Ready with Controls, or Further Assessment Required. The useful part is not the label itself; it is identifying which dimensions and individual questions need attention before scaling the use case.

As business impact increases, the strength of the assessment, evidence and oversight should increase with it. A low-impact internal productivity use case does not need the same governance treatment as an automated decision affecting customers.

Try the live assessment

https://huggingface.co/spaces/rakeshranderia/responsible-ai-readiness

View the source

https://github.com/rakeshranderia/responsible-ai-readiness

Related framework

https://github.com/rakeshranderia/data-governance-framework

The broader model behind the work remains: Data Governance → Trusted Data → AI Readiness → Responsible AI → Measurement → Scale.

Making Windows 11 Feel a Little More Familiar with PowerShell

Rakesh Randeria — Sun, 06 Sep 2026 21:26:33 +0000

Change is good, but sometimes a little familiarity is good too.

Windows 11 introduces a cleaner interface and a number of useful changes, but some long-time Windows users still prefer a few parts of the Windows 10 experience.

Rather than replacing the Windows shell or using a large “debloat” script, I wanted to see how far I could get with a small, conservative PowerShell toolkit focused on three things:

restore classic Notepad
show existing notification-area icons
make Start cleaner and more familiar

The result is a small project called Win11 Classic Experience.

1. Restoring classic Notepad

The first objective was simple: keep the lightweight classic Notepad experience.

The script:

verifies that the classic Windows Notepad capability is installed
installs it if required
removes the modern Microsoft.WindowsNotepad package
removes the provisioned package where present
suppresses the classic Notepad upgrade banner

There is also a safety gate: the modern package is not removed unless classic Notepad is confirmed as installed first.

One thing I deliberately avoided was creating a watchdog or scheduled task that constantly fights Windows servicing. If a future Windows update reintroduces the modern app, the script can simply be rerun.

2. Showing existing tray icons

Windows 11 tends to place many notification icons into the overflow area.

The approach here is straightforward:

$RegistryPath = 'HKCU:\Control Panel\NotifyIconSettings'
$Name = 'IsPromoted'
$Value = '1'

Get-ChildItem -Path $RegistryPath -Recurse | ForEach-Object {
    New-ItemProperty `
        -Path $_.PSPath `
        -Name $Name `
        -Value $Value `
        -PropertyType DWORD `
        -Force
}

This promotes the notification icons already known to the current Windows profile.

The important limitation is that new applications may create new tray entries later, so the feature may need to be rerun after additional applications are installed.

3. Making Start a little more familiar

Windows 11 cannot genuinely be turned back into the Windows 10 Start menu without replacing or extending the shell.

That was outside the scope of this project.

Instead, I used native Windows settings to make Start more application-focused:

Start_Layout = 1

ShowAllPinsList = 1

Start_IrisRecommendations = 0

In practical terms, this means:

use More pins
show all pins by default where supported
reduce recommendation content

It is still Windows 11 Start, just a little cleaner and less recommendation-heavy.

Conservative by design

The important part of this project is probably what it doesn't do.

It does not:

disable Microsoft Defender
disable Windows Update
weaken UAC
remove Microsoft Store
remove Edge
mass-remove inbox applications
install third-party shell replacements
apply dozens of undocumented registry tweaks

The goal is not to produce an unsupported or heavily modified Windows build.

The goal is simply to restore a few familiar behaviours.

Audit before apply

The toolkit includes both audit and apply modes.

To review the current state:

.\Win11-Classic-Experience.ps1 -Mode Audit

To apply the changes:

.\Win11-Classic-Experience.ps1 -Mode Apply -RestartExplorer

Individual features can also be applied independently.

Why build this?

For me, this is less about resisting change and more about removing small pieces of friction.

A familiar desktop can be useful, particularly for people who spend a lot of time administering systems and want the operating system itself to stay predictable.

The project is available on GitHub:

Win11 Classic Experience

https://github.com/rakeshranderia/win11-classic-experience