Moving on, we will investigate the importance of the business analyst’s often delicate relationship with individual stakeholders. A business analyst is a facilitator of change, and in affecting these changes within a company, the analyst must interact with multiple stakeholders of varying personalities. When identifying and delivering the necessary changes within a business, the analyst must develop and maintain a relationship with each individual stakeholder. Each stakeholder will wield a different level of authority within the company and hold a certain amount of power over those changes that are coming into effect. Noting this, the analyst must take part in a careful balancing act, juggling these relationships in order to facilitate change with minimal difficulty.
"I’ve observed a disconnect between stakeholders from the Pentagon and the engineers building the system. I’d like to show you a new technique called Behaviour Driven Development (BDD), which can help us explore how software will behave BEFORE it’s built”.
Operational business decisions happen every minute of every day in your organization. You’d like to think that business managers can truly manage them. You’d also like to think that the results of those decisions are comprehensively correct, consistent, traceable, and repeatable (high quality). But are they? Based on real-life evidence I strongly suspect they often are not.... When IT professionals talk about “decisions” they often mean branch points within the deep systemic logic executed by machines – classic decision points in data processing. I don’t mean that either.
The difficulty of gathering information and establishing requirements, owing to the chaotic nature of the business world, is clear to see. Every business analyst must overcome their own Mad Tea Party if they are to be successful in carrying out their mission. As Alice is confronted with the unreliability of the Hatter, the March Hare, and the Dormouse, so too is the analyst faced with unreliable stakeholders. In her attempts to gain an understanding of the never-ending tea party, Alice’s use of elicitation is effectively useless in the face of endless riddles, an unconventional sense of time, and undependable characters. Analysts find themselves in comparable environments with various degrees of chaos and unpredictability.
Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic. When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us