302

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]

302