What's the best way to define an IT Strategy Roadmap?

Leading with current state has an unfortunate tendency of constraining thinking around the current structure and capabilities of IT. I recommend pushing this activity out until after you’ve envisioned what the market you will be competing in is (a strategic foresight exercise), and how that informs your organizational strategy, and then evaluate what capabilities you will need (future state) to perform in that market.

Process Simplification should form the basis of an all-encompassing IT Strategy Roadmap. To begin with, it's essential to collate all relevant data from all the business functions within your organization, with the clear objective of simplifying processes across value chain to serve the final customer. Once we analyze every step in each of these processes, it will guide us to the required automation. This collaborative approach ensures that the roadmap aligns with your company's business objectives and technological requirements. Include representatives from diverse areas such as marketing, sales, engineering, accounting, HR, and product management to gain a comprehensive understanding of your organization's technological needs and goals.

SWOT diagram while useful to trigger some initial investigation do not bring the level of granularity needed. They are also too generic removing biases. I agree that a clear view of the current state is highly important and often missed (because people are much more interested into dreaming a future one), but SWOT is one of the worst tools. Look into Wardley Maps as a much more useful tool

Creating a strong IT strategy requires deep business understanding, seamless IT & Business collaboration, and adaptability to change. The critical point is to ensure that the assessment aligns with organization's strategic goals. Blindly identifying weaknesses or strengths in isolation from the business context can result in misdirection. Current state assessments also frequently emphasize on technology and processes, often overlooking human and cultural dimensions. Organizational culture, employee morale, openness to feedback, and change resistance significantly shape IT transformation. Neglecting these factors can pose implementation challenges in the future.

I would question whether you need to know where you are before you map the strategy. Although it sounds counterintuitive most organisations don't have a clue as to where they are in terms of IT knowledge, business relevance etc. To get a view on this ask the organisation how accurate their CMDB is !! The development of the strategic plan needs to be revolutionary and not evolutionary - make it visible and demonstrable. How many organisations do you know who pay 'lip-service' to adhering to the strategic plan and then in 2 years time have to go through the whole process again? Make it bold and approach it in an agile way - deliver goals along the plan often and visibly.

I like to start with the desired state. Bringing a wide cross section of stakeholders from across the organisation together to share their aspirations and goals. Create a safe space for everyone to contribute openly. Use a variety of mechanisms to unlock the diverse thinking. Consider the future through the lens of different personas including customers, employees, beneficiaries or partners. One tool I love to use is to send a postcard of the future, what is the image depicting, what is different and how does it feel? This process builds engagement and support from those who will deliver and receive the change. It is a critical success factor to have their support and understanding of the direction you're headed.

Strategy from an idealistic future is still very popular and completely useless in a faster changing environment. Yet it keeps in business many of the consultancies commissioned by executives that need the stamp of Big5s so not to expose selves too much. The other issue with this approach is that everything becomes a project and you cannot deliver much of it, unless you keep the delivery services of said consultants. Strategy should start from the present because it is where you will start anyway. What's the best present you could have? What's the evolutionary potential of the present? And then I very much like the concept of vectors. Directions and worth. This also helps for having strategy flowing through the existing business.

Starting with a view of the intended outcome is, is usually the best point of departure in my experience. Here one wants to frame what good looks like from a business perspective and firm up on the actual measures of success. If your organization is publicly traded then your performance will be judged differently to say an NGO. Framing these metrics serves as anchor to judge if decisions framed in the IT strategy and plotted against the roadmap are delivering towards the required outcome.

In my experience, using SMART goals in IT security means setting precise, measurable objectives, ensuring resources are available, aligning with company objectives, and keeping to clear timelines, like aiming for a 25% vulnerability reduction within a year. I've leveraged OKRs to align IT goals with the business, setting high-level objectives and quantifiable results. Balanced Scorecards gave me insights across financial, customer, internal, and growth aspects. Using Value Stream Mapping, I pinpointed bottlenecks in processes. I consistently strive to adhere to established IT principles, policies, and standards to give me a clear picture of my current IT state or posture.

An example of a strategic initiative for the team that maintains the SAP ecosystem could be to reduce the risk exposure of SAP to both internal and external threat actors. This can be a daunting task. It usually starts with the realization that without a vendor product, the assessment of current state and roadmap to future state will require more manual effort than the current team can provide. For example, an admin executes the transaction code SUIM. This can return query results for a specific server environment (called a "Client" on a "SID" in the SAP jargon). But what if you want to automate that task? . . .and run that same query on 20, 50, 100, 200 Client environments. . .automatically? Now the power of the vendor product shows.

I've found beneficial results that are aligned & flexible by focusing on below aspects: Collaborate with cross-functional teams, including IT, business units, and stakeholders, to brainstorm initiatives that align with your digital transformation goals. Focus on initiatives that target high-impact areas, such as customer engagement, operational efficiency, and innovation. Leverage the Agile SAFe methodology to structure your initiatives into Agile Release Trains (ARTs) that promote collaboration, continuous delivery, and alignment with business value. Utilize prioritization frameworks such as MoSCoW, RICE, or QFD to assess and rank initiatives based on urgency, business impact, feasibility, and alignment with digital transformation goals.

One-page initiative profiles are a great way to communicate the key information about a given initiative. Consider including a brief description & scope, impact/benefits, budgetary cost, timeline, risks and dependencies on your initiative profiles.

The big irony of looking to be Agile and planning for (inevitably rigid) roadmaps.... If you want agility, you need a new strategy operating model where the roadmap is dynamic. Strategy / Strategy Deployment / Lean Portfolio Management should work seamlessly together to provide a dynamic way of doing meaningful reprioritization and making decision to pursue further or pivot, and even realign the inside-out to the new outside-in needs. There is no agility unless the strategy can change, and it is not a strategy that follows a roadmap that will change easily. Agile methods won't fix it - this is the fallacy that many organisations have ridden with Agile for the past 2 decades and don't have an inch additional agility to show for it.

Link your roadmap to your vision. Identify how and when the change activities deliver the outcomes defined in your vision. Use this to motivate people to stay focused on the change, especially when it becomes hard and you hit bumps on the road. Introduce appropriate governance to adapt and adjust your roadmap to real life. Internal and external factors will introduce the need to change. Being able to see this and be flexible to adapt in timely manner will improve your success.

The roadmap you build needs to give timeframes, assign responsibility and link to documents that define each of the deliverables. The closer to the delivery the more detail you will need. The roadmap needs to plan scoping as well as delivery so that these tasks are not missed. A timeframe may only include scoping or documenting and a subsequent timeframe will include subsequent stages of roadmap items. The roadmap needs to be agile, but to ensure the trust of your stakeholders you need to have items which will be delivered as they are important, and won't move without major stakeholder engagement. There will be items which may move as they are less time critical, and then there will be a third category which is discretionary.

Roadmaps are not linear roads, they are iterations that you have walk and see how things progress. The best way I have found till now is the iterations following OODA Loops: observe, orientate, decide and act. The work done by John Boyd is great and deserves a review.

Communicating progress on roadmaps is crucial to build and maintain trust with business key stakeholders, with logistical elements such as deliverables, timelines, and ownership. A challenge that I am seeing often is the agility to pivot out for unplanned initiatives, allocate appropriate resources and energy, quantify efforts and time spent and be able to articulate how much delay may have been incurred to the originally agreed and published roadmap.

Set a roadmap timeline at the beginning, e.g. 3 years. Review the roadmap with business users at least twice a year, and whenever a key initiative outside of the planned activities arises, so that the business can prioritize the new initiative and determine its impact on roadmap activities. With technology changes happening very fast, it is important to frequently review plans so that new opportunities based on new technology can be incorporated on a timely basis.

A good communication is always essential in any strategy, project or change you want to implement. In this case, we should talk not just about communication, but about implicaction.Because it's necessary to involve all the stakeholders in the IT strategy roadmap; know their points of view, and concerns and get them motivated and really convinced to support the changes.

Participation and contribution is a much more effective way than communication. How you distribute strategy is more important than how you communicate it.

A comunica??o muitas vezes é o maior gargalo de um projeto, pois ela é a base do engajamento, da fluidez e eficiência das a??es. Pessoas para colaborar de forma efetiva precisam entender e aceitar o desafio como sendo algo que vale a pena.

One key thing I'd like to add is the importance of staying flexible and being able to adapt to changes. You definitely want to keep an agile mindset in pursuing your strategy - review and reflect in regular intervals not only on your progress but also the ever-changing environment you operate in.

While I wholeheartedly agree that technology and change in general is accelerating, if you are competing for company funds and visibility you most likely have to denote a timing associated with the spend and the anticipated benefits. If not then I’m not sure how you’re differentiating your strategy from among competing roadmaps. If the strategy is purely aspirational, then I agree, timing doesn’t matter.

Coming back to that SAP Vulnerability Vendor illustration, it is important to select a vendor that can give you a clear picture of what is your current Risk Posture and ALSO, the vendor, or more specifically, the vendor product, should be able to generate a "remediation roadmap" that can help you: 1. Get Healthy (risk remediation) 2. Stay Healthy (vulnerability resilience) The vendor's products and/or consultant team should be able to help you get to the desired state and be able to STAY at the desired state. This SAP Vulnerability management market is currently a growing segment of the SAP vendor segment. It is a hybrid of SAP Security and traditional Cybersecurity. You can simply think of it as #SAPCyberSecurity. Follow the hashtag!

Looks like Strategy is still well and truly welded in the 1960s in the above and needs a serious shake up in the world of Digital / Complexity / Globalisation / Tech acceleration / any many other multi facetted challenges that organisations and society are facing.