Bridging the gap between IT and Business

Bridging the gap between IT and BusinessBridging the Gap between Business & IT
System’s development is often characterised by a strained relationship between IT and Business / “the us and them syndrome”. The parties may not trust each other’s motivations or appreciate each other’s needs and constrains. In reality though, they have a common objective; a solution that works, easily and cost effectively.

As Business Analyst you may often find yourself torn between the two areas and to survive you must be honest. Sharing all relevant information with the stakeholders and telling the truth without blame or judgement to promote free and informed choices. Such an ideal environment isn’t always achievable. In fact, none of my suggestions are likely to work if you’re dealing with truly unreasonable people.

Defining Business requirements early in the project will clarify the prospective benefits for both the business and IT. The participants also need to realistic about costs and project constraints.

It’s not unusual for an analyst to solicit input from users only to be told, “I don’t have time to talk to you. You should know what I need”: However, project success is most like to occur when the analyst can forge an effective collaborative relationship with key business representatives. Identify individuals who could serve as the voice of the business for each business event, then engage them in discussion of their needs.

Business representatives might hesitate to participate in the requirements exploration until they know exactly what you expect from them, document project responsibilities clearly. Insufficient user involvement is well established as a leading cause of software project failure. Point this out to reluctant business users, who don’t want to spend time on requirements discussions. Remind them of problems you have experiences on previous project that can be attributed to inadequate user involvement. Nearly every organisation has horror stories of new systems that didn’t satisfy user needs, didn’t provide expected functionality, performance expectations or duplicated the shortcomings of the preceding systems. You can’t afford to keep rebuilding or discarding systems that don’t measure up because the user’s needs weren’t sufficiently understood. If the business won’t commit to reaching a shared understanding of their requirements, it might you’re your best interest to avoid that project.

This week’s archaeological dig:
Posh:
In the days when the wealthy traveled to India by ship it was customary for passengers to book quarters on the cooler port side of the vessel on the outward journey, and the similar cooler starboard side on the homeward trip. Hence port/out (PO) and starboard/home (SH) gave rise to the acronym POSH. Today we refer to people of class (Spice Girls notwithstanding) as being posh.

Business Analyst Communication

Business Analyst and communication

Communication and the Business Analyst

The Business Analyst communication becomes the middleman, bridging the gap between vague business user notions and clear development specifications. This analyst must first understand the user’s actual needs and then define a set of Business Requirements that allow designers, implementers and testers to build and verify the system. If you aspire to be an effective analyst, become proficient all forms of communication, including listening, speaking and writing. As you interact with user representative, understand their objectives of the proposed projects and their concerns about the business. Learn to use the vocabulary of the business, rather than forcing your business users to understand your jargon. Include business terms in your Data Dictionary.

Don’t be afraid to ask for clarification; business users should not expect every analyst to be a business expert. You might explain that you’re not completely familiar with their business and that is why you don’t fully grasp what they are describing. This approach sometimes makes the business more willing to help because they can see that you’re making a real effort to understand their environment. This is where models become imperative, as there is no ambiguity in modelling rules.

We all think within our own frame of reference, which is based on our own experience and knowledge. Take the time to learn about your business user’s environment and understand how they prefer to communicate. Watch out for assumptions that underlie either the users’ expression of needs or your own thinking. Avoid imposing your personal field of understanding on what you hear the user say.

Requirements development should lead to an understanding shared by the various project stakeholders. The analyst is responsible for writing high-quality and well-organised requirements that clearly express this shared understanding. Writing documents that business representatives can understand and verify, is a challenge, which is why I recommend that you use models (a picture tells a 100 words). Support the picture with narrative text, to further clarify understanding.

Today’s archaeological dig:
Port and Starboard:
Originally, the old sailing ships (like the Vikings), didn’t have a rudder, and were steered by a board on the right side. This came to be the “steerboard” side; the other side was called “larboard” at first, but since the side with the board couldn’t be against the dock, this other side, the left, became the “port” side.