1. Engage all your staff. They can identify operational inefficiencies, redundancy, and savings opportunities. Any budget reduction results in rumors, speculation, and fear of job loss. Engaging your staff in the budget process empowers them, informs them, and reduces their worry.
2. Find the low hanging fruit - vacancies, travel/training, consulting fees, food/entertainment, and other "nice to have" expenditures are the first place to start any budget reductions. I passionately support training, but when faced with budget cuts, most staff would elect to support salaries and reduce training.
3. Identify service reductions - all IT projects are a function of scope, resources, and timing. Reducing the scope of service and determining what projects to cancel is an important part of budget reductions. One challenge is that organizations often have short memories. If you offer a budget reduction linked to a service reduction, you may find that the budget reduction is happily accepted but the service reduction is forgotten in a few weeks. In fact, many departments throughout the organization will suggest that budget reductions are possible if more automation and technology is added to their work processes. Reducing service at a time when customers need more service may not be the optimal approach, which I will discuss further below.
4. Extend timelines - assuming that resources are diminished and scope is already reduced, the last lever a CIO has is to extend the timelines of new projects. Instead of delivering new software this year, delay it to next year. Existing staff can take on more projects only if they have a longer time to do them.
5. Accept risk - Our job in IT is to ensure stability, reliability, and security. 99.99% uptime requires multiple redundant data centers, but there is not a precise cookbook as to how this should be done. I have implemented 2 data centers a few miles apart and not a grid of worldwide data centers. Why? Because risk = likelihood of a bad outcome * the impact of that outcome. When creating budgets, I decided that the likelihood of a regional disaster which destroys the IT capability of the entire Boston region is small. The likelihood of a single data center fire, flood or explosion is measurable, so I chose to mitigate that risk. In times of budget stress, a re-evaluation of risk is appropriate. Can network, server, storage and desktop components be kept for a year or two beyond their usual lifetimes? Can maintenance contracts be reduced or eliminated and mitigated by having spare components handy? Just as with service reductions, the strategy of increasing risk to reduce costs must be widely communicated, so when a failure occurs, everyone understands it was a risk accepted as a result of budget reductions.
In general, I do not recommend fighting budget reductions with overly dramatic stories of doom and gloom. That is not professional. Instead, CIOs should provide senior management with a list of services and a list of risks, then decide collaboratively what to do. This ensures that the CIO and IT is seen as an enabler and team player rather than a cause of the budget problem.
Having been through numerous budget reduction experiences over the past decade, I have witnessed the paradoxical effect that IT budgets are sometimes increased when organizational budgets are decreased. Savvy administrators know that economic downturns provide the urgency to re-engineer processes and accomplish politically difficult strategic changes. A short investment in automation can lead to long term reductions in operating costs. Thus, this downturn may be the opportunity to eliminate paper, streamline labor intensive manual methods, and consolidate/centralize for economies of scale.
Over the next 60 days, I will work with Harvard Medical School administration on all these issues and report back as to what we collectively decided to do.