From Four Months to Two Weeks: How I Rebuilt IT Planning to Make Transformation Possible

A mature IT organisation can still have an immature planning model.

That was the uncomfortable truth.

This was not a failing IT organisation. Far from it. We had been managing shared services for several years. We had consolidated data centres into central computing hubs for the company. We had a robust cybersecurity organisation protecting data assets across the enterprise. We had a scaled global network solution spanning regions, sites, and business operations. We had technical teams that knew their domains and had built credible, enterprise-grade capabilities.

But maturity creates a new problem.

Once the foundations are in place, the question changes.

It is no longer simply, “Can IT provide stable shared services?”

It becomes, “Can IT help the business transform?”

That is where the old model started to strain.

Several major transformation demands were building at the same time. The OT organisation was trying to create cloud-based services at scale. Endpoint management needed to be centralised under one umbrella. ERP and other major business platforms needed to be revamped to support upcoming structural business changes. Data, security, cloud, architecture, integration, and operating model decisions were becoming increasingly connected.

Some of these were long-standing, festering requests that we had struggled to move forward.

Others were new and looming.

All of them mattered.

And all of them exposed the same issue: the organisation had strong technical capabilities, but it did not yet have a planning and accountability model capable of managing business transformation across functions.

The Annual Operating Plan made that painfully visible.

Corporate IT owned the AOP for a $400M IT budget and more than 70 shared services. Business Units needed enough visibility to integrate IT priorities into their own plans and update budgets. Finance needed allocation logic. Leadership needed confidence. Each technical domain needed roadmaps, financials, dependencies, and presentations.

Lots of presentations.

The process tied up more than 300 people for roughly four months every year.

For a mature IT organisation, that was not just inefficient. It was a warning sign.

The organisation had become very good at describing services, budgets, and technical plans. But the next wave of work required something different: shared ownership of outcomes, cross-functional decision-making, business-led roadmaps, value-based prioritisation, and an operating rhythm that could handle change.

The old planning model could manage the annual story.

It could not manage the transformation.

The Annual Plan Had Become the Work

The planning process had a familiar rhythm.

Management teams disappeared into planning sessions. Key contributors were pulled away from delivery. Presentations were created, reviewed, revised, challenged, reworked, and reviewed again. Large forums were convened in the name of alignment. The same story was told repeatedly, each time slightly sharper, slightly more polished, and slightly further away from the operational reality it was supposed to represent.

The view looked six to eighteen months ahead, but business reality refused to stay still.

Business conditions changed. Priorities shifted. Emergencies appeared. Regulatory pressure moved. Structural changes loomed. Dependencies surfaced. Capacity assumptions became questionable.

By the time the plan was complete, parts of it were already out of date.

The issue was not the quality of the people.

The issue was the design of the system.

We were asking an annual planning process to solve what was really an operating model problem. And that made real transformation almost impossible to move at pace.

The Old Model Could Describe Activity, But It Could Not Manage Transformation

At first, the problem looked like planning overload.

T

oo many meetings. Too many templates. Too many review forums. Too much rework. Too many people spending too much time creating too many slides.

But the deeper issue was structural.

The planning process was built around technical domains, budget allocation, and presentation review. It could describe activity. It could create a corporate story. It could produce a polished view of the year ahead.

What it could not do was manage real transformation.

That mattered because the organisation was not simply running a collection of technical services. It needed to manage major cross-functional change: ERP shifts, cloud migrations, AI programmes, cyber resilience, IT/OT integration, data modernisation, endpoint consolidation, and service transformation.

Those are not technical projects.

They are business transformations.

An ERP shift changes process ownership, data definitions, reporting, controls, local ways of working, and business accountability. A cloud migration changes operating practices, cost transparency, security patterns, resilience expectations, engineering capability, and vendor management. An AI programme changes decision-making, data governance, process design, risk management, workforce impact, and value measurement. Endpoint consolidation changes service ownership, user experience, security posture, support models, device standards, cost transparency, and operational control.

The old model could not see those changes whole.

Each technical domain created its own view. Finance focused on allocations to the business. Architecture focused on frameworks and technical alignment. Corporate IT focused on tightening the story. Business priorities were barely included and were too often treated as distractions rather than the reason the plan existed.

The Business Units, who would bear much of the disruption and change, were often not properly in the room.

That was the fault line.

We were asking a technically organised planning process to carry business transformation. It was never going to work.

Alignment Had Become Presentation Theatre

The most visible symptom was the presentation cycle.

Decks went through endless review loops in large forums. The stated goal was to get everyone on the same page. In practice, much of that effort was Corporate IT tightening its own story.

That distinction matters.

Alignment is not everyone hearing the same presentation.

Alignment is shared ownership of choices, trade-offs, consequences, and commitments.

We had plenty of presentation review. We had far less genuine alignment.

The Business Units, who had to bear the brunt of the change, were not sufficiently involved in shaping the plan.

Their priorities were not meaningfully built into the planning process. When business priorities did appear, they were often treated as distractions from the plan rather than inputs into the plan.

That is a dangerous inversion.

Technology planning exists to enable business outcomes. When business priorities are treated as noise, the plan may look tidy, but it is no longer anchored in value.

This created a predictable pattern. Corporate IT would present a plan. The plan would be approved. Roadmaps would assume resource commitments from other groups because the work had appeared in the Annual Operating Plan. Cross-functional dependencies were treated as if approval equalled capacity.

It did not.

A roadmap in a deck is not a commitment from another team unless that team has had the authority, capacity, and accountability to make the commitment.

We had confused visibility with agreement.

Value Was Getting Lost in the Technical Domains

Another problem was how value was discussed.

The planning process was largely organised technical domain by technical domain. Each area could explain its own priorities. Infrastructure had its view. Applications had theirs. Network, security, servers, operations, and other groups all had their own perspectives.

Each domain could make a case.

But the broader value picture was getting lost.

Corporate finance was focused on budget allocations to the business, not value creation. The architecture organisation existed, but its focus was mainly on the framework connecting technology to business. It was not playing the role the organisation really needed: strategic alignment of value-creation activity across the enterprise.

So the process produced technically valid plans that did not necessarily add up to a coherent business outcome.

That is one of the quiet failures of large IT planning processes.

Every domain can be individually rational while the whole system remains strategically confused.

A network upgrade may make sense. A security programme may make sense. An application modernisation initiative may make sense. A server platform refresh may make sense. Endpoint consolidation may make sense. A cloud platform may make sense. But if the work is not connected through a common business vision, priority model, dependency view, funding logic, and ownership structure, the organisation ends up with a portfolio of plausible activity rather than a plan for value.

That was the real problem.

The Annual Operating Plan had become a way to organise activity, not a way to align outcomes.

The Cost Was Bigger Than Time

The obvious cost was the four-month planning cycle.

The hidden cost was worse.

The organisation was spending a third of the year preparing to describe what it intended to do, while much of the actual work slowed down because the people needed to make decisions and deliver change were locked in planning activity.

The plan created confidence on paper, but rigidity in practice.

Large transformation programmes entered the year looking coherent, but underneath the surface they carried unresolved questions around ownership, sequencing, capacity, architecture, business readiness, funding, and value.

That is how ERP programmes become system replacements instead of business transformations.

That is how cloud migrations become hosting exercises instead of operating model shifts.

That is how AI programmes become experiments instead of measurable business capability.

That is how endpoint consolidation becomes a tooling exercise instead of a genuine shift in user experience, security, service ownership, and operational control.

The planning model was not just slow.

It was actively reducing the organisation’s ability to transform.

What I Changed First: Accountability

I did not start by redesigning the planning template.

That would have missed the point.

I started with accountability.

The old model relied too heavily on Corporate IT pulling together a plan and then trying to socialise it across a large, complex organisation. That created review, negotiation, and rework, but not real ownership.

I established a shared accountability model through new functional committees. These committees included membership from both the Business Units and Corporate IT. They were accountable for creating the vision and roadmap for each function.

That was a deliberate design choice.

The committees were not advisory bodies. They were not passive review groups. They were accountable management forums with authority to shape direction, agree priorities, and commit their organisations to the roadmap.

They were also responsible for communicating their roadmaps back to their CIO cohorts, making sure each part of the organisation understood not only what was changing, but why it mattered and what commitment was required.

This changed the behaviour in the room.

When people are only invited to comment, planning becomes theatre.

When people have authority to commit, planning becomes management.

Priorities became more real. Dependencies became more visible. Capacity conversations became more honest. Trade-offs surfaced earlier. Business impact was no longer something to explain after the fact.

It became part of the planning conversation from the beginning.

I Turned Roadmaps Into Living Management Tools

The next change was to the roadmap itself.

Previously, roadmaps were often disconnected, technically framed, and treated as annual planning artefacts. They helped populate the deck, but they did not consistently guide management decisions throughout the year.

I changed that.

Each functional committee became accountable for a detailed vision and roadmap for its service.

That roadmap had to include a clear view of the best future state. It had to explain what was changing and why. It had to define clear metrics and KPIs, including both lead and lag indicators. It had to provide an eighteen to twenty-four month view of committed activities.

Just as importantly, it had to remain alive.

The roadmaps were not frozen annual artefacts. They were maintained as living documents so the organisation could respond to changing business conditions, emerging risks, new priorities, and operational realities.

This made transformation manageable in a way it had not been before.

An ERP shift could now be discussed through business process change, data ownership, integration needs, controls, investment, value, and readiness.

A cloud migration could be managed as a change to operating model, financial transparency, resilience, security, service ownership, and engineering capability.

An AI programme could be shaped around business outcomes, data readiness, governance, adoption, risk, process redesign, and measurable value.

Endpoint management could be centralised under a single umbrella with a clearer view of user experience, security, support, standards, cost, and accountability.

The roadmap stopped being a list of activity.

It became a management tool for transformation.

I Reframed Senior Leadership’s Role

I also changed the role of senior IT leadership in the planning process.

Previously, too much senior leadership energy was being consumed in large planning forums and presentation reviews. Those forums created the appearance of control, but they did not always resolve the real issues.

I introduced a process for senior IT leadership to create a master vision and high-level roadmap. This became the strategic frame that guided the functional teams.

Senior leadership became accountable for the decisions only they could make: resolving priority conflicts, addressing resource constraints, setting quality requirements, and defining the overall direction of travel.

This separation was important.

Senior leaders should not be buried in every functional detail. But they must create the conditions for coherent decision-making.

The functional committees translated the enterprise direction into service-level roadmaps, commitments, metrics, and financial views. Senior leadership managed the enterprise trade-offs.

That created a cleaner operating rhythm.

Direction came from the top.

Ownership sat with accountable functional teams.

Commitments were made by the people with authority to make them.

Conflicts were escalated to the level where they could actually be resolved.

I Repositioned Enterprise Architecture Around Business Value

One of the most important shifts was Enterprise Architecture.

The organisation had an architecture function, but it was largely technical in orientation. It focused on frameworks, standards, and technical alignment. That work mattered, but it was not enough.

The organisation needed Enterprise Architecture to help connect technology planning to business value.

So I changed the model.

Technical architects were moved into the technical operations teams, closer to the people who owned delivery, operations, and consequences. Enterprise Architecture retained ownership of architecture as a practice. It defined principles, requirements, guardrails, and standards.

But it no longer acted as the central gatekeeper for every technical decision.

Technical decisions moved to the operations heads.

That created a sharper accountability model. Operations leaders now owned the decisions and the fallout from those decisions, including impacts on adjacent areas. That forced better collaboration between security, network, applications, server teams, and other operational groups.

Enterprise Architecture was then freed to focus on higher-value work: business architecture, CIO vision definition, priority alignment, IT/OT integration challenges, and the connection between technology decisions and business outcomes.

This was a critical shift.

Architecture moved from being perceived as a technical checkpoint to becoming a strategic alignment capability.

I Connected Finance to Value, Not Just Allocation

The financial model also needed attention.

Corporate finance had been focused on budget allocations to the business. That was necessary, but incomplete.

The planning process needed a clearer financial picture from the perspective of investment, value, and chargebacks.

I made that part of the functional roadmap accountability.

Each function had to maintain a clear financial view. Not just what it cost, but what investment was being made, what value was expected, how chargebacks worked, and how financial implications connected to the roadmap.

This helped move the conversation away from “who pays?” and towards “what value are we creating, what choices are we making, and what are the financial consequences?”

That distinction matters.

A budget allocation process can distribute cost.

A value-based planning process helps leaders make better decisions.

Why the Cycle Dropped to Two Weeks

The planning cycle reduced from four months to two weeks because annual planning was no longer being asked to do everything.

The organisation was no longer starting from a blank page every year.

The roadmaps already existed.

The business input was already embedded.

The functional committees already owned the direction.

The financial views were already maintained.

The metrics were already defined.

The senior leadership priorities were already clear.

The major conflicts were already visible.

The architecture alignment was already happening throughout the year.

So the Annual Operating Plan became a focused consolidation and decision cycle, not a four-month scramble to manufacture alignment through presentations.

That is the part many organisations miss.

You do not reduce planning effort by simply compressing the calendar. You reduce planning effort by moving the real management work into the operating rhythm of the organisation.

The two-week cycle worked because the organisation had become mature enough to sustain it.

What This Accomplished

The measurable outcome was clear: I reduced a four-month annual planning cycle to two weeks.

But the bigger accomplishment was not speed.

The bigger accomplishment was making transformation manageable.

The new model created clearer shared accountability between Business Units and Corporate IT. It established functional roadmaps that connected vision, value, finance, metrics, and delivery. It focused senior leadership on enterprise direction, quality requirements, priority conflicts, and resource constraints. It repositioned Enterprise Architecture around business value and strategic alignment. It placed technical decision-making with the leaders accountable for operational consequences. It connected finance to investment, value, and chargebacks. And it created a planning rhythm that could adapt as business conditions changed.

That changed the organisation’s ability to manage large cross-functional change.

ERP, cloud, AI, cyber, data, IT/OT, endpoint, and service transformation no longer had to be squeezed into disconnected technical-domain plans. They could be managed through business-led roadmaps, clearer ownership, stronger decision rights, and continuous alignment.

That was the real win.

The Lesson I Took From It

Planning does not become faster because people create better slides.

Planning becomes faster when the organisation knows how to make decisions.

In this case, the four-month cycle was a symptom. The real problem was fragmented accountability, weak business integration, disconnected roadmaps, technical-domain planning, finance conversations focused too narrowly on allocation, and architecture positioned too far from business value.

By changing those things, the annual plan stopped being a heroic corporate exercise.

It became a short, focused confirmation of decisions the organisation was already managing throughout the year.

That is what transformation needs.

Not more planning theatre.

Not another annual scramble.

Not another stack of polished presentations pretending that disconnected activity equals alignment.

Real transformation needs an operating model capable of carrying it.

That means shared accountability, clear decision rights, living roadmaps, value-based finance, business-led architecture, and governance that helps the organisation make decisions rather than delay them.

Reducing the planning cycle from four months to two weeks was the visible result.

The real accomplishment was building a planning and accountability model strong enough to manage business transformation.