Whether an analyst resides on the business or IT side, he or she is ALWAYS in the middle. For a Business-side analyst to be effective, there must be an understanding of how to interact with IT and a knowledge of what is expected when requirements are turned over. The inverse is true for the IT BA, who needs to understand not only business domain and operational knowledge, but also the organizational structure of stakeholders and business units. This places either type of analyst in a very precarious position that requires finesse when the time comes that the analyst must deal with issues that cross over the fence.
The analyst needs to manage the communication that MUST occur between the two operational entities. There are techniques in place to help the BA that are tried and true. As with the attitude issues and resolutions I wrote about in my previous post, technique is only the vehicle to achieve the goal. Willingness, knowing when it is appropriate and being able to cross boundaries to assist who is often considered “the enemy” is the critical skill. Unfortunately, there are times that even though the desire to assist a project partner is evident, the organizational boundaries of ownership prevent that from occurring.
Executive Management, responsible for resource allocation expenditures, may view this as dollars wasted, while not realizing that by helping “the enemy”, the analyst is providing huge value their own team. Very often the psychology and rules of corporate management strictly govern what a manager can or should do with a resource. Briefly to this point, there may be tight guidelines that prevent the formal sharing of resources or a resistance to allow resources to spread their wings for the good of the department. The more they spread, the greater the loss of control. These are ownership constraints that prevent collaboration on projects. It takes a confident manager to overcome these types of obstacles.
A recent project I worked on as an IT analyst is one that comes around twice each year to address market conditions. It’s a revenue producer and is highly visible, cannot fail and is very fast-paced. The last round had a business stakeholder who wasn’t new to the organization, but was new to the project. Things started off fine, but as the complexity and speed of the project grew, this person began to struggle. So here’s the dilemma…do I take time that I don’t have away from my primary duties to help this person out? I bet you’re familiar with a few of these:
- “They’re business. We’re IT. Their own people can figure it out.”
- “That’s their problem, not ours.”
- “If that’s the best they can do, it’s not our problem.”
- “So? We have enough of our own problems. What would you like me to do about it?”
Well, enough of that. Let’s step back here and look at what is going on. 
We are seeing the initial arc of the circular relationship between Business and IT. The customer has project (problem/opportunity) that they have funded and IT is working on it for money (getting paid). Continuing this path will maintain the current relationship, but it does nothing to make it a successful one when issues arise and one side or the other cannot fulfill its part of the equation. The second arc brings both sides together in collaboration in which the two rely on each other for success as a whole. Situations like the above are looked at as problems for the “other side” to worry about, but aren’t they REALLY opportunities in disguise to come together?
To continue, the customer and I began to work very closely together. There was much back and forth collaboration, many conversations, lots of hand holding, and paired testing. When this person didn’t know who to contact to answer a question, I provided information. When pieces and parts of requirements were disjointed or missing, I described why it couldn’t be delivered like it was, how to fix it and provided templates and guidance to help.
I spent maybe 15-20 hours in small increments over the life of the project with this person one-on-one. Little stuff like making myself available, answering a few questions, calling to see if I could assist, and providing education made big differences in our working relationship and the deliverables coming over to IT. This isn’t superhero stuff that many teams seem to gobble up; it’s just good customer service. What happened out of all this was a gracious, more confident stakeholder, better deliverables that arrived on time, and a stronger working relationship.
What did NOT occur was that my manager didn’t berate me for “wasting” my time, because there’s a prior proven understanding of the value of this exercise. When IT receives better quality deliverables from a customer or stakeholder, IT struggles less to define what is really needed and is able to meet its own deadlines and produces less defects that require additional defects. That’s important to IT’s bottom line; we’re more productive and more efficient. Customer dollars that may have been spent fixing defects now appear as profit.
If a resource can identify opportunities for improvement, there must be flexibility and autonomy to take advantage of it. There must be management that believes in the value of reaching out to the partner, because the monetary and non-monetary benefits far out weigh the cost. Financial frugality and accountability are important aspects of running a solid business, but ownership has its place. Getting the job done is an activity that any level of manager would defer to, no matter who signs the check.
….and those arcs I spoke above….they’re much stronger when they form a circle.
Pingback: Twitter Trackbacks for Making it Work Between Business and IT: Overcoming Analyst Ownership to Kick-Start Collaboration [guest post] [bridging-the-gap.com] on Topsy.com
Hi Doug
I enjoyed your post. My current assignment is a GOOD example of where we bridged that business to IT divide. My current employer is very large, risk-averse and loves process. Unfortunately, we also have this scary concept of IT (Business) analyst and Business analyst. They should be two BA’s just working together, however, what happens is that one draws up the reqts spec and handles the business stakeholder relationships while the other one draws up use cases and similar and handles IT stakeholder relationships.
On a recent assignment in a smaller business unit, we agreed to genuinely collaborate from Day 1. The upshot was that we have two business analysts, one on the IT payroll and the other on the business payroll. We just split the work in a sensible manner and work together constantly. I am not ‘shielded’ from the business stakeholders and he is not ‘shielded’ from the IT stakeholders.
This is a much better way of working but points out how important organisation culture is and how it can work against you.
Does anyone have similar experiences or is it just me?
Alex
Doug – Great and really detailed article. I look forward to reading more of your posts.