How do you draw up an IT master plan?

The IT master plan is a key “foundational” document within an IT department; while developing it is no small task, its outcome carries significant implications: it defines the IT department’s strategy in relation to that of the company and serves as an indicator of the IT department’s position within the organization. Do you need to develop an IT master plan? Here are some tips for successfully completing this strategic exercise.

What is a master plan?

The IT master plan is a reference and summary document that describes how the organization’s (public or private) strategy applies to the IT department. It therefore provides a roadmap for what the information system will or should be in the future (typically over a 3- to 5-year horizon), as well as the resources needed to achieve this goal (including personnel, Budgets, processes, Projects, etc.).

Its primary purpose is therefore to provide direction and a vision of the goals toward which all projects and activities carried out within the IT Department should strive and work toward.

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 any case, the master plan is a way to anticipate the future, to lift our gaze from the day-to-day and see further ahead. In particular, it will enable us to plan, at a macro level, the strategic projects and investments that will be entrusted to the IT department. And, from a very practical standpoint, it will help align the myriad “small projects” that will need to be addressed anyway, distinguishing between those that are crucial for achieving the goal and those that are more peripheral.

Beyond the Roadmap it outlines—which will be frequently referenced in the years following its adoption—we must not lose sight of the fact that a master plan often reveals the role the IT department plays within the organization. This is what makes it 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 common) or “overlooked” by other stakeholders, this is a sign that the IT department is still on the sidelines and is largely viewed as a support function; it then serves as a Roadmap for the CIO to steer his or her department and shape the way information systems are built.

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, Budgets, Communication and, of course, Planning. In this respect, we recommend phasing in the major stages, and setting 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^first step will help identify IT challenges in relation to the company’s strategy. In a changing environment, the IT department finds itself “at the heart of the system” (business, customer relations, regulatory compliance and regulations, operational efficiency, etc.). The key challenge, therefore, is to identify the guiding principles upon which everything else will be based, while 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.
• to ultimately result in the establishment of IT guidelines (generally between 5 and 10) that should 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 preliminary phase can be supplemented by an internal audit: by interviewing stakeholders—particularly members of the executive committee—you will gain a clearer picture and a better understanding of the needs of the IS’s users and beneficiaries (especially the business units), you’ll be able to assess the IT department’s current and desired role within the company, its expectations in terms of value creation, and so on. This active listening can be particularly valuable when taking on a new role, for example, to help you gauge 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 by an opex/capex analysis, cf. Opex/capex – Capital Expenditure – analysis, see this article.); it is also interesting to compare with market benchmarks.
• Project portfolio already underway, with a weather forecast of projects.

Target principles

At this stage, we will establish and record :

• The DSI’s 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 enable us to 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: featuring major phases and a timeline for priority initiatives (and related Projects).
  This multi-year presentation (for example, in Gantt chart format) can be supplemented with a more detailed breakdown for the coming year. This program 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, drawing up a master plan was a rather “rigid” commitment: this strategic summary document provided the IT department with a multi-year roadmap of all the Projects, how they were to be built, with what objectives, and 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 Agility master plan will enable us 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 Agility approach, so as to address all the issues and objectives set out in the IS strategy.

One final point: We must at all costs avoid a “tunnel vision” effect, which would involve mapping out the entire IT department’s roadmap at the outset of the master plan. Instead, we must reserve ample capacity for business and operational projects that will drive short-term performance and emerge as we go along. A pragmatic, non-dogmatic approach 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 steers it. Nevertheless, you would also be well advised to expand the group of employees who will contribute to its development (beyond simply listening to all stakeholders during the diagnostic phase, as discussed earlier):

• ^First and foremost, your teams, 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, you should also designate and identify a pilot in charge of each one; this will be key later on in 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 planning, with a view to completed projects and schedules that have been met or revised (and new emerging projects).

5/ Don’t neglect communication around the master plan

Developing an IT master plan is a project in and of itself, and like any project, it’s important not to overlook communication. It is, in fact, a powerful tool for explaining to the entire organization (company or institution) the challenges the IT department is preparing to tackle 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.

One final related tip: once the substance has been established, don’t overlook the form, as a large part of the evaluation will hinge on it: The master plan is, in and of itself, a communication tool, and its sharing and adoption should not be overlooked, as they will, in a sense, set the standard for future initiatives; so it’s worth refining its presentation (for example, by creating more accessible abstracts or summaries) to help promote the IT department.