All complex technology programs face the need for a substantial year-on-year capital and operational budget to successfully deliver their expected benefits. GIS programs are no different. GIS managers, however, are not financial experts - they are domain and technology experts. In this article, three consultants from PA Consulting offer a methodology you can use.
This article will provide the financial layman, responsible for building a budget, a simple yet robust approach to building a GIS program budget. We will provide a step-by-step approach to building your budget and offer guidelines and insights into what makes a strong and defensible budget forecast. We will explore how to build a defensible multi-year budget forecast from the bottom up.
The approach is broken down into five high-level steps.
- Team up with your finance department.
- Categorize your program into logical themes.
- Define individual project resource cost elements.
- Assemble your projects individually from the bottom up.
- Identify and apply your operational expenditure (OPEX) and capital expenditure (CAPEX) rules.
It is not uncommon for organizations to have ambiguous, complex and changing budgeting procedures, templates and guidelines. If this is your experience at your organization, you are not alone.
Complex accounting rules are often at play rather than poor planning on the part of your finance department. This department can be your most powerful ally in the budgeting process, given the often changing budgeting policies. You should team up with your finance department colleagues and engage with them early and often to ensure that the approach you are taking, template you are using (or building), and supporting documentation you are assembling all comply with their expectations.
Demonstrating your willingness to proactively work with the finance staff will go a long way to having them provide their approval before your budget is considered for final approval by the executive body.
You should actively seek to determine:
- if there are specific formats or templates required for the budget submission (it would be prudent to ask for specific examples of previous "gold starâ budgets)
- what documentation will be required to support the budget approval (e.g. business case, strategy, cost/benefit analysis, etc.)
- the rules of the approval process (e.g. who has sign-off and at what budget limit does sign-off move higher in the organization)
2. Categorize your program into logical themes
Building a budget is a not just a summary of figures for your finance department. It is a means to structure your planned GIS program activities in a meaningful way that can be easily understood. The more logical your budget is, the more likely it is to be approved without having indiscriminate reductions applied.
The most effective means to do this is to create themes within which you can group your GIS project initiatives. For example, there are:
- Infrastructure projects that will require you to budget for hardware (laptops, servers, etc.) and software (GIS, translators, RDBMS, etc.)
- Data projects that may involve data capture, conversion, acquisition, etc.
- Application build projects which require software developer, analyst and architect resources
- Sustainability projects that are required to make sure that there are resources available to modify work practices, business processes, standards, etc. as data and applications are designed and deployed
- People related projects which may involve training
The key reason for categorizing your individual projects is so that you can justify how they fit into the overall GIS program - that is, how they will collectively deliver the expected benefit to the business. If you haven't built a logical picture of how all your budget components/projects fit together into a cohesive and logical whole then you risk having pieces of it cut, somewhat indiscriminately.
3. Defining cost components
Once you have determined what projects you expect to complete in the coming budget year and you have categorized them into logical themes, you need to build up cost components at a resource level. A cost component is a single unit cost for a resource (e.g. the cost of a single server or the daily rate of an external contractor).
Building up your budget from logical cost components or "building blocks" at a resource level will allow you to logically explain how you arrived at your budget estimates. For example, if you define a project that would deliver a new Web-based application to users, you would likely need the following to build and deliver it:
- Hardware - upon which to load the software/data
- Software - which would provide the technology to serve maps over the Web
- Data - you may need to purchase an external dataset from a vendor (e.g. landbase)
- Inside Labor - representing full-time equivalent (FTE) salaried staff who work at your organization
- Outside Labor - representing suppliers from outside of your organization
We recommend simply making a list of all the cost components that you expect to apply to your projects and then seek unit costs for each of them. You can do this by working with your vendors (list prices for hardware/software, rate cards for external labor) and asking your finance department for internal labor cost rates or standard procurement lists maintained by your organization.
4. Assemble your projects individually from the bottom up
Now that you have categorized your projects into themes and identified the individual cost components, you can construct each project by assembling unit costs from the bottom up. You also need to define the quantity of each cost component you will need, the date you will start using it, and the duration over which you intend to use it.
There are generally three different ways that you will use resources from a budget perspective. You will purchase it:
- outright on a given day - considered a point purchase (e.g. purchase a server from a hardware vendor)
- based on resource usage at a given daily rate - often referred to as Time & Materials or T&M (e.g. engaging an external contractor starting on a given date for a fixed duration)
- based on a fixed price - this means you will start incurring cost on a given date but will receive invoices over a given duration
- Hardware: two (2) servers on April 1st for $32,000 each
- Software: one (1) server license purchased April 1st for $10,000
- Datasets: one (1) landbase dataset license for $15,000 on April 15th
- Inside Labor: one (1) business analyst at an internal cost of $250 per day, starting April 1st for four weeks, two days a week
- Outside Labor: two (2) programmers at a cost of $500 per day, starting April 15th for six weeks full-time
Based on the above information, you know that you will need a total budget of $121,000, with expenditure starting on April 1st and ending six weeks later on May 27th. Total forecasted expenditure in the month of April is $101,000 and for May it will be $20,000. This is important for your budget as your finance department will want your expenditure outlook.
By taking this approach you can determine for each of your projects what you forecast to spend and when you forecast to spend it based on a logical construction of your budget.
5. Identify and Apply OPEX/CAPEX Rules
Now that you have constructed your budget forecast it is critical to ensure that you have correctly allocated each budget element to either a capital or operational budget. As a general rule of thumb, you will want to assign as much of your budget to a capital category as possible.
Carefully applying some basic rules to project CAPEX assignment can result in an easily justifiable and defensible budget split. Start by trying to answer whether the project is:
- a one-off effort (i.e. not regular day-to-day business as usual activity)?
- transformational to the business (i.e. provides new capability not possible with existing data in its current form)?
- going to result in a new consolidated dataset (i.e. built from a collection of disparate legacy data platforms/sources}?
- likely to add value to existing data assets (e.g. through cleansing, alignment, standardization, or through improving granularity of existing data)?
We have found that when following the five steps outlined here you can effectively develop a GIS program budget aligned with the requirements of those providing sign-off.
The approach outlined will resonate well with both finance and senior executives involved in approving budgets, as it demonstrates your capacity to financially plan your program in a robust manner.