IT Plan Without a Corporate Plan???
IT Plan Without a Corporate Plan???
By: Wes Melling
Hot Issue: Can I
develop a short-term (or long-term) information technology plan, when my
company doesn't have a strategic plan?
It is perfectly possible to write an IT plan without a
corporate plan, on your own initiative, without incremental budget. Not ideal, but possible. (Having an IT plan, short term and long
term, is pretty much mandatory.)
It is often possible to involve peer managers from line
(non-IT) functions to assist in sanity-checking the business assumptions you
will be forced to make to get your IT plan written. (Getting non-IT managers involved in the process is highly desirable.)
It is sometimes possible for the IT plan to kick off
discussions that lead to a corporate plan, or at least some agreed-on strategic
thinking. (Achieving this result is
wonderful, but icing on the cake; be pleased if you achieve a solid IT
plan, and very pleased if non-IT peers have gotten involved.)
These recommendations assume you have a double problem — that you
lack both a corporate strategic plan and an IT strategic plan. You shouldn’t try to write both a short-term
and a long-term plan. Our
recommendation is that you write a short-term (12-month) plan with a one or two
page “long range trends” section for context, and then loop back on a long
range planning process after two or three months, to have a comprehensive IT
LRP in place as context for your next 12-month plan.
We recommend an initial planning process with the following
Pick a team.
Pick a methodology.
Assign homework (learn the methodology, read some
provocative books, analyze the competitors’ web sites, ask your primary IT
vendor for a long range technology forecast).
Document long-term trend assumptions for your industry
and for IT. (By “your industry” we mean
your company’s industry.)
Do the “where are we” components of the plan
(competitive analysis, supplier and customer analysis, performance audit,
strengths and weaknesses).
Do the “where do we want to be” components of the plan
(vision, mission, goals).
Do gap analysis.
Do the “what do we do short term to move toward our
vision” components of the plan (architectural vision, application priorities,
capacity plan, training plan, organizational plan, advanced development plan,
Compile and publish throughout IT. Solicit feedback. Update, republish.
Sanity check with non-IT peers.
Review with top management.
Tasks above the dividing line have to get done; those below are
for extra credit.
There are some actions we recommend that you not take:
Do not ask permission.
(If your planning process is questioned, the answer is something like
“There are sea changes going on in IT, and so we need to look out into the
future to make sure what we’re doing short term won’t be a throwaway.”)
Do not ask for more budget.
Do not let anyone outside of your group become a
gate on the release of your plan.
Do not even hint that the rest of the company has done
something wrong by not having a strategic plan.
Do not blow a promised delivery because you’ve put a
critical project manager on the planning team.
Pick A Team
We’re starting with a premise that this planning process has to
move fast, which means there can’t be more than five people on the team. You’re one.
You’re not the process driver, because you want to be able to brainstorm
with the group, so you’re not allowed to hold the Magic Marker. The process driver will need project
management and meeting facilitation skills.
All four other team members will need to be assertive enough to tell you
[respectfully] when you’ve had a less-than-brilliant idea. One member should be known for getting
outside the nine dots, and one should enjoy slaughtering sacred cows. One member should be a first-rate
technologist, and one should really understand the company’s business. And one had better be able to write coherent
prose using the English language.
Your direct reports may or may not want to be on the team. They will certainly want someone “looking
out for them”. Go with it.
Pick A Methodology
If your company has no strategic plan, we assume it has no
approved planning methodology. You’ll
have to pick one. We strongly urge
orthodoxy. You should anticipate
“discussion” of your plan (at a content level) when it’s finished. The last thing you want to deal with is
“discussion” of your methodology as well, so you want to be able to show that
you used proven methodology, adjusted wisely for your environment, with rigor,
and without sins of omission.
We list below web links to several sources for strategic planning
methods. Most have a long-range time
horizon, and all are for corporate (vs. IT) use, so you’ll have to adjust
them. [Note: When you do your own
search, you will see a lot of processes designed for universities or
governmental units. Ignore those.] Also, the word “planning” in the Amazon
search engine will produce any number of books. Pick a method. Tune it
for your situation. Publish the tuned
version. Make sure the team understands
it. Make compliance a primary virtue in
Invest about a week in getting the team’s head out of “last
First, the whole team should read Stan Davis’ Blur
Perfect; they both deal in the radical changes that are going on in all
kinds of businesses, and the foundational role of IT will be easy to infer as
you read. Both books raise the issue of
information and services replacing “matter” in products. Think about the impact of Internet banking
on the consumer banking “product” – when’s the last time you physically wrote a
check? How likely are you to change
banks now that you have all your electronic bill-paying set up? Think about the information and service
content of the OnStar system in your Chevy Tahoe. Ask yourselves what the future implications are for your
company’s products. Ask what IT’s role
should be. Pick someone (not you) to
start the team’s first meeting with an “implications for us” presentation. Set aside time for (possibly heated)
Second, assign your two best “web-heads” to analyze how
your key competitors are using the Internet, and to prepare a competitive
status report for the team’s first meeting.
Third, assign a database guru and a skilled report
writer to an analysis of your company’s customer and supplier sets. How many suppliers are there? How many
suppliers does it take to provide 80-percent of the company’s sourcing. How many customers are there? How many customers does it take to provide
80-percent of the company’s revenue?
What demands have customers made for direct or Internet-based
system-to-system linkages? Have a
summary presented at the first team meeting.
(Note: These resources need not
be team members. They are input
providers.) Map the information flow
between your company and its suppliers and between your company and its
Fourth, assign your operations manager to provide an
operations audit of 2003 performance and a capacity plan for 2004, both to be
incorporated in the 2004 plan.
Fifth, assign your development manager to provide a
development performance review for 2003, and a first-pass application delivery
forecast for 2004.
Sixth, assign your tech support manager to write a
summary of architectural standards in place, with an evaluation of whether each
standard is still sensible in the context of emerging technology. Ask him/her to list architectural decisions
that should be made in 2004.
Do the “Where Are We” Components of the Plan
Review the input from the competitive analysis, supplier and
customer analysis, and performance audit teams. Assign a next draft. It
helps if there is resource that can go do these sections in parallel with team
Schedule a “strengths and weaknesses” meeting. There are two questions for this meeting:
What are the “strengths and weaknesses” of the IT
organization and its systems assets?
What are the “strengths and weaknesses” of the way your
company is using IT as compared to competition?
Do the “Where Do We Want to Be” Components of the Plan
(Trends, Vision, Mission, Goals)
This is the section of your 12-month IT plan where you put the
five-year planning assumptions you would usually get from the corporate LRP and
the IT LRP, neither of which exists.
This is also the section that’s the most fun for the team.
We strongly recommend that you schedule one or two days off
site. If you were in Tennessee, you
would do this in the lodge at one of the state parks (Spartan rooms, unreliable
phones, no cell phone service whatsoever, lots of fresh air, and lots of
simple, heavy food).
The first item of business is to document where the team believes
your industry is going over the next five years, and to articulate the role the
team expects IT to play.
The second agenda item is to document the team’s assumptions
about technology trends, and to record the ways that technology change can be
converted to competitive advantage.
Then on to vision, mission and goals. Every planning meeting this author has ever seen has wasted at
least one meeting in a completely non-productive argument over the definition
of those terms. The web is no
help. Go to six sites, and you will
accumulate six definitions. We offer
our own definitions, whose charm is mostly that they are semantically clear and
easy to enforce:
A “vision” is the dream of what you would like your organization to be. It is
a perfect future
state. It expresses hopes and
aspirations. A vision statement
always uses “state of being” verbs (e.g. “is”, “will be”, “can be seen as”,
statement describes what business you are in, why you exist, and how you plan
to execute. It contains
programs, initiatives and actions. A
mission statement always uses “action” verbs (e.g. “operates”, “distributes”,
“manufactures”, “designs”, etc.).
A “goal’ is a performance metric, usually numeric, for
each program or initiative in the vision statement. A “goal” always contains a measurement. For example “Improve user satisfaction with
data center service” is not a goal.
“Achieve an “exceeds requirements” response from 80% of data center
users to a survey designed and administered by a third party” is a goal.
Enforcement is easy.
A vision statement that includes an “action” verb needs to be
redone. A mission statement that
contains a “state of being” verb needs to be redone. A goal with no measurement needs to be redone.
We cannot over-stress the importance of letting your team
brainstorm during the development of the trends, vision, mission and goals
statements. You will be tempted to jump
in. If you jump in too early, you will
end up writing this section alone (unless the other team members are very
assertive). Confining yourself to
gentle Socratic questions during the first three hours of the meeting will be
productive in the long run.
Do Gap Analysis
If trends, vision, mission and goals are an enjoyable part of the
process, gap analysis is painful, and we suggest it not be part of the same
meeting. Ask the vision meeting
participants to think about the vision, and to send the process driver thoughts
about where the gaps lie. Let the gaps
accumulate in e-mail form, and then have a review meeting to see if all the
gaps have been spotted. You may want to
involve folks who are not on the team in the asynchronous part of the gap analysis.
Do the “What Do We Do in the Next 12 Months to Move Toward Our
Vision” Components of the Plan
At this point, if your line managers (operations, development,
tech support, et al.) have not been involved in the team, they must be brought
on board. This section of the plan will
commit them to goals for the short term.
After a kick-off to make sure goals are bought into at the 90,000-foot
level, this section can be parceled out to the line managers. Set a simple review and agreement process.
Compile and Publish
You want a document your staff can work to. You want buy-in from all of IT, so you need
a process where everyone can review and comment. You’ll want to update and republish, and the second version
should demonstrate that the team listened to the feedback.
You also want a document you can show to your non-IT peers to get
comment and insight. And you want a
document you can show to top management, and ideally, use as part of next
year’s budget process. So be sure to
bill the published document as a “living document,” and make it clear you want
help from outside IT in improving it.
Sanity Check with Non-IT Peers
OK, you’ve done the part you have to do. Now it’s time for “extra credit”. Get copies of your plan to peers. With each specific peer, call attention to
those issues in the plan you think affect him/her, or to assumptions where
you’d really like his/her insight. Try
to get a conversation going.
Review with Top Management.
We assume you (or your manager) are a member of the senior management
team. A casual mention of the plan and
an offer to review it should get it scheduled as an agenda item. Stress the business assumptions, and
graciously accept push-back.
Disagreements are truly helpful – they keep you in synch with
management. Agreements, even verbal,
are really helpful – they become part of the budget process.
Why Is This Less Than Ideal?
Let’s face it, most of us in IT look at the world through
IT-colored glasses. The long-range
“business” assumptions in this plan are going to be different than the business
assumptions (or planning guidelines) you’d get from marketing, engineering or
manufacturing management. You are
almost certain to have missed some key insights that might have changed your IT
plan. That is why it is so important to
get your non-IT peers accustomed to working on the plan with you.
Your first goal is “verbal alignment”…”Yep, this looks
reasonable” from a line (non-IT) manager.
If your senior management likes your plan and your process, in
the future you may have a corporate plan to align with.
Survival. You can’t run
IT with a quarterly horizon and achieve excellence, even with corporate
managers who have a quarterly horizon.
Your organization will know where it’s going and why.
Done right, you’ll get business thinking into your technology
Take this bull by the horns before he gores you.
Stan Davis, Christopher Meyer, Blur,
John Wiley & Sons, 1999.
Stan Davis, Ellie McCarthy, Future
Perfect, Perseus Publishing, 1996.
The Strategic Planning Process
Associates: Reinventing the Strategic Planning Process
About the Author
Wes Melling, TAC Expert, has over 40 years of IT
experience with a focus on enterprise IT strategies. Wes is founder and principal of Value Chain Advisors, a
consulting boutique specializing in manufacturing supply chain
optimization. He has been a corporate
CIO, a Gartner analyst, and a product strategist at increasingly senior
levels. He has held P&L
responsibility for a $2B systems business unit. Wes’ specific areas of expertise include the burgeoning arena of
supply chain event management, IT product strategies, strategic messaging and
end game management.