A common challenge of enterprise Business Analysts is the discovery, understanding, and description of requirements in the context of implementing packaged solutions. Management assigns us to projects with a predefined solution, and we struggle to figure our role when there seems to be no significant build activity. What are we supposed to do in this situation when there seems to be no need to produce standard requirement deliverables?
Put a typical Business Analyst in this environment and do not be surprised to hear the phrase “I’m not sure of my role.” Why do packaged solution projects cause discomfort?
A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry.
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.
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.
To be a great analyst, you’ll need to ask great questions. In order to ask great questions, you’ll need to remain inquisitive. Fact of the matter is, that if you are performing any kind of analysis, you need to become very comfortable with asking difficult questions. Questions that make people uncomfortable and questions that might even potentially expose unpopular answers.
Customer journey mapping is a great way to understand your customer intimately to provide insights into providing targeted customer experience that empower the customer positively to drive better business outcomes. This technique places the customer first with a deep emotional understanding, then looks backwards toward the experiences provided by the operating model, thus enabling good aspects to be reinforced and negative ones to be managed. It provides a complete 360 end to end experience of the customer to be realized driving customer insights, allowing more blue sky approaches to offsetting emotional deficits...
The scenario is simple: You’ve been tasked to determine the requirements for a new project. You’ve done your homework by reviewing existing documentation. And, now, you’ve arranged to have a meeting with a Subject Matter Expert (SME).
So, where does one begin on this path to enlightenment? When you talk to the SME for the first time, do you start by outlining everything that you think you’ve learned already?
People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation. This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.”
Maybe it’s time to get back to the basics behind requirements and why we need them. In this 3-piece article series, we are getting back to the basics of requirements. Our first installment addresses how to ask the right questions.
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us