How to improve budget management during software development
Projects have always been a popular way to organise software development and funding. 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.
When businesses are project-oriented, 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.
System changes
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.
Project dependency
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.
Thinking long-term
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”.
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.
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?
About the Author
Louise Cermak is Principal Consultant at software engineering consultancy Catapult. Find out how Catapult can help coach your teams and embed good practice on its website. Catapult is a UK DevOps and Agile consultancy, and Atlassian Solutions Partner based in London. Our team has over 20 years’ experience in software engineering and digital consulting to help businesses create an improved product development process. Our experienced practitioners help organisations in a range of sectors to optimise their current ways of working to deliver quality software and improve customer retention.
Featured image: ©Gorodenkoff
