What Makes an IT Strategy 'Strategic'5

What Makes an IT Strategy 'Strategic'5

In Episodes 1 - 4 of this series, we have covered the general introduction to this Strategic Planning methodology as well as

  • the ‘Business Understanding’ phase - which reveals and incorporates the underlying business drivers for the process
  • the ‘Client Perspective’ phase - which obtains vital input from the firm’s clients
  • the ‘Review of Existing IT’ phase - from which we obtain all the source information we need about the current technology landscape in the firm, as well as how it is organised and managed.

[If you have chanced across this episode first, I suggest you go back to my article page and find Episode 1 and read the series in order. See Episode 1 here.

The next stage of the process, Phase 4 on this schematic, is the ‘Target IT Structure’.

No alt text provided for this image

This is where it starts getting a bit more complicated. Essentially, there is a period of analysis that takes as input all the information gleaned from the three phases so far and identifies all the potential business opportunities that can be gleaned as a result.

This myriad of ‘opportunities’ then needs to be coalesced into groups representing related or similar processes or initiatives.

At this stage one also needs to use expertise and knowledge to identify any additional initiatives that it is felt could give the firm competitive advantage in its key business areas, as well as identifying any gaps in the firm’s IT portfolio by comparison with industry ‘best practice’.

Finally, as mentioned in Episode 2, one also needs to consider including any relevant emerging technologies that are so significant that they may either have a disruptive impact on the firm’s business objectives, or which may single-handedly be responsible for novel business opportunities in their own right. These are the exceptions to the rule that all elements in an IT strategy should be ‘business driven’.

In practice this initiative identification and coalescence stage is a very scientific one that gets done by means of the use, ad manipulation of, dozens of yellow ‘Post-It’ notes.

Now you have a list of discrete potential IT projects or initiatives that are likely to have a positive impact on the firm’s ability to achieve its business objectives.

What might these IT initiatives encompass? They could be almost any remotely IT-related project or initiative, such as:

  • IT infrastructure projects: moving to Cloud, changing network topologies, outsourcing etc
  • application projects: upgrading or replacing systems, procuring new systems etc
  • pilot / proof of concept for innovative technologies
  • modifications to the firm’s working practices or processes designed to improve their effectiveness or efficiency in tandem with IT applications
  • management initiatives designed to improve the IT management function
  • management initiatives designed to augment the training in, and the more effective use of, IT applications.

Recommendations concerning the size, shape and disposition of the IT department would wait until the overall IT strategy is further defined so that one can ensure that such proposals take into account the full burden falling on the IT department from the final agreed set of IT projects.

At this stage, you will normally have more initiatives that any organisation could either afford, or have the other resources to execute, within any short to medium-term planning period. They therefore need to be prioritised.

For each potential project or initiative identified the firm needs to identify a senior user sponsor with whom a business case, or ‘information system proposal’ (ISP), will be prepared. In relation to any business or ‘coal-face’-related IT proposal this sponsor will need to be a suitable interested partner or senior manager; in relation to a support proposal it should be a suitably interested support director, and in the case of a pure ‘technology’ proposal it would be the CIO or a nominated representative. 

The ISP is essentially a mini-feasibility study and business case for each proposed initiative and covers:

  • a functional description of scope
  • an estimate of costs
  • the benefits expected
  • the impact on the business objectives
  • risks
  • urgency
  • integration and dependency requirements of the proposed system in relation to other current and proposed applications.

In more detail, each of these aspects will cover the following.

Scope

The functionality and deliverables to be covered by the proposed system or initiative; this needs to identify clearly what the initiative includes and what will be excluded. 

Costs

The required approach is to undertake a realistic (if anything, pessimistic) estimate of all costs that the firm is likely to have to expend in order to execute this initiative, and to ensure that the firm and the users are in a position to exploit its full potential usefulness. 

This means including the obvious costs – such as hardware and software; the less obvious costs – such as supplier implementation support, data cleansing and migration, project management, implementation consultancy, change management, training, any additional staffing requirements and so on.

There should therefore be no cost surprises for the business later. 

Other cost considerations that would need to be dealt with include non-financial management and IT resource requirements, the capital versus operating expenditure aspects of the project, as well as the phasing of the costs, the funding of the expense and the resulting impact on cash flow and the long term ongoing and lifetime costs of maintaining and managing the systems. 

A macro view of these latter cost issues is also taken on the costs of the strategy as a whole at the conclusion of the study. 

Benefits

The potential benefits of the projects will need to be reviewed with each ISP Sponsor; this will initially involve any identifiable tangible benefits such as reduced cost, cost avoidance, increased sales/income and increased margin/profitability. 

The objectives here are twofold; firstly, to be as prudent in the identification of realistic potential benefits as one is in identifying the potential costs, and secondly to ensure that the Sponsor is fully on board with the quantum of benefits taken forward into the strategic analysis. 

Having exhausted the realistic potential tangible benefits relating to each ISP, you then need to work with the Sponsor to identify the intangible benefits that are likely to flow from each initiative. These might include such things as quality and speed of client service, consistency of work output, the development of global enterprise tacit knowledge, the management of risk, increase of staff satisfaction and such like. Even where a financial ROI cannot be sustained, some projects will be deemed necessary as a matter of business judgment – and these intangible benefits are vital to that judgment. 

Business Impact

Another vital mechanism for judging the relative merits of the various ISPs is a review of the extent to which each project will assist in enabling the firm in achieving its strategic business objectives. 

This is achieved by working with each Sponsor to identify which of the firm’s “do-wells” (as prioritised by the Board in the earlier Business Understanding workshop) will be effectively facilitated by each ISP, and to what extent. 

A scoring and weighting exercise provides a mechanism for comparing the relative business impact of each of the ISPs. 

Risks

Together with the Sponsor you then need to identify the key risks that will be attendant in relation to each project. For each risk identified it is necessary to analyse the nature of the risk, the likelihood of the risk occurring, the likely impact of an occurrence, and what ameliorative steps should be put in place to mitigate any potential negative impact. 

This part of the exercise should cover both business risks (such as the ISP requiring enormous changes to working practices, having uncertain benefits, or requiring a global ‘big bang’ implementation); as well as technical risks (such as the adoption of leading-edge technology, or massive network performance requirements). 

Urgency

As well as risk, you should then review the relative urgency of each of the ISPs – whether that is a business urgency (such as a pressing need to meet a potential new client requirement); or a technical urgency, (for example, relating to a key support system that is proving unreliable or unstable). 

Integration & Dependencies

In order to aid the analysis of the scheduling of any proposed systems during the succeeding stages of the strategy, the integration requirements between the ISP and other current firm applications, as well as the other ISPs – and any operational dependencies between the same, will need to be identified.

It may be, for example, that the firm would wish to make use of some new application that is reliant upon some functionality in Microsoft Office 365, or wishes to develop a key knowledge management initiative that is dependent on procuring a new document management system.

ISP Summary

The ISP analysis then needs to be gathered, documented and key elements presented in a tabular form to allow the strategy team and management to take a view on the relative business merits of each of the proposed ISPs as a whole.

The second part of this step is concerned with deciding how the proposed applications are best delivered in terms of:

  • software
  • systems architecture (type and design of networking solutions / on-premise / outsourced)
  • hardware and telecommunications
  • IT function resources and firm (e.g. centralised or distributed).

This is accomplished by developing and comparing a number of options containing each of the above elements. The options may also mean that a different level of benefits is achieved, or the timing is altered. The options are then discussed with IT management together with any significant migration issues.

The benefits of this step are to establish those applications which are both cost-effective and support the business objectives and consideration of a wide range of technical options for the provision of information systems to the firm.

At this stage, very likely, there will also be a number of 'Quick Wins' to be fed back to the IT team - these will usually be relatively small technical issues that have been causing a disproportionate degree of inconvenience to the firm's users, and which can easily be fixed.

Summary

We now have all the raw input and baseline information we need and can start assembling the strategy – this begins in the next episode in this series: the Target IT Structure.

Jump to Part 6...

To view or add a comment, sign in

Insights from the community

Explore topics