Blog Layout
Managing Software Budgets
Rich Cullen • February 17, 2020
Software projects rarely make headlines for being completed within original cost expectations (though thankfully it does happen). High profile overruns with large-scale implementations such as banking systems or outsourced government projects are well documented, but the challenges of keeping to schedules and budgets is also present for smaller undertakings. Creation of any new product is inherent with risk but why is keeping a software budget on track so difficult, and what are the factors that can influence this?
Conflicts Within a Project Team
This post is concerned mainly with delivery of a new product by a team working on behalf of a client (as apposed to say an ongoing development or post-MVP iteration). This may represent a software house working on behalf of a customer or an internal team steered by members of the same organisation. In either case there will often be conflicts between the various stakeholders, which may include: -
- Customer; often keen to maintain a fixed cost, perhaps pressured by budgets determined at board-level but will also have a strong expectation of what the product should achieve. The expected outcome (in their mind at least) may or may not be realistic for the budget.
- Designers; UX and UI designers will be passionate about the best possible experience and interface. Great designers know this means taking all stakeholders' interests into account but the desire to impress through visuals and functionality will be strong.
- Developers; often keen to use the latest tech, push their skills forward and demonstrate technical competency through refined code.
- Users; unless they have been well integrated into the design, development and testing process, users can unfortunately sometimes be an after thought. The needs of the user though are critical and frustration will surface quickly if not addressed.
The Role of the Product Owner
Holding a project together requires a strong team member to help manage overall delivery. Depending on the process being used, they may be known as a Project Manager or a Product Owner. This person will: -
- Facilitate requirement gathering; understanding the needs of the customer and assessing how this forms a requirement for the resulting software product.
- Negotiate with the customer over scope and features; initially at the outset when working with the customer to establish indicative budget and then throughout delivery to ensure features are deliverable and achievable.
- Communicate decisions and priorities to the development team; acting as a bridge between the customer and developers to help the understand the needs of project and decisions being made. This is not to say developers and customers should not directly interact (they most certainly should) rather the facilitation of understanding between the two parties is aided by this person.
- Assist in testing and demonstrating work back to customer; when a feature has been completed and ready for "demo", it is presented back to the customer.
Setting the expectation across the team is one of the fundamental requirements to help keep budget under control. By undertaking the role outlined above, decisions that are affected by cost can be discussed and fed-back to all stakeholders. This transparency builds a wider understanding of why decisions are made to help ease the conflicts within the team dynamic.
Start Small
Depending on the development approach being taken there are other considerations with respect to managing budget. For example, a "Waterfall" approach whereby the product development is tackled in sequential stages such as specification, design, development and testing will require very formal scoping and version control for a budget to be adhered to. An "Agile" approach, where requirements are expected to change throughout the delivery process necessitates a great deal of collaboration and mutual understanding between the delivery team and customer.
One method that will benefit both of these approaches with respect to budget is to simply restrict what is being delivered. Consider whether a section of the overall requirement can be costed and delivered initially. This presents an opportunity for all stakeholders to build an effective team ethic and understanding. This will benefit the product itself for the next phase of development when all involved have developed a more collaborative working relationship. As a result subsequent development is easier to estimate as expectations are more clearly aligned.
Let's Talk
If you feel I may be able to assist your organisation, please contact me and we can talk through your requirements.
Get in Touch