This article is the third in a series of five about finding time to become more strategic (see part 1). This is one of the key challenges faced by anybody who has a partnering role on behalf of technology support functions in a company. Here we discuss a common symptom - "the Town Crier" syndrome, how we can become more than relayers of information; and how we can consequently improve our tenure in role by avoiding this syndrome.

A long time ago (!) I was new to the domain of Business Relationship Management, I took sections of my job description and tried to implement them as I assumed they should be. With mixed results. Example responsibilities include:

• ".... to represent the IT department at a senior stakeholder level...."
• ".... to ensure alignment between IT products and services and those needs of people within the business....."
• "....to keep the stakeholders updated and be a point of escalation on important issues...."

I came from a Business Analyst and Project Management background, and the temptation for me was to take those elements of the previous roles that seemed to relate to those responsibilities and do more of the same, rather than do a wholesale new approach on partnering. Without a clear understanding of the practical implication of the above responsibilities, I still find many BRMs:

• Presenting a schedule of attended meetings as a justification of "what they do", indeed a service they offer (!)
• Reporting service and project metrics on behalf of those people accountable for the delivery - often presenting bad news more than good.
• Reporting issues raised at business stakeholder meetings and escalating them within the IT department - being seen as an additional chaser internally.

To me, this is evidence of the "Town Crier Syndrome": Effectively becoming a mouthpiece and a relayer of information. Is there a justification for this role, and indeed is this the correct interpretation of the responsibilities above? I argue not, however having fallen victim to these aspects, I can understand why they happen:

• Organisation friction - the company gets so large, silo's form and keeping everyone on the same page becomes difficult.
• Translation - people don't speak the same language (business vs technical) and need someone in the middle to understand and relate the impact
• Distrust - people don't get along and need an impartial arbitrator to create the necessary communication.
• Lack of accountability - people are lazy and there is a culture of indifference.

So, in effect we find ourselves absolving the organisation's inefficiency rather than enabling it and helping it be better, quicker, cheaper. So guess what. Your information relaying service will be the first item on the cost cutting list once things get tough. The organisation will be just fine with it's dysfunction, politics and inability to translate without it.

Solving the root cause of these symptoms is a herculean task greater than what one person can solve by themselves, since typically these are organisational and cultural issues. So, do we sit back and fire off a few emails or go through a bruising tour of duty trying to keep opposing sides happy? Well, I suggest we manage what's in our control and influence: principally our conversation, what we do and the way we act.

What to do?

In principle, I argue there is a fundamental need for Relationship Management for an organisation of any size and that all stakeholders have a responsibility to contribute to the effectiveness of relationships and communication in an organisation. I assert "Relationship Management" means quite simply Relationship Management - not some convoluted extension or job title. What does this mean in practice? It means anybody who has an interaction or a communication with a group of stakeholders has a responsibility to communicate effectively and manage their relationships well. If indeed there is a person whose sole occupation is on relationships then I suggest they are accountable for the effectiveness of those relationships across the whole organisation. THAT is a fundamentally different remit and skillset. Following on from this a practical example would be, say, a Relationship Manager coaching peers and team members on relationship skills and advising on the best communication or engagement approach.  Who would accept such counsel in an IT organisation? Would that Relationship Manager be seen as a credible advocate?

Whilst you may not have relationship coaches on hand, I suggest you can move away from recording requirements to managing expectations. Consider the customer experience. It's not what is delivered, but how and in so doing how do people feel about the overall outcome and way they were engaged in it's delivery.

Understanding what those expectations are is fundamental to managing the relationship - it provides clarity and demonstrates progress if reviewed on a regular basis with your stakeholders. The most difficult expectations are the ones that are implicit, such as lobbying on their behalf for a service (potential conflict of interest?), being the first to know of the major problem, being knowledgeable and up-to-date on their activities. Other implicit assumptions can be inferred from understanding of person's principles, values and their agenda (e.g. I want you to respect me and my work). These are the expectations that often get missed yet may well scupper a good relationship.

Find the gap, close the gap: As a person who manages your relationships, your role is to expose these implicit and explicit expectations, gain agreements on whether they can / will be fulfilled, monitor progress and then close the gap in expectations. This causes you to ask: how can we as an organisation work differently to work better, faster, cheaper?

The other principle I adopt is those who are accountable for delivery, report the delivery - be they a service delivery manager, business analyst or a project manager, and indeed an enterprise architect. Our role as a Relationship Manager is oversight of the relationship rather than the content. If we need to get involved, it will be because there is a gap in communication style and expectation, or there is a difficult conversation that needs to be facilitated. The end goal being that you do not need to be party to the conversation if it is within standard parameters.

So what do you report?

Well, speaking purely about relationship management, then you'll be reporting progress on expectations being met or not. The idea being is to see progress on closing the gap in expectations and delivery of those expectations. This is not just about reporting. That expectation gap is the trigger for you to start thinking about how to close it. What pain points exist in how work is done within it and how can we remove them? - not just once by succumbing to the white glove syndrome (see the last blog post) but for good, through continuous improvement.

Just think of all that time you'll  free for yourself by delegating the reporting - you're not going to spend hours cultivating pages of PowerPoint, and attending meetings where the sole purpose is to update and inform. If you've enabled effective relationships, closed the expectations gap on issues which distract your business stakeholders through continuous improvement, then you have time to be more strategic.....Just think of the different, more strategic conversation you could have....

Easier said than done?

As with anything, changing the way you work takes practice. We offer workshops and coaching in relationship management. We wont turn you into a guru but we can certainly help with your peer's expectations and give you the techniques to be more effective.