Adventure is just bad planning" observed Roald Amundsen, the renowned Norwegian explorer. Good strategic planning processes seek to avoid unintended consequences. They firmly focus on the destination and develop means of getting there with certainty.
Economic indicators point to continued cost restraint in most sectors. Having a coherent, business-supported IT strategic plan (ITSP) is essential for ensuring that IT investments get over the line.
Most IT departments carry out strategic planning irregularly. Unintentionally, they may prepare a plan that does not resonate with its business or technical audience. Some common ITSP pitfalls are:
1. Ambition unmatched by capability or capacity: The worst planning mistake is to be overly ambitious with new initiatives that cannot be realistically executed on time.
Assessments need to be made of the capability of the business to absorb change and the availability of change agents to facilitate it. IT is the same: will new technologies need to be assimilated, then supported? Is the IT mature enough to carry out ambitious projects?
Also, if there are other initiatives running, will executives be available for project-related activities while also fulfilling their day jobs? Unrealistic plans are soon maligned, then sidelined and their authors brought to account.
2. Missing business-enablement magic: The best ITSPs uncover new initiatives that deliver competitive advantage and inspire staff. This is the holy grail of any strategy and the focal point for a plan's internal marketing.
Competitive advantage also applies to the non-profit sector, where advantages improve stakeholder satisfaction or streamline cumbersome processes. If the plan becomes a bland list of everyday projects and does not give rise to an " 'aha!' moment" or two, it probably needs more development.
3. Tail wags dog: An ITSP needs to reflect organisational aspirations, not dictate what business strategies should be. This can be challenging if the business or divisional vision is nebulous.
Running ITSP workshops may lead to awkward moments and cause discomfort to uncommitted executives. To gain traction, it may be necessary to hold informal, pre-workshop meetings with specific business users.
Provide well-researched data on business-sector technology trends and link them to expected benefits.
Avoid having IT reverse-engineer business strategies. This is a perfect case of the tail wagging the dog and is likely to cause strong push-back from the business.
4. Unrepresentative: It is a mistake to only seek involvement at the chief executive level, but good plans are developed bottom-up as well as top-down. Nowadays, many business users are well-versed in technology and less risk-averse than their IT counterparts.
Also, don't overlook contributions from subject experts who often reside in lower organisational tiers within the business and IT.
5. Verbal bloat: In consulting assignments, I've seen lengthy prologues with background data and discussions on project prioritisation. Worse is when ITSPs have morphed into technical strategies, aimed only at a technical rather than business audience. Where warranted, develop an IT technical strategy to supplement the ITSP.
An effective ITSP should be easy reading for a business audience. Ideally no more than 30 to 40 pages. It should be supported - for internal marketing - with a precis of one to two pages, providing, in effect, a "plan on a page".
6. Value management governance bypass: The ITSP needs to be linked to existing value management processes. Usually based around IT portfolio management or its broader organisational equivalent, requirements include:
- Clearly defining expected quantitative (including any key IT performance improvement metrics) and qualitative benefits and the executives responsible for their delivery;
- Establishing formal review processes for monitoring the delivery of value.
7. The ITSP process is run on a start-stop basis, not as a continuum of activities: Organisations with mature approaches to ITSP development don't simply kick it off from a cold start every three years or whenever a new ITSP is due.
Rather, they utilise value identification and creation processes that operate on an ongoing basis with good research and development. The R&D should be focused on identifying technology and process opportunities, carrying out market scans then running pilot projects to test business-enabling technology.
When appropriate, it then becomes simple to plug the most promising R&D candidate projects into the ITSP.
8. No supporting IT architecture: A defined IT architecture is an essential adjunct to an ITSP, especially in organisations in which business users become enamoured with particular solutions. To prepare an ITSP without an architectural backdrop is to risk having to deliver an incompatible mix of application software and infrastructure, with the attendant issues of cost, maintainability and risk.
Rob Mackinnon is an adviser with IBRS. Email comments to firstname.lastname@example.org
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.