The risks of IT visions

To begin, it is good to be clear about what a vision exactly is. The ‘Van Dale’ defines a vision as: "view or an opinion on/about something." We have a view or an opinion about everything in the universe, and so we can have (and formulate) a vision about everything. But what is the purpose of a vision? A vision should provide direction. In the context of IT, a vision usually serves several purposes. First, a vision provides a view of how the organization deals with internal and external developments, for example, data-driven work: what does this mean for our organization? But second, a vision can also serve as a dot on the horizon. A dream image of what, for example, the target architecture should look like in 5 or 10 years. This doesn’t necessarily need to be a "dream" image. The vision can also bring you back down to earth and show you what is realistic or more obvious in the coming years. Ultimately, a vision will have to lead to being able to make the right choices and determine a clear strategy. Thus, the strategy is a concrete elaboration of the vision containing the actions and steps to be taken. Based on this strategy, the organization must make tactical decisions and implement operational actions, often encapsulated in a roadmap, portfolio and/or program plan.

It all sounds simple, yet in practice I see many organizations struggle with creating and implementing visions. Within my assignments, I frequently encounter the same pitfalls that organizations face when creating (and implementing) visions. I like to explain these:

1.  Another vision: Besides creating visions for our clients on all aspects of IT, we also encounter existing IT visions at clients. At the same time we experience that these visions are not embodied in the organization and/or that the organization does not adopt this vision. Next to that, there is also hardly any control on the adoption of the vision within organizations. And that is a shame, because what are you making a vision for if it gets shelved in the end? It is a waste of effort. One time I had been asked by a client to create a vision for the information provision (in Dutch: informatievoorziening). However, within weeks of starting this assignment, it turned out that a few months(!) before our arrival, a vision on exactly this subject had already been drawn up within this organization. So the big question is how to make sure that all that time and effort does not turn out to be a waste? My advice: do not let the vision rest after it has been drawn up, make sure that the organization becomes familiar with the vision by regularly communicating about it and that everyone is or can be aware of it. 
2. Your vision, my vision: A vision should make strategic and tactical decisions easier, not more complicated. And that's where things tend to go wrong in practice. There are often multiple visions within an organization related to the same topic, which in turn leads to conflicting visions. For example, at a client I came across an integration vision and an application vision that contradicted each other. What is the truth in that case? And why are these subjects not packed together in one vision on information services or provision? The challenge is not to get carried away with writing visions; it must be just enough to create good strategies based on the vision! My advice: don't write a vision for each topic, but pack topics together and write an integrated vision for these topics.
3. Let a vision be a vision: Wanting to be too comprehensive in the vision is another way to strike out. When creating visions, the thoughts of subject matter experts, among others, are indispensable. At the same time, when involving these experts, the risk of getting bogged down in details immediately lurks. For example, I have experienced what happens when you bring in experts from adjacent areas of expertise, in this case legal experts, at the last minute. When drafting a vision for a client, we received last minute feedback from Legal Affairs (JZ) on the vision. The feedback mainly emphasized points and commas which, in my view, added relatively little value to the dot on the horizon we were describing. My advice: let a vision be a vision. A vision should not be a detailed elaborated story describing how everything should go. To describe elaborated plans and strategies, the implementation, project and program plans that will follow later, as a follow-up to the established vision, are better suited.
4. No vision without buy-in: At the end of the day, it does not matter what’s in a vision if there is no buy-in or support for the established vision. Buy-in / support means that the business (employees/organization), as well as the colleagues involved in IT, understand what the vision means and why it will benefit them. Their needs and concerns must be understood and addressed. It is nice if a new vision for data-driven working has been drawn up by the CIO office, but if the business has no idea what to do with it if they have not been included during the process of writing or if they are not interested in it, this will lead to the business not acting on it and thus the drawing up of a vision is pointless. My advice: make a good analysis of the stakeholders at the start of creating the vision and include them step by step during the realization and elaboration. By doing so, they provide valuable input, but also experience the process and feel ownership of the vision.

In short, creating and implementing a vision is easier said than done. Want to learn more about how we can help you create and implement good visions and how to avoid these pitfalls? We would be happy to do so with no obligation. Feel free to contact daan.vanhorssen@highberg.com or joost.vanlier@highberg.com.