Us Against Them

In some environments, going up against an adversary is not only a good thing to do—it’s expected in order to win. How­ever, in the sometimes contentious world of development, it’s almost guaranteed to cause a project to fail. 

There is a long history of business organizations feeling shortchanged by IT organizations based on perceived value and incorrect assumptions, such as when there is no compre­hension of the effort required to imple­ment what is thought to be a simple change. These are dangerous character­izations, and without good communi­cation between those who need support from a technical organization and those who provide it, there is a great chance that success will not be achieved. 

Fortunately, the role of the business analyst is becoming more prevalent and better understood. While most people perceive a business analyst as necessary to gather and document requirements, many overlook an analyst’s ability to function as a liaison between business stakeholders and IT delivery personnel, which creates a positive relationship between the two. This is a critical ca­pability and one that requires advanced communication skills that include ac­tive listening, relationship building, and collaborative facilitation. 

A business analyst is in a unique po­sition both to understand the needs of stakeholders and to protect the interests of the delivery organization—and it re­ally doesn’t matter to which side of the business/IT “fence” the analyst reports. The analyst’s skills provide a means to bridge gaps by exposing differences with explanation and fa­cilitation, fostering constructive dialogue and collaboration, and breaking down barriers to success. There is probably no other position in an organization that understands the stra­tegic goals of business operations while concurrently recog­nizing the pressures and limitations of IT delivery. That means that, in the end, the organization’s executives have their spe­cific interests protected at the individual project level, which, in turn, ensures a healthy balance in the handling of develop­ment lifecycle pressures. 

Fostering a collaborative approach to bring stakeholders’ often conflicting interests to bear, the analyst can undertake exercises and utilize techniques to pull these forces together to achieve a common goal. It is the common goal that is often forgotten within an organization when business and develop­ment teams head into the project arena for a battle that was completely unnecessary in the first place. 

There are a couple of specific ap­proaches that an analyst can take to bring harmony to an organization. 

IT-side Analyst
There are several things that can help strengthen the relationship with business-side partners. For instance, providing an explanation of seem­ingly superficial problems brings a more thorough understanding to the problem domain. Often, what ap­pears to be a simple fix is in fact much more complex. This is a divisive point between business and IT, as one side feels it isn’t getting value for dollars spent and the other claims that there is no understanding of what is really involved. Without some cursory hand­holding and explanation, the division broadens and tensions build. 

This scenario is less evident in an agile environment that has the business stakeholder embedded into the development team. In IT shops that employ the waterfall methodology, it can be a huge problem. Often, there is a perception of someone just hammering out a little code and “presto!” the change appears ready to use in production. Without realizing that there might be additional analysis, design sessions, test creation and execution, required documentation, and release or deployment activities that all require time from resources, the business stakeholder may have trouble understanding why IT takes so long to produce changes. 

The lack of collaboration and communication exacerbates the perceptions and emotions that grow out of the lack