The new system is partly configured. The reporting project is waiting for cleaner data. Someone has started rewriting the process, but the team still uses the old spreadsheet. Every project has a reasonable explanation for its delay.
Taken together, they leave the business doing the same work while carrying the extra effort of trying to change it.
That is an illustrative situation, but it is a useful place to start. Before adding another project, I would want to understand what is preventing the existing work from becoming useful.
Get back to the business result
Project names can become detached from their purpose. “Implement the CRM” describes an activity. It does not explain which part of the business should work better afterwards.
Make the intended result concrete. Perhaps every enquiry should have an owner, an agreed next action and a visible history. Perhaps managers need to see which quotations have stalled without asking three people for updates.
That description gives you something to test. It also helps you challenge work that looks impressive but contributes little to the immediate problem.
Ask whether the original need still exists. Demand, staffing or priorities may have changed since the project began. Money already spent is a reason to understand the position, but it does not establish that the remaining work is worth doing.
Find the thing that is actually stopping progress
“We need more time” may be accurate, but it is not specific enough to act on. Which piece of work is waiting, what does it need and who can provide it?
There is a practical difference between a task that needs doing and a decision nobody has made. A team can spend weeks refining a report while waiting for agreement about what counts as an enquiry, a qualified opportunity or work won.
Review the stalled work with the people doing it. Identify the missing input, unresolved decision, capacity constraint or technical problem. Then give that obstacle an owner and a next action.
Avoid treating every delay as a motivation problem. If the people assigned to change the process are fully occupied delivering today's service, the plan needs a capacity decision.
Define a smaller result that can be finished
When a project feels too large to recover, identify the smallest useful outcome you can complete and test.
For the enquiry example, that could be one team consistently capturing requests, assigning ownership and recording the next action. Agree how you will check it with representative enquiries, including missing information and reassignment between colleagues.
Be precise about the boundary. State what this phase includes, what remains outside it and who accepts the result. New ideas can go into a later list rather than quietly expanding the current commitment.
A limited first result still needs to work for its intended users. Do not call it finished because the configuration exists if people cannot operate it during an ordinary working day.
Plan for the change to become normal work
The team needs to understand what changes, when it changes and where to get help. Instructions should reflect the actual process, including the exceptions that appeared during testing.
Decide who maintains the new arrangement after the project ends. That includes updating instructions, dealing with problems and checking whether the expected improvement is happening.
Agree when the previous method will be retired and how any necessary transition will work. If two methods remain available indefinitely, decide whether that is an intentional requirement or unfinished implementation.
Review the business result after people have used the change. Faster enquiry assignment is useful evidence. A completed training session, by itself, does not tell you whether ownership is now clearer.
A practical recovery exercise
Take one stalled project and write a short recovery brief:
- Result: What should work better, for whom, and how will we tell?
- Position: What is complete, usable, incomplete or no longer relevant?
- Blockage: What specifically prevents the next useful result?
- Decision: What must be agreed, stopped or sequenced differently?
- Ownership: Who can resolve the obstacle, and what capacity do they need?
- Completion: What will we deliver next, by when, and who will accept it?
Work through it with the delivery team and the person who can make the necessary decisions. If the evidence shows that the project should stop, record that decision and recover anything useful from the work already done.
My starting point is to make the next worthwhile result achievable. Once the business can finish, use and assess an improvement, it has a sounder basis for deciding what comes next.
Novologix supports change programmes, connecting priorities, implementation and adoption. If several improvements are competing for attention, we can discuss the result you need and the leadership or delivery support required to move the work forward.