Software Delivery Health Check
Your software project is busy.But is it actually under control?
A 7-working-day external review of scope, ownership, decision flow, delivery signals and process.
I identify what is putting delivery at risk, what is only a symptom, and what should change first.
No transformation programme. No PM outsourcing.
No direct access to your systems required.
One independent assessment and a practical 30-day action plan.
Busy ≠ controlled
The project is moving.Your confidence in it is not.
The roadmap exists.
Jira is active.
The team is working.
Status meetings happen.
And yet milestones keep moving, priorities change mid-cycle, decisions take too long and the reporting picture never quite explains why delivery feels harder than it should.
You may already see the symptoms
The problem is rarely a lack of activity.
The problem is understanding what is actually affecting delivery and what needs to change first.
The Health Check
An independent delivery review.Not another process initiative.
The Software Delivery Health Check is a focused external review of an active software project.
I review the project through the minimum context needed — agreed materials, selected exports and focused walkthroughs — and compare the official project picture with the signals underneath it.
Within 7 working days from kickoff and access, you receive a clear assessment of the main delivery risks, the root causes behind them and a practical plan for the next 30 days.
No maturity model.
No Agile theatre.
No 12-week transformation roadmap.
Diagnose first.Fix what matters.
The review
I look at the projectas a delivery system.
Not one Jira board. Not one status report. Not one unhappy stakeholder.
The relationship between them.
Scope & commitments
What has actually been promised, to whom and based on what.
Roadmap & milestones
Whether dates still reflect delivery reality or simply remain on a slide.
Backlog & Jira
Whether priorities, work and dependencies are visible enough to support real decisions.
Ownership
Where responsibility is explicit — and where everyone assumes somebody else owns the problem.
Decision flow
Which decisions are delayed, repeatedly reopened or stuck between stakeholders.
Delivery signals
What the current project data and behaviour are telling you before the status report does.
Reporting
Whether reporting creates clarity or simply makes uncertainty look organised.
Meeting flow & overhead
What supports delivery, what duplicates information and what can stop.
Dependencies
Where delivery relies on another team, stakeholder or decision without sufficient visibility or control.
What you get
A delivery assessmentyou can actually use.
You receive a written Delivery Health Report built around decisions and action — not observations for the sake of observations.
Executive Delivery Assessment
A direct assessment of the current delivery state.
With a concise explanation of why. No artificial 87/100 delivery score.
Top 5 Delivery Risks
Signal → cause → impact → action.
Signal — What is happening.
Root cause — Why it is happening.
Likely impact — What happens if nothing changes.
Recommended action — What I believe should be done.
Ownership & Decision Gaps
Where accountability disappears between roles.
The places where responsibility is unclear, decisions have no obvious owner or accountability disappears between teams, stakeholders and management.
Process review
STOP / REDUCE / KEEP
STOP
Activities creating cost or noise without improving control.
REDUCE
Useful activities that have become heavier than necessary.
KEEP
What is already working and should not be disrupted.
Immediate Fixes
3–5 specific changes.
Not next quarter.
Next week.
30-Day Delivery Action Plan
Immediate stabilisation and clarity.
Ownership, decisions and delivery visibility.
Changes required to make the improvement stick.
60-Minute Review Session
We go through the assessment together.
I explain what I found, challenge assumptions where necessary and help prioritise what should happen first.
The process
Seven working days.Minimal disruption to the team.
Context
We start with a 60-minute context session. You explain the project, the commercial or organisational context and what is making you question the current delivery picture. We agree the minimum material needed for the review. Direct system access is optional — not required.
Review
I review the agreed delivery context. This can include selected or redacted documents, exports, reporting examples and live walkthroughs. I may ask focused follow-up questions where the project picture does not match the underlying signals.
Diagnosis
I separate visible symptoms from likely root causes and identify the delivery issues with the highest potential impact. The goal is not to document everything that could be improved. The goal is to identify what matters now.
Report & Action Plan
You receive the Delivery Health Report and the 30-Day Delivery Action Plan.
Review Session
We spend 60 minutes going through the conclusions, priorities and immediate next steps.
Confidentiality by design
Minimum access. Minimum data.
Direct access to Jira or other internal systems is optional. Redacted documents, selected exports and live walkthroughs can be used instead.
I do not need source code, production credentials or unrelated personal data to review software delivery.
Confidentiality terms are agreed before project materials are reviewed.
The 7-working-day review period starts once the context session is complete and the agreed review material is available.
Clear boundaries
This is deliberately nota transformation programme.
Not an Agile transformation.
I am not coming in to rename meetings, introduce a framework or assess your Scrum maturity.
Not PM outsourcing.
I do not take over the project or become another person in the reporting chain.
Not a code or architecture audit.
I review software delivery. I do not assess code quality, security or technical architecture.
Not a team performance review.
The goal is not to rank people or find somebody to blame.
Not a months-long consulting engagement.
The Health Check is designed to produce an independent diagnosis and a clear first plan quickly.
Diagnose first.Fix what matters.Then decide what comes next.
A good time to step back
You probably do not needanother status meeting.
You do not need to know exactly what is wrong.
That is the point of the review.
Why me
10+ years inside software delivery.Not observing it from the outside.
I'm Maciej Jankowski.
I've spent more than a decade managing software delivery and working between engineering teams, clients and stakeholders.
My experience includes software products, embedded and IoT systems, pharma R&D and gaming environments.
Different domains. The same recurring delivery problems.
Unclear commitments. Dependencies discovered too late. Decisions without owners. Status reporting disconnected from project reality. Processes that grow faster than the clarity they were supposed to create.
My role has rarely been to make a process look cleaner.
It has been to understand what is actually happening, surface risk early, create clarity and get the right decisions made.
That is the perspective behind the Software Delivery Health Check.
Start with the project
Still not sure whether the project is under control?
Tell me what is making you question the current delivery picture.
I will tell you directly whether a Software Delivery Health Check is a sensible next step.
No sales deck required.
Start with what is happening in the project.