Archive for the ‘IT Engagement Model’ Category


Image via Wikipedia

Time for an update. I would like to share some insights from my daily work experiences. Within my company we’ve changed the way we innovate.

Until a year ago, we had several departments throughout the company responsible for innovation. These departments were part of the business and in general they acted in a demandrole towards the (centralized) IT unit. While this caused suboptimal usage of scarce resources and money, our board decided to group all innovation activities in a limited number of strategic programs. I am responsible for one of them. These programs all are part of the business. To eliminate boundaries between business and IT, people from business and IT all take part in these programs. The day-to-day, functional governance is done by the programmanagers, for business as well as IT. So, although we still have an IT department, the innovation people are united in one of these programs, business and IT, and in many cases even with suppliers included.

We not only brought business and IT people together in one (virtual) organization, but also changed the overall responsibility of innovation. We used to talk about projects, due dates, milestones, etc. Now, we’re talking about capabilities and business benefits. Not the project is important, but what it is supposed to deliver and supposed to change within the organization is important.

In fact, we took measures to improve alignment, by introducing some mechanisms mentioned in the IT Engagement model of Fonstad [2005, 2006].  One could also recognize this as a step towards business/IT Fusion as introduced by Hinssen [2009].

It may sound like an easy task to change in such a way. But, it’s tough. Even in a situation where people from business and IT are brought together, thinking and acting in a way the business understands remains difficult. People are used to talk in sharply defined project-terms. But, to become a real partner in business-discussions requires a total different mindset. And, as I’ve experienced, this is something which takes a lot of time and intensive leadership.

I like to share some of the insights have experienced last year.

Shared (understanding of) goals
To realize alignment, shared goals are crucial. But, more important, is a shared understanding of those goals. This seems to be an open door, but it is not. Business and IT people must learn to speak in the same language. This requires explicit and intensive discussions. Do you really understand each other? Do we actually mean the same thing? It is as hard as learning a real language.

Senior sponsors
You can only succeed when senior executives of all partners are committed to the program. This means, executives from business and IT. In our case we installed a programboard with executives of all departments, which meets bi-weekly to decide on all major topics and projects. This commitment is needed to give a program enough mandate and power to act on behalf of business and IT.

Clear expectations
Create an organization in which business and IT are integrated, one should be aware that clarity should be given regarding roles and responsibilities of the members within the program. People are used to focus on the goals of their departments. Now they should focus on the shared goals of the program. In some cases these goals can be contradictive. Make sure these differences are made clear upfront, or at least, make very clear to the people within the program how they should act in these kind of situations. Otherwise this can become a disturbing, hard-to-get, issue undermining the program. Also, be aware that a combined program should take into account both interests of business as well as IT.

Managing stakeholders’ expectations is also very important. Stakeholders tend to act and react the way they used to. They have to get used to the integrated approach, where business and IT act as one. They also have to get a clear picture of their own roles and responsibilities, as well of what they can expect from the program.

This are some lessons I have experienced in real life. When I project this on what I have read (and published earlier), I conclude that a lot of what I have seen has been captured in the “4C model” of Weiss and Anderson [2004]. Apparently, this model captures quite nice the most important elements to enhance alignment between business and IT.


Fonstad, Nils, and Robertson, David: Engaging for Change: An Overview of the IT Engagement Model, CISR Research Briefing, Sloan School of Management, Massachusetts Institute of Technology (MIT), March 2005.

Fonstad, Nils, and Robertson, David: Transforming a company, Project by Project: The IT Engagement Model, CISR Working Paper 363, Sloan School of Management, Massachusetts Institute of Technology (MIT), September 2006.

Fonstad, Nils Olaya: Engaging Matters: Enhancing Alignment with Governance Mechanisms, CISR Research Briefing, Sloan School of Management, Massachusetts Institute of Technology (MIT), December 2006.

Hinssen, Peter: Business/IT Fusion, How to move Beyond Alignment and Transform IT in your Organization, Mach Media, 2009

Joseph W. Weiss and Don Anderson: Aligning Technology and Business Strategy: Issues & Frameworks, A field study of 15 companies, Proceedings of the 37th Hawaii International Conference on System Sciences, 2004


One of the proposed mechanisms to improve alignment is the usage of relationship managers or liaisons. Some people think this is usefull, others think the opposite. From firsthand experience I can say that it can be usefull, but only when the role is filled in properly.

The liaison role is one of the linking mechanisms as proposed by Fonstad in the IT Engagement model. Also Luftman suggests using this role to improve Business/IT alignment. But there is criticism on these kind of roles. In his blog, Harwell Trasher puts down a strong advice not to use a Business/IT Liaison person. He found out that over time liaison people gravitate toward either the business or IT camps, and begin to take sides in disagreements. Then, the liaison will magnify the problems rather than solving them.

Although I recognize this risk, I personally think liaisons can help improving alignment between business and IT. In the right situation, with the right person and for the right period of time.

Liaison roles are usually set up when the volume of contacts between departments grows. They are formal roles designed to facilitate communication and bypass vertical communication channels. A lot of their work is carried out through informal communication of information. Problems which lead to the introduction of liaisons includes conflict between business versus IT, inadequate communication, poor understanding, no structure to prioritisation, business without control, increased pressure on systems, time wastage, insufficient requirements determination and employee demoralisation [Barry and O’Flaherty, 2003].

One of the critical characteristics of this role is its ability to remain neutral. They are supposed to facilitate both sides and work through any impasses. The role of liaisons is highly political, liaisons must “understand politics and then avoiding them”.

What’s extremely important, is that there comes a stage in every action, where the liaison must step out of the process, because he/she is no longer adding value. The liaison should facilitate both business and IT to work together, but shouldn’t get in between. So, after the initial stages of communication, his or her role will vanish. Liaisons should act somewhat reactive, sweeping up issues and promoting collaboration as they go along. Whenever possible, push back both sides (business and IT) and mediate in conflict situations.

Liaisons can help in organisations where Business/IT Alignment lacks maturity. Liaisons can help bridging the gap between the two parties and help developing communications. But, liaisons should limit themselves to facilitating. Otherwise they can get stuck in the middle, and they can hinder further collaboration by business and IT and become just another barrier. Then, they could be used for things where business and IT don’t feel like working together. In all cases, the liaison should protect their neutrality and keep the facilitating role.

Question is in which unit this liaison is organised. It could be within IT, as well as within the business. What I think is wise to do, is to select a person for this role with experience in the opposite side. If the liaison is organisationally part of IT, select someone with extensive business experience. If the liaison is part of the business, appoint someone with an IT background. In the end, a person with experience in both business and IT is ideal, but not frequently available.


Blog Harwell Trasher:

O’Flaherty, Brian, and Barry, Owen Harte: A Case of ‘Non Strategic’Alignment – An IT and Business Unit Liaison Role, 2003

Knowledge Sharing Is...

Image by Choconancy1 via Flickr

One of the six dimensions of the Strategic Alignment Maturity Model of Luftman (2000) is Communication. Communication is part of the social dimension of alignment. This dimension consists of 6 attributes, which all are important to achieve and sustain alignment. Let’s take a closer look at those attributes.

The first one is Understanding of Business by IT. To be effective, IT has to understand the business environment. Knowing about their processes, but almost more important, knowing the business’ customers, the products, competitors and so on. The second attribute is the other way around: Understanding of IT by the Business. Business should be aware of the capabilities of IT, but should also understand what needs to be done to develop and maintain information systems and technology. The better these understanding of business and IT of both worlds, the more mature alignment will be.

The third attribute is Inter/Intra-Organizational Learning. The better an organization is capable of learning (and educating) from opportunities like previous experiences, problems, and challenges, the more mature the alignment is.

Fourth, Protocol Rigidity has to do with the way how business and IT communicate with each other. Is it one-way or two-way? Is it only formal, or also informal? It may be clear that a two-way communication, with formal and informal characteristcs suits alignment best.

Next, Knowledge Sharing is also very important part. As I have introduced in the former post, knowledge sharing is an enabler for alignment. Shared domain knowledge is defined as the ability of IT and business executives, at a deep level, to understand and be able to participate in the others’ key processes and to respect each other’s unique contribution and challenges.

The last attribute in Communication is Liaison Breadth/Effectiveness. According to Luftman, many firms choose to draw on liaisons to facilitate. The key word here is facilitate. Facilitators whose role is to serve as the sole conduit of interaction among the different organizations are often seen. This approach tends to stifle rather than foster effective communications. Rigid protocols that impede discussions and the sharing of ideas should be avoided. I will come back to the role of liasons in a following post.


Luftman, Jerry: Assessing Business-IT Alignment Maturity, Communications of AIS, Volume 4, Article 14, December 2000

Logo of the Vlerick Leuven Gent Management School

Image via Wikipedia

Last week I found a report which contains some interesting results, and is quite recognizable in my daily practice. It presents the results of a survey under CIOs and CFOs on the effects of the crisis on the way companies manage their IT. The study is done by Vlerick Leuven Gent Management School and Deloitte.

They distilled four main engagement themes which stimulate a more effective kind of engagement:

  1. Bonding at the top
  2. Look for benefits
  3. Serve professionally
  4. Engage respectfully

Bonding at the top

Engagement requires more than one or two visits of the CIO to the companies management team with an overview of next year’s IT budget. What is required, is working side-by-side. The purpose of the engagement remains the same. Setting the right expectations, specifying rules for allocation of resources to fulfill these expectations, and defining a framework to verify the performance. Informal engagement channels are as important as formal channels. As a CIO in the study said: “It would be suicide to go to the executive committee without having worked everything out in advance”, and “We are not making their choices. We guide them (the business) with a roadmap, to have an influence on the order of things, to show interdependencies.” The usage of roadmaps and architecture appeared to be fruitful in discussing scenario’s.

Look for benefits

Especially in a crisis, it’s more accepted that business benefits up-front get challenged. IT can and have to take their role in this. An important mechanism here are ‘post-project reviews’, as we have seen earlier in the work of Fonstad on Engagement mechanisms (see former post).

Serve professionally

To get on speaking terms, IT must perform and deliver. Operational excellence and knowing the ‘cost-to-serve’. This will provide IT with excellent input to start the dialogue with the business and to create engagement. Also important are risks and riskmanagement. “Do not hide risks, make them visible” as one CIO pointed out. Put risks on the radar, before being able to manage them properly. Mitigate risks by avoiding big, long projects. Maximize into six-month (or even better three) projects. Otherwise, you can get trapped, due to unforeseeable challenges.

Engage respectfully

What is needed, is a culture in which business and IT allow eachother to intervene. Talk about execution implications of strategic options. And, this is needed throughout the organisation, not only at C-level. Liaison-roles are mentioned as very important (which was also one of Fonstad’s conclusions). This can take the form of business-analysts or IT account managers, but more important, social skills are required. In places where strategy and operations as well as business and IT meet, people should operate who are able to “sit with their peers and show the ability to listen, learn and influence”.

Two other fundamental trends are also pointed out in the survey. Business IT Fusion is seen as upcoming. The second trend is the fact that IT users are becoming more and more IT savvy. As a result, they expect more and more control on how their money us spend. This puts an extra challenge on IT to perform and deliver, and to approach users in an appropiate way.



Viaene, Stijn, Jolyon, Olivier, Hertogh, Steven de: Engaging in turbulent times; Direction setting for business and IT alignment, Vlerick Leuven Gent Management School and Deloitte Belgium, October 2009.

MIT Sloan Logo

Image via Wikipedia

In this post I will introduce the IT Engagement Model, developed by Nils O. Fonstad of CISR, MIT. In previous posts I already showed the importance of alignment on and between different layers in an organisation. In a study of the Center for Information Systems Research (CISR) this issue is adressed as well. Fonstad (2006) states that IT departments always struggle with the eternal dilemma how to achieve company-wide strategies while simultaneously responding to urgent requests from business units to implement dozens or even hundreds of solutions for local projects. Two different streams of research have attempted to adress this challenge.

Research on IT Governance has taken a top-down approach and specified how management allocate decisions. The other stream of research, with a more bottom-up approach, focuses on how projects can be coordinated and managed.  According to the CISR study, neither of these approaches is sufficient. Succesful approaches adress two fundamental goals – alignment between IT and the rest of the business and coordination across multiple organizational levels. In earlier post I mentioned horizontal and vertical alignment, to adress these different dimensions.

An IT engagement model has been introduced, which is defined as the system of governance mechanisms that brings together key stakeholders to ensure that projects achieve both local and company-wide objectives. This engagement model consists of three general components.

  • Company-wide IT Governance – decision rights and accountability of comapny level and business unit level stakeholders to define company-wide objectives and encourage desirable behaviour in the use of IT
  • Projectmanagement – a formalized project management process, with clear deliverables and regular well-defined checkpoints, that encourages disciplined, predicatable behaviour for project teams.
  • Linking mechanisms – processes and decision-making bodies that connect project-level activities to the overall IT governance.

The first two are well recognized. What CISR has found to be the ‘missing link’ is the third element: Linking Mechanisms. Linking mechanisms are at the heart of a company’s IT engagement model. They enable ideas to flow back and forth between company-wide IT governance and project management. Linking mechanisms ensure that high-level governance decisions are understood and implemented by project teams, so that projects help to incrementally achieve the company’s objectives and the company learns from every project.

An effective IT engagement model enables traditionally independent stakeholders to negotiate between competing demands, influence one another, learn from each other, develop trust across the company, and work collectively on achieving local and company-wide objectives. It ensures that project solutions are not developed by any single stakeholder, but rather, result from multiple stakeholders working together to resolve competing interests (e.g. tactical versus strategic, local versus enterprise-wide, new versus reuse).

All three components of the IT engagement model are important sources of mechanisms. Engagement mechanisms take the form of roles, procedures, decision-making bodies and work-groups.

Engagement Mechanisms:

Linking mechanisms can be found in three categories: business linkage, architecture linkage,  and alignment linkage. Business linkage mechanisms link projects to company- and business-level strategies. Architecture linkage mechanisms link projects to enterprise and business unit architectures. Alignment linkage mechanisms link IT with the rest of the business, particularly at the business unit level. There are all kind of mechanisms possible. In the enclosed figures, some of the most prominent are shown.

CISR found out that firms with a stronger level of alignment distinguished themselves by engaging IT and non-IT stakeholders in three areas:

  1. Establishing and maintaining a daily level of conversation between IT and non-IT peers
  2. Ensuring that different projects link to corporate goals and shared resources, and
  3. Asessing and learning from project performance.

These firms had a key mechanism in each of these three areas. These were:

  1. Business-IT relationship managers:  A business-IT relationship manager is a formal role in which an individual engages with IT and a specified part of the business.
  2. Program Management Office: this typically consist of a central group that coordinates resources across projects, ensuring they collectively contribute to corporate level objectives.
  3. Post-implementation Reviews: PIRs typically consist of a group that essesses a project’s key targets and deliverables at the conclusion of a project or project cycle.

In following posts, I will dive deeper in the topic of IT engagement in relation to Alignment.



Fonstad, Nils, and Robertson, David: Engaging for Change: An Overview of the IT Engagement Model, CISR Research Briefing, Sloan School of Management, Massachusetts Institute of Technology (MIT), March 2005.

Fonstad, Nils, and Robertson, David: Transforming a company, Project by Project: The IT Engagement Model, CISR Working Paper 363, Sloan School of Management, Massachusetts Institute of Technology (MIT), September 2006.

Fonstad, Nils Olaya: Engaging Matters: Enhancing Alignment with Governance Mechanisms, CISR Research Briefing, Sloan School of Management, Massachusetts Institute of Technology (MIT), December 2006.