I’ve been at Atomic Object for approximately 8 years, and during that time I’ve had the opportunity and the challenge of managing relatively large software projects. I’ve learned quite a bit from fellow Atoms and picked up a few tricks of my own throughout the years. One of the best practices I’ve picked up is keeping a well-organized and properly-categorized budget.
Software projects are generally given an overall budget that a team can work against. However, the realities are that a budget can be made up of a number of different components — some of which have nothing to do with actively _creating_ features and are instead meant to be used for upfront processes (Kickoff and RDP Phase), customer communication, project management, technical documentation, etc. Depending on the overall complexity of your project, you may have one or two of these categories or all of them.
h2. Fool’s Gold
It can be tempting to manage to an overall budget because it’s simpler (which may be appropriate for smaller projects), takes less time to update each week, and can be less prone to error. However, it can put your team in a hole from the beginning and give your client the wrong impression with regard to budget and the realities of it.
For example, let’s assume a project just finished its RDP phase, which included a kickoff/discovery session, synthesizing the kickoff/discovery session, and creating a backlog of features to complete — all of which are valuable and crucial to the long-term success of the project.
The first week into the project, and the team is already in a hole that they now have to climb out of — which is completely unfair to them. Additionally, the customer is given the impression that project is behind after just _two_ weeks into the project.
The reality is that budget available for actual feature development is less than the overall budget, since the first week was spent on valuable upfront processes.
h2. Get Organized
Take the time to organize your budget into the categories and make sure to subtract any upfront costs from the overall budget. The remaining budget is what can be used for feature development.
Where the feature can be tracked as follows:
Even though the budget available for feature development is smaller than the original budget, the team is actually ahead by 2%. The team is given a budget that they can actually work against. Moreover, the customer is given better information about the budget and where the team stands with regard to progress.