How to draw up an IT master plan?

The IT master plan is an important “foundation” document in an IT department. While its preparation is no mean feat, its completion is just as high-stakes: it commits the IT department’s strategy to that of the company, and acts as a revealing indicator of the IT department’s position within the organization. Do you need to draw up a master plan? Here’s how to make a success of this strategic exercise.

What is a master plan?

The IT master plan is a reference and summary document that describes how the organization’s strategy (public or private) applies to the IS department. It thus enables us to project what tomorrow’s IS will be or should be (frequently, within 3 to 5 years), as well as the means required to reach this objective (in terms of resources, budgets, processes, projects, etc.).

Its primary vocation is therefore to set a course, a perspective of what all projects and activities within the IT department should be aiming for and moving towards.

There is no single model. Its development depends on the context of the company or organization in which it fits. You may come across :

• Master plans that are highly “business” oriented, in the context of companies with major transformation challenges, such as external growth; in this case, they are closely linked to the company’s strategy.
• Others are very “technology” oriented, focusing more on how to build the information system (IS) and its urbanization.
• Mixed models integrating these two dimensions.

Why draw up an IT master plan?

Some public or private sector organizations are governed by multi-year strategic plans, and the IT department is no exception to the rule: the IT master plan can therefore be seen as the translation, applied to the IS, of this more global corporate project.

Other contexts can be conducive to the development of a master plan, such as the arrival of a new employee, or a change in the company’s scale, such as an external growth operation requiring the merging of two previously independent information systems.

In all cases, the master plan is a means of anticipating the future, of looking beyond the daily grind. In particular, it will enable macro-planning of the structuring projects and investments that will be entrusted to the IT Department. And, very pragmatically, to align the myriad of “small projects” that will have to be addressed anyway, by separating those that are crucial to achieving the target from those that are more peripheral.

Over and above the roadmap it lays out, which will be referred to frequently in the years following its adoption, we must not lose sight of the fact that a master plan often reveals the place occupied by the IT department within the organization. That’s why it is so strategic:

• If the IS is a nerve center within the company, fully integrated into the strategy, the master plan will be all the more important as it affects the business, professions and operations, with strong expectations for return on investment.
• If it is absent (which is still frequent), or “little looked at” by the other stakeholders, this is a sign that the CIO is still on the bangs, and considered more as a support function. It then serves as a roadmap for the CIO to steer his department and drive his way of building Information Systems.

How do you go about it?

Drawing up an IT master plan is a major undertaking, and generally takes between 3 and 9 months to complete. To ensure its success, we recommend that you treat it as a project in its own right, to which you apply a true project management methodology: resources, budget, communication and, of course, a schedule. In this respect, we recommend phasing in the major stages, and positioning validation milestones equivalent to presentation, discussion and arbitration sessions in management bodies. Step by step, the “repository” will thus be enriched until it is complete and definitive. Two main structuring phases can be identified:

Step 1: Strategic analysis

This ^1st step will determine the IT challenges in relation to the company’s strategy. In a changing environment, the IT Department is “at the heart of the system” (business, customer relations, compliance and regulations, operational efficiency, etc.). The challenge, therefore, is to identify the guiding principles on which everything else will be based, ensuring that they are aligned with the company’s strategy.

In practical terms, how do you go about this retrospective and forward-looking stage?

Firstly, by maintaining a “high-level” vision, free from the contingencies of the existing IS. To do this, it is advisable to take into account both :

• The company’s strategy for the next 2-5 years: its environment, its ambitions, its positioning. This analysis can be carried out by means of a “classic” SWOT analysis, for example during a workshop with the management committee.
• The challenges faced by the company’s various Sectors in order to exist and develop; this is a way of integrating business issues into the thinking process.
• IS strategy: this is based on the IT environment (its changes on a macro level), coupled with technology watch, for example.
• and, finally, the establishment of IT guidelines (usually between 5 and 10) to cover the entire scope addressed by the IT Department.

This ensures that business challenges are transposed into IT challenges, while maintaining their strategic alignment with the company’s overall challenges.

In addition, and depending on your internal context, this upstream phase can be supplemented by an internal audit: by questioning the stakeholders, and in particular the members of the management committee, you will gain a better vision and understanding of the needs of IS users and beneficiaries (in particular the Business Units), you will be able to assess the current and desired place of the IT Department within the company, its expectations in terms of value creation, etc. This active listening can be particularly interesting when taking up a new post, to enable you to take the pulse of how the IS is perceived within the company. This kind of active listening can be particularly useful, for example, if you’re about to take up a new post, to get a feel for how the IS is perceived within the company.

Stage 2: Operational implementation of the master plan

On the basis of the major findings and initial orientations, this operational phase will enable us to establish the main operating principles and associated resources for delivering a roadmap. This phase also involves several stages, which will be presented and submitted to arbitration, with an increasingly concrete and operational dimension:

Diagnosis: at this stage, it’s time to compare the chosen strategy with reality. Drawing up a complete inventory and a precise analysis of the existing situation will enable us to understand the starting point and measure the gaps with the target. This overall mapping must be exhaustive, covering IS architecture aspects as well as functional, technical and organizational dimensions, and thus enable us to assess :

• The IS itself: data architecture, applications, service levels, security and risk management…
• Its organization and processes.
• The role of teams: skills assessment, staffing, outsourcing, organization, training needs, hiring, retention, etc.
• Budgets (which, depending on the company’s financial policy, can be enriched with an opex/capex analysis). opex/capex analysis, see this article); it is also interesting to compare with market benchmarks.
• The portfolio of projects already underway, with a project weather forecast.

Target principles

At this stage, we will establish and record :

• ISD target mapping
• Recommended technological choices (cloud, languages, etc.)
• Team size and organization (including planned recruitment and/or use of subcontractors, if necessary)
• Identify the strategic projects that will help build and achieve the target IS to meet the company’s priority challenges.

The means (the trajectory)

These last stages are the most concrete, since they orchestrate the action plan to be implemented. We present :

• The IT department’s roadmap for the duration of the master plan: with major sequences and a phasing of priority projects (and related projects).
  This multi-year presentation (in Gantt format, for example) can be coupled with a more detailed zoom on the coming year. This programming takes into account any interdependencies, as well as available resources.
• A budget summary

Example of the organization of a typical master plan :

In the age of agile, is a master plan still relevant?

Traditionally, the drawing up of a master plan was both binding and, in a way, rather “rigid”: this strategic summary document provided the IT department with a multi-year roadmap in which all business projects were included, along with how they were to be built, with what objectives, and in which direction.

While this approach has the advantage of providing a very clear and precise medium-term framework for the entire company, it has the disadvantage of creating a tunnel effect that is hardly conducive to agile management. This is a major disadvantage in uncertain contexts, brought about either by the instability of the external environment, or by the need for the organization to be swift and reactive to deal with the unexpected.

To take account of this underlying trend, it is essential to incorporate this uncertainty and the need for flexibility into the very design of master plans. Otherwise, there is a great risk that their relevance and “validity” will rapidly erode. It’s true that their vocation is to set out a long-term perspective that sets a course and maps out the situation towards which we must strive. But from now on, we need to consider them as a compass, and be ready to re-evaluate the trajectory each year according to the hazards, unforeseen events, trade-offs and new priorities that may emerge.

Thus, in the roadmap it establishes, the agile master plan will make it possible to plan and subdivide the various projects, to give the “color” of their construction and conduct (with such and such a technology, such and such a method, etc.) but above all to assume the task of leveling out the projects between those that are fully contributing to the target and those that need to be carried out more rapidly with the systems in place at the time. A complementary approach consists of orchestrating several “small projects” and iterating through consecutive sequences in a true agile approach, so as to address all the issues and objectives set out in the IS strategy.

Last but not least, it’s vital to avoid the tunnel effect of setting out the entire IT department roadmap with the launch of the master plan. On the contrary, we need to leave plenty of room for business and operational projects that will drive performance in the short term, and which will emerge as we go along. A pragmatic rather than dogmatic vision must prevail in agile master plans.

Five golden rules for a successful master plan

1/ Never lose sight of the fact that a strong (and therefore impactful, sustained) master plan is driven by the company’s strategic stakes (whether they be business stakes of growth or more defensive stakes of resilience) and not by IT considerations; it is because it is designed to place the information system at the heart of the organization that it will gain its strategic place, establish itself as a reference base and facilitate the maintenance of ongoing investments over time to bring it to a successful conclusion.

2/ Establish and propose alternative scenarios

This advice is not specific to master plans: giving the choice is often a good “ploy” to win a decision, as the decision-maker becomes the actor in the decision. It is therefore advisable to propose several scenarios in a master plan, which can be either trend-setting, innovative and more disruptive, or compromise. This can be applied to the strategy as a whole, or you can focus on a particular issue and submit several possible orientations to the decision-makers for their consideration: this solution has advantages and disadvantages, at this cost, etc. This way, you can explain and share the possible options. In this way, explaining and sharing possible options at a very early stage helps to prepare the ground for future decisions, respond to objections, enable you to explore questions in greater depth and explore alternatives between the various decision-making bodies.

The simple fact of explaining the pros and cons of different options, of showing that several paths are possible, that there is no single right answer, is proof that adopting a master plan means assuming a bias (or biases) and sharing responsibility for this decision.

3/ Be open and collaborative in the development process

It goes without saying that a master plan bears the strong imprint of the CIO who pilots it. However, it is also in your interest to open up the circle of collaborators who will contribute to its elaboration (beyond listening to all stakeholders during the diagnostic phase, as seen above):

• ^First and foremost, your team, and in particular your managers: it’s their roadmap for the next few years that’s being drawn up. Involving them at an early stage is the best way to get them on board, to give them a sense of direction, but also to take account of their experience and feelings. If your master plan establishes a certain number of priority projects, remember to designate and identify a pilot in charge of each one; this will subsequently be key to steering the implementation of the plan as the exercises progress. It will also be key to rallying teams around the implementation of the plan, initiating the first projects and implementing the first decisions.
• Why not call in an outside consultant: it’s not uncommon to enlist the services of an external consultant to help draw up the master plan. In addition to freeing up time for this structuring but time-intensive activity, the contribution of an external viewpoint is above all a lever for opening up the field of possibilities, gaining access to data, benchmarks and third-party solutions, and challenging the existing situation with an external, neutral viewpoint, free frompreconceived ideas and resistance to change, and therefore more likely to get things moving.

4/ Don’t assume that the job is done when the master plan is validated: it’s true that drawing up a master plan is a lengthy process (3 to 9 months on average), and the temptation might be to consider the mission accomplished once the document has been validated. This is far from the case. It has to live over time, and it’s vital to revisit it periodically (at half-yearly milestones, for example) to take stock and report on its progress, and to reassess what needs to be reassessed, if necessary.

These are the points we recommend you address in an interim review:

• Background and highlights of recent months
• Critical” feedback on alignment with the strategic axes of the IS initially established: are they “on track”, do we need to qualify, re-evaluate to rectify the situation?
• Review and forecast of major projects: achievements, strengths, difficulties encountered, next structuring steps, trends
• Review of the roadmap in terms of scheduling, with a perspective of completed projects and schedules kept or revised (and new projects emerging).

5/ Don’t neglect communication around the master plan

Drawing up an IT master plan is a project in itself, and like all projects, it’s important not to forget about communication. It’s a fantastic tool for explaining to the whole organization (company or institution) the challenges the IT Department is about to take up, and the role it intends to play in the coming years.

From the kick-off – the announcement of the development process, which serves to raise awareness – to the benchmarks to be shared at each key stage, right through to the final validation of the master plan. For each one, it’s important to put yourself in the target audience’s shoes: in order to be understood, convinced or adhered to, the audience must first and foremost be able to follow us, and to do this we must systematically think about adapting to our audience, even if it means simplifying certain concepts, thinking about clarifying certain issues and above all avoiding jargon.

Last but not least, once you’ve decided on the substance, don’t neglect the form, which will play a large part in the evaluation: the master plan is in itself a communication medium, and sharing and appropriation of it should not be neglected, as it will in a way be authoritative in the means to come. It’s therefore worth working on its own form (for example, making more accessible abstracts or summaries) to contribute to the marketing of the IT department.