Securing GIS Program Budget

By Ross Smith, Andrew Sheahen and Alistair Davidson

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. As a result, it is common for GIS program managers to struggle to acquire suitable and sustained budgets for new and ongoing initiatives, especially when the GIS program is in competition with other corporate initiatives for a limited pool of funds.

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.
  1. Team up with your finance department.
  2. Categorize your program into logical themes.
  3. Define individual project resource cost elements.
  4. Assemble your projects individually from the bottom up.
  5. Identify and apply your operational expenditure (OPEX) and capital expenditure (CAPEX) rules.
1. Teaming with finance
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)
Knowing these simple items upfront allows you to provide supporting documentation with the budget and to consider capping your budget requests just shy of senior level sign-off. For example, if your direct boss has sign-off authority for $500,000, then you may choose to purposefully limit your budget to $495,000, rather than $505,000 which may require a vice president's or CIO's sign-off.

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
This can be fairly difficult during the early stages of program planning as there may be many unknowns with which to contend. It is nonetheless a critical piece of the budget puzzle that needs to be correctly identified.

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
In the example above, you would want to know what each of these resources would typically cost at a component level. How much will a server cost on average? How about disk space or a desktop or Web-server software or an internal business analyst per day or an external programmer per day?

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
If you consider our previous example for the Web-based application, let's assume that you will need:
  • 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
(Click for larger image)

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)?
Answering yes to one or more of these questions would form the base justification for CAPEX categorization. We recommend you work closely with your finance department to determine which of your projects can be capitalized.

Conclusion
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.


Published Saturday, June 23rd, 2007

Written by Ross Smith, Andrew Sheahen and Alistair Davidson



If you liked this article subscribe to our newsletter...stay informed on the latest geospatial technology

© 2016 Directions Media. All Rights Reserved.