Software projects often start with clear budgets and tight deadlines but many still go over cost, miss timelines, or underdeliver on value. Whether you’re managing a small internal build or a complex enterprise system, controlling the cost of a software project requires more than upfront estimates. It demands agile planning, continuous prioritisation, and a shift from traditional project-based thinking to long-term product delivery.
However, in recent years many have pointed out the restrictive nature of this system, the most notorious being Dr. Mik Kersten, author of Project To Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework.
One of the downfalls of project working is budget management during the iteration stage. To help businesses avoid unnecessary costs when developing new products, Louise Cermak Principal Consultant at software engineering consultancy Catapult offers her advice.
Why Traditional Budgeting Fails in Software Projects
When businesses are project-orientated, business cases are created to justify funding, and the budget for each project is set at the very beginning. While finance processes have often relied on waterfall approaches, this can pose a variety of challenges. For starters, if the project runs over, new negotiations are needed for extra funding. Then, once the project reaches the final Quality Assurance (QA) phase, it can become more expensive than expected if multiple changes are needed. In agile, the QA phase is considered an anti-pattern as it should begin from the initial design meeting through to feedback instead of having its own step in the process.
Short-Term Projects vs. Long-Term Product Thinking
Project teams are often short-lived, so, once the project has been completed, the team will usually disband. However, when changes are needed later, reassembling the team can be difficult and costly. The combined knowledge would have also been lost after separation, and it takes time for team members to get back up to speed on how the service or system was left.
In the interim, other teams may have also made minor changes that were not documented, tested or implemented correctly, leading to technical debt and refactoring. This is because the speed of delivery is often prioritised over proper technical implementation. Despite wanting to develop software as quickly as possible, teams end up having to go back and reflect on what they have learnt.
How BAU Work Affects Software Project Delivery
Often, most projects will depend on the delivery status of others, and whether these have been started, as well as companies’ typical Business As Usual (BAU) work. Common examples of BAU work include system maintenance, configuration changes, updating security patches and preparing demos for presales work.
Balancing both BAU and project work can be challenging, particularly for over capacity teams. This can be solved with a very clear prioritisation methodology, which should be consistently applied across the organisation. Product prioritisation is based on delivering value to the customer quickly by prioritising features that matter most to the end-user. In the same way, BAU should also be prioritised and ranked against features, to deliver value.
If a feature can’t be delivered due to tech debt, the tech needs to be prioritised and addressed before the feature is delivered. If BAU work is not prioritised alongside feature delivery, further progress is blocked, adding cost implications and decreasing the value achieved, so any business benefits cannot be recognised.
Moving from Project-Based to Product-Based Teams
Not all employees need to be involved in projects and businesses are increasingly considering a microservice or microservice-based approach. When thinking about long-term development, project-based teams cannot offer businesses the speed and scalability needed to get ahead.
Instead, businesses are turning to product-based teams. These are long-lived groups that collaborate with other product teams via microservices. They are made up of multi-skilled individuals that take ownership of a product from concept to decommission. By creating product teams, businesses are moving away from “get this project done quickly and move on to the next” and towards “let’s create a successful product that our customers value”
| Feature | Project-Based | Product-Based |
|---|---|---|
| Team Structure | Temporary | Long-lived, cross-functional |
| Focus | Delivery milestones | Continuous value |
| Budgeting | Upfront, fixed | Iterative, value-driven |
| Knowledge Retention | Lost after project ends | Retained within product team |
| Change Management | Disruptive | Built-in and continuous |
Improving Software Project Budget Management
Creating smaller, highly skilled teams that centre around one product removes the restrictive barriers that often add to the budget. Product teams manage their budgets using value-based prioritisation. The team determines what features to deliver within the fixed budget to continuously iterate and improve customer value.
Get Help Managing Software Projects with Catapult CX
When getting started with product-based working, it is better to start by creating an initial product team to test and learn from, adapt it for the next product team and so on. Need help transitioning to a product-based model?
Find out how Catapult can help coach your teams and embed good practice by contacting us.
