General Business Analysis

It your responsibility to make sure that you understand what the impact of GDPR are going to be for the data that you work with. There is no doubt that this is going to shake things up in the data protection world for both organisations and individuals. We will publish another blog that will tell you what steps as a business analyst you need to make sure that you and your organisation do not breach GDPR regulations.

How do you become a business analyst and where do you begin?  So you want to cross over to the land of analysis? A land of ‘schizophrenic’ people who need to possess multiple skills and make meaning out of ambiguity. You'll need to break down complex problems into bite-size chunks that can be easily understood. You'll also need to manage different stakeholders and break down knowledge barriers formed by these stakeholders. (Most having been in their organisations for decades) Finally, you'll need to develop a thick skin to stand in the firing line.

 

During a recent presentation to business analysts, I used one of my consulting projects as an example of how to apply an analysis technique we were discussing. A member of the audience asked, “What made this company hire you as a BA consultant to tackle this project, when they already have so many in-house product managers and business analysts on their teams?”

In his classic book Flawless Consulting, Peter Block described three types of roles that consultants might take on: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction when working with clients and a different source of satisfaction for the consultant. Business analysts can engage with clients in the same three modes. This article describes some of my experiences with these three modes of consulting engagements.

Given the speed of change, it is really tricky to predict what trends will grow in popularity or relevance. I am sure whatever emerges will seem obvious in hindsight, even if it would have been difficult to foresee. Yet, I have always thought that making predictions has a useful place in that it creates a conversation and it creates debates. So, what follows is designed to provoke discussion, and is intended to represent ‘potential trends to watch’.

As, more and more companies start to embrace cloud technology, it is vital that business analysts are able to identify the cloud service that is required to meet business requirements. As business analysts, we are often criticized for not getting involved in the technical side of things. However, it can be difficult to make decisions on technical side of things, if you don’t understand the language that is used in this space.

A BA walks into an elevator, is joined by an executive, and suddenly the executive asks the BA, “So, what are you working on these days?” (Sounds like the start of a joke ...)  Most business analysts, due to their project success focus, think of requirements management when questioned about their work. So the BA responds by describing the features of a business solution that the BA is currently working. The BA seldom mentions the associated business benefits with the work (i.e. why the work is vital to the business). Unfortunately, the BA ignores the first rule of conversation: know your audience. The executive asking the question is more likely to understand and be interested in the business value provided by the work, rather than the solution features.

There are some practices that can practically make our life much easier if we adopt them early in the project.  This fourth article of the series “ Business Analysts and Change Management - What we need to know” addresses the minimum that we - as Business Analysts - might need to know about change management, but this time at organizational level

Gherkin is a language used to write acceptance tests. BA's use Gherkin to specify how they want the system to behave in certain scenarios...  It’s a simple language. There are 10 key words (e.g. Given, When, Then). Because it’s a simple language, it’s understandable by the business. As well as being understandable by the business, Gherkin can be understood by an automation tool called Cucumber. That means Cucumber can interpret Gherkin and use it to drive automated tests. This links BA requirements to automated tests.

Ground rules are essential for any meeting. It may be what makes the meeting a success or failure. As a Business Analyst we are constantly organizing and facilitating meetings of various sizes to progress through the SDM (System Design Methodology) for a project. It is important that all sponsors and participants of the project understand what to expect from the upcoming meetings to be organized. Ground rules are generally discussed during the kickoff meeting, documented, and then displayed moving forward.

Disbenefits are changes to on-going operating costs as a result of a project; they could be perceived as positive or negative. These disbenefits are included in defining the Total Cost of Ownership rather than a component of project cost, and is more of a focus for controllers due to its on-going nature rather than one time project savings and revenue.

The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. 

While BABOK and other sources include Behavioral Characteristics as an essential underlying competency for business analysts, many analysts may have only a vague idea of how it applies to their personal work environment, or even exactly what behavioral characteristics are, so let’s define those first.... The term behavioral characteristics simply refers to an analyst’s workplace ethics and character. 

I take the approach that as Business Analysts, the line between requirements and design is an imaginary line. We need to be pragmatic (abandon purist thinking) and not be afraid to wear the design cloak, to adopt design thinking. 

 

So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.

---

Author: Michael Roy, Business Analysis Professional / Requirements Leader

Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.

 

I bet everyone has, at least once in their career, heard the expression: