Skip to main content

Author: Sounderrajan Seshadri

Budget Management with Agile Projects

This article aims to provide insights on the way budgets could be managed for Agile projects.

As I have been in the banking industry for the last 10 years, I would support my proposition with the budgeting approach in banks.

Traditionally, budgeting lifecycle is performed once a year. The assumption factored in budgeting exercise is to have deliverables in line with the overall numbers.

With Agile projects, this has huge ramifications as the vision of the project may not be in sync with the budget needed for the end state deliverables

This issue gets surfaced primarily because of the nature of the agile framework wherein the scope of the project gets incrementally fleshed out over sprints.

On a parallel note, cost implications need to be weighed in with pros and cons.

The project I had managed involved migration of legacy framework to State-of-Art technology using open systems.

This exercise meant carrying out a POC during project phase to ensure the ROI is intact.

From Sprint 1, the team realised that budget management needs to be pigeonholed sprint-wise in the larger scheme of things. Hence, we proposed to the management that prioritisation with business needs to be iterated frequently to avoid cost/schedule overrun.

By Sprint 4, team successfully managed to showcase the prototype using CICD Pipeline, React JS technologies. Based on the assessment the team decided to have a mix of legacy with end state technologies for Phase 1. As a result, the support for legacy systems had to be extended with commercial implications. These numbers were not factored in the initial budgeting exercise.

At this juncture, tech team emphasised a two-pronged approach in terms of tweaking the budget with the deliverables prioritised. Some of the tech deliverables like the Gateway were funded by Technology as opposed to the functional deliverables from business. This step was a radical departure from waterfall projects where budgets are frozen along with the application design and infrastructure upfront and typically comes from either tech or business.

In order to maximise the ROI, interim launch was planned to reinforce the value proposition to business after Sprint 4. After the interim launch, team brainstormed with the business team again on the need for compartmentalising the cost and scope based on the progress with the sprints.


Advertisement
[widget id=”custom_html-68″]

As per Agile standards, planning is generally advocated for 2 sprints in advance. With consensus from business, tech team tried to introduce a better predictability with sprint planning for 4-5 sprints ahead. With this approach, we managed to come up with high level plan for the subsequent launches well ahead of time.

Resource management was one of the important focus areas as significant cost wastage could be incurred without proper planning with vendor teams. Based on compliance regulation, some of the data specific to a country could not be tested by team members from other countries. To overcome this limitation, team members were co-located to expedite the project delivery. Here again, the cost was juxtaposed with the schedule to have an informed judgement.
Vendor teams were notified in advance on the roadmap for development. In addition, onboarding process with client had to be revamped to ensure faster turnaround.

Peer programming was practised effectively to make sure internal staff are capable enough to handle post-Live operations. The mandate from management was to ensure that pairing with vendor staff is to be continued as long as the internal staff are not up to speed on auto-pilot mode. This was one of the key areas which required close monitoring as it has significant implications on the cost. However, it helped the project team tremendously to pick up all the essential skills on priority basis.
To maximise the effectiveness of the project team, the vendor teams in charge of peer programming were also provided a deadline to complete some crucial sprint deliverables.

With other ongoing projects, we constantly endeavoured to check if some of the scope along with the cost could be parked appropriately. This exercise is extremely important in a heterogenous environment where multiple systems are interlinked across different countries and have dedicated system owners. The country targeted for adoption of new technology on a first-time basis would normally have to invest more for a period of time before other countries leverage on the same infrastructure and start sharing the cost.

After multiple launches, the key takeaway of the project is about immaculate planning needed for implementation of changes which is one of the hallmarks of Agile. Although changes are recommended from the perspective of continuous improvement, prioritisation with business is needed at every stage to ensure the final product meets the expectations of the project sponsor.

The fundamental discipline enforced with Waterfall implementation which necessitates top down support continues to be critical to ensure the success of the project for Agile implementation as well. With this observation, I would think that a hybrid approach – best of Waterfall and Agile practises would always be helpful in any environment.