Tag: Business Analysis

The Value of Business Analysis: Identifying Business Need

Written by Aaron Whittenberger on August 25, 2014. Posted in Articles.

One of the critical roles of the Business Analyst (BA), or Enterprise Analyst (EA), in the area of Enterprise Analysis is to identify business need. Many business professionals make the mistake of thinking that since it is named Enterprise Analysis, that identifying business need can happen only at the enterprise level. Nothing could be further from the truth; Enterprise Analysis and identifying business need, can happen at the enterprise level, involve multiple lines of business within the organization but not the entire enterprise, and at the business unit level.

There are many factors, or many ways that the business analyst can identify business needs. It can be a result of market research or an identified new opportunity brought about by actions of a vendor or competitor. It could be derived from a strategic goal or initiative of the organization. It could have come from a business user complaint about a current system issue and/or the subsequent Root Cause Analysis. It could also be derived from an Enterprise Analysis activity that the BA performed, such as Capability Gap Analysis, SWOT Analysis or Product Feasibility Analysis.

If this vital role is not performed than the organization would not realize the benefits of identifying some business needs that need to be addressed, possibly gaining greater competitive advantage, possibly achieving strategic goals or taking advantage of an opportunity presented in the market. As you can see this can have a direct effect on the strategic success, and bottom line, of the organization.

Define Business Need

Once identified, the business need should be documented in the Business Case to initiate a project to develop a solution for this business need. This solution may, or may not, involve information technology software development; some solutions are completely a business solution. The business need defines the problem for which the business analyst is attempting to find a solution. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted and which solution approaches will be evaluated.

Define Problem

Defining business need and defining the problem are two different things. The business need leads to the problem, but both the business need and problem statement needs to be defined and documented. Take for example that you have identified that sales have been decreasing for the past three years. So your business need statement could be “Need increased sales”. What is your problem statement? A root cause analysis uncovered an aging sales force using archaic sales techniques, no new products introduced to the marketplace in three years, competitors introducing products with innovative features, no new marketing campaigns in the last two years, rising costs, and production equipment in need of repair and upgrade.

Leads to the Solution

Now that the true problems have been identified, the enterprise can now initiate separate projects to find solutions for the sales problem, product problem, marketing problem, and production problems; rising costs and production equipment. The team assigned the sales problem can determine if they need to hire younger salespeople, provide sales training on newer techniques, provide better sales support, or implement a new Customer Relationship Management (CRM) system. Likewise, the other project teams will determine proper solutions to their defined problem statement.

One pitfall that many business analysts and project teams fall into is trying to define the business need by the solution. In practice, quite often the business stakeholders define the solution at the start of the project instead of defining the problem statement first. They start with the solution first instead of the problem first. This reduces the solution alternatives that receive consideration and may bring a lesser valuable solution to deployment than what could have been achieved. So starting with the business need, problem statement, and solution scope; then developing alternative solutions will bring the most valuable solution to the organization, and the business analyst’s recommendation, to light.
In our sales problem example above, the organization may have identified slumping sales for three years. Without proper problem statement identification the business team may decide to simply hire more salespeople to increase sales. Without proper root cause analysis, they may hire older salespeople, just like the rest of the sales force they have. None of the true root cause problems get resolved because the team jumped to the solution with identifying the true problems needing addressed.

We all learn from our mistakes, what pitfalls to developing the Business Case have you encountered in your career?

Don’t forget to leave your comments below.

Business Analysts: Born or Made?

Written by Marcos Ferrer on July 28, 2014. Posted in Articles. 1 Comment on Business Analysts: Born or Made?

The short answer is both – shortest blog ever or ??? IF you know BOB F., please let him know he can claim his prize from me for his excellent answers presented in my last blog.

Back to our topic. I for one have often blamed :)* my mother, Kathleen Ferrer (nee Morgan, September 26, 1923 – June 26 2014), the only person who both bore me and made me. I often thanked her for my life and her influence, and will miss her very, very much.

I thought I would try to investigate the common experiences or characteristics that lead one to an ongoing BA career.

So, here are some data from my life, left blank for the moment. Fill it in on paper or in your head if you wish, AND EVEN BETTER – Click here to link to the survey:

Then contribute YOUR experiences and characteristics (anonymously) to help all of us BAs and BA wannabes know – Born or Made?

All participants will receive a summary of the survey results if wished 🙂

Date of Birth: ______________

Gender: ______________

Age learned to read: ______________

Who first taught you to read? ______________

Age first fell behind in math: ______________

Who taught you most of your math? ______________

Number of houses growing up: ______________

Maximum distance between any two of these houses in kilometers: ______________

Minimum distance between any two of these houses in kilometers: ______________

Most advanced Business Analysis certification or degree achieved:

CCBA
CBAP
Other Business Analysis certification [give the acronym]: ______________

If your own experience suggests a new question relevant to your path to BA, please add it in the blog comments below. Nice to hear from you, readers are so rare in today’s world, and writers more precious yet 🙂

————————————————————————————-

:)* Blame, in my blogs, is always a joke. My true belief is that blame is a stone-age behavior in an information age culture, and is just as useful in that evolving culture as the sheet music to the song “In the year 2525” would have been during the Cambrian explosion. I could, of course, be completely wrong.

Don`t forget to leave your comments below.

The Project Manager vs. the Business Analyst

Written by Vicki James on June 9, 2014. Posted in Articles.

I have a hard time deciding whether “versus” is a good word to compare the two roles. On one hand, the project manager and business analyst should be working collaboratively. On the other hand, the two roles do offer a healthy contest in project related decisions. The issue at hand is that there is a lot of uncertainty about the difference in these roles. The result of this uncertainty is cases where one person plays both roles without enough skills for each, and other cases where the team members do not know who is responsible for what. Hopefully, we can clear this up.

The core of the difference is in the title.

The Project Manager manages the project – “The application of knowledge, skills, tools, and techniques to provide activities to meet the project requirements.”
The Business Analyst conducts business analysis – “The set of tasks and techniques used to work as a liaison among stakeholders to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to meet its goals.

One source of confusion is the activities in both sets of tasks according to the relevant Body of Knowledge[i]. The intent is that planning and monitoring tasks within the BABOK® are limited to business analysis activities as indicated by the task title.

PMBOK® Task	BABOK® Task
4.2 Develop Project Management Plan	2.3 Plan Business Analysis Activities 2.5 Plan Requirements Management 2.6 Manage Business Analysis Performance
4.4 Monitor and Control Project Work	2.6 Manage Business Analysis Performance
5.1 Plan Scope Management 5.2 Collect Requirements	2.5 Plan Requirements Management Process 3.1-4 Elicitation: Prepare, Conduct, Document, Confirm 4.2 Manage Requirements Traceability 4.4.5.1 Requirements Documentation
5.3 Define Scope	5.4 Define Solution Scope
5.4 Create WBS 5.6 Control Scope	4.1 Manage Solution Scope 5.4 Define Solution Scope
5.5 Validate Scope	7.5 Validate Solution
8.3 Quality Control (Testing-monitoring and recording results)	7.6 Evaluate Solution Performance(Results analysis and recommendation)
13.1 Identify Stakeholders	2.2 Conduct Stakeholder Analysis
10.1 Plan Communications Management	2.4 Plan Business Analysis Communication
10.2 Manage Communications 10.3 Control Communications	4.5 Communicate Requirements 2.6 Manage Business Analysis Performance

Stakeholder analysis is one good example of collaboration between project manager and business analyst. The business analyst focuses on stakeholders specific to the requirements and scope of the project. The project manager is looking beyond this to stakeholders whose interest is outside of the project scope. Perhaps the project manager is recording a competitor as a stakeholder to aid in the identification and tracking of potential project risk. The stakeholder analysis is a joint effort. Assign items resulting from the stakeholder analysis to either the project manager or business analyst based on stakeholder interest and influence.

Another point of confusion is in the PMBOK® task of Collecting Requirements. It looks as though the project manager is responsible for collecting requirements. When you look further at the PMBOK® tasks you also find Quality Control, yet we know the project team has members responsible for product quality. The intent of the PMBOK© is that project managers take responsibility to ensure activities for collecting requirements are covered in the project management plan and monitored along with the project. Not the project manager collects the requirements.

Section 5.1 of the CBAP® Handbook does a great job of differentiating “analysis” activities from other activities. Download the CBAP ® handbook from the Certified Business Analysis Professional™ (CBAP®) website for detailed examples of these activities.

Volunteers from both the International Institute of Business Analysis (IIBA®) and Project Management Institute (PMI©) joined in a collaborative project to “facilitate a shared understanding of the roles.” The conclusion –

Both the PM and BA play leadership roles—the PM for leading the team and delivering the solution and the BA for ensuring that the solution meets the business need and aligns with business and project objectives. And both roles, equally, are required for project success.

You will get decisions based on full information of the impacts to the project and the benefit of the solution when you have both a strong PM and BA playing leadership roles on your projects. The result is a project that brings greatest business value to the organization.

I had the distinct pleasure of joining Elizabeth Larson, PMP, CBAP, CSM, as guest experts on PMChat (a weekly Internet radio show/Twitter web chat) to discuss the BA and PM roles on June 1, 2012.

Don’t forget to leave your comments below.

[i] Project Management Body of Knowledge (PMBOK® Guide) 5th Edition
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0

References

Get Fit: Lose the Business Analysis Weight

Written by Angela Wick on February 18, 2014. Posted in Articles. 1 Comment on Get Fit: Lose the Business Analysis Weight

Many of us started 2014 with a stack of goals and resolutions. Did you resolve to take a few pounds off by eating healthier, hitting the gym, or running a 5K?

What about your professional health and fitness? Do you have a few extra professional pounds dragging you down?

Some BAs are lugging a spare tire around their middle—outdated techniques or broken relationships hold them back from becoming their best professional selves.

So, let’s lose some BA weight and build strength, increase flexibility and improve efficiency. Here are a few ways to work smarter not harder in 2014.

1. Strengthen or Rebuild your PM relationship

BAs have many important relationships to manage, but the relationship with the PM might be the most important. The best BA/PM combos are true partnerships.

Sit down with your PM and discuss requirement process goals and improvements for 2014. Tell the PM what s/he can expect from you that is different, new, and improved. Explain what you need from the PM to support these goals.

Foster this partnership throughout the year:

Establish consistent communication channels: set up a weekly status meeting, touch base over coffee or lunch, create brief summaries of key meetings and share them, and/or create a visual, one-page BA dashboard that gives up-to-date status of your deliverables.
Find common goals and work together to achieve them. Figure out how to make each project successful and how to add value to your organization.
Solve problems together. When complex project issues arise consult the PM. Share information, strategize and collaborate.
Understand ALL potential project risks—not just BA tasks—so you can look out for your PM’s interests. Be the eyes and ears of the project team.

2. Trim the details

Scale back on details that are of minimal value. For every document, every presentation, every e-mail—ask yourself why each detail is important. In many cases, excess details blur the big picture. Stakeholders with a blurry big picture are a major risk to a project. This lack of context will cause way more pain than missing details.

When peers ask for feedback, clarify the type of feedback they want. Don’t focus on grammar details and typos when they ask for content and contextual feedback.
Review emails before sending. Is the length appropriate? Do you use bullet points and white space effectively? Are you asking for too many things from a really busy person in an email? Is e-mail the appropriate tool for the information you have to share? Would a call or meeting be more effective?
Review your documents before distributing. Are you creating documents full of details and sending all the details to everyone to review? Consider your audience. Does everyone need all that detail? Are there ways to effectively summarize the information? Can you add visual elements that provide context for your stakeholders? Can you decompose the information so it is easy to follow for everyone?

3. Kick your meetings up a notch!

Evaluate your facilitation toolbox. Toss those old tools and find a few new ones. You’ll see huge benefits in efficiency when you learn how to make meetings fun, collaborative, and valuable for everyone. Here are a few tips:

Determine what each stakeholder will learn or get from your meeting.
Keep the invite list as small as possible. Meaningful collaboration happens in small groups.
For workshops—plan activities elicit information strategically rather than just asking, “What are your issues?” or “What are the requirements for this feature?” or “What is the best way to fix this?” It’s highly unlikely these canned questions will produce creative or complete responses.
Make meetings engaging. Don’t sit around a conference room table for an hour. Get moving. Use whiteboards and Post Its. Find creative ways to elicit ideas or prioritize requirements.
Virtual Meetings-Multitasking is bad enough in person, but it’s usually worse on conference calls. (You’ve heard dogs barking and kids crying and toilets flushing right?) You have to encourage active participation, beyond just listening. Engage the eyes and the hands. There are so many tools out there, many of them free, that help BAs create interactive virtual meetings. Try virtual whiteboarding, virtual Post Its, virtual breakout sessions or virtual facilitation games.
Make them fun, collaborative, and with value for everyone. What will they learn or get from your meeting?

So, take a risk in 2014. Drop the dead weight and try a new technique, build stronger relationships and question the details. Assess your best practices and find efficiencies. Flex your BA muscles!

Don’t forget to leave your comments below.

Requirements vs. Design – Does it Really Matter?

Written by Richard Larson on February 18, 2014. Posted in Articles.

Much has been written recently about design in the business analysis field. Some writers have even suggested that since most or all of what we do is about design, then requirements don’t matter anymore. It is popular – even exciting perhaps – for BAs to think of ourselves as designers, since much of the work we do results in solutions. We don’t disagree with the trend and the main concern prompting us to write this article is to point out the importance of including the “as is” state as part of any requirements – or should we say design – effort.

In thinking about the topic it is our opinion that a) perhaps people lack some perspective on where and how business analysis has evolved and b) the debate about requirements vs. design may be mostly one of semantics. Over the years, Elizabeth and I along with many others, have worked hard to help the BA profession carve out its place in the business world.This effort has involved moving from the extremes of having either a technical, systems analyst role or an administrative business “super user” role do the business analysis work.

Part of the impetus for the new design focus has been a strong aversion by some in the Agile community to business analysts or business analysis. Those who feel strongly tend to concentrate on the design aspects of a new product and don’t see the need for much if any actual analysis of the business or business need. (See Tony Heap’s blog its-all-design.com for an example. ) If business analysts are now just designers and we need little analysis, we are moving back to the earlier systems analyst role. Although that might be a satisfying career move for some, it does not usually serve the organization well. To say that we don’t need to worry about requirements is missing the essence of what a business analyst can and should be.

Early in Rich’s career he worked as a programmer-analyst doing COBOOL programming with a variety of databases. That was a euphemism for a role that was 90% design/programming and 10% analysis as we know it today. In thinking back, our jobs then were to implement decisions made at higher levels in the organization, both from the CIO and business management levels. Although we met occasionally with business stakeholders, we generally worked to adapt the business to available technology. While today’s “design” does not imply that we have to ignore business needs, it does suggest that we will focus on solutions without truly understanding the needs.

Haven’t we moved beyond that approach over the last few decades?

Let’s walk through some reasons why the emphasis on design over analysis is an issue. Being only or mostly interested in “design” implies that we don’t care about the “as is” state anymore, as is suggested in recent articles, blogs, and discussion groups. (See David Morris’ article, We Are All Designers Now. ) Without understanding the current situation, we cannot hope to understand:

How end users’ jobs will change with the implementation of the new product or product increment. If we do not know the extent of the change we cannot help workers adapt to the change, which increases the risk of lack of buy-in, unhappiness, and even possible sabotage.
Which of the issues with the “as-is” need to be addressed. If we implement new processes and systems without curing existing ills, we will lose credibility.
No new product or solution is devoid of the current state. Even when we create a brand new product or service, it must fit into the current environment and infrastructure. That means we will have requirements that must be met – not designs – to ensure the new solution contains existing functionality that works and without which the new product cannot perform adequately.
In addition, most of us work on projects that are not entirely new products, but replacements and enhancements of existing systems or processes. These efforts need plenty of analysis of the “as is” state and its corresponding requirements to make sure the changes we bring will fit into the rest of the business operation.
Even for brand new products, there are many business rules and decisions that apply across projects and should be taken into account for the project at hand. For example, the new Training Management System we built for our web site was contracted to a development company. The “specification” the development company used represented our decisions (i.e., business requirements) about what was to be built. The specification was clearly not a design – that was done by the developers – but represented our needs and requirements for the new system.
The BABOK® Guide version 3 talks about requirements being the representation of a need and design as a representation of a solution. That is a workable distinction, although it is a bit awkward to talk about “designs” at the same level as requirements. To understand the distinction better, it helps to substitute the words for the process instead of the outputs:
- Analysis is understanding the needs and requirements and communicating them to the builders of a solution.
- Design is how new features and functions will be incorporated into a solution, plus maintaining existing requirements that should be kept in the new solution.

The last point is perhaps our biggest concern with the new thinking. The business analysis community has fought for years to keep analysis distinct from technical design. In the end, we don’t care that fashioning a solution is called design. After all, what is now being called design is nothing different from calling the output of the process “To-be” requirements.

To illustrate our point, consider Figure 1. The example might be a typical enhancement to an existing system or process. In the traditional business analysis approach, the “as-Is” state is analyzed as a starting point to capture processes, data, and interactions that must be kept for any new solution. Those are “as-is” requirements.

The “current state to be retained” in the “Design” box below are also requirements. They could be processes, data, or user and system interfaces. The design process comes into play when determining how to integrate them with the new features being added. Those new features could equally be called “To Be” requirements as well as design. This is not technical or physical design, but the “logical” design mentioned earlier.

Examples of “To Be” requirements (or design if you prefer) include many traditional BA outputs including:

Process models showing an “As Is” as well as a new business process.
Data models showing “To Be” data requirements and business rules relating to the relationships between entities.
Use Case models with interaction requirements and corresponding business rules.
Prototypes and mock-ups indicating interface requirements. These models tend to cause the most “overlap angst” with other staff such as UX experts. Data models come in a close second in the “don’t step on my turf” confrontations.
Interfaces with other systems.

SUMMARY

In the end as long as we are talking about “logical” design and not technical or physical design, the authors agree with the current trend calling BAs designers. In actuality, BAs have always been designers because we help people conceptualize and visualize solutions that will help businesses meet goals and objectives through solutions. As long as we don’t forget the importance of “As Is” and “To Be” requirements and the part they both play in any solution, then emphasizing design over requirements becomes to us an academic argument.

Don’t forget to leave your comments below.

The Best Reason to call BAs Designers?

Perhaps the biggest reason to call our work design has nothing to do with the BABOK or Agile. It is financial. Yes, the accountants are reluctant to capitalize analysis work, but they do allow capitalizing design work. This makes a huge difference for funding of projects since capitalized costs can be spread out over the useful life of the product being built.

Elizabeth and I have a friend who runs a consulting firm in Minneapolis. He tells us his clients won’t typically pay for “analysis” or “requirements” work. But, he also understands the value of business analysis for the success of his company’s projects. So if he couches the same work as “design,” the clients are more willing to pay for it.

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.