Business / IT Collaboration Model: A Practical Approach

Registration is free. Login or register to view/download this content.


Business Relationship Manager - Product Lifecycle Management, Chevron Corporation

The collaboration between the business department and IT department of an organization has been subject to research by many organizational professionals. Some companies manage things very well, others have their problems. This article will not provide you with a silver bullet for business & IT alignment, but provides some practical directions for establishing a business driven collaboration.


Although many approaches towards collaboration have been defined, some formal and others more informal, none of them seems to be that successful to become a general practice. All have advantages and disadvantages, making them work in some of the companies, but not in all.

The quality of the collaboration often depends on

  • The way the different parties understand each other
  • The way all parties succeed in managing each other’s expectations

A key driver for many companies is increasing business value of the internal processes. This implicates an increased attention to the efficiency of the internal business / IT collaboration model. The following paragraphs provide how business processes can be a valuable asset in improving the efficiency of the business / IT collaboration.

Common Understanding

One of the key elements lying at the base of collaboration is mutual understanding. If the different parties that are required to work together are not in line it is very hard to achieve a successful collaboration. In the case of business and IT, the presence of a ubiquitous language between business and IT is a mandatory precondition enabling collaboration between both parties.

Although this common understanding seems easy at first sight, it is often the first thing where things start to go wrong. Having a shared communication language is a good start, but insufficient. Business people and IT people have different backgrounds. They think different, and use words and statements that do not necessarily mean the same thing. An example: if a business user wants to be able to enter a new sales order very fast, is he then talking about the way the offer should be entered in an automated system, or is he/she talking about the response time of the system once he clicks the OK button of the order entry screen? He is talking about performance, but the perception of performance varies depending on the party and the context.

In the last years, many business domains have started an approach to model and optimize their operations. These initiatives (often referred to as BPM, BPO, BPI) take a look at the way the business operates, model this way of operation, and do some form of analysis and improvement on the operations. Where successful, it established a shared and commonly understood language between the different business domains of a company. A shared language that includes not only the behavioural aspect of the business (who does things, and how it is done), but also the information aspect (what is a sales order, what is a customer, how do they relate, …) and the business rules that apply to the processes and information (e.g. when a customer can place an order, how to calculate discounts, …).

If this shared language in the business is present, it will benefit your company if you manage to port it all over your organization, including the IT department.

In all organizations where IT is not the core business, IT has a support role. It merely supports the business in doing what results in company profit. The quality of this support will therefore depend on the way IT manages in understanding the operations of the business. From this point of view, it is very hard for IT to impose an IT language (such as UML, Use Cases, etc) to the business as the language to use towards IT.

However, introducing business processes in an IT department as a valuable asset they can work with, is not as hard as you may think. Most IT departments do model the behaviour aspect, the information aspect, and the business rules, when it comes to modelling business requirements for automation projects. Providing them with well modelled business processes, will majorly facilitate and speed up the analysis work they have to do anyway.

Figure 1

Expectation Management

A second pillar of collaboration is the management of mutual expectations. These expectations can be very wide, but in essence they will cover the answers to these questions:

  • Who will deliver what?
  • By when?
  • How will this be delivered (format, quality)?
  • How will acceptance of the delivery be done?
  • How will intermediate communication be arranged?

The basics on how to make this work (process aspect) are handled in every book or training on (project) management. The process needs to work with a commonly understood baseline serving as content and context for the mutual communication.

Again, the business process model can serve as a reference base for managing expectations. They offer an understandable framework that can be used by both business and IT to pinpoint highlights, problems, attention points, but also to report on the progress of automation, report & communication of service interruptions, etc. Reporting on service levels or service interruptions based upon the business process model will improve the readability of the service report at business side significantly.

When a business process model is used as reference base, imho, the importance of the implementation methodology also diminishes. Evangelists often promote certain methodologies such as agile to be the way IT can prove business value. However, with a proper process model, the business has a clear overall view on what they want to realize and where the important points are. Whether a waterfall, iterative or agile methodology is used to make this happen, it is just a matter of delivering what is defined before, in a timeframe acceptable for the (business) customer.

Similar Resources