Tag: Business Analysis

Honey, What is it you Really do at Work?

Written by Andris Grunde on December 16, 2013. Posted in Articles. 1 Comment on Honey, What is it you Really do at Work?

Are you sometimes at a loss to explain to your spouse, family or friends just what is it that you actually do at work as a Business Analyst? Do they ask you questions that you don’t quite feel comfortable answering?

And even if you have answered the question, you haven’t completely explained what it is that you actually do. More importantly, you haven’t touched on what value you give to your organization. Here is a scenario that you might recognize:

Q: “So, do you tell the programmers what to do?”
A: “Uh-hmm, no I don’t. I really describe and document the new system or parts of a system that they have to produce.”

I know that after trying to answer a question like this, and adding in some more details that I think are relevant, I can see by the long pause that follows my answer that I haven’t communicated much but have simply managed to overload the questioner with TMI; Too Much Information. I’ve answered the question but not explained myself.

But why be concerned about these kinds of questions, you might ask. You know what you need to do, so go and do it so your clients and manager will be happy and forget about your job description. That’s fine, but I believe that by answering these questions you will sharpen your own understanding of the role you play as a Business Analyst.

Consider this scenario:

Q: “Well, I know that business is about making money, and you’ve analyzed all that, so do you have any tips about making money for me?”
A: “Well, ……. actually I don’t work at making money, I work on computer systems.”

There are two parts to this problem of describing what we do:

The “Business Analyst” title is too broad and easily misinterpreted. “Requirements Engineer” is more accurate, but you are more likely to find this title in academia rather than in business. The Business Analyst title has persisted for good or bad.
We know what a firefighter, teacher, or doctor does, at least at an abstract level, and why those jobs are important. Some might even understand what a Network Engineer does. But not many people understand why it’s important to describe business workflow in great detail before the programmers begin their work in order to produce quality software.

Whenever I am in a situation like this, where it is too time consuming and complicated to thoroughly explain something, I often resort to analogies. This is a quick way to communicate the core values that a BA brings to their job roles, and the choice of an analogy sharpened my own thinking about what I accomplish at work.

My favorite job analogy is that of a lawyer who you see in order to have your will or testament written. In your everyday language with your lawyer you describe what you intend to happen, much the same way that project stakeholders first describe the new system or improvement that needs to be produced. It is the lawyer’s role to understand what you described, determine feasibility, and question ambiguities or conflicts in your statements. The lawyer may also act as a consultant, offering alternatives that may affect your estate taxes or point out something you may have overlooked.

The lawyer then produces a document specifying your desired outcomes. The document must include all your specifications, and be free of any ambiguity so it can be interpreted clearly by any other lawyer or judge. After all, if your will is being read then you will not, obviously, be available to answer any questions.

The Business Analyst also produces a document that needs to be precise and unambiguous, and while the BA will be available to answer any questions from other stakeholders the document still needs to stand on its own.
Using this analogy has helped me to understand the key role that language plays in the discussion, discovery and clarification of requirements, from ordinary language that typically includes jargon and colloquialisms to precise descriptions that leave no room for multiple interpretations.

In ordinary language, we tend to use metaphors and indirect comparisons rather than literal descriptions. I don’t know if this occurs in languages other than English, but it does occur even in conversations with technical people. A software engineer I worked with used phrases such as ‘The system knows that …’, which of course is total nonsense. That system, any system, knows nothing; it’s just a machine. Yet we use these expressions constantly when discussing functionality or requirements.

As a Business Analyst you need to be aware of when discussions include these metaphors and colloquialisms so that you can question or clarify them until you arrive at a clear understanding of requirement needs.

Another analogy I’ve successfully used is that of an editor at a publishing house who is putting together a book of regional recipes. The editor consults with chefs or prominent cooks, similar to the way a BA consults with subject matter experts, to discover and then document recipes.

The editor may write about the background of these recipes, and then develops the recipes in a clear manner so that any reader can follow them. In all likelihood, the editor is not a chef, but most likely does have a strong interest in cooking. This analogy emphasizes collaboration with subject matter experts when you are not an expert yourself, and clear writing that follows logical sequences.

This is, of course, what a Business Analyst does when developing use cases. You might think of a recipe as a use case, with preconditions, triggers, actors, sequential steps, and postcondition metrics. Both the editor and Business Analyst have similar deliverables to produce; a step-by-step description of how to create a dish in the case of the editor and a workstep or process description in a use case format for the Business Analyst.

Besides sharpening your own thinking, answering the ‘what do you do at work’ type of question can make you more confident in your role at work.

What analogy would you use to answer that question, ‘What do you do at work?’

Don’t forget to leave your comments below.

Peace at Last: Agile and Waterfall Find Common Ground in Techniques

Written by Angela Wick on December 3, 2013. Posted in Articles.

As the battle between waterfall and agile rages on, organizations continue modify their approach to software development. Very few move directly to a pure agile approach. Instead, they pilot agile processes, create project selection criteria for agile projects, they shorten release times, minimize project documentation, and many are creating hybrid approaches blending both Waterfall and Agile.

As software development methods evolve, the BA role and their requirement processes come into question. Organizations begin to ask, “How do BAs fit in?”

Some have BAs do the documentation and for Agile projects what gets documented is anything from photos of sticky note user stories, to formalized user stories with acceptance criteria, to the same requirements documentation as in waterfall but done at the end vs. beginning of the implementation.

Where I see the common thread in the BA role is in usage of key techniques needed to understand the business need and maximize the value the solution brings. Regardless of the methodology, roles, and deliverables, the goal of every project is to deliver value to the stakeholders and organization.

In order to deliver value, project teams need a shared understanding of context, processes, needs, wants, priorities, etc. The elicitation and analysis techniques used to build this shared understanding are the common ground between approaches like Waterfall and Agile.

We can share!

BAs can use agile techniques in non-Agile environments.
Agile teams can benefit from traditional BA techniques.

Here are a few examples….

Process Modeling

This may be a traditional technique, but process modeling can provide huge benefits to agile teams. A visual process model offers shared context across an organization and/or system that creates meaningful dialogue.

Process models help agile and non-agile teams understand:

the process being executed
the perspective of the user or the system
workflow sequence and timing
how users or systems collaborate
dependencies

Process models in an agile environment might look different—they might remain high-level and avoid detailed sub-flows. They might reflect only future state. They might focus on user perspective rather than system perspective. However, even a few high-level flows would help agile team members understand the big picture, which can sometimes get lost in short sprints and daily code releases.

Business Rules Analysis

Critical to any business process being implemented, agile teams need to define business rules just as much as non-agile teams.

The timing and depth of the analysis might be different across methodologies. Waterfall project teams might analyze business rules on the front end of the process, resulting in a large, project-wide business rules document.

Agile teams might consider business rules at the beginning of each sprint or face-to-face, with the process owner as they are coding. Agile teams need to have a plan for addressing business rules that cross sprints or a dependent on code that will be developed in other iterations. Many teams use User Stories and Acceptance Criteria where many of the business rules are documented as part of the Acceptance Criteria to the User Story.

User Stories and Acceptance Criteria

These techniques may be coined as “agile” today, but are great techniques for any type of project.

In an agile project, these techniques inspire a high level of collaboration and just-in-time requirements. They integrate requirements, use cases and test criteria in one simple template. The user stories and acceptance criteria templates are generated with an assumption that details will be gathered through direct, usually face-to-face, collaboration at the time of coding.

In traditional requirement processes, user stories and acceptance criteria might be adopted to shorten the requirement gathering process. In traditional projects, it’s often difficult to determine when requirements are “complete.” Using user stories and acceptance criteria in combination with collaboration at the time of coding, might take the pressure off BAs to nail down every detail before a project moves to development.

Collaboration Games

Collaboration games are often associated with agile development. Even the IIBA currently features collaboration games in the Agile Extension of the BABOK.

However, these techniques can and should be used for any project, regardless of methodology.

Traditional BAs can use collaboration games for requirement workshops, issue resolution, identifying needs and features, prioritization, etc. The games inspire creativity and innovation and help engage stakeholders.

Feature Prioritization

A key input to agile development is a prioritized feature list. In many cases, the feature list is fluid and changes as agile teams work through iterations.

Traditional BAs could share a variety of prioritization techniques with agile teams. BAs know how to gather input from multiple sources and make sure that ALL stakeholder opinions are included and aligned.

Agile teams might rely on a narrow group of stakeholders and might not see connections between organizations that would create dependencies between features.

Functional Decomposition

Traditional BAs use functional decomposition to break complex processes and functions into small, manageable pieces for the purpose of analysis. In most traditional environments, each area would be analyzed and all requirements would be grouped together in one project.

Agile methodology relies on breaking complex processes into small, manageable chunks of work. In this case, the functional decomposition would be the skill needed to identify the sequence and contents of each iteration and may be used to break down user stories. Functional Decomposition helps agile teams see where stories fit into a larger process architecture.

Peace at last…

So, now you see—waterfall and agile can live in peace. They can share techniques.

To deliver value to stakeholders, all teams need people with skills to create meaningful dialog, gather accurate information, inspire meaningful collaboration and align stakeholders.

How do you use your BA skills to add value to an agile team? Share your story below.

Don’t forget to leave your comments below.

Business Analyst – Only a Liaison?

Written by Bindu Metta on December 3, 2013. Posted in Articles. 1 Comment on Business Analyst – Only a Liaison?

Often a Business Analyst is considered to be a liaison between IT and Business units to ensure that the “requirements” as set out are met. This might be a starting point for a novice Business Analyst; however the role becomes stagnant if the BA does not explore the Businesses, processes within the organization to understand the enterprise as a whole and help in making recommendations that helps the organization advance financially or have an edge over competitors.

Sometimes it is also a good idea to understand the business models of the competitors to have a fair view of what the customers are really looking for in the competitor’s products. I am not saying that a comparison must be drawn between the Business competitors as the strategies, goals and structures are entirely different. An overview of the market segment trying to understand customer inclinations (irrespective of the fact whether a customer uses your product or the competitor’s product) is necessary for a Business Analyst to get the “overall picture” before making recommendations at the Enterprise Level.

As you gain experience within the organization with regards to the processes, models, business units it is imperative that the Business Analyst works hand-in-hand with any of the business owners or a business unit to foresee the market trends, changes and understand the customer impulse.

“Venturing into the market” by actually meeting the clients, having discussions, building rapport that allows the Business Analyst a view into their needs and “nice-to-haves” helps to forecast the trends. It also aids in getting a 360⁰ view of the current scenario that enables business units think well in advance to cater to customer needs. A living example of such innovations can be found with the whole range of apps (applications) that are being introduced to the customers at the rate of one app a minute.

Though technology is only a way to get closer and interact with the customer instantly, it is the idea that is the driving force behind these innovations. Ideas coupled with proper analysis (here comes our Business Analyst who has now gained insights into the real world keeping in mind the goals of the organization) will boost the growth in a dramatic fashion be it in increasing customer satisfaction levels or helping in increase the customer base that will in turn boost revenue growths.

The whole concept of venturing into the market or analyzing on the go should be an on-going process to keep up with the pace of the growth momentum and business analyst skills can be largely utilized into this area along with the skills of a product analyst.

Please don’t get me wrong as I am not suggesting that the business owner or the product analyst must be replaced by a Business Analyst- all that I am trying to suggest is to utilize the analysis skills of a Business Analyst to help the Business owners/product analysts come up with innovative ideas to MOVE FORWARD! After all “COLLABORATION” is the key to success in any organization- Agree?

Don’t forget to leave your comments below.

Thinking Like a Business Analyst

Written by Steve Blais on November 26, 2013. Posted in Articles. 1 Comment on Thinking Like a Business Analyst

I was flattered recently during a meeting about a proposed merger when I was waxing eloquent, or perhaps ineloquent, about a review of the business processes and seeing how the business processes matched in each organization. I was suggesting a ‘pick of the litter’ approach. One of the directors at the meeting said that I was “thinking like a business analyst”. I doubt he was thinking about requirements or projects. The business analysts he probably was referring to were those who analyzed the businesses of organizations the company was contemplating merging with or acquiring. He may also have been accusing me of some negative attribute he associated with business analysts, but I took it as a complement, nonetheless. Regardless, it got me to thinking about thinking.

Thinking Fluently

The thing is that we don’t think in words, we think in pictures, images, concepts, and so forth and then translate them into words in order to communicate them. Perhaps fluency, or “thinking like…” is a matter of seeing and understanding the pictures or concepts instead of or in addition to the words. For example when you learn a second language you spend lots of time translating the words. To understand a word in the second language, you translate it first into a corresponding word in your native language which produces an image in your mind. An English speaker learning Spanish would translate “el vaso de agua sobre la mesa” into “the glass of water on the table” and then see the image of the glass on the table in her mind. A Spanish speaker would see the image in her mind immediately. When you are fluent in the second language, you are able to do the same as the native speaker: see the image without exchanging the words in your frontal cortex. Of course each of us has a different image in our heads of what a glass of water on the table looks like, but that’s fodder for another article later.

So we might conclude that if we are “thinking like” some role, or profession that we find ourselves fluent in that role, or profession, or in other words, we see the concepts and images instead of just the words. There may be other phrases or descriptions for the same thing, such as someone “getting it”, whatever “it” is, or to borrow a phrase from the current discussions of agile, “you don’t do agile, you are agile”.

Thinking like…

I think we all have roles or positions or times in our life when we can say we were or are fluent in something, other than a language. For example, at times in my life, I have felt myself fluent in several roles.

In my early years I thought like a programmer. When presented a problem. I could see the code that would be written that would solve that problem. Unfortunately, I probably suffered from what Gerry Weinberg calls the “No Problem Syndrome” in which case I was probably mentally seeing a solution in code before the problem was fully explained. Too many jumping to solutions in that way is another definition of “thinking like a programmer”.

There was also a time that I felt as though I thought like a system analyst or designer. I could see the software programs interconnecting, accessing data, and even the hardware devices on which they would reside. As an analyst I could see the pieces of a larger problem, sometimes with an inability to see the larger problem itself. As a data modeler, for example, I would think in terms of entities, relationships, foreign and primary keys, even when conducting the initial interviews with the users and business stakeholders. This, as you can imagine, resulted in some rather interesting miscommunications during the elicitation phase.

On the other hand, I was never much good at thinking like a project manager. While I had my successes in project management, there were those of my peers who could see a Gantt chart in their heads when presented with the project charter. They could mentally break down the scope into a work breakdown structure and could see the precedence network in their heads with all resources arranged and delegated amongst the tasks. I needed to go through the routine of decomposing and organizing the project with the team. I tended to think technically rather than managerially. It wasn’t ‘instinctive’ to me until I had spent many years managing, at least not as instinctive as writing code or designing systems.

Not a success guarantee, but certainly an indicator

Fluency, or “thinking like..”, is not a guarantee of success in any given profession or role. In other words, you can certainly be a success in a given role without becoming so invested in that role that your thinking is consumed by it. There is certainly evidence and cognitive behavior studies that indicate that we have predilections for fluency in certain areas. Some people have a natural ability to learn languages and the intonations and inflections that make their recitation in that language seem natural, even to a native speaker. Others struggle just to learn enough vocabulary to understand, much less speak. Similarly, some people will find it much easier to be fluent in a programming language than others. However, fluent or not, a person may be a highly successful programmer, designer, project manager, speaker of a second language, or business analyst without necessarily being fluent.

On the other hand, there is also evidence that indicates with focus, attention, practice, and intent, one can master a role, and become fluent in it, even without a predilection toward it. In the book outliers, Malcolm Gladwell suggests that one can become an expert, be fully fluent, in a role or profession by practicing that role or profession for 10,000 hours.

Regardless of whether you have a penchant for it or not or whether you are fluent in business analysis or not, you will be more successful as a business analyst when you think as a business analyst. So what does it mean to ‘think like a business analyst’?

Thinking like a business analyst

The problem with ‘thinking like a business analyst’ is that the role of business analyst is so vague. A programmer programs, she writes code that makes computers do things. A system analyst or designer analyzes problems and creates computer-based systems to solve those problems. What is the specific activity that the business analyst thinks about?

Requirements? Can you imagine thinking about everything in terms of requirements, as in “It is dinner time, what are my requirements for dinner?”
Documentation? Yes, the business analyst seems to do a lot of documentation such that sometimes his entire role seems to be about documentation, but thinking in documentation, as in “let me write down what I am going to wear to work today” doesn’t seem to be applicable.
Liaison or translator between the business and IT? Your thinking might run like this: “let me explain to you what is going on with this television show, dear”. No, that doesn’t quite get it either.

Since all business analysts regardless of assignment or interpretation of the position or role are problem solvers, (the business analyst’s mission: Business, the final frontier. This is the mission of the business analyst: to go identify business problems, to seek out new solutions, to boldly go where no business analyst has gone before. [1]) perhaps thinking like a business analyst is thinking as a problem solver. Sherlock Holmes comes to mind as an example. Mr. Spock is another.

We are all born with the capacity to solve problems. Many of us let that capacity atrophy as we get older for a variety of reasons, mostly cultural and social. After all, Holmes and Spock are not the most lovable of characters. If you look at problem solving thinking, you see a number of different modes of thinking that may go into solving problems.

Critical thinking is a form of reasoning that challenges thinking and beliefs to determine what is true, partially true, or false. For example, a business analyst thinking critically would question the problem statement to make sure that it is the real problem statement and not the description of a symptom before proceeding with the analysis. Critical thinking underlies the other business analyst problem solving thinking modes. Sherlock Holmes is an example of a critical thinker, constantly challenging LeStrade’s and others’ assumptions of guilt or innocence as not being based on facts.

System thinking is the process of viewing problems as parts of whole systems rather than individual occurrences. The business analyst needs to view the organization and its business processes as a system or systems within systems to truly understand the impacts of the changes to the organization that the business analyst is bringing about. There have been a number of discussions on LinkedIn business analyst discussion groups lately about the application of system thinking to business analysis masterfully led by Duane Banks and Julian Sammy.

Strategic thinking as applied by an individual involves the generation and application of insights and opportunities that extend beyond the present timeframe. While system thinking provides the business analyst the larger view in terms of breadth, depth and context, strategic thinking provides the business analyst a larger view in terms of time. While strategic thinking is not usually associated with the business analyst who typically works on projects which are tactical in nature, the business analyst, being in the center of business and IT is usually in a prime position to understand the strategic implications of the projects and products on the organization.

Analytical thinking is essential to problem solving and goes hand in hand with critical thinking. Critical thinking and analytical thinking are sometimes considered synonymous. Critical thinking is specifically focused on thinking while analytical thinking is focused on everything else. Since it is often difficult to see the complete problem or the entire situation in which the problem exists given the complexities of business and technology today, the business analyst breaks the larger picture into smaller more manageable images to make examination and understanding easier. Again, Sherlock Holmes broke crime scenes down to pieces of evidence that, when put all together, assembled a complete picture of the crime and the perpetrator. This reassembly of the evidence or the pieces back into a complete whole to determine the ‘crime’ is what allows business analysts to be both system thinkers and analytical thinkers successfully. The two modes of thinking are not diametrically opposed or mutually exclusive.

Visual thinking is perhaps the only mode that might require a bit of predilection in that some people are more visual than others. But this thinking mode brings us all the way back to the initial premise that we don’t think in words, but in images and concepts: visions. To the degree that we as business analysts can visualize the problem and solution and describe that vision or render the vision into graphical form is the degree that we will be understood in our efforts to communicate.

Now that I think about it…

Thinking like a business analyst might be simply thinking first:

Thinking before reacting,
Questioning before accepting,
Verifying before assuming,
Understanding before judging,
Viewing the whole process before focusing in on the detail issue,
Analyzing before concluding,
Visualizing before writing.

While we as business analysts value the activities on the right hand side we value the activities on the left side more (to paraphrase the Agile Manifesto). Thinking like a business analyst may simply be a matter of reasoning about problems, visualizing solutions, and asking more questions.

Don’t forget to leave your comments below.

Get Support from the Grumpy Old Man

Written by Angela Wick on November 12, 2013. Posted in Articles. 1 Comment on Get Support from the Grumpy Old Man

How would you “caricaturize” your organization?

We’ve all been to a fair or festival and watched caricature artists draw distorted people with giant cartoon-like heads and exaggerated features.
If you made a caricature of your organization, what would it look like?

Here are two extreme organizational caricatures:

Grumpy Old Man

Picture Andy Rooney’s bushy eyebrows, a cigar, a scowl and an iron fist.
This organization is set in its ways, not open to change, fixed in routine, dictatorial, risk averse, backward-thinking—what worked in the past will continue to work.
BAs in this environment might have strict procedures, many required templates, limited flexibility and a clearly-defined hierarchy.

Fearless Toddler

Picture a wide-eyed, smiling and wobbly 12-month old, touching and tasting everything without concern for consequences. Each day is a series of experiments with repeating cycles of attempts, failures, learning and trying again.
This organization values experimentation, rewards risk, and is forward-thinking—what’s next and what’s new.
BAs in this environment might be required to define their own roles and procedures, with few internal rules and minimal structure. Priorities might change frequently.

Which caricature describes your organization?

How does that impact your ability to get the support you need to try new tools and techniques?

The Fearless Toddler would welcome your experimentation, but how do you get support from the Grumpy Old Man?

Here are a few ways to help your Grumpy Old Man open up to new ideas:

Cross-Team Training
In many organizations, stakeholders don’t really understand the BA role. The right team workshop can help everyone appreciate possibilities and benefits of effective elicitation, analysis, issue resolution and prioritization processes

This strategy exponentially increases the value of training because resistance is minimized and BAs have the support they need to help their organization move forward.

Something magical happens when BAs, PMs, QAs and SMEs learn new skills together. At one of my client sites, BAs were happily overwhelmed when their business managers pushed them to try four new techniques just days after they all took BA training together.
Take Baby Steps
Start small. Figure out a way to apply new ideas in phases. Find a way to fit new techniques into current procedures. Start with techniques that are a simple expansion of current practices.

If you have a new facilitation technique you want to try, practice it in a low risk meeting with a small group of friendly stakeholders. Ask for honest feedback.
Ask permission
Many people will tell you “it’s better to ask forgiveness later than ask permission now.” However, in some organizations it is not appropriate to try new techniques and tools without approval from a leadership team. In this case, you may need to follow a formal process to introduce new ideas.

Even in less-structured organizations, a simple request process might maximize cooperation:
1. Choose a new tool or technique.
2. Submit a brief proposal to key members of your organization.
3. Describe the benefits of the technique, your implementation plan and how you will report the results.
4. Make sure you include any benefits that save time, reduce cost or minimize risk.
Just do it! Take the risk and try something new.
1. Prepare well, be confident and be willing to fail.
2. Set expectations. Let people know that you plan to try something new.
3. Use time wisely and give stakeholders a way to provide feedback.
Whether you succeed or fail, you’ll learn something valuable about yourself and about your organization. Maybe you’ll learn that your organization is not as grumpy and old as you thought or you’ll learn the old process worked better. You might find support and flexibility or you might find a brick wall. Use your findings to inform future choices and experiments.
Share expert opinions

Sometimes you need a third party to help you advocate for change. You could hire a team of consultants. But if your budget is limited, find expert resources online. Find articles, videos, and other resources.
Build your base

Float new ideas, one person at a time, during lunch, after meetings, at happy hour, in the elevator and by the coffee pot. You will find support.

How do you get your stakeholders wide-eyed and smiling? How do you build support for new tools and techniques in your organization? Please leave your comments below.

Don’t forget to leave your comments below.