By Nicole NOGUER
Nicole Noguer is an experienced Chief Information Officer (CIO) with more than 30 years of experience across both the public and private sectors. She served as CIO of the Bourgogne-Franche-Comté Regional Council from March 2020 to December 2023. During her nearly four-year tenure, she led a comprehensive IT department audit, defined and managed the region’s IT master plan (covering 100 planned projects), implemented the Information Systems Security Policy (ISSP), deployed Microsoft Office 365, and modernized both financial management and regional grant management processes.
Prior to that, she served for more than seven years as Director of Digital Services and Innovation at the Doubs Department. Today, she works as an interim CIO, supporting organizations through periods of transformation. Most recently, she assisted the City of Meaux and the Meaux Urban Community at the end of 2024.
“The Chief Executive wanted things to work again. I proposed an IT master plan.”.
By Hubadviser – Exclusive interview
Foreword
Introduction
There is a growing belief among CIOs that the IT master plan has become outdated. Too long, too complex, and too uncertain. Organizations spend months producing a fifty-page document that is already obsolete before it is even approved. Better, some argue, to focus on urgent issues and move forward one project at a time.
I do not share that view. My experience at the Bourgogne-Franche-Comté Regional Council only reinforced this conviction, even though the conditions under which I launched the IT master plan were far from ideal.
When I arrived, the IT department had been struggling with operational issues for far too long. Outages were recurring. Users were frustrated. Executive management had lost patience. My mandate was clear: conduct an audit, stabilize operations, and propose an action plan. No one expected me to talk about strategy.
Yet that is exactly what I did.
The Chief Executive’s reaction was predictable. He agreed to the initiative, but during the first steering meetings, while operational issues continued to surface, I could sense his doubts. From his perspective, we were spending time discussing strategy when we should have been tightening the bolts and fixing what was broken.
Many CIOs have faced this moment. And many step back. They tell themselves: first stabilize operations, then think about strategy. I believed that was the wrong sequence.
I knew exactly where we were heading. The operational recovery effort—a robust action plan built on the audit findings—was already underway. However, meaningful improvements would inevitably take time before becoming fully visible.
At the same time, I was convinced that both initiatives could move forward together: strengthening day-to-day operations while building a strategic vision for the future.
The reality is that operational improvement and strategic planning are not contradictory; they are interdependent. An IT master plan helps determine what must be fixed first, where investments should be made, and what can reasonably be postponed. Without a strategic direction, continuous improvement becomes little more than a series of isolated fixes. Problems are addressed without knowing whether they are the right ones to solve.
Holding that position requires confidence, especially when executive management is demanding immediate results. It requires believing in the value of an IT master plan, even while knowing that not everything written in it will ultimately be delivered.
An IT master plan is not a contract. It is a direction of travel.
And that was precisely what was missing.
Part 1 - Making an IT master plan successful
The pitfalls that cause most IT master plans to fail
An IT master plan can fail in many ways. And most of those failures are entirely predictable.
The first pitfall is outsourcing the exercise completely to a consulting firm. The consultant brings the methodology, facilitates the workshops, and structures the discussions, that is their value. But if the CIO does not lead the process personally, the final document belongs to no one. Not to the business departments, because they do not feel ownership of it. Not to the IT department, because it did not build it. Not to executive management, because it does not believe in it. An outsourced IT master plan is an IT master plan that is dead on arrival.
The second pitfall is consulting business stakeholders without truly engaging them. Gathering a list of wishes is easy. It produces unrealistic project portfolios and frustrated departments when prioritization decisions are eventually made. What matters is guiding business teams through a structured reflection process: first assessing their current situation, then discussing their strategic ambitions, and only then identifying their needs. In that order.
The third pitfall is failing to establish governance. An IT master plan that ends with a polished document and no operational follow-through is worthless.
The day after it is presented, it already starts to become outdated. If there is no plan for how it will be maintained, updated, and integrated into an ongoing dialogue with business stakeholders, then the organization has simply spent money on a PowerPoint presentation.
The fourth pitfall is engaging the wrong level of management. Department directors must be involved, not only their direct reports and operational teams. An IT master plan that bypasses decision-makers will never produce meaningful decisions.
What I did to avoid these pitfalls
I led the IT master plan myself. Delegating it or leaving it entirely to a consulting firm was never an option. For six months, I devoted up to half of my time to the initiative. It was demanding, but that is the price of ownership.
I selected the right consulting partner. My criteria were straightforward: proven experience with IT master plans and a strong understanding of regional government organizations. What also made a difference was the delivery model. We worked with an experienced engagement director who remained involved from start to finish, rather than a large team where a senior consultant appears occasionally while junior consultants handle most of the work. We met every week and continuously adjusted our approach.
I involved every department without exception. Not only those that were already working closely with the IT department, but all of them. In every organization, there are departments that have never really engaged with IT. These are often the teams that develop their own solutions, create shadow IT environments, or build workarounds. The IT master plan forced them to come to the table. In many cases, they had significant needs that nobody had previously heard about. To secure their participation, I personally presented the initiative to the management committee. The Chief Executive gave me the floor, which carried weight. The directors themselves were expected to attend, not just their teams.
I built governance requirements directly into the statement of work. A prioritized roadmap, explicit prioritization criteria, and a long-term review and update process were all defined as mandatory deliverables, not optional additions to be considered later. In practical terms, this meant quarterly meetings with each business area, project dashboards to monitor progress, and designated IT representatives within every department.
I presented the roadmap to the management committee. Just as I had presented the launch of the initiative, I also reported back on the outcomes. An IT department should not produce a strategic document in isolation. It must report back to the organization that contributed to its development.
I do have one regret. At the beginning of the project, the consulting firm prepared a presentation intended to engage executive management. I did not review it before it was presented. It was not up to the required standard. The lesson is simple: review every deliverable that will be presented to executive management, regardless of how much confidence you have in your consulting partner.
Part 2 - Improving IT department performance
The burdens holding us back
Before talking about what we implemented, it is important to explain what we found. Because many IT departments face structural challenges that are often inherited and rarely acknowledged.
There was no standardized workplace policy. Following the merger, two technical environments continued to coexist: traditional desktop environments on one side and virtual desktop environments on the other. Two architectures, two deployment models, and a support team forced to manage both. It was incredibly time-consuming.
There was also a lack of structure around IT support. Not all incidents were logged. The ticketing tool had been selected without a formal requirements process, essentially by reusing an existing version without any real consideration for workflows or operating procedures. Under those conditions, it was impossible to understand where issues originated, let alone address them in a systematic way.
There was no measurement of user satisfaction. The IT department operated without knowing how it was perceived and without any baseline against which progress could be measured.
Above all, there were internal divisions. Technology debates had become ideological battles. The choice between traditional desktops and virtual desktops had created opposing camps within the team, shaped by strong convictions, years of conflicting experience, and an inability to reach a collective decision. This type of deadlock is common in IT organizations: decisions remain unresolved because no one wants to deal with the dissatisfaction that inevitably follows.
Eventually, a decision had to be made. In the end, COVID forced the issue. The large-scale deployment of video conferencing for remote work simply did not perform adequately on virtual desktop environments. Traditional desktops prevailed because of real-world usage, not theoretical arguments. Yet even with clear evidence supporting the decision, some critics remained.
That experience taught me something important: you will never convince everyone. Spending energy trying to win over the most determined opponents is often a losing battle. It is far more effective to rely on the people who are ready to move forward and build momentum with them.
What we implemented and the impact it had
Before launching any initiatives, I conducted a satisfaction survey across the entire organization. We assessed equipment, applications, IT system performance, day-to-day support, the IT department’s contribution to projects, governance, and communication. We established baseline scores for each area. The objective was simple: repeat the exact same survey at the end of the transformation to measure what had genuinely changed, rather than what we believed had changed.
Alongside the IT master plan, I led an internal transformation program within the IT department. Despite the executive team’s initial position that no new roles would be created, two positions were ultimately established: a Chief Information Security Officer (CISO), a role that did not previously exist, and a governance and architecture support role responsible for enterprise architecture and the coordination of governance bodies. Both individuals joined the leadership team and fundamentally changed its dynamics.
Standardizing workplace environments simplified day-to-day operations considerably. Communication also played a critical role. We introduced a regular newsletter covering IT department activities and systematically shared survey results with users. On paper, these actions may not seem particularly remarkable. In practice, they significantly improved how the IT function was perceived across the organization.
Support dashboards took the longest to implement. It was a real uphill battle: incidents were not consistently logged, the original tool selection had been poor, and the underlying processes had to be redesigned from the ground up. We eventually got there, but much later than expected. The key lesson was clear: processes come first, tools come second, never the other way around.
Three years after launching the audit, we repeated the same satisfaction survey. Every area had improved significantly: governance, communication, and perceived IT performance. Even dimensions that had not been problematic at the outset showed measurable progress.
Most importantly, these results came from the users themselves. Not from an IT department congratulating itself on its achievements.
That is the only measure that truly matters.
Conclusion - Don't isolate yourself
For IT departments operating under pressure, there is a strong temptation to retreat into day-to-day operations. Managing incidents, maintaining systems, responding to requests. Pushing anything that resembles strategic thinking to a later date.
That is a mistake. Paradoxically, this retreat is often what creates the most serious problems. Without a strategic vision, prioritization becomes impossible. Investments are made in the wrong areas, symptoms are addressed while root causes remain untouched. Without a shared direction with business stakeholders, it becomes difficult to secure sponsorship for modernization initiatives. Without strong engagement across the organization, it is equally difficult to keep teams motivated. The best talent does not stay in an IT department that is focused only on itself.
An IT master plan is not a theoretical exercise. When an organization has not had one for a long time, or has never had one at all, it is important to invest in a comprehensive, structured, and ambitious approach. It is a significant undertaking, but it lays the foundations for years to come.
Once that foundation is in place, the IT master plan becomes a living process. It must be actively managed, challenged, and updated every year. The environment evolves. Political priorities shift. Budget constraints change. New technologies create new opportunities. An IT master plan that is not regularly updated quickly becomes obsolete. The governance framework established from the outset, regular meetings with business stakeholders, project dashboards, and steering committees are precisely what keep it alive without having to start from scratch every time.
A CIO must always remain a strategist. An IT master plan and continuous improvement are not initiatives to be launched only when conditions are ideal. They are part of the operating discipline of a high-performing IT organization.
And it is by sustaining both over time, simultaneously and consistently, that an IT department becomes a truly influential function within its organization.
Four key lessons
1. Do both at the same time. Continuous improvement and an IT master plan should not be treated as sequential initiatives. They reinforce one another. The IT master plan provides the strategic direction that determines where operational improvement efforts should be focused first.
2. An IT master plan without governance is not an IT master plan. A prioritized roadmap and a framework to keep it alive are not optional. They are fundamental requirements that must be built into the statement of work from the very beginning.
3. Measure before acting, and measure again afterwards. Conduct a user satisfaction survey at the start and repeat the exact same survey at the end. It requires a degree of courage because you have to confront the reality of what users think. But it is also the only reliable way to prove that meaningful change has taken place.
4. An IT master plan is not a document produced every five years. It is a strategic direction that must be reviewed continuously. This does not mean conducting a full-scale exercise every year. A lighter annual review is often enough to keep it aligned with reality. Priorities change, constraints evolve, and new technologies create new opportunities. An IT master plan that is not updated becomes an obstacle rather than a tool. Strategic agility requires ongoing maintenance.
“An IT master plan without a project portfolio is not an IT master plan. I’ve seen a few of them. They belong in the trash.”
