Does Your Software Project Feel Like It Is Drifting?
Software development rarely goes wrong all at once.
More often, there are small warning signs.
A release slips by a couple of weeks. Then another estimate changes. A feature that sounded simple becomes much bigger. Costs start creeping up. Progress reports contain plenty of activity, but it is difficult to tell what has actually been completed.
Eventually, you find yourself asking a fairly basic question:
Are we actually on track?
That can be surprisingly difficult to answer when you are relying on the same development team or supplier to both deliver the work and explain how well the work is going.
A software development review gives you an independent view.
Does any of this sound familiar?
You may benefit from a review if:
- Deadlines regularly move
- Development costs keep increasing
- Estimates change after work has started
- You cannot clearly see what has been completed
- Releases are becoming less predictable
- Bugs keep returning
- Priorities change without clear reasons
- Your roadmap never seems to get shorter
- Your developers say the system is more complicated than expected
- Technical debt is blamed for most delays
- You are being asked for more budget
- You are considering replacing your development company
- You are thinking about rebuilding the software
- Different people are giving you different explanations
- You are no longer confident that you are getting value from the development spend
One of these problems on its own does not necessarily mean a project is failing.
Several happening together are worth investigating.
Before You Spend More Money, Get an Independent View
Software projects can consume a remarkable amount of money while everyone involved remains busy.
Busy and productive are not always the same thing.
The commercial question is not simply whether developers are writing code. It is whether the work being done is moving the business closer to the outcome you are paying for.
That is where independent review becomes useful.
I look at the project from the perspective of the founder or business owner.
I am interested in questions such as:
- What are we trying to achieve?
- Is the current plan realistic?
- Are the priorities clear?
- Is the team working on the right things?
- Are estimates credible?
- What is causing the delays?
- Are technical problems genuine constraints or symptoms of something else?
- Is the architecture creating unnecessary difficulty?
- Is there enough visibility for management?
- Does the team have the capability needed?
- Should you continue, correct course or reconsider the approach?
The aim is not to find fault.
It is to give you enough reliable information to make a better decision.
Why Software Development Problems Become Expensive
A development problem does not have to be catastrophic to become costly.
A team of developers working for another three or six months on the wrong priorities can consume far more money than the cost of getting an independent assessment early.
Rising development costs
Small delays accumulate.
A project expected to cost $100,000 can become considerably more expensive when scope, estimates and priorities are poorly controlled.
The problem becomes harder when nobody can explain exactly why the additional spend is necessary.
Lost time
There is an opportunity cost to delayed software.
A new SaaS product might miss customers. An internal system might continue forcing staff through inefficient processes. A business waiting for an integration may delay another project.
Time matters as much as the development invoice.
Founder uncertainty
One of the most frustrating situations for a non-technical founder is receiving an explanation that sounds plausible but still leaves them unsure.
You should not need to become a software engineer to understand whether your project is progressing.
Technology leaders should be able to explain technical problems in commercial terms.
The wrong recovery decision
When confidence falls, founders sometimes jump straight to the biggest solution.
Replace the developers.
Rewrite the software.
Move everything to another platform.
Start again.
Occasionally that is the right answer. Often it is not.
A review can help separate problems that require major change from problems that can be corrected with better priorities, engineering practices, leadership or governance.
What I Review
Every engagement is slightly different, because every software project has its own history.
I focus the review on the areas most likely to affect delivery, cost and business risk.
Delivery and progress
I look at how work moves from an idea or requirement through development, testing and release.
This can include:
- Current delivery status
- Recent releases
- Work in progress
- Delivery cadence
- Missed commitments
- Development bottlenecks
- Release practices
- Unfinished work
The goal is to establish what is genuinely moving and what may simply be generating activity.
Scope and priorities
Poor prioritisation can make a capable development team look ineffective.
I review whether there is a clear connection between business priorities and development work.
This may include the roadmap, backlog, current initiatives, feature requests and how decisions are made when priorities compete.
Estimates and planning
Software estimates will never be perfect.
They should still be useful.
I look at how estimates are produced, whether uncertainty is being communicated properly and whether commitments are being made at a sensible level.
Repeatedly missing estimates is usually a signal worth investigating.
Architecture and technical debt
Sometimes the developers are right.
The software genuinely may be difficult to change.
Legacy code, poor architecture, old dependencies or accumulated technical debt can make seemingly simple changes much harder than expected.
The important question is not whether technical debt exists. Most established software has some.
The question is how much it is affecting delivery and what should reasonably be done about it.
Development practices
Depending on the situation, I may examine:
- Source control
- Code review
- Automated testing
- Manual testing
- Release processes
- Development environments
- Continuous integration
- Deployment practices
- Defect management
- Documentation
This is not about ticking boxes against a fashionable engineering checklist.
A four-person development team does not need the same processes as a bank.
The practices need to be appropriate for the product, team and level of business risk.
Team and supplier capability
Good technology depends on people.
I look at whether responsibilities are clear, whether the right skills are available and whether the structure supports the work being asked of the team.
For outsourced development, I can also review how effectively the supplier relationship is working.
Reporting and founder visibility
Can you tell what is happening without sitting in every development meeting?
You should be able to.
I look at the information being provided to management and whether it helps you understand:
- Progress
- Cost
- Risk
- Priorities
- Dependencies
- Decisions
- Upcoming work
Good reporting does not mean creating another dashboard nobody reads.
It means providing enough useful information to make decisions.
How the Software Development Review Works
I keep the process proportionate to the problem.
The objective is not to bury your team in interviews, questionnaires and paperwork.
1. Founder discussion
We start with a conversation about what is happening.
I want to understand what you expected, what you are seeing now and what has caused you to question the project.
We also identify the decisions you are trying to make.
2. Project and evidence review
I review the information already available.
Depending on the engagement, this may include:
- Roadmaps
- Project plans
- Backlogs
- Development boards
- Estimates
- Release history
- Architecture information
- Technical documentation
- Supplier proposals
- Progress reports
- Development costs
- Relevant source code or repositories
I am not looking for paperwork for the sake of paperwork.
Existing evidence is usually more useful than asking someone to create documents specifically for the review.
3. Development team or supplier discussion
Where appropriate, I speak with the people doing the work.
This is important.
Founders and developers can experience the same project very differently.
The founder may see slipping deadlines. The developer may see years of technical debt, unclear requirements and constant priority changes.
Both perspectives matter.
4. Independent assessment
I bring the commercial and technical information together.
The objective is to identify the main causes rather than simply documenting the symptoms.
5. Findings and recommendations
You receive a clear assessment of what I have found, which issues matter most and what I recommend doing next.
6. Founder debrief
We discuss the findings together.
You can challenge the conclusions, ask questions and work through the practical choices available.
You should finish the review understanding your options, not holding a report full of technical terminology.
Fixed Scope Software Development Review
Software Development & Delivery Review
From $3,500 + GST
- Clear scope
- Independent assessment
- Practical recommendations
- Founder debrief
The Software Development & Delivery Review is intended for businesses where enough money, time or business risk is involved to justify an independent senior assessment.
The exact scope is agreed before starting.
A typical review covers the most relevant areas of delivery, planning, technical practices, team capability, project visibility and technology risk.
The scope will depend on the size of the project and the question you need answered.
You will know what is being reviewed before the engagement begins.
Not sure if you need the full review? Start with a conversation. I’ll tell you if I don’t think the review is warranted.
What You’ll Receive
The purpose of the engagement is clarity.
Depending on the agreed scope, your review may include:
Independent assessment
A clear explanation of the current position from an experienced technology leadership perspective.
Key findings
The most important delivery, technology and management issues identified during the review.
Risk priorities
A practical view of which issues require attention now, which can wait and which may be less important than they initially appear.
Recommended actions
Specific steps for improving the situation.
Recommendations are prioritised rather than presented as an enormous technical wish list.
Decision support
Where you are considering a significant decision, such as changing developers, increasing the budget or rebuilding the platform, I will help you assess the options.
Founder debrief
We work through the findings together so you understand what they mean for the business.
See What the Review Gives You
You will not receive a long technical report that leaves you with more questions than answers.
The findings are organised around the decisions you need to make. I separate the important issues from the background noise, show you where the main risks sit and recommend what should happen next.
A typical review might summarise the position like this:
The Goal Is Clarity, Not Another Rebuild
It is surprisingly easy for a troubled software project to end with someone recommending a rebuild.
Sometimes the person making that recommendation also happens to sell software development.
That does not automatically make the recommendation wrong, but there is an obvious commercial incentive.
My position is different.
I am not reviewing your project because I want to replace your developers with my development team.
I do not have one.
If the sensible recommendation is to continue with your existing team, I will tell you.
If the project needs better priorities rather than new technology, I will tell you.
If a relatively small change in engineering practice would solve the problem, there is little benefit in recommending a six-month rebuild.
And if the existing approach genuinely needs major change, I will explain why.
Independence matters because you need advice from someone sitting on your side of the table.
A Great Development Team Can Still Have Delivery Problems
A software development review should not begin with the assumption that somebody is incompetent.
Over more than 35 years working in technology, I have seen delivery problems caused by all sorts of combinations.
Good developers can struggle with poor priorities.
Founders can unknowingly disrupt delivery by repeatedly changing direction.
Technical debt can make reasonable estimates unreliable.
A capable development company can be working from unclear requirements.
A senior engineer can become the bottleneck because too much knowledge or decision-making depends on them.
Sometimes everybody is working hard and the system around them is still producing poor results.
That is why I look at the whole environment rather than starting with the code.
People before technology matters here.
You need to understand how the people, responsibilities, decisions, processes and technology interact before deciding what to change.
What Happens After the Review?
There is no predetermined answer.
That is rather the point.
The recommendation might be to continue largely as you are.
It might be to make a handful of changes.
Or the review may identify a more significant problem that needs attention.
Possible outcomes include:
Continue
The project may be healthier than it appears.
Sometimes the main issue is simply poor communication between technical and non-technical people.
Improving visibility may be enough.
Correct
The project remains viable, but changes are needed.
This might involve priorities, planning, testing, delivery practices, documentation, reporting or leadership.
Recover
A project that has significantly drifted may need a structured recovery plan.
That could include redefining scope, resetting expectations, establishing clearer governance and creating a realistic delivery plan.
Reconsider
Occasionally the evidence suggests that the existing strategy, supplier or technical approach no longer makes commercial sense.
If so, you need to understand that before committing the next round of budget.
Can I Help After the Review?
Yes, where it makes sense.
Some clients may want help implementing the recommendations.
That could include technology leadership support, project recovery, supplier management, governance improvements, CTO coaching or ongoing Fractional CTO support.
But that conversation happens after we understand the problem.
I would rather recommend five sensible changes than manufacture fifty so there is more consulting work afterwards.
Who Is This Review For?
The Software Development & Delivery Review is particularly useful for:
- SMEs building internal software
- Businesses using an outsourced development company
- Founders managing offshore developers
- Businesses funding a major software project
- Companies considering changing development suppliers
- Businesses deciding whether to continue investing in an existing platform
I work from Brisbane with businesses across Queensland and Australia.
The review can usually be conducted remotely, so location is rarely a barrier.
When this may not be the right service
You probably do not need this review if you simply need somebody to fix a small technical problem or write some code.
It may also be unnecessary if the development spend and business risk are relatively small.
This service is most useful when the decision you are making is commercially significant enough that an independent view has value.
If your main concern is whether your CTO or senior technology leader is operating at the level the business now needs, a CTO Leadership Review may be more appropriate.
If the bigger concern is dependency on one critical developer or technology person, consider the Key Person Technology Risk Review.
For a broader independent assessment of your technology, risks and priorities, an Independent Technology Review may be the better starting point.
Frequently Asked Questions
Reviews start from $3,500 + GST.
The final price depends on the size of the project, the number of people involved, the information that needs to be reviewed and the questions you need answered.
The scope and price are agreed before work begins.
The time required depends on the scope and availability of the people involved.
A focused review can often be completed without disrupting normal development work.
The emphasis is on gathering enough evidence to make a useful assessment rather than conducting a lengthy audit.
Not always.
Many delivery problems can be assessed through project information, release history, development practices, architecture discussions and conversations with the team.
If source code would materially help answer the questions being investigated, we can include it in the scope.
Usually, yes.
It is important that the development team’s perspective is represented.
A good review should not simply repeat management concerns back to management.
I want to understand what the developers believe is slowing the project down and compare that with the available evidence.
Yes.
In fact, independent review can be particularly useful when the business relies on an external software development company.
I can look at delivery, visibility, priorities, estimates, development practices, technical decisions and the overall supplier relationship.
Only if the evidence genuinely supports that conclusion.
Replacing a development team is disruptive, expensive and carries its own risks.
Often there are better options.
If your existing team can reasonably correct the situation, that will usually be preferable to starting again.
Yes.
Software projects often involve commercially sensitive information, source code, intellectual property, supplier relationships and internal concerns.
Confidentiality is treated seriously and appropriate agreements can be put in place where required.
We prioritise them.
Finding ten problems does not mean fixing all ten tomorrow.
I will help you understand which issues present immediate business risk, which affect delivery and which can be handled over time.
The aim is to create a practical way forward rather than generate panic.
Not Sure Whether Your Software Project Needs a Review?
If you are spending significant money on software but are becoming less confident about progress, getting an independent view before committing the next round of budget can be a sensible step.
You do not need to arrive with proof that something is wrong.
Sometimes the first useful question is simply:
“Can you help me work out whether I should actually be concerned?“
We can start with a conversation about what is happening, what you are being told and what decision you are trying to make.