I’ve seen it again and again, the same business & IT anti-patterns in organisations with an internal IT department.

According to Wiki, an anti-pattern ‘is a general reusable solution to a commonly occurring problem, but is ineffective and/or counterproductive in practice‘. Wiki contains a nice list of anti-patterns but IMHO there should be a ‘Business & IT’ category with some additional anti-patterns.

IT arrogance, ‘we do the analysis, we know what the business needs’

This anti-pattern usually starts emerging after a couple of failed projects where the business people had trouble specifying their needs. To prevent changing requirements, more and more emphasis is placed on analysis, change management and planning. Sadly, during that time the responsibility for analysis shifts from the business people to the IT people. The business is still accountable for determining requirements, but most of the actual work is done by the IT people.  As a consequence the business is less and less involved in the change process and also is even less skilled in determining their needs.

The end-state of this pattern is that the IT department has little faith in it’s customers capabilities to define requirements and doesn’t even try to collaborate. I’ve seen this a couple of times. A large and complex project is conducted with no customer involvement at all, because the IT people think they know what’s best.

Of course these project have there share of failures, but somehow these failures reinforce the notion that more analysis is required and that it should be done by IT specialists. Probably because each customer interaction leads to more uncertainties and not less, whilst additional analysis documents (seems to) provide work packages that can be planned and controlled.

Sales dominance, ‘we set the pace because IT is incapable to do so’

Sometimes another Business & IT anti-pattern emerges within sales-dominated organisations where IT has an important role in creating a solution. Time to market is critical in selling solutions and can make the difference between sale or no-sale. Some organisations have a culture where refusing a deal is not an option, where conversations only go one way; ‘how can we make this happen? ‘. This creates pressure on the IT team to accept projects with little chance of success within the given time frame or budget.

The result is that during pre-sales phase the IT team tries to claim more time in order to create a solution and that sales tries to limit the time (and budget) in order to make the deal. Of course sales is always right, so the project is started anyhow. The IT team does not want to fail and tries to deliver on time and within budget (but not without some personal sacrifices). Due to the ’Halo‘ effect and reverse halo effect, each time IT delivers on time it’s the sales team that was right, each time IT fails it’s their fault.

The end-state of this pattern is that a pre-sales teams with technical specialists is created which determine costs and time for each bid. This pre-sales team answers to the sales team. The IT team ‘only’ has to create the solution once the bid is accepted. The anti-pattern is reinforced each time something goes wrong during the project because ‘solutions’ for IT problems are implemented within the pre-sales team (for example by transferring experts from IT to pre-sales).

Anti anti-pattern approach

Both anti-patterns have in common that a stronger party dominates a weaker party and that this dominance is made even stronger. In the short term this might resolve some immediate issues, in the longer term it is a bad thing. You wouldn’t want to have such a relationship in your private life, would you?  By making one party stronger then the other party, the weaker party becomes even more weak. An unhealthy situation at the start deteriorates and becomes even more unhealthy.

A more effective approach would be to make the weaker party stronger until the collaboration becomes balanced and healthy again. It is the more difficult road to follow but leads to better results.