Software Delivery & Process Advisory
For projects where the technology is not the problem. Requirements are vague, nobody can say what "finished" means, progress cannot be judged from the outside, and the relationship with the supplier or the internal team has become a series of hopeful meetings.
The situation this service is built for
A project is under way. Money is being spent. Work is undoubtedly happening — but the client cannot tell whether it is the right work, whether it is on schedule, or what would constitute completion.
This is rarely because anybody is acting in bad faith. It is usually because the requirement was never written down precisely, acceptance was never defined, and progress is reported in terms of activity rather than outcome. Everyone is doing their best inside a structure that makes judgement impossible.
The engagement can also be preventive: commissioned before a project starts, so requirements and acceptance criteria exist before a supplier is appointed. That is the cheaper version, though it is less often the one requested.
The role here is advisory to the client. It does not replace the client's legal, financial or regulatory advisers, and it carries no contractual authority over any supplier.
Problems this service may address
- Requirements exist only as conversationWhat was agreed depends on who remembers the meeting, and two people remember it differently.
- No definition of doneNobody can state the conditions under which a feature would be accepted, so review becomes negotiation.
- Progress cannot be judgedUpdates describe effort rather than completed outcomes, and the same items appear week after week.
- Scope grows without acknowledgementNew requirements are added informally, and the timescale quietly absorbs them until it cannot.
- Communication has no rhythmContact is ad hoc, so problems surface late and decisions wait for somebody to chase them.
- Risks are known but unrecordedEveryone privately expects the same problem, and nobody has written it down where it can be managed.
- Documentation is missing entirelyDecisions and configuration exist only in the heads of people who may not always be available.
What the work can cover
Possible work
- Requirement refinement
- Project-stage planning
- Acceptance criteria
- Delivery workflow review
- Risk identification
- Communication structure
- Vendor coordination guidance
- Documentation improvement
Typically included in scope
- Current-state reviewWhat has been agreed, what has been built and where the two have diverged.
- Requirement rewritingTurning conversational requirements into statements specific enough to be verified.
- Acceptance criteria definitionConditions for each item that make "finished" a factual question rather than an opinion.
- Stage planWork sequenced into stages with visible outputs, so progress becomes observable.
- Risk registerWhat could go wrong, how likely, and what would reduce the exposure — written down and owned.
- Communication structureWho meets whom, how often, what is reported and who decides.
What is not automatically included
- Project management of the deliveryThe role is advisory. Day-to-day management remains with the client or the supplier unless separately agreed.
- Contractual or legal adviceWhere a dispute concerns contract terms, the client's own legal advisers must be involved. This service does not replace them.
- Financial or regulatory adviceCommercial recovery, insurance and compliance questions require the client's own specialist advisers.
- Technical code reviewDetailed inspection of the software is covered by Application Review & Modernisation Strategy.
- Development workWriting or fixing software is a development engagement and is scoped separately.
- Authority over a third-party supplierGuidance can be given on what to ask and expect; instructions to a supplier come from the client.
Engagement process
Situation review
A confidential conversation covering what was agreed, what has happened and what the client wants the engagement to change. Both an optimistic and a pessimistic account are usually present; both are useful.
Documentation and evidence gathering
Reviewing the proposal, correspondence, specifications, progress reports and whatever has been delivered. Facts before opinions.
Gap analysis
Establishing where the agreement is silent, where interpretations differ and where progress cannot be verified. The gaps are usually more informative than the disagreements.
Requirements and acceptance criteria
Rewriting the outstanding work as specific, verifiable statements with acceptance conditions — the single change that most often restores a project's footing.
Delivery structure
Stages, review points, reporting format and decision routes, designed so progress can be judged from the outside without micromanagement.
Advisory period
Where agreed, a defined period of ongoing availability — reviewing progress against criteria and advising the client as decisions arise.
Expected deliverables
- Written requirement setOutstanding work expressed specifically enough that completion can be verified rather than debated.
- Acceptance criteriaConditions per item, agreed by both sides before work continues.
- Stage planSequenced work with observable outputs and review points.
- Risk registerIdentified risks with likelihood, effect and mitigation, assigned to named owners.
- Communication and governance noteMeeting rhythm, reporting format, escalation route and who holds each decision.
- Findings summaryAn honest account of where the project stands and what is required to move it forward.
Client responsibilities
- Full access to project documentation, including correspondence that is uncomfortable to share
- An honest account of what was agreed verbally as well as in writing
- Willingness to have the supplier informed of the engagement, where one exists
- A nominated decision-maker who can accept or reject the recommendations
- Acceptance that some findings may concern the client's own conduct of the project
- Separate engagement of legal or financial advisers where the situation requires them
Factors that affect scope and price
Increase scope
- A long project history with substantial correspondence to review
- Several suppliers or internal teams involved
- A large volume of outstanding requirements to rewrite
- An extended advisory period rather than a one-off piece of work
- Formal reporting for a board, funder or insurer
Keep scope lean
- Commissioning the work before the project starts rather than mid-crisis
- A single supplier and a reasonably documented history
- Focusing on the outstanding work rather than re-examining what is complete
- One nominated contact who can supply material promptly
Pricing notice. All prices are indicative starting points. Final pricing depends on project scope, complexity, integrations, documentation, timescale and agreed deliverables. Applicable taxes and third-party costs are confirmed in the written proposal where relevant.
Follow-up options
Ongoing advisory
A defined period of continued availability — reviewing progress against the criteria and advising as decisions arise, at an agreed cadence.
Technical review
Where the quality of what has been built is in question, a detailed application review examines the software itself.
Independent completion
Where a project cannot continue with its current supplier, the documented requirements allow another party to quote against a clear specification.
Questions about this service
The intention is the opposite. Most delivery difficulties come from ambiguity rather than from anyone behaving badly, and clear requirements usually benefit the supplier as much as the client.
Working openly is strongly preferred: the supplier is told the engagement exists and is invited to contribute. Competent suppliers generally welcome written acceptance criteria, because it protects them too.
An informed view can be given on whether the work described is proportionate to the amount charged, and whether progress reported matches what appears to have been delivered.
That is a professional opinion, not an audit and not a legal determination. Where a formal dispute is likely, the client's legal advisers should be engaged, and this service supports rather than replaces them.
It is the ideal moment. Written requirements, acceptance criteria and a delivery structure agreed before a supplier is appointed prevent most of the situations this service is otherwise called in to repair.
Preventive engagements are also smaller and cheaper, because there is no project history to reconstruct and no positions to unpick.
They sometimes will, and they are reported anyway. Delayed decisions, changing requirements and unavailable stakeholders are among the most common causes of software projects drifting.
Findings are written factually and without blame, because the purpose is to change what happens next rather than to establish fault. A report that only criticises the supplier is usually an incomplete report.
This service is advisory: it improves the structure and gives the client the means to judge progress. Day-to-day management stays with the client or the supplier.
Where continued involvement would help, an ongoing advisory arrangement with a defined cadence and defined scope can be agreed separately.
Continue
Services that often accompany this one
Service enquiry
Describe where the project actually stands
What was agreed, what has been delivered and what is currently unclear. Enquiries about live projects are treated as confidential.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom