Recently, Brian Shea and Jonathan Feldman presented “IT Budget: Getting A Seat At The Table”, a webinar sponsored by InformationWeek and IBM. Jonathan is the CIO of the City of Asheville, NC and a columnist for InformationWeek. Wendy Schuchart from InformationWeek moderated the talk.
Jonathan and Brian hit a number of topics during the talk including: building credibility as an IT leader, IT governance committees and establishing transparency between IT and the business. Jonathan has a great write-up of the talk on his blog.
Their prepared remarks focused on the challenge of keeping projects flexible within an IT budgeting process that often promotes inflexibility. Here are the main ideas:
- The world doesn’t stand still for a year: From start to finish, the corporate budgeting cycle is often a year (or more). In terms of a software development project, a year is a really long time. During that time, the market will change, technology will change, the priorities of the business may shift, and the team(s) implementing the project will learn and discover new things (e.g. clarify requirements and priorities, discover constraints and dependencies, and tighten design).
- The Budget Cycle is a good time to define business priorities: The goal of the budgeting process is for senior leadership to decide on the priorities for the year and allocate money to those priorities. This is a good thing. Clear business priorities gives the company direction for the year.
- The Budget Cycle is a bad time to define project specifics: Sometimes during the budget process planning can go beyond business priorities and can start to get really specific. Into the nitty gritty of projects: what technologies should be implemented, how projects should be structured etc. I argued in the webinar that this is often a bad thing.
- The Dangers of defining projects too early: There’s a few problems with getting into the project details too early. (1) during the budgeting process, people who are equipped to talk about detailed requirements, constraints and design considerations are not in the room. (2) Once senior leadership makes a decision it generally has a lot of institutional inertia behind it. It may become difficult for a project team or middle manager to reverse course on a decision that’s already been made about the project. (3) For this reason, assumptions made early in the budgeting process can become “locked in” decisions for a project team. And this can result in a project team that is less able to respond to and learn from the changing conditions within a project.
- Case Studies: Brian and Jonathan discussed a couple of case studies. One in which a team had locked-in a project design very early (including detailed technology decisions). Later, the team needed to do a costly pivot when the design didn’t address the core business requirements. The second case study involved a team that kept the project definition quite flexible. The team was able to execute on an aggressive timeline, in part, because they were able to be flexible with changing priorities and evolving requirements. The end result of the project looked very different than people had expected at the beginning, but the team was able to execute successfully on the business objectives.
- Themes: The take-away themes: During the budget cycle, focus on business goals and outcomes, but not project specifics. High-level business goals should come from senior leadership (top down), project design should come from the project team (bottom up).
Subscribe to new articles about Salesforce + FinServ
We write about Salesforce for the Financial Services Industry. It’s Free. No Spam. Unsubscribe whenever you want.