IT Planning is Broken

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0

IT Planning is Broken

Think back a few months.  It’s August and you are starting to marshal the troops for the annual pilgrimage to the mecca known as the annual IT budget.  You arm each of the IT leaders with a template, spreadsheet, and other tools with which they will collect the requests from the various business areas – customer segments, product businesses and corporate functions.  Depending on your organization, you may also start collecting some sizing data for each initiative – costs and benefits.

Once each of the field operatives are done collecting, then the real fun starts.   Each of the lists are then consolidated into a big list and additional details are added with the goal of prioritizing them against some kind of framework (that may or may not already be agreed to).  If the business value data hasn’t been collected, some basic sizing data is added.  Then this list often gets massaged several times in IT leadership meetings.

Just about the time that the CIO and his/her team is getting a feeling for the size and shape of the business-driven list, the CFO starts sharing the available budget (we’re somewhere in the October time frame now…) and the CIO gets to go back to the group to report that (again) we can’t fund all of the projects that have been requested.  In fact, we can probably only do about one-third of them.  The remaining planning time, maybe into January, is then applied to further prioritizing, sorting, iterating and finally telling many of the business users that their requests didn’t make it.

Yes, this is an extreme case, and no, everyone’s organization doesn’t work this way.  But, many companies I have worked with have long, reactive and wasteful planning processes.  In fact, in Diamond’s 2009 Digital IQ survey, companies reported that they spent 240 man months performing IT planning.  I’m certain that this time is not all productive – we can do better.

Agile IT Planning, Then Agile Business

Addressing this problem is a two-step process.  First, we need to eliminate the wasted steps in IT’s approach to planning.  The key to this is to begin with the end in mind, as follows:

  1. Develop a draft of the plan before asking for additional inputs.  It’s ok to have gaps and placeholders but it’s critical to set the boundaries up front.  This draft should be developed by the CIO and his/her leadership team – 5-10 people max.
  2. Agree upon scope and other planning assumptions, including how much time will be spent in each phase, who will participate and how much money will be available, even if the definitive budgets aren’t set yet by the CFO.
  3. Communicate the draft plan, planning process and expectations to business and IT stakeholders so they know what you expect from them.

Typically, I see some forms of #2-3 but very few organizations draft a plan before going out and soliciting business input.  I think this is one of the primary jobs of the CIO/IT leadership that is often skipped and substituted with “tell me what you need next year” in the name of business-IT collaboration.

Once the gathering, analysis and prioritization work (and time) is eliminated for the initiatives that would never make it anyway, you can focus on adding some time back into planning, but focus it on more productive things, which I will cover in my next post. [Part 2 – How to Fix IT Planning]

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0
  • Pingback: Tweets that mention IT Planning is Broken — CIO Dashboard -- Topsy.com()

  • Pingback: Twitted by cbcurran()

  • Great post. I have seen companies be successful at the planning process with the right governance put in place at the highest level. Done correctly it means that a business project, with an IT component, will not get funded unless the IT dollars are there AND the project survives the IT cuts.

    Something else that IT shops need to look at is the ROI on performing all maintenance upgrades year after year. Some upgrades and regular software maintenance makes sense others don’t. Taking money out of maintenance and putting it into the innovation bucket is hard but necessary.

    Scott

  • Great post. I have seen companies be successful at the planning process with the right governance put in place at the highest level. Done correctly it means that a business project, with an IT component, will not get funded unless the IT dollars are there AND the project survives the IT cuts.

    Something else that IT shops need to look at is the ROI on performing all maintenance upgrades year after year. Some upgrades and regular software maintenance makes sense others don’t. Taking money out of maintenance and putting it into the innovation bucket is hard but necessary.

    Scott

  • David W Wright

    This planning is deeply flawed, even if you “fix” it as described. An effective organization is not a collection of competing interests, and IT is not a resource to be divvied up. Where is the organization’s overall strategy and goals in this scenario? How will organization-wide improvement occur when projects are isolated into departmental silos?

  • David W Wright

    This planning is deeply flawed, even if you “fix” it as described. An effective organization is not a collection of competing interests, and IT is not a resource to be divvied up. Where is the organization’s overall strategy and goals in this scenario? How will organization-wide improvement occur when projects are isolated into departmental silos?

  • Chris,
    You took me back in time to my budget planning cycles. 😉 Regarding the draft. Later on as my company grew I had to develop what we called a “zero draft” plan just to keep organized. It worked well because as we got input from the CFO/CEO we began to shape things accordingly. It also allowed us to talk intelligently to business and management. We eliminated a lot of waste and time.

  • Chris,
    You took me back in time to my budget planning cycles. 😉 Regarding the draft. Later on as my company grew I had to develop what we called a “zero draft” plan just to keep organized. It worked well because as we got input from the CFO/CEO we began to shape things accordingly. It also allowed us to talk intelligently to business and management. We eliminated a lot of waste and time.

  • Pingback: Twitted by webtechman()

  • Pingback: Links for December 13 2009 | Eric D. Brown()

  • @dwwright99 I think I see your perspective on the planning outlined in this post as being flawed … I am struggling to overlay this on past organizations were I’ve worked where indeed the business was isolated in silos yet they clearly had a need to leverage enterprise solutions. But looking back, the plans that were so heavily invested in producing, 12 months later, rarely reflected what IT investments were actually made when it came to organization-wide efforts that actually turned out value.

    Looking forward to more posts on this subject.

    My blog: http://bit.ly/Ya8TQ

  • @dwwright99 I think I see your perspective on the planning outlined in this post as being flawed … I am struggling to overlay this on past organizations were I’ve worked where indeed the business was isolated in silos yet they clearly had a need to leverage enterprise solutions. But looking back, the plans that were so heavily invested in producing, 12 months later, rarely reflected what IT investments were actually made when it came to organization-wide efforts that actually turned out value.

    Looking forward to more posts on this subject.

    My blog: http://bit.ly/Ya8TQ

  • Lately I have wondered if part of the problem is the 12-month planning / budgeting cycle. Given the changes that Agile has made to how development work is approached, do we need to be looking at budgeting in a similar fashion? Are there any companies that have done away with the traditional “year” in terms of budgeting and planning? Is there any reason at all that a budget cycle has to be tied to the length of time it takes the earth to make a trip around the sun?

    It would have to be embraced by more than just IT, since IT budgets roll up to the overall budget for the company, but I would love to see an organization try something other than the traditional 12-month cycle.

  • Lately I have wondered if part of the problem is the 12-month planning / budgeting cycle. Given the changes that Agile has made to how development work is approached, do we need to be looking at budgeting in a similar fashion? Are there any companies that have done away with the traditional “year” in terms of budgeting and planning? Is there any reason at all that a budget cycle has to be tied to the length of time it takes the earth to make a trip around the sun?

    It would have to be embraced by more than just IT, since IT budgets roll up to the overall budget for the company, but I would love to see an organization try something other than the traditional 12-month cycle.