This article provides empirical advice for software project customers, product owners, project managers, team leads. Software project budget has to be clearly understood, examined and optimized. All the practices have been verified by ISS Art's team.

1. Budget is a constraint

Budget is one of the main constraints on each project. Often it plays the main role in the project delivery.

1. Indicating the constraint. At the same time, the project team may be unaware of this constraint. This message to the team is the first, cheap, logical and probably easy step to the budget optimization. It is important for both a domestic and an offshore development team. What is not said, can't be understood by anyone.
2. Checking the team's understanding. After that, you can regularly check whether the team shares your perspective. If the project manager knows, that the budget is the main constraint, they will trade between other constraints and leverage methodology in order to keep within the limits and report on the budget more purposefully.

Advice #1: make sure the development team understands the budget constraint.

2. Estimation of the project scope

You need to know estimations of the software development. The estimation is like a weather forecast and can't be 100% accurate. The more risks your project has, the larger the estimations divergence will be. There are two different estimation approaches:

1. Agile estimation;
2. 'Waterfall' estimation, we could call it structured or detailed, but let's call it Waterfall in order to define a wide range of methods other than Agile (Waterfall itself, RUP, PRINCE2 etc.).

Agile estimation

Agile estimation helps to keep the scope of work flexible, the advantage of this method is its speed, flexibility and ability to work with undefined system specifications.

At ISS Art, we once had a big project with a poor documentation. The usage of Scrum with story points estimation helped us to start getting first estimations. We helped the customer to get a clearer understanding of the budget plans. Agile estimation works well under the changing requirements and priorities. If this is your case, choose the Agile estimation.

Detailed estimation

Typically, if we start a project from scratch, we provide a three-point estimation. We decompose tasks to 4-12 hours granularity and get optimistic, most likely and pessimistic estimations for each item. It allows us to inform the customer about the probable budget and make them more confident in making decisions regarding the required project scope.

Budget estimation template for a software project. ISS Art's template.

Risks estimated

The gap between the optimistic and the pessimistic estimation is filled with risks. The optimistic estimation is made with a suggestion of no risks, and the pessimistic one is made for the case of all the significant risks. The development team should be able to comment on the risks.

To make your budget transparent, please:

Advice #2: make sure the team provide estimations and treat risks.

3. Metrics for the budget control

One day you will want to investigate the status of your project budget. Some metrics may help you understand it, such as:

1. Actual cost is simply the amount of money, that has been consumed by the project works.
2. Distribution of the spent time. On ISS Art's 'time and material' projects, we regularly provide our customers with the time logs (a roster report, a spent time report) with distribution by team members, tasks, weeks and days and any type of criteria you want to track. One of ISS Art's customers requested to provide a weekly timelog with distribution by their clients. It helped the customer to balance the priorities in accordance with the expected profit of each client.
3. Critical chain project buffer (CCPM fever chart) consumption. The critical chain implies using the project buffer for all the risks that may occur. The ratio between work progress and the buffer consumption is worth being tracked. This metric can indicate whether your project is 'healthy' or not.

CCPM chart for status monitoring of a software project budget. Image by: donlowe.org

Advice #3: select the budget metrics, track them regularly.

4. Identification and elimination of waste

Understanding of the spent budget reports is needed not only for someone's confidence. It allows us to make possible waste clear and eliminate it. It is important to take aim at the following widespread types of software development waste:

• Building the wrong feature or product;
• Mismanaging the backlog (including unclear user stories or specifications);
• Rework;
• Defects;
• Unnecessarily complex solutions;
• Extraneous cognitive load;
• Psychological distress;
• Waiting/multitasking, delays;
• Task switching;
• Knowledge loss, relearning;
• Ineffective communication;
• Handoffs.

What if some of these are burning your project budget right now?

Apparently, some type of people's time waste can't be found with only spent time reports. A good project manager, who is working closely together with the development team, can help to identify and get rid of those types of waste.

Let's discuss it in the comments below! We are ready to share our experience with you.

Advice #4: identify the budget waste to eliminate it.

5. How to optimize costs

Here are practices to lower the project costs, that we use on different projects.

1. Limited work in progress (WIP), focusing. It is a well known Kanban practice, that allows one to keep minimum work 'on their plate'. It enforces focusing, enables flexibility, reduces double work and reworks, shortens the delivery time. "Grasp all, lose all".
2. Concise documentation. Full project documentation is a dream. And this dream is oftenly able to burn the project budget. Because, the more comprehensive are the docs, the more effort is needed to keep them up to date. Keep the documentation as simple as possible. One of the core Agile values is "Working software over comprehensive documentation". Let your product (and its source code) document itself. Make checklists instead of long articles, start from short lists of the system entities, use cases and components.
3. Corresponding skills for each task. If you have simple routine tasks assigned to your high-skilled expensive team members, try to assign those tasks to cheaper staff. Let everybody do their business.
4. Flexible scope. It is impossible to reach all the three goals at once: low budget, tight timeline and highest scope/quality. A project manager has to trade between these constraints due to the project management triangle. If a feature of the product is not necessary or seems to be not very profitable, you can try to move it to future development phases or put it on hold.
5. Flexible schedule. Based on the same principles, the mitigated schedule constraint may lead to saving some budget share, when it is possible to make some works less urgent and not to do a lot of work in parallel.

Advice #5: use reliable approaches to lower your project cost.

Conclusions

We hope that these simple pieces of advice will save your software project budget and make its issues crystal clear for you:

1. make sure that the development team understands the budget constraint;
2. make sure the team provides estimations and treats risks;
3. select the budget metrics and track them regularly;
4. identify budget waste to eliminate it;
5. use reliable approaches to lower your project cost.

Of course, there are many other different practices to make the budget crystal clear and optimized.