Hooray! It's Budget Time! | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Hooray! It's Budget Time!

September 3, 2009
by Neal Ganguly
| Reprints

A good friend of mine has a favorite saying which states “given enough, time, money and resources, anything is possible”. I think most would agree that it’s a fairly accurate statement within practical constraints (for example, no amount of time, money or resources will make me a good dancer). Regrettably, time is almost always limited, money is usually in short supply, and resources generally scarce (often related to the money problem). This gets to the heart of one of the greatest challenges for the CIO and, in fact, any organizational leader. Load balancing, resource management, project portfolio management, pipeline management – regardless of the buzz phrase one chooses to apply, the issue is prioritization.

While prioritization is an ongoing exercise for executives, at no time is the need to prioritize more acute than budget time. Organizations on a calendar year budget are very likely mired in the planning and budget process right now. For the CIO, this means a seemingly endless list of wants (requests, needs, demands) from the customer, and an excruciatingly limited amount of resources with which to address the wants. None of this is news to my CIO colleagues and there are a variety of tools and structures that can be used to help manage this challenging process. My concern is not about the challenges of prioritizing wants during budget time – it’s in the validity of the budget process itself.

I can’t speak for all my colleagues, but at our facility the budget planning process generally starts in April or May of the prior year, during which time needs are analyzed, budgetary estimates are established, and requests are made and prioritized – ultimately leading to a budget approval by the board in the 4th quarter. So there are 6-7 months between the identification of a need and the commitment of funding. If needs are identified after the 2nd quarter they may be deferred to the following year’s budget process. Thus, in theory, a need identified in October of this year, may not get funded for over 12 months. In the meantime the analysis process consumes a great deal of time and attention of IT staffers who are also assigned to ongoing projects.

In the fast paced world of IT – particularly Healthcare IT – things are changing rapidly and the old budgeting paradigm does not lend it self to the flexibility needed to quickly shift direction in response to changing priorities. This may apply less to complex multi-year projects than it does to the ad-hoc stuff. It’s the ad-hoc stuff that really clogs up the pipeline, and is often far less thoroughly planned out- and can negatively impact all timelines.

Should IT budgeting be an annual exercise, or should it happen more often? How can the needs analysis process be streamlined to ensure that requests come to IS analysts with clear justifications? Should those analysts reside in IS, or be based in the business units? Do business unit leaders have the skills to properly justify their wants? These are just some of the thoughts floating around in my head as we prepare to submit our 2010 budget requests. Good luck to my colleagues who are in the same boat



Great topic and intriguing post! The idea that "annual" is somewhat arbitrary. Maybe doing a budget more frequently would right things up. Or, of course, doing budgeting less frequently. Very hard to imagine that working!

Here's a few related observations:

1) Multi-year initiatives, whose business fundamentals have not changed, often have their second, third or beyond years' budgets discounted or cut. This is often framed as "putting those initiatives on hold," as though there was nothing perishable (and therefore wasted) in the recent past investments. I've never seen spoilage of valid previous investments included in the decision process. This contributes significantly to the high failure rate of multi-year projects.  (Put in more flattering terms, it's only the more sophisticated CFOs who understand the assets on their balance sheets, and the related strategic execution implications.)

2) Problem #1 is exacerbated in politically directed organizations, like the federal government. My friends in leadership in informatics in various federal agencies have warned me. There is no way to protect a healthy, wanted and needed child, in most cases. Birthing a different one is the charge, as if there's no deep expectation that it will have downstream needs in years ahead.  Politically-sponsored projects can have the sophistication of an unbalanced, hormonally-raging teenager.  The impact on annual budgeting processes is chaotic.
3) The annual budgeting process this past year was madness for all of us. All of the necessary assumptions were in question. And that was before the ARRA/HITECH and it's relatives, outlined by Anthony. By November, we already had collapse of the finance and real estate markets. Hospitals all had capital budget freezes and there was serious concern over how to cover pension obligations.  The option of reducing or eliminating HIMSS participation in 2009 was discussed everywhere (providers, vendors, consultancies, etc).  Objectively unusual.

4) Neal, there's a parallel, similar problem associated with the annual process of budgets that occurs in new product development. Product and software development cycles in past decades followed a waterfall model, where a half dozen sequential (non-overlapping) tasks of roughly 2 months duration characterized the plan. In the mid 1980s, the Japanese dramatically reduced their new product introduction cycle using Scrum. There's a great Harvard Business Review article (by Hirotaka Takeuchi and Ikujiro Nonaka in January of 1986; Exhibit 1 below is from that article), outlining how Cannon, Honda, Fuji and NEC used this.

Various software companies began using it and several of the largest ones, including Siemens, GE, and Cerner have made significant investments in the methodogies. Central to this is short, interative cycles, daily stand-up meetings to report progress and problems.  THis makes them transparent early, and stakeholder reviews, about monthly, which includes and encourages re-priorizing the backlogged work ... because experiential knowledge grows and needs and understanding of needs change. Much quicker than annually ... as you pointed out in your post.

The big learning for all of us is that targets (immediate goals) move over time. A process based on annual review and planning is not suitable when clarity on objectives evolves more rapidly. It's way too easy to waste a year of development resources when the flaws in the strategy and tactics are evident in month two.  How common is that?

I think you'll want to keep an eye out for our October cover story, which focuses on how CIOs can strategize (and budget accordingly) in an environment with so much uncertainty. Considering all the questions around HITECH, meaningful use, certification, the move to ICD-10 and HIPAA 5010, it's a major problem to be financially locked into decisions made 12-18 months ago.