Failing to plan is planning to fail is the saying, but to what degree is a plan relevant in a dynamic environment with multiple stakeholders and multiple sources that can impact the organization and strategic plan. The organization’s environment is adding to complexity and the bigger the organization, the more likely the decision makers will experience a high degree of complexity when it comes to the decision-making processes.

A roadmap is in other words a great artefact to use, when the decision makers need an overview of how the individual activities and decisions impact the organization and its possibility to deliver on the decided strategy, and likewise can roadmaps deliver the relevant “framework” for making the relevant decisions. But what is needed in order to build a roadmap that can deliver the overview? And is the roadmap the most important delivery?

Complexity in Decision-Making Processes

Medium-sized and major organizations will eventually experience that decision making processes are becoming increasingly complex, which has impacts the time for when and how the decisions are made. The delay of implementing the decisions does the added complexity e.g., in the layers of the organization impacts the organization’s ability to adjust to its environment.

The sources of complexity in organizations are many, but you will most likely experience complexity increase when:

New hierarchies are introduced, meaning decisions have to be made by people far away from actual production of the organization.
New comprehensive rulesets are implemented and enforced.
New structures of the organization e.g., the enforcement of new department structures and new ways of communication.
New services, products and processes are introduced and leads to new ways of working where limited existing knowledge is available.

The increasing level of complexity in organizations cater for the establishment of roles like enterprise architect, business architects and solution architects who can coach the different stakeholders of the organization to navigate the complexities and to enable coherences. One method to assist with the guidance of the stakeholders is the use of roadmaps.

Roadmaps

A roadmap has to be individualized for the specific organization and its specific industry. A good roadmap includes perspective for market orientation, business related themes and technical deliverables. It is almost needless to say, but the roadmap must include a time perspective and the perspectives, those earlier mentioned, have to be connected.

The enterprise architect would have to consider a few different themes before the development of the roadmap takes place, and the primary concern to address during the planning is to consider that the roadmap itself is not the value adding component. The primary value adding component of the roadmap is the process of delivering it. The artefact as such is valuable for communication to different groups of stakeholders, though the value of creating clarity is mainly developed during the roadmapping process, since the activities in most cases would involve executive stakeholders.

The Roadmapping Process

The enterprise architect will have to act as the facilitator and as a subject matter expert, when or if, questions are asked during the sessions in the process by the different stakeholders. Likewise, the enterprise architect can as such not own the roadmap, except, if he or she is a member of the executive committee of the organization.

First and foremost the enterprise architect has to ensure executive sponsorship for the process. When the sponsorship has been ensured, then the relevant stakeholders have to be identified and engaged. The first meetings will likely have to be done individually with the stakeholders, so they are prepared for what will be done during the workshops where groups of the stakeholders are engaged. One of these group workshops would include the kick-off session, which will have to provide alignment and commitment to the process, since without the “geist” or “spirit” to take part in the process for developing the roadmap, then it is likely very little will happen.

The enterprise architect will also have to work on ensuring a vision is articulated as part of the roadmapping process, and the vision is captured, so the participants in the process can support the mapping of the roadmap towards achieving the vision. The vision and the prework to the roadmapping process can be captured by using scenarios and undergo a specific process for this with the executive committee, so they have an aligned view of the vision, before the roadmapping process is commenced.

During the roadmapping process the enterprise architect has to ensure that the participants do not begin to suffer from group thinking, since the best possible outcome of the process will be produced by a diverse group of stakeholders, who can challenge different hypotheses and perspectives in the roadmap. This is to be done through the first round of workshops. The enterprise architect will also have to consider engaging the stakeholders individually before the second round of workshops is commenced, since there likely will be a different group of stakeholders involved in these.

The second round of workshops will usually include the subject matter experts e.g., software engineers, solution architects, logistics specialists, sourcing specialists, operations specialists, security specialists and a like. The specialists will during these workshops provide clarifications on how the different deliverables are interconnected, and what impediments have to be dealt with as-well.

The third and last round of workshops in the process of developing the roadmap will be concluded by a presentation for the members of the executive committee. They will have to commit to the roadmap before the organization as such can begin executing as according to it. Before the presentation to the executive committee the deliverables in the roadmap will have to be described as a portfolio of projects (in some cases as portfolios) so program managers and project managers can assist in delivering the projects.

After the last round of workshops have been completed, then it is time to involve the stakeholders in the organization that did not take part in the workshops. This can be done creating a few rounds of presentations so the stakeholders are informed and they can ask questions regarding how to proceed with the roadmap. The stakeholders can prove to be regular employees as well as middle managers like head of departments and senior vice-presidents. Besides the presentations, then “company town hall” meetings can be made use of in-order to spread the knowledge of the roadmap, and in the case of this, the enterprise architect should take part of these to assist answering the questions.

The roadmap has to be published, e.g., at the organization’s intranet, so the executives, middle managers and the employees can look information and “navigate” accordingly. Afterwards, the enterprise architect will have to pivot to a “Plan – Do – Check – Act” approach to make sure the roadmap is kept updated and implemented through the project portfolios.

Conclusions

The primary value adding activity of developing the roadmap is the process where the different stakeholders take part in developing the roadmap. The roadmap will have to include a market perspective, include business related themes and technical deliverables.

The second most important outcome of the process is the roadmap, which can be communicated to the relevant stakeholders in the company, and in some situations to stakeholders outside of the company. With the roadmap in hand it will become easier for the stakeholders in the company and its environment to navigate the complexity.

There is no doubt on the topic. If you want your organization to harvest the benefits of strategic planning and digitalization, then you will have to apply enterprise architecture, and your approach has to be top-down, or does it?

Strategic Management and Planning

Organizations of all sizes have some form of strategic planning even if they claim they do not, since not having a strategic plan is a choice on how to (or not to) plan and how to identify opportunities, e.g., this could ad-hoc. All organizations regardless of these are private, public or NGOs make choices regarding strategic planning and their strategies everyday and every year. Organizations who fail to do strategic planning on top-level (executive committee or board of directors) will experience that employees or middle managers will do some form of planning that can impact the ad-hoc strategy one way or the other.

Strategic planning and strategic management can have different results and outcomes depending on how the organization chooses to apply the different methods and tools in the different stages of the development of the strategic prioritization. On the one hand, organizations that invest time and resources in doing the strategic management and planning that involves the right stakeholders and the right level of activities will experience better outcomes than organizations that do not invest in their strategic planning capabilities. On the other hand, regardless if the individual strategic plan fails, then the ability to develop coherent plans are valuable in any situation and crisis management.

Failing

Strategic plans fail, some indications are up to 90 % or so, since the top-management or alike are not committed to implementing the strategic plans or the objectives have not been defined properly or the plan has not been defined in a way that takes the organization’s environment into consideration, and therefore is not valid for implementation, when time and resources have been allocated.

Schools and Planning

There are different schools for conducting strategic planning and strategic management. Mintzberg has identified 7+ schools for strategic management and strategic planning. These schools have different pros and consequences while conducting strategic planning and articulating strategies.

The different strategy schools is a broad theme that I will publish a blog post about later on, though the point in this particular context is that though strategic planning and strategic management has a tendency to fail, then there is a bright light at the end of the tunnel. Keep in mind that as long as a strategy and strategic plan provides multiple options for organization to make use of, then it is more likely to succeed, and if these options have been tested with different potential outcomes then it is more likely that the strategy and strategic planning can prove useful. The different outcomes can be based on different techniques such as scenario planning and roadmapping, which are tools that encourage involvement from different stakeholders in order to ensure the outcomes are done right.

The different schools and different paradigms that can be used to empower the strategic planning process, though in general it seems like the strategic plan has to be anchored in the top of the organization in order to make it possible to implement the strategic plan:

The board of directors have to accept the strategic plan and its framework, and thereby allocate the budget for implementation.
Members of the Executive Committee have to approve the plan and ensure resources are allocated.
Vice presidents, managers and team leads have to ensure the right persons and the right time and other resources are available.

Enterprise Architecture

Bernard (2012, p. 33) defined enterprise architecture is the combination of strategy, business and technologies. As such enterprise architecture is an approach to ensure coherence of planning and implementation of future designs for enabling the defined objectives. One of the core perspectives of using enterprise architecture as a methodology for strategic planning is to differ between the As-Is situation for the organization and the To-Be situation for the organization. The process of defining the blueprint for the To-Be situation for the organization is usually described in enterprise architecture frameworks. Enterprise architecture frameworks includes the need to define the business strategy and thereafter define:

Business Architecture (e.g., business processes, business rules, product features, principles for business development).
Information Architecture (e.g., information processing, data dictionaries, data maps and mapping, GDPR processing overview etc).
Technology Architecture. (e.g., system landscape, standards for software development, overview of infrastructure components).

The EA frameworks usually define a set of artefacts for each of the different types of architecture forms.

Sadly, in most organizations the enterprise architecture team is anchored in the information technology department and not in the business units, which means that in many organizations then the approach for enterprise architecture becomes too IT-centric, and consequently the organization will not be able to harvest the full potential of using enterprise architecture. The problem with IT-centric enterprise architecture is that technologies in itself is not particularly strategic, in fact, in most organizations technologies can at best be considered a theme that is dealt with on a tactical level.

Technologies and Digitalization

Enterprise architecture can empower organizations to get a higher return on investments of their use of information technologies. This will usually be done through a digitalization perspective, which means that the business practices and customer experiences are to be optimized by the use of information technologies. In this light it would say that the current practices are to be re-engineered to fit better in digital interactions with new tools and platforms to support the dialogues needed. Digitalization requires that business opportunities and problems are addressed and not as such new technologies that are identified for implementation.

Enterprise architecture that is too IT-centric will usually do this the other way around, meaning that the individual enterprise architects change their mindsets to identify how business problems either can be solved with existing technologies (in the organization) without scope on solving business problems, and over time it will become apparent that business stakeholders begin to avoid the enterprise architects since they will not provide the desired outcomes for them. To some extent then the too IT-centric enterprise architecture approach will lose its ability to impact the organization’s business strategy and thereby lose its ability to stay strategic, and as such the scope changes from a top-down approach for enterprise architecture (which ensures impact) to a bottom-up or at best middle-out. The middle-out approach would lead to more benefits across the organization, but as such it will not impact the overall strategy, and this approach cannot be considered strategic.

Conclusions

Enterprise architecture that leads to great impact on the organization has to be anchored in the top of the organization, as it would be, with strategic planning. This means enterprise architecture has to be business centric and to some extent be situated in the business unit and not in the IT-department. Enterprise architecture teams that are anchored in the IT-department have to work on staying business centric in order to avoid being too tactically oriented, and by that ensure their inputs can be implemented on a strategic level in the organization. In this light, it is possible to do enterprise architecture with a bottom-up approach or a middle-out approach, but the outcomes will not be as significant as with the truly top-down approach to enterprise architecture.

Sources

Bernard, S.A. (2012). An Introduction to Enterprise Architecture. Authourhouse.

Mintzberg, H., Ahlstrand, B. & Lampel, J. (2009). Strategy Safari. Prentice Hall: London.