Posted: 22 February, 2016
Link to source
Stop me when you’ve heard this before. Our IT group knows that customer satisfaction externally – with the business units and even specific IT champions – is really suffering. People start to talk about “client delighters” and “low-hanging fruit” as a metaphor for getting quick, small, and highlighted wins to point to back on the scorecard. Then someone gets the idea to staff a new, business liaison role for these customers, a group of folks (preferably entry level inside of IT) who can consolidate demand into manageable streams for IT.
This post will discuss some of the lessons learned in constructing that role – that of the business relationship manager or business analyst – specifically in the IT organization. When done thoughtfully about the culture change desired, this role can be extremely impactful to overall satisfaction around IT services. When done poorly, it can fizzle out in a pool of unmet expectations. I’ve seen this and helped implement this role at a number of larger companies, even ones who are pretty strapped on the IT funding side (read: not your leaders in the digitalization-of-the-business space). I would suggest that the reasons this can underachieve are rooted in a lot of the pre-existing conditions within IT, which therefore need to be challenged to make overall satisfaction go up. If this sounds like “we’ve always done it this way” needs to go out the window, then maybe you’re half way there.
How should we scope this relationship role? Fundamentally, it is a role where we expect to have a dialog – representing the customer’s needs into IT, and the IT roadmap as the echo back to that customer. If we see this as a conversation rather than a telling exercise, we’ll avoid what I saw at one Fortune 50 company – no names here! – of the junior folks being placed in the role to gain adoption of what IT had on the shelf already. They were evangelists and expected to ask the question “why aren’t you using service X more?” This not only exacerbated the relationship with the business, it actually caused very embarrassing problems during portfolio planning one year. The portfolio plan of a roughly $400MM annual budget was done by the architects in a room with an Excel spreadsheet up on the wall. Everyone argued for their projects, but the analysts were seen as too junior and not included in the process. One line-item – for a collaboration system – was deemed of too low value to be implemented so the analyst was told the outcome and relayed the message to the business unit. The BU hired a consultant, who pointed out the obvious, that the company already had a collaboration system – in IT nonetheless, for all the BU’s to benefit from – which was underutilized and that the customer didn’t need to pay the consulting firm to develop something that already existed. The IT leadership were appropriately “shocked!”
In another example, the main business unit of the company was used to paying an “IT tax” every year – common to a lot of organizations, the IT budget is constructed out of a flat tax of a rate per month per user which can then be used for new projects, maintenance and general IT expenses. Their liaison lived I the business unit and was not an IT resource. The level of frustration with IT not prioritizing to the proportional amount of the budget that the BU contributed led to the vice president asking the CEO if they could get out of paying the tax, whose spend so misaligned with the balanced scorecard needs that it was basically lost capital.
Some good examples, you say, but what should this role look like? I’ll start by saying that there are three components to this role:
An understanding within the business unit of why this is useful to them
An understanding within IT and finance and procurement and security as to why this role is pivotal to them
And the role mechanics itself – how we hire & train for it, how many we have, and what processes it contributes to.
Though the first two are organization dependent, I would argue that the most successful BA communities have had one each of an executive IT sponsor (with a CIO commitment and scorecard element) and an executive business unit sponsor (with an understanding of the business trends and how funding proceeds from the company’s balanced scorecard). This is not trivial to accomplish because it means that the handshake between IT and a business unit has to start on the right foot – compatible personalities, goals to achieve which both sides recognize, and potentially changes to other long-standing traditions (such as converting from “tax” funding to direct-aligned funding).
The role itself has a number of components, which I have put on the graphic below, including methods of regularly assessing demand in different areas, knowing the current state, working with roadmaps and driving from ambiguous discussions of “what do you like?” to “how exactly is this service working for you and give me two things to improve on.”
Figure 1. A business relationship role as conversation facilitator
Probably one of the more useful aspects to consider when implementing this role – which the CIO may already have a sense of – is that IT increasingly is one of several options the business unit has for embracing digital projects. Some groups outside of IT may already have competence in building and deploying solutions in their work process or unit – the choice to do it yourself, without going to stodgy old IT has existed for a while (arguably increased with the pervasiveness of the “cloud”). Some business units may have their own contractors or systems integrators – almost a captured IT department to themselves. IT rightfully sees this as competition – the question from the CEO is whether there is value in having projects exclusively be routed through IT, or only in certain scenarios. What is the value of IT? Can the business analyst help strengthen that proposition for a central skill set for projects, and central contracting for services, and centralized/integrated systems?
Part of the answer here may be in one of the processes the BA can influence – portfolio planning. Architects may argue what is urgent? What is cheapest to prioritize? What is required or time-critical? Or even what is on the strategic plan? The goal in the mind of the leadership is to first off avoid any embarrassing mistakes. Though I’m not advocating doing something stupid, I do often talk about the need to avoid two budgets within the company. If the business funds something, they know it aligns to their scorecard (which comes from the board); if IT has a separate pot of money not guided by these principles and not attached to scorecard items, it is not providing a valuable service by definition to the company. We need (as IT collectively) to be more transparent in prioritizing the budget and willing to forego an upgrade which may increase risk for other projects which our customers tell us have greater impact to the overall bottom-line. In effect, we could move to a more reactive model for the operational needs and reinvest in strategic items through the guidance of the BA. Could we have a conversation with the VP of product design like “I know the network was out for facility 3 for 2 hours last Saturday, do you agree that the project we did for external collaboration more than made up for it?” Certainly a lot of us who have been in IT cringe at this sort of tradeoff – but we should not shy away from understanding the relative benefits of a more ambiguous solution, compared to the play-it-safe and just keep the lights on behavior we often fall into. Crises can happen, the IT dashboard is not (and probably should not be always shown to be) green: we may just need to explore better skills at communication.
Another quick note on the portfolio: not every project is phrased in benefits that are cost-reducing. To be good at business analysis, we have to be able to compare quantified benefits with different underlying metrics. A marketing project that is aligned at growing presence in China should not always fall below the server refresh to Windows 2012, avoiding $250K of maintenance costs. If the first project succeeds, revenue might grow by enough to fund #2. The converse is not true, but we often prioritize the latter over the former because we may not have an apples-to-apples comparison (in fact business cases from lines-of-business may rarely have hard, cost-reduction numbers, and may make IT projects seem even better!) The BA should ask the question to the customer – which do you want to do?
So, a few pointers on how to do this well. I would suggest the following as some key guideposts along the road of implementing the business relationship function:
Check your skills and take training where needed – Can the BA’s identify the needs and the trends in the BU? Can they construct business value propositions? Can they then help the PMO in framing the right objectives for projects and loop in the chief architect when needed? Do we need a couple MBA courses to learn the language? Secondary goals would include skill with understanding the IT roadmap: the main goal is to listen and understand.
Get the right level of tooling to start out with. The BA process needs a web site where they can collect inputs for the portfolio process, a business value template, and a pointer to the current service catalog. This can be as simple as Excel spreadsheets. Do not let the search for the perfect tool stop your organization from improving its satisfaction today.
Go back and check your work. Make a date to go back to the sponsors and customers and ask them how their metrics improved as the result of IT participation and support. If you don’t track the impact of the change, all that work of making good value cases really is wasted.
Business alignment can happen. The best way to do this is still through the relationship manager role, but IT needs to be willing to regularly have the hard conversation about what’s not going so well, in order to tune the engine for what’s next. This is the hard task of convincing the customer that IT has the conviction to be a service organization. Best of luck on your journey, and may the road rise up to meet you in your aspirations.
Comments