Tag: Business Analysis

Empathy At Work: The Secret of Business Analysis Success

Written by Angela Wick on January 14, 2014. Posted in Articles. 1 Comment on Empathy At Work: The Secret of Business Analysis Success

For many people, empathy is a tool for personal or spiritual relationships. We save our empathy skills for people who are struggling with poverty, illness or grief. We don’t apply empathy to those who are happy or content and when it comes to our professional lives, most feelings, including empathy, remain tightly bundled under our business casual façade.

In some professions, like nursing or social work, empathy is an obvious asset. Marketing and advertising professionals rely on empathy as well. But what about project management, business analysis and software development? How can we apply empathy to our professional lives? How can empathy help us bring value to our stakeholders?

Empathy and Business Analysis

Your mother used to say something about walking a mile in other people’s shoes, seeing through someone else’s eyes, put yourself in their position… When it comes to our professional life, applying empathy mantras to our stakeholders can lead to amazing discoveries about our projects.

Take a look at this drawing. It’s a simple representation of an empathy map.

If you understand what your stakeholders are thinking, seeing, saying, hearing and feeling you can:

Proactively and effectively manage issues and risks
Evaluate politics, priorities and motivations
Uncover hidden requirements and bridge requirement gaps
Locate constraints and dependencies

Implementing Empathy

Gathering information for the empathy map can be a bit tricky. We can’t just schedule an “Empathy Map Meeting” and ask everyone what they are thinking and feeling, right?

No! Please don’t schedule an empathy map meeting. Tone and timing are very important. Here are few ideas:

Gather insight before meetings. You can meet with key stakeholders one-on-one before important meetings. You can prep them for the meeting and ask a few questions that would offer insight into their thoughts and feelings.
During a series of meetings, ask the empathy map questions in different ways to gather current versus future state. What are you hearing? What do you need to hear? What are you seeing? What do you need to see?
Watch body language during meetings. What is your project sponsor feeling when she rolls her eyes every time the SME speaks? What is your tech lead thinking if he is shaking his head during an issue resolution meeting?
Don’t be the scribe during meetings. You need to be able to observe and listen to the interactions between stakeholders. You won’t see the eye rolls, frowns, smiles and head nods if you are too busy taking notes.
Follow up after meetings. Take time to personally reflect on stakeholder interactions during meetings and if necessary follow up with stakeholders one-on-one or in small groups.
“What’s in it for me?” aka WIIFM is a question you should ask yourself on behalf of every stakeholder at the beginning of each project, before each meeting and as you design each deliverable. Your communication will be more efficient and you will get faster buy-in and better engagement from your stakeholders.
Write it down. Create a spreadsheet with each stakeholder and empathy map sections. Add to it regularly as your project moves forward. You may never show your empathy map to others, but it will be a great reference tool. When you encounter issues throughout the lifecycle, your empathy map will offer great insight to help your project stay on track.

Empathy and Innovation

Applying empathy to a project will help BAs successfully navigate their basic tasks, but can BAs inspire innovation with their empathetic approach?

Definitely! Empathy and innovation are related:

Approaching all requirements and project tasks with empathy will yield meaningful collaboration. BAs will know the right questions to ask to engage stakeholders and draw out key information. Meaningful collaboration yields innovation.
Innovation often relies on finding connections between two seemingly unrelated ideas or processes. BAs who understand the empathy map for each stakeholder see connections that others don’t. Maybe two stakeholders from different organizations are hearing the same complaints from their team. The BA might be able to bring the stakeholders together to help each other solve the problem.
Innovation requires the full participation of all stakeholders. If an empathetic BA knows that a SME has a great idea, but probably won’t share it because he feels intimidated by the project sponsor, the BA can facilitate a process that draws the ideas out anonymously.

Do you use empathy as a technique? If not, give it a try. Share your experience in the comments below.

Don’t forget to leave your comments below.

The BA Practice Lead Handbook 13 – Taking your Business Analysis Team from Good to Great

Written by Kathleen B. Hass, PMP on December 17, 2013. Posted in Articles.

As we look ahead into the next century, leaders will be those who empower others.
Bill Gates

In article 6 of this series, we discussed an approach to building a capable BA workforce able to manage the complexity of your team’s project assignments. In this article, we discuss the need for the BA Practice Lead, as well as the BA, to become effective leaders of teams. Your job is all about building and sustaining high-performing teams.

What’s the big deal about teams?

Complex projects are challenged today because of people failing to come together with a common vision, an understanding of complexity, and the right expertise. Virtually all work today is accomplished by teams of people. Sometimes teams of teams consisting of groups around the globe. Team leadership is different from traditional management, and teams are different from operational work groups. When leading high-performing, creative teams, it is no longer about command and control; it is rather about collaboration, consensus, empowerment, confidence, and leadership.

What do high-performing teams look like?

When you think of great teams you have observed, what teams come to mind? Perhaps your local professional sports team is the first mental image that emerges. Whatever the sport, high performance is the name of the game. Sometimes, high individual performance is a detriment to the team. Success in the world of professional sports is about team performance.

So, outside of sports, what high performing teams have been a wonder to your eyes? Let’s just begin to identify some of them and the nature of their sustained high-performance. We will name just a few. I am certain you could add to this list.

Paramedic Teams

Paramedic teams mean the difference between surviving and succumbing to an overwhelming force. Paramedics provide medical care at an advanced life support level in the pre-hospital environment, usually in an emergency, at the point of illness or injury. This includes an initial assessment, a diagnosis and a treatment plan to manage the patient’s particular health crisis. Treatment can also be continued en route to a hospital if more definitive care for the patient is required. Paramedics almost always work in teams of two to four specialists, each fully understanding his role, and how it integrates into the whole approach to assess the degrees of urgency to wounds or illnesses and provide life-saving interventions. It is about the importance of the mission and the team resolve.

Firefighting teams

I once met a New York City firefighter who had been with his squad for decades. I asked him how he handled such a pressure-filled job. His answer: “I would pay them to let me be a fire fighter.” He was talking about the camaraderie, the spirit, the brotherhood, the importance of the mission. Think 911 or Hurricane Katrina.

Non-Governmental Organizations (NGOs)

I have a sister who is heading up an NGO at the United Nations. She mentors interns and high-school age young women and men to become involved in global solutions to problems such as the trafficking of women, the poverty and environmental health issues of communities that are adjacent to coal mines, the basic right of all to have access to clean drinking water. She says she had her dream job. It is about the importance of the mission and collaboration with other world-changing NGOs.

Symphony Orchestras

Today the Boston Symphony Orchestra, Inc., (BSO) presents more than 250 concerts annually. It is an ensemble that has richly fulfilled their vision of a great and permanent orchestra in Boston. BSO has been the scene of almost two hundred American premieres over the last century. From Wilhelm Gericke to James Levine, each conductor of the BSO has created a legacy of new works introduced to BSO audiences. The BSO Archives houses printed programs, press clippings, posters, photographs, administrative files, an extensive collection of radio broadcast tapes of concerts and commercial recordings. It’s about musical expertise, cultural and historical contributions, and first-rate performances.

Heart Transplant/Operating Room Teams

Transplant patients who come to University of Colorado Hospital are often very, very sick. Their survival depends on well-orchestrated care delivered by the transplant team. There have been many historic transplant stories at University of Colorado

Hospital and by the physicians and researchers of the University of Colorado Denver School of Medicine. Among them:

First-ever liver transplant in the world. (1963)
First successful double lung transplant on a cystic fibrosis patient in Colorado.
Colorado’s first solitary pancreas transplant to eliminate diabetes in a patient.
First in utero stem cell transplant to save a fetus with a rare blood disorder.
Opened a liver cell bank – one of the first in the country – to further research into new liver transplant procedures.
First living-related liver transplant in Colorado.
First living-related liver transplant on an adult with fulminant liver failure.
Region’s first liver transplant from a non-related donor.
One of the first in the nation to perform living-donor transplant surgery.

It’s about top-of-their-game medical professionals, superior medicine, a highly-skilled, interdisciplinary team, and progressive, innovative change.

Navy Seals

And then there are the Navy Seals. Well, they are the Navy Seals, probably the most famous of all great teams.

Navy SEALs are a unique breed of warrior who conduct special operations in any environment, but who are uniquely trained and equipped to operate from, around and in maritime areas. SEALs take their name from the environments in which they are trained to operate: sea, air and land. Their small highly trained teams usually work quietly at night conducting some of the nation’s most important missions. SEALs are constantly deployed throughout the world to protect national interests.

Think Seal Team Six, sometimes referred to as the Special Mission Unit. ST6 is a multi-functional special operations unit with several roles that include high-risk specialized missions. Required entrance skills include combat experience; language skills; and the ability to blend in as civilians during an operation. Members of ST6 are selected in part because of the diversity of skills of each team member. The ST6 training schedule is without comparison in its intensity. Though highly classified, they are renowned for their barely credible, almost fiction-like accomplishments.

Technology Innovation Teams

At the top of nearly everyone’s list when it comes to innovation, – Apple, Inc. Their products are at the top of nearly everyone’s gift list. For them it’s about innovation, creating things we don’t even know we want or need. From

ED BAIG OF USA TODAY DECLARES IPAD AIR THE BEST YET AND “BETTER THAN ITS ALREADY BEST OF BREED PREDECESSORS, SUPERIOR STILL TO EACH AND EVERY RIVAL BIG SCREEN SLATE THAT I’VE TESTED. APPLE DOMINATES THE TABLET APPS ECOSYSTEM. ITS TABLET REMAINS THE EASIEST TO USE.”

DAMON DARLIN AT THE NEW YORK TIMES WRITES, “COMPARED WITH THE OTHER TABLETS ON THE MARKET, APPLE STILL HOLDS THE EDGE.” HE HIGHLIGHTS MANY OF IPAD AIR’S KEY FEATURES INCLUDING SIZE, BATTERY LIFE, PROCESSING POWER, STORAGE, AND WI-FI WITH MIMO.

ON HIS BLOG, DAVID POGUE IS IMPRESSED WITH THE BATTERY LIFE, SPEED, AND DESIGN OF IPAD AIR, STATING, “SOMEHOW, APPLE WAS ABLE TO PUT THE IPAD ON SUCH A RADICAL DIET WITHOUT SACRIFICING ANY OF ITS FEATURES.” READ MORE: APPLE.COM/IPAD-AIR

We could go on and on. There are great teams in every walk of life. So, our challenge is to find out what makes some teams good and others great.

What do all great teams have in common?

Let’s examine what all of the great teams have in common. To a fault, they all include these elements:

Small but mighty – if the team is too big, members lose their sense of camaraderie and purpose.
Core full-time, co-located leaders – they follow the shared-leadership model, each taking the lead when their knowledge, skills and expertise are needed.
Highly trained and highly practiced – practice, practice, practice!
Diverse, multi-skilled – a high performing team needs a variety of skills, capabilities, talents, cleverness, and the dexterity to understand all of the perspectives of complex situations.
Experienced – there is simply no substitute for experience
Personally accountable – each member holds himself personally responsible and accountable for the success of the mission.
Expertly coached – behind all great teams is an inspiring, loyal, coach who removes all barrier’s to the team’s success.
Holistic, systems thinkers – great teams see the whole picture and understand how complex teams need to adapt as the environment changes or more is learned.

In addition, great teams understand strategic criticality of the effort, the mission, and the value of their work products. They all have a common set of values and guiding principles. They are passionate about the mission, the work, the results. They keep score and constantly improve their methods, approaches, quality, training, communications, and therefore, results.

What’s the big deal about teams?

So how do you take your team of BAs from a good team to a great team?

It’s about Capabilities

First and foremost, it’s about capability. We once again present the capability model below to demonstrate that as project complexity increases, the capability level of the project leadership team must also increase. The model describes how capabilities evolve from technical prowess to leadership, strategy and innovation fortes.

It’s About Understanding Complexity

And it’s about using complexity thinking to make decisions about building, leading and sustaining high-performing teams. Again, as project become more complex, more sophisticated leadership abilities are required. Studies show that companies can’t find the employees they need – critical thinkers with the ability to:

Adapt, invent, re-invent,
Collaborate, create, innovate, and
Leverage complexity to bring about innovation.

Traditional project jobs are changing:

Typical tasks are being automated and commoditized.
The critical Business Analysis focus is now on strategy, innovation, value to the customer and wealth to the bottom line vs. requirements management.
The critical Project Manager focus is now on complexity management vs. project management.

So, use complexity thinking when making critical project leadership assignments, as depicted in the diagram below.

Use Complexity Thinking to Make Project Leadership Assignments.

It’s About Filling the Gaps in Capabilities

The graph below demonstrates the typical gap in capabilities when dealing with complexity. We re-introduce the diagram below to depict the findings from the ground breaking research study, The Bottom Line on Project Complexity, the results of which were presented at the PMI Global Congress 2010 North America. The study correlated the current state of BA practice maturity with project complexity and project outcomes.

The industries represented in the study were Insurance (Ins), Financial Services (FS), Information Technology (IS/IT), Government and Non Profit (NP), Health Care (HC), and Transportation (Trans). The diamonds represent the typical complexity level of projects within the industry. The research findings indicate that the average BA maturity level for these industries is 1.68 as represented by the black horizontal line in the diagram. But the complexity of projects mostly fell at level 3, highly complex projects. Therefore, there is a gap between the complexity level of most projects and capability levels of BA practitioners working on the projects. The BAs were also asked to predict the probable outcome of their projects in terms of budget, schedule, and scope (BSS in lower right). The diamonds are color coded to represent the degree of challenge the BAs predicted will be evident at the end of the projects.

Assuming that these research findings are relevant to your current BA team, it is imperative that you take action to close the gap in your BA team capabilities. If you are unable to do so, it is likely that two thirds of your current highly-complex projects will fail or be challenged for meeting BSS (CHAOS Report 2011, The Standish Group).

It’s About Filling the Gap between Project Complexity and our Capabilities

Putting it all Together

So what does this mean for the Business Analyst?

For BAs, continually learn about great teams and effective team leadership. Strive collaborate with the other project leaders (the PM, the architect, the lead developer, the business visionary) to take your current project team from a good, capable group to a great, high-performing team.

So what does this mean for the BA Practice Lead?

For both the BA and the BA Practice Lead, reference Chapter 5: Fostering Team Creativity – the Business Analyst’s Sweet Spot of the book entitled The Enterprise Business Analyst by this author. If you do not have the book on your shelf, you can access it through the IIBA e-library if you are an IIBA member. It provides a more in-depth discussion of building and sustaining high-performing teams. Topics include:

Effective Teams
The Power of Teams
Team Development Through Stages
Team Leadership Styles Through Stages
Best Team Practices for the Business Analyst
Creativity – A Right Brain Pursuit
Everyone is Creative
Getting There – From ad hoc Group to Working Group to Creative Team
The Business Analyst as Innovator
Becoming a Creative Force
The Innovation Imperative
Innovation is a Team
Putting it All Together: What Does This Mean to the Business Analyst

Don’t forget to leave your comments below.

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.