Peer relationships


Via Steve Jones, here’s another story that perfectly encapsulates the power of realising that a partnership approach between IT and business can drive real improvements in the return that you get from IT investment.

In short: Steve’s associate (working in IT) found that a project he was responsible for wasn’t getting the business buy-in that was required to make the project a success. So he cancelled it.

This “support” thing cuts both ways. We all know about how IT has to support business needs – but when you create a contract, both sides have obligations to fulfil. For too long, IT teams have let business teams get away with not keeping their own implicit obligations.

Perhaps one solution is to formalise business teams’ obligations more explicitly in “service contracts” when IT projects are created, or when big changes are requested. Has anyone done this in an internal IT context, or even an outsourced IT context? What did you find?

One of the the themes that came up time and time again in our interviews for the book was the importance of getting out of the mindset that the IT organisation is in existence to blindly serve requests from the business.

Neil M dealt with this one a little in his last post. And now from Mike Kavis and James Taylor, via the ever-smart Todd Biske, there’s another anecdote that further shores up this argument.

Yes, the IT organisation is there to serve the business. But serving doesn’t imply subservience. Quite often it means asking tough questions and working out the best way to say “no”.

I just came across Steve Jones’ post, Nodding dog alignment – the perils of aligning to people not business, in which he points out the sad reality that many IT organisations which believe they are aligned with the business aren’t actually delivering value. Why? Because they are aligning with the wrong things. Instead of focusing on business goals they focus on the individuals who have those goals with the result that:

the IT department just turns into a nodding dog and says yes to all requests made by anyone who can claim to be a business person. This is what leads to hideously configured packages because “the business said so” and to a fragmented IT estate and ever increasing IT spend for ever decreasing business value.

This issue is something that came out strongly in the research for our book (the perfect Christmas gift 😉 )and is reflected in two of our principles for effective IT-business alignment.

First, the IT organisation must establish a peer relationship with the business, rather than a supplier-customer relationship which Steve flags. It’s about shared accountability and responsibility and, in much the same way as a P2P network, involves dynamic interactions controlled through a set of protocols (or governance policies and procedures) in accordance with objectives and constraints (business goals, budgets, people in the IT-business alignment case; file downloads, network bandwidth and latency in the P2P case).

Second, it’s not about working on the basis of “he who shouts loudest”. Rather it’s about working towards a set of goals and objectives that are coordinated and agreed by the combined business and IT team.

As Steve so aptly puts it:

Business alignment isn’t about people alignment.

I was talking earlier on to one of the people we interviewed for the book, outlining the main findings and getting some feedback. One of the main topics we focused on was the nature of Enterprise Architecture, and what characterises EA work “done right”.

The person I was talking to relayed a conversation they had with a client recently that was interested in becoming “Zachman compliant”. The client was under the impression that if they could do this, it would be a stamp of approval that they were “doing EA well”.

I’ve seen things like this myself from time to time, and it’s worrying. Organisations set up EA teams that are naturally inclined to focus on modelling technology landscapes and so on, and that focus more on the outputs (models) than on how they arrive at those outputs.

The problem here is that the process of EA is at least as important as the outputs. “EA done right” is as much about how you conduct EA work, as it is about what you produce. EA done right involves architects engaging in truly two-way discussions with stakeholders in IT and business – sharing ideas, learning and also communicating what’s been learned so far, so everyone understands more. EA done wrong involves architects sucking ideas from the brains of “users” and not giving anything back. The architects learn more but very quickly you end up with a fundamental disconnection between business and IT and you’re no closer to developing a common language.

And this brings us back to Zachman – because although ZIFA goes further than just promoting the Zachman framework (it’s starting to promote the importance of developing a good process) there are an awful lot of people out there who just focus on the framework. And although the framework is  a great way of categorizing models and knowledge, it says nothing about how that knowledge is arrived at.

If you just focus on getting good at filling in the cells in the Zachman framework, that’s no guarantee at all you will be doing EA in a way that helps IT or the business.

Here is the audio of what we hope will be a series of podcasts with CIOs who’ve instigated work to improve IT-business alignment in their organisations. The interview is between us two Neils (me and Macehiter) and New Zealand-resident Peter Burggraaff, until recently the CIO of NZ retail chain Farmers Trading Company. Peter talks to us in this 31’34” podcast episode about his initiative at Farmers and the outcomes he achieved.

In the podcast Peter explains that Farmers was in a situation where IT cost was way too high, and although the IT organisation was doing some things well (particularly managing operational services) it wasn’t seen as a real contributor of business value as Farmers looked to put some big business changes in place. He goes on to explain how he started to turn this situation around and built a solid and trusted relationship with Farmers business management. Thanks Peter!

If you’d like to get involved in this programme of podcasts don’t hesitate to let us know.