Project Insights: Tracking a Project’s Burn

Written by: on February 7, 2017

Do you want your project to be completed on time and on budget? Of course you do. However, it’s more complicated than you may think. Every project is unique and there are countless variables that come into play. When estimates are well thought out and dependencies are known, a realistic schedule and team can be put in place. Once the project starts, a project manager should have a methodology for tracking their project burn rate. In short, burn rate is the rate at which the project is spending its original budget. The team’s performance for a given week or a delivery sprint will drive any adjustments the project manager needs to make to keep the project on track. These decisions will not only impact the success of the project, but they also drive business-level decisions, such as hiring, resourcing adjustments and employee mentoring. In this project insights article, we’ll evaluate some of the common factors that are necessary to effectively track a project’s burn and how these decisions can not only impact an individual project, but also business-level decisions.

Data-Driven Estimates

With over 5 years of mobile app design and development experience, we leverage historical data to more accurately estimate the work that goes into each project. Not only do we analyze the time that past projects needed for design, development, and QA, but we also look at trends we are seeing in particular client projects. As a start to the process, each product feature is categorized and given a level of confidence. Whenever we have low confidence in an estimate for a feature, our first question is, “how can we increase our confidence?” This typically means that we need to review assumptions with our clients and dig deeper into the feature. The higher the confidence, the better chance we have for staying within budget and shipping on time. If we are unable to increase our confidence level, a load factor would be added to the estimate to pad the time needed.

We also use load factors for each category when estimating the work for a particular product release. As an example, a load factor percentage is applied to development estimates as developers need to also attend meetings and need time to fix bugs related to the feature work. Another example is that we use a percentage of development time to estimate the total QA time needed for a product release. There’s an average we use based on the norm for past projects, but as we continue to release updates for our clients, we can track the historical data from previous releases to more accurately estimate future releases.

Project Planning

In a previous insights article, I covered the key aspects to successfully kicking off a project, but the devil is in the details. A project plan should cover the goal, scope, assumptions, dependencies, milestones, etc. Along with team alignment from kickoff, the project manager must evaluate some specific factors, including:

  • Are any team members taking vacation time and is it built into the schedule?
  • Was there padding added at the end of the schedule in case our estimates are off?
  • Did we analyze which features are most risky and prioritize them higher?
  • What’s needed to drive the on-time delivery of any dependencies?
  • Will requirements be available before feature work is started?
  • Is QA involved early on to review requirements and build out test cases?

Evaluating Project Burn

Whether a project is a fixed bid project or a time & materials project, a project manager still needs to evaluate their team’s performance vs. criteria set from estimates. Since we typically plan work in 2-week sprints, a team’s velocity can be tracked for each sprint, but also analyzed on a week to week basis. Let’s use one simple example that can take us down various paths and impact the overall burn of a project.

One specific developer is estimated to complete 7 points of work in a two-week sprint (with 7 points equaling 7 ideal days or 56 hours). In this example, there is a load factor of 25%, meaning that there are still 3 days (24 hours) remaining for a 2-week (80 hour) sprint. This load factor accounts for meetings and bug fix time needed throughout the two-week sprint. Let’s walk through some examples and the resulting decisions a project manager would make.

  • Scenario 1: A developer explains that they are struggling with a feature and will be 3 days (24 hours) late with it.
    • Result: The project manager needs to identify these issues as soon as possible in standup meetings to make sure the developer is getting the support they need. The project manager also needs to add 3 days (24 hours) to future projections as we are now 3 days (24 hours) over our original estimates.
  • Scenario 2: The developer is out sick for 5 days.
    • Result: The project manager adds 5 days (40 hours) to our forecast in later weeks as that time needs to be made up (which could also mean adding support from a new developer onto the project).
  • Scenario 3: The developer finishes 7 days of work in 4 days.
    • Result: The project manager can remove 3 days (24 hours) from future projections as we saved 3 days (24 hours) from our original estimates.
  • Scenario 4: There is a feature with really low confidence because the team is waiting for a SDK from a third party provider. Once the team gets the SDK and is able to analyze it, they find that it’s going to take 2 weeks longer than the original estimate.
    • Result: The project manager would discuss the new findings with the client product owner and determine if lower priority scope would be cut from the release or if the schedule would be extended.

The list goes on and on, but you can see how the knowledge learned during a project’s daily standup meeting and throughout a sprint will impact the adjustments a project manager will make to their project’s projections. These projections impact the ability to ship on time and within budget. It’s one thing if we end up over budget at the end of the project. It’s way worse if we are over budget and it’s a complete surprise at the end of a project. First, our clients will be upset. Secondly, our teams are often unhappy because the project manager didn’t accurately predict the additional work needed, which results in a team working long hours before the end of the project. In this case, the project manager probably didn’t provide support or add resources when needed. The project manager most likely also didn’t communicate that the project was tracking behind schedule and didn’t ask the client if the schedule could be adjusted. Lastly, these mistakes not only lead to team member burn out, but they also impact revenue projections for the business, which in turn can impact factors such as future hiring.

Tracking Project Burn

There are various tools that can be used to track a project burn, but at POSSIBLE Mobile, we found that it would be most effective to develop our own. Matt Mills, a Program Manager at POSSIBLE Mobile, created a homegrown burn report tool, which all project managers can use to track their project burn on a weekly basis. Schedules are built out after the completion of the estimation phase and then added into the burn report as a starting point for the project. The schedule outlines all estimated hours each team member will use throughout the given weeks for the project and it also takes into account variables such as planned vacation time. The burn report tool is used in conjunction with our time tracking software and it provides project managers a means to track the current project burn (hours and cost), projections (hours and cost we are trending to be under or over budget), and manage change request adjustments (hours and cost). Project managers can also document why adjustments are being made to projections and therefore adjust the forecast for upcoming hours in the schedule. The summary of these findings provides our company with a financial overview for every project and helps us understand our revenue projections. Summarized data is also pulled out of the reporting and added into a weekly report that is given to our clients along with overall status updates for each project.

Whether you have a homegrown tool or track a project’s burn with specific software, project managers need to continually evaluate their projects to make the necessary adjustments. If analyzing the project burn isn’t done accurately, everyone feels the pain.

Stay tuned for the next two project insights in the series. The fifth article in the series will cover steps to successfully shipping a mobile app or connected device. The last article in the series will cover the benefits of teams holding retrospectives, which help to determine what the team did well in the project versus areas that need improvement.

Brad Rossini

Brad Rossini

Brad is a Project Manager at POSSIBLE Mobile, a high-end mobile development company. He has been leading mobile development teams for over 4 years. He’s an avid snowboarder and entrepreneur who loves anything startup related.

Add your voice to the discussion: