Skip to main content

Tag: Business Analysis

The Innovative Business Analyst

Written by Tim Coventry on . Posted in Articles. 1 Comment on The Innovative Business Analyst

Many people talk about the importance of business processes without identifying the true value to an organisation. We hear often about Business Process Management (BPM) however I see that many of these initiatives forget about the business need and get carried away with the mapping of business processes or focus on the notation correctness. Instead I often talk about “service/product and business process driven requirements.” What do I mean? Well this is when a Business Analyst (BA) starts with understanding the business process for a service or product in order to elicit the business requirements. Why is this important you ask? Well correctly structured business process driven requirements focus on the business need, as all organisations, for profit, government or even a “not for profit,” exist to deliver services or products or both to customers. These services and products are inevitably delivered through business processes, people and technology. Therefore it is critical that the BA always considers business process within their analysis to discover the business need, related to the delivery of services/products.

Often it is said that a BA should concentrate on the “why” not the “how,” which is true initially however, at a more detailed stage it is necessary to solve the how to deliver the outcome. Instead of saying a BA should focus on the “why” I prefer to say a BA should focus on what is the “service or product” we are delivering within the scope. Inevitably the discussion will soon include the processes and business functions required to deliver the service or product, which is the why.

I have experienced that stakeholders often have the “how” already in mind, “I went to a conference last week and received a demo of xyz software and I’m sure it will solve all our problems” this probably sounds familiar! I call this the “butterfly syndrome” where stakeholders focus on the pretty butterflies flying around the room rather than the service or product delivery. In this situation I quickly acknowledge that xyz software could be the answer but suggest we perform our due diligence to confirm so we don’t waste time and money. How about we start with the services and products where the problems exist? That way we can solve the problems and identify opportunities for improvements while we look at xyz software. This can be done irrespective of our choice of SDLC methodology (e.g. Waterfall, Agile, Iterative).

The first question I ask is “what is the service or product we are delivering within the scope?” Normally I already know the answer to this question through the usage of the BABOK technique Document Analysis that allows me to determine the answer before I engage the stakeholders. Great sources of this information are company websites and glossy brochures as these hopefully clearly outline the services or products offered by the organisation. Next I like to understand the services and products within the scope of the initiative or project, and determine whether these are supportive activities (necessary but non-value adding) or direct value chain activities (value adding).

 
coventry nov12

Typically I use a value chain similar to the Porter’s generic value chain to focus my understanding of how the scope fits into value adding and non-value adding activities. If the activities are value adding it is easy to link them to the services and product delivery. Non-value adding but necessary supportive activities are more challenging to identify the linkages to the services and products however connecting the dots can be exhilarating.

I learnt the usefulness of this technique when working in a healthcare environment when I was asked to work on a project that had identified the need for a new Human Resource IT system. When I started to analyse further I discovered the organisation had a problem with recruiting enough nurses, as frontline and regional patient services (value-adding service) were under resourced to produce a suitable customer service. Around the world Human Resource business units (non-value adding but necessary supportive business function) perform five business process patterns; Strategic Human Resource Planning, Recruitment, Retention (includes learning and development), Redeployment/Retirement and Employee Management (includes payroll etc) so typically a new Human Resource IT system would cover all of these five processes. However in this instance the problem was only in one area “Recruitment” and so I suggested that we focus our attention (scope) to fixing the problem affecting the value adding service hence reducing delivery time and costs. My initial suggestion of analysing the cost/benefits of employing temporary staff to handle the recruitment peaks using existing processes and technology did not resonate well with the stakeholders. So the project team concentrated on delivering a technology solution to improve the recruitment process. In the end, the recruitment workflow technology solution provided better business value than a “butterfly syndrome” new Human Resource IT system.

Innovation – businessdictionary.com: The process of translating an idea or invention into a good or service that creates value or for which customers will pay. I think the BA role provides the greatest opportunity to lead and influence stakeholders to make more informed business decisions, assisting organisations to become more strategic, flexible, customer focused and innovative in delivering services and products.

Don’t forget to leave your comments below.

It’s Time to View Your Role as a Communication Expert

Written by Kupe Kupersmith on . Posted in Articles. 2 Comments on It’s Time to View Your Role as a Communication Expert

kupe Oct29I teach a class on applying improvisation skills that focuses on how to be a better team player, collaborator and communicator. I start the class off by asking people what skills they need to be effective in their role. In this session people generally say communication skills, problem solving, negotiation skills, influence, teamwork, etc. Many of the underlying competencies in the BABOK. They also bring up the multitude of techniques familiar in our community like use cases, user stories, impact mapping, context diagrams, workflow diagrams, etc. In my last blog post I argued that decision making was not an underlying competency it was what a business analysis professional does. In my classes and here in this post I argue that the same applies for communication skills.

As I was formulating my thoughts for this post I attended a Greater Atlanta IIBA chapter meeting where a panel discussed communicating to executive level employees. My friend and BA thought leader Jonathan Babcock made a statement that resonated with me. He said, in so many words, BA’s need to be great communication experts. I was so moved I almost gave him a standing ovation.

You need to view your role as communication expert. Your goal is not to complete a template, your goal is not to document Use Cases, your goal is not to help groom a backlog. You goal is to have the necessary stakeholders involved in your initiative gain a shared understanding of the problem and how to go about solving that problem. It’s that simple. The tools and techniques are there to help you communicate. They are not what you do.
Other professions, not yours, have communication as an underlying competency. For example, a plumber. Their main competency is plumbing services. Their goal is to get water from point A to point B without any leaks (over simplified, but you understand where I am going). Their main role is not communication. Yes, they have to communicate with other team members and a homeowner, but it is truly a secondary competency.

Communication challenges are at the core of why in our profession best practices are not always the best practice. Being a communication expert means you are communicating with individuals. Every individual is different. Everyone has their preferred communication style, their own information needs. So when someone says I have a requirements best practice you can’t assume it will work for you and your team. That practice was the best for their team. You need to understand what works for your team and your situation. Now don’t stop learning from others. Just use other people’s experiences to help come up with your approach.

In our community waterfall vs agile is a big topic. This comparison and these conversations are masking the real issue. If you have the mindset of communication first, nothing else matters. Regardless of methodology used you add value to your team by helping gain that shared understanding. Do what is necessary to gain that. New techniques or new uses for existing techniques surface all the time. Use them to help you communicate.
When you view your role as a communication expert you will start to see how to identify when you have done enough analysis. Knowing when you have done just enough analysis is not when a technique is complete to a certain level of quality. You know it when you have communicated clearly and there is a shared understanding. When that goal is reached you are done. There is no silver bullet here. If everyone on the team is very familiar with the business area and problem to be solved it may happen faster. If the problem and solution are complex and there are new team members it will take longer.

Without being able to see your faces or ask you directly I am going to assume we all have a shared understanding. If not, let’s continue the conversation in comments below.

All the best,
Kupe

Don’t forget to leave your comments below.

The Business Analysis Profession has no Principles!

Written by Steve Blais on . Posted in Articles. 1 Comment on The Business Analysis Profession has no Principles!

We business analysts often complain and wring our hands over the lack of respect we get as a profession. We debate what we are and what our profession is and does. Why don’t we have the respect that the medical profession has, or architecture, or even software development? Why don’t we get the same respect as lawyers and politicians…well, maybe we don’t want to go that far.

What have they got that we don’t have?

Recall the end of The Wizard of Oz. The Wizard granted everyone’s wishes, but in a way that was not the magic that was expected. He gave the Lion courage by vesting him with a medal. And he gave the scarecrow brains by giving him a piece of paper bestowing a degree. Upon receiving the “degree” the scare crow immediately spouted some brilliant equation showing that he suddenly had brains. The Tin Woodman was given a “heart”.

Suppose what makes a profession is simply a series of accoutrements such as a Manifesto or a Bill of Rights or a set of Principles? After all, doctors have the Hippocratic Oath. Politicians have the words that they agree to when they are sworn in (defend and uphold…). Lawyers have…well, they have something. Agile software developers have the Programmer’s Bill of Rights written by Ron Jeffries.

So I propose that we have some statements of purpose and goal and principles that will govern and guide our profession. 

Since a Manifesto seems to be the rage nowadays, let’s start with a Business Analyst Manifesto. This Manifesto was created by Laura Brandenburg 

Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve. [1]

Doug Engelbart a computer pioneer and inventor of the mouse among other innovations, may contribute our statement of purpose (paraphrased):

The business analyst increases the capability of the organization to approach a complex problem situation, to gain comprehension to suit the organization’s particular needs, and to derive solutions to problems.

I might add a Bill of Rights and Empowerments that I posted several years ago: [2]

As a business analyst you have the right to:

  • Ask questions
  • Understand the problem and problem domain first
  • Make sure you are solving the right problem
  • Challenge the business
  • Challenge the solution team (to explain why they are choosing to solve the problem in a certain way)
  • Come up with solutions
  • Define the problem domain
  • Solve the problem

As a business analyst, you are empowered to:

  • Ask questions
  • Challenge the norms, the “way things are done” both on the business side and on the development side
  • Try new techniques, methods, and processes to perform your job
  • Suggest new methods or ways of executing business processes in the organization
  • Analyze instead of accept
  • Get and understand information first before committing to a solution
  • Ask more questions
  • Do the good quality job for the organization as a whole instead of only individual organizational entities
  • Define and solve the business problem

While these are three years old, they still apply to today’s challenging environment, and are perfectly applicable to an agile development approach as well.

Finally, we should have some principles or guidelines to follow, some large scale best practices which unify and coalesce what we do. I submit that we can collectively perhaps assemble applicable principles amongst us. I will humbly step into the gap with some principles that might be adopted:

Principle 1 – Focus on the Product

The business analyst focuses on the product not on the project

Understand what a solution is worth to the business

While the project manager focuses on the project to make sure that the project is on time, within budget and delivers everything required, the business analyst focuses on what is to be delivered to make sure the real problem is solved and there is a discernible benefit to the organization when the project is complete. 

Principle 2 – First Define the Problem and Then the Solution

Paraphrasing Davy Crockett: Be sure you know what the real business problem is and then go ahead.

Too many times business analysts assume that a statement given to them by the business is a problem when in reality, the business provides a solution. That solution may not be the most efficient or effective solution; in fact that solution may not even be right. And when the business complains that their problem is not solved even though you implemented their solution, you will likely be blamed for the failure. Spend the extra time up front to make sure that you are dealing with the real problem that needs solving. 

Principle 3 – Users Do Not Have Requirements

Users do not have requirements; stakeholders do not have requirements – they just have information The business analyst seeks that information and analyzes it to produce the solution document containing the requirements.

Starting with the assumption that the requirements only exist when the business analyst analyzes them into existence is a good starting point for solution development. Taking the opposite assumption – the users know exactly what they want and what the technology can do to solve their problem – is a recipe for long meetings, continuous turmoil and change, and consistent conflict resolution. 

Principle 4 – Focus on Information Not Individuals

The problem in elicitation is not finding the right individuals to talk to; it is finding the right information regardless of source. 

Too many times the business analyst is told to go get the requirements from certain individuals. Those individuals may not be available or may not know they are supposed to be the repository for all answers. Sometimes Subject Matter Experts aren’t. The best approach for the business analyst is to determine what information the business analyst needs so that the business analyst understands the problem and can create a solution, and only then determine where that information is located. If some individuals cannot be accessed, most likely the information still can be acquired through other sources.

Principle 5 – Separate Elicitation from Analysis

When eliciting information, do not analyze; when in analysis, do not create information.

When you analyze while gathering information the responders interpret the analysis as judgment on the information provided or on themselves. This stems the flow of information. To keep the information flowing, keep the judgment and analysis out of the interchange. 
Similarly when you are analyzing the information, and you add new information not obtained through elicitation, you are making assumptions about that information. You are weakening your analytic conclusion. Turn any supposed information not based on elicitation or deductive conclusions into questions that require further elicitation.

Principle 6 – Improve the Process First then Add Technology

Evaluate non-IT solutions first before resorting to computers and software to solve the business problem. Focus on the business, and how IT can be used to improve and enhance the business’s status quo

Constantly review and appraise the organization’s processes and operations to determine where changes can be made that will add value to the organization

Our job, as business analysts, is to add value to the organization by solving business problems. Suzanne Robertson puts it this way, “The job of a business analyst is to identify what people need so that they can improve the way that they do their work and to communicate those needs to people who can implement solutions”” [3] In other words, determine what will make things better for the business then determine what the technical solution might be, if any.

Principle 7 – Do not let documentation substitute for communication and collaboration

Requirements describe the solution to a defined, understood and approved business problem

Over the years the emphasis in the requirements process of software development has been on the production of a requirements document. Whole business analyst teams have been organized around the creation of said document. It becomes a project is and of itself. And while it may well be a good idea to treat the definition of the solution as a project, it is not a good idea to replace solid communication with a document. Remember that the document should be the recording of all the communication that has occurred beforehand, not the communication itself.

Principle 8 – Gain Acceptance before you gain Approval

Acceptability of a solution is not the same as approval of a solution. There are different dynamics at play.

All sorts of problems occur when the person who has the authority to approve is in the same meeting as those who need to confirm that the solution will work for them. Separate the confirmation or verification process from the approval process. Get the solution definition confirmed by those who are eventually going to use the solution in real life: “Yes this will solve our problem!” and accepted by those who are going to implement the solution: “yes, we can do this within the project constraints!” before passing the solution to those who need to authorize the funds or resources to implement the solution.

Principle 9 – Make Sure the Business Community is Ready for the Product / Solution 

The business problem is not solved until the solution is being used in the business environment. 

You can have the best solution, a Nobel Prize winning solution, and have it never used because the business people who have to use it don’t use it for whatever reason. Perhaps they are not ready for it. Perhaps they really like their work-around. Perhaps they have had too many changes in the recent past to be able to assimilate this one. The business analyst needs to lead the Transition from the current process to the new, improved process. Not only does the business analyst need to make sure that the new process and / or system is ready for the users, but that the users are ready for the new process and / or system. 

Principle 10 – Communicate, Cooperate, Collaborate

Keep communications flowing in all directions

Live on the Feedback

Above all, communicate. Never let a day go by without an interesting discussion or provocative dialog. Turn conflict into cooperation. Turn contention into collaboration. Eliminate uncertainty and risk by the exposure of new information.. Never be a bottleneck of information. Learn. Teach. Spread the information and expand it. Know more today than you did yesterday

So there are ten principles to start our Principles of the Profession. I am sure there are more that you can think of to add to our list.

Don’t forget to leave your comments below.

[1] Brandenburg, “The Business analyst Manifesto”, Bridging the Gap, 12/17/2009

[2] Blais, “Business Analyst Rights and Empowerment”, Bridging the Gap, 4/29/1020

[3] Pullman & Archer (ed), Business Analysis and Leadership: Influencing Change, Kogan Page, Ltd, London, 2013

Gaudi and Steve Jobs Way of User Interface Design

Written by Emrah Yayici on . Posted in Articles. 1 Comment on Gaudi and Steve Jobs Way of User Interface Design

In many companies, one of the challenges for business analysts is: “Designing Best User Interfaces”.

To achieve this objective business analysts should first shift their focus from designing the best “user interfaces” to designing the best “UX (user experience)”.

In case design thinking is limited to best “user interfaces”, the focus is only given to visual aspects and functionality. But the best “user experience” can only be achieved if usability is also positioned as a must have throughout the design process in addition to functional and aesthetic concerns.

To ensure usability of the interfaces companies have started to establish dedicated UX teams. These teams work on the low-fidelity prototypes created by business analysts and improve their usability by applying UX design principles. They also conduct usability tests with real users to find and fix the usability problems on the prototypes. Afterward they send the prototypes to visual designers who create the most aesthetic visual designs.

However in majority of the companies the role of UX teams is still totally played by business analysts. This may be due to budget constraints and unawareness on the importance of usability. At the companies that don’t have UX teams, business analysts have to spend more time and effort to improve their knowledge on usability and UX design principles.

The most important of these principles is “User Centricity”.

User interfaces are considered usable if they are easy to use and good fit for the people who use them. This requires a User Centered approach in the design process.

Throughout the construction history, Gaudi has been one of the most famous architects with his user centered architecture design approach. His story starts with a childhood suffering from poor health. This situation prevented him from going to school, and he spent most of his time in nature. His observations of nature inspired his design approach, which can be summarized as follows: “The great book always open and which we should make an effort to read, is that of Nature.” With this philosophy he designed buildings with “organic style,” which then became an important standard in architecture.

Another man revolutionized the high-tech industry in a similar way. By positioning users at the center of the analysis and design process, Steve Jobs led the innovation of the most usable consumer electronics products ever. He achieved to create natural-born users of his products. Even kids can use his company’s phones and touchpads with gestures similar to their natural behavior. This new design approach made his company the best performer in the high-tech industry.

In user interface design, the most practical way of adapting Gaudi and Steve Jobs way of user centricity is applying user profiling technique during requirements elicitation stage of the project. User profiling is grouping users according to their mental models and level of computer use based on their personal characteristics such as age, gender, education, income level and business background. Business analysts should define user profiles in addition to user requirements during requirements gathering sessions, define personas (imaginary characters) for each profile and should consider the characteristics of personas during user interface design.

This user-centered analysis and design approach ensures both functionality and usability and helps to provide the best experience on user interfaces.

Don’t forget to leave your comments below.

 

Business Analyst and the Agile Business Analyst

Written by Prabhu Sivakumar on . Posted in Articles.

Often I have been asked how the role of the BA would change in an agile environment. Software development teams transitioning form a Waterfall methodology to an Agile methodology often have difficulty in clearly defining roles and responsibilities of the team members. This is especially true for the role of BA, as agile teams include a business owner who plays a more involved role than in a Waterfall process.
Though there is a business owner working closely with a development team playing a product owner role, the role of a BA is extremely important in organizing the business needs and creating the roadmap for the team. Business Analysts serve a critical role in understanding the problem domain and digging into the root cause of the business need or the problem. Business Analysts have to adapt to the new process and understand not just the template of the artifacts that needs to be produced (Epics and User Stories) but the spirit of the agile methodology. This will help the team dynamics and will help avoid user stories written like functional requirements.

The following table tries to compare how the role of Business Analyst changes in an agile environment.

BA Agile BA
Requirements are documented in Use Cases, Business Requirements, Functional requirements, UI Specifications, Business Rules. Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details. Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on getting a ‘sign off’ on the requirements. Focuses on ensuring the requirements meet the current business needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team. Agile BA/Product Owner is part of the team.
Tends to dictate solutions. Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.
Long turnaround. Quick turnaround.
Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document. Focus on the functionality of the developed software.In other words, output (Artifact) is the software that meets the business needs.
  Needs the ability to look at the big picture (with fewer details) but also needs the ability to break the big picture into smaller pieces, so that the development team can execute on it in two to three week intervals.
Focus on being very specific in the requirements (construed as inflexible) Leave room for negotiation (and be flexible) as long as the problem is solved.

Love to hear your thoughts and experience.

Don’t forget to leave your comments below.