Bridging 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:
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.