9.5 WRITING THE BUDGET

Once the information has been gathered and you have all your figures worked out, it is time to commit this information to paper and articulate your message. This section discusses some points to keep in mind as you write your budget proposal and also suggests what kinds of documentation to provide.

9.5.1 Know Your Audience

One of the key things to keep in mind is who your audience is going to be. As your work goes through the approval process and is exposed to higher levels of management, the perspective from which it is viewed will change dramatically. Those that were close to the planning will likely have a firm grasp of the details of the compliance plans and have a good technical understanding of what is required. However, the folks reviewing and approving budget proposals are not very likely to be interested in technical details. This is not to say that providing this information is of no value; it should be included and explained in such a way that non-technically oriented people can understand. But, ultimately, what will really sell your proposal is whether or not your figures are fundamentally sound.

A second point to consider is to make sure your proposal and underlying cost justifications are in line with the business strategy of the organization. This is critical in that upper management will be hard pressed to approve of a plan that runs counter to its stated direction. This might be a good time to get a hold of your organization's mission statement or any documentation in which management's vision for the direction of the organization is articulated .

With HIPAA compliance now a primary imperative, the proposal should also state how the plan moves the organization closer to compliance. It may be helpful to map the objective of the plan with specific HIPPA requirements.

In summary, the proposal and supporting documentation should be written framed around the following points:

Fundamentally sound numbers
Alignment with the strategic orientation of the organization
Alignment with HIPAA requirements

9.5.2 Factor in Metrics

Earlier, we discussed budgeting as a process with 2 primary elements: proposal and approval followed by execution. During the execution phase, management is going to want to gauge the performance of the plan. There are two ways in which to measure the performance of the plan:

Establish a set of metrics to measure plan performance. For example, if your plan calls for the implementation of a smart card based system for authenticating logins at the nursing stations , one metric could be comparing the number of unique logins to login records before the implementation. If the system is working and achieving the desired result, you would expect to see an increase in the number of unique logins over the old system.
Comparing costs and expenditures with plan estimates. The difference between the estimates as articulated in the plan and actual costs are known as 'variance.' A small variance is normal usually, however, large variations in plan vs. actual should be investigated. Large variations over a long period of time may indicate that the estimates were inaccurate.

The comparison of plan vs. actual costs is one of the primary metrics that management will use to measure the effectiveness of the plan. However, as your write the proposal, it is good practice to come up with your own set of metrics and factor them into the plan. This way you have more than one way to measure whether or not the plan is achieving its goals. So, if a plan under execution experiences cost overruns, your other metrics may indicate that it is doing what it is designed to do in terms of results. Cost overruns happen for a variety of reasons, but if the overruns are not significant and your metrics are indicating positive results, there is less chance of the plan being viewed as an under performer and not meeting expectations.

9.5.3 Budget Documentation

Your organization may already have a standard set of documents and formats in which budget proposals should be submitted. However, at a minimum, there are several key documents you should provide.

9.5.3.1 Project Detail

Prepare a project detail that outlines the entire project item by item. Begin with an overview of the entire project and description of what the plan is designed to do. This is an opportunity to start stating your business case. However, in the overview keep things high-level. You may also introduce some information about the technology, but keep in mind that the main theme should revolve around the business case and alignment with the organization's strategy.

Following the overview, a definition of terms may be appropriate. This is especially true if you are introducing a new technology or a process that is unfamiliar to the organization. If certain expressions are going to appear throughout the documents that mean something specific in a certain context, this could be something you should define at this point as well. An example would be in risk assessment; terms such as 'risk,' 'threat,' 'impact,' or 'exposure' all have specific meanings in the context of a risk assessment. However, in every day usage, some of these terms are often used interchangeably.

A project is multidimensional; it will have subcomponents which may need to be acquired , but it is also implemented over time in a methodical manner. How you structure the remainder of the document will depend largely on the nature of the project. For example, if a technology is being proposed, then it may be appropriate to base the structure of the document on components of the technology. Or if the project involves a technology roll-out that has an impact on processes and procedures within the organization or affects multiple departments of an organization, then it may be more appropriate to structure the document in a timeline fashion. In either case, both issues should be addressed if you are to convey an accurate understanding of what is involved in the project and the goals you wish to achieve.

The detail portion of your write up is where you can state the logic for how you arrived at your supporting figures. You should include the resources you used to obtain your figures and possibly even walk through calculations if the scenario is complex or addresses the point more effectively than a write up. In general, use of graphical or organizational treatments such as tables, charts or matrices is a good idea. Complex thoughts or concepts are often expressed more clearly using these techniques.

9.5.3.2 Executive Summary

The executive summary should be a summation of all the important points in the project detail. It should be concise and to-the-point. You can place the figures you came up with in the executive summary, both in terms of costs and benefits, but it's not a place for all the supporting calculations and justifications. However, it should be fairly easy to reference the supporting data from the executive summary.

This is arguably the most important document of the set. Your business case and alignment with strategic goals should be clear from this document although not necessarily supported here; let the project detail do that for you. As the project moves up the chain of command through the approval process, the executive summary will become more important as upper management will likely reference this first. If the strategic alignment and business purpose of the plan is not visible here, it may not get the support to fund your initiative.

9.5.3.3 Project Roadmap

The project roadmap is another significant piece of documentation. It should lay out, in a timeline fashion, how the project will unfold. Your project roadmap should specify what the major milestones are for completion of the project in the order in which they need to occur. Also, beneath each milestone, you should specify the tasks required to reach each of the milestones including estimated times for completion and resources required. The Gantt chart format is the best way to convey this type of information. There are a variety of project management software products that can be used to create Gantt charts. A sample Gantt chart is illustrated below.

9.5.3.4 Financial Plan

This is a job best handled by a spreadsheet application. There are a number of things you may wish to express in this format, but at the minimum, you should create a summary of your financial figures including all the calculations for both your costs and cost benefits. This gives the readers of your project plan one place to go to see the whole financial picture. Another piece of the financial plan to include is a spreadsheet based on a timeline format in which you map out over a period of time when expenditures are expected to occur and when cost benefits might be realized.