Skip to main content

Tag: Business Analysis

Why Does my Development Project Need a Business Analyst?

The short answer: Because you want a project delivered on time, meets your specifications, and works for the end customers.

The long answer: The following project is a real example to illustrate the missing pieces and how a business analyst could have made a huge impact. Do you see similarities with a project you have?

Background

A team member (let’s call him Guy) worked with the client managing multiple Excel spreadsheets. Guy saw a pain point and realized he could do something about it. He suggested building a web application with relational databases to help the team. The client liked this idea because they realized this new tool would impact forecasting and reporting – affecting the bottom line.

Guy set to work with the client outlining the project and developing the tool. A talented project manager (Pam) joined the project. Despite Guy’s knowledge of the business process and technical skills and Pam’s attention to detail, this product was behind schedule. The end customers found that this tool relieved some pain points but didn’t address all of their needs or use cases.

What happened?

Why did a product that started out so promising end behind schedule and not fully addressing the end customers’ need?
Simply put, because there was no business analyst. Guy spent his time working with the client to understand the use cases instead of developing the tool. Pam spent the majority of her time collecting the requirements from the client. No one talked to the end customers. The only requirements provided where the “Shalls” included in the contract that did not cover the full scope of the tool. And most importantly, no one ensured Guy spent his time developing instead of gathering user stories.

What does a business analyst provide?

The most important value a business analyst provides is getting the right information to the software developer in the right manner. The business analyst works with the team to make sure the product delivered fits their needs. In this case, a business analyst allows the developer to focus on developing code.

Business analysts bring:
• An understanding of the business needs and the client needs
• A full understanding of user stories and use cases for the end customer
• Detailed requirements translating the customer needs into technical tasks
• Clear communication with the developer to create the right tool
• Detailed work with the project manager to confirm deliverables are on time and meet the contractual obligations

Wrap up

So why should I spend extra money for a business analyst? Because omitting this crucial team player will cost me in time and quality of the final product.

Do you have an example of a project that succeeded because of a business analyst’s work? Do you have a project that could have been better with the help of a business analyst?

BA or Not BA

BA NOT BA
Traceability matrix Slavishly make this
Functional decomposition Dump on free thinking positions
SWOT SWAT
Balanced scorecards Biased scarecrows
Verify requirements Vilify requirements
Active listening Passively missing meeting
Clarity, completeness, coherence, concision Confusion, carveouts, crazy, carrying on & on &…
Prioritization Riot promulgation
Enterprise architecture Architect renter prizes
Decision analysis Revision paralysis
Agile methodology Methodological fragility
Measured outcomes Declarations of victory
Brainstorms Stormdrains
You found the error You didn’t find the error

Thanks for reading, and be sure to use your comments (BA) not your fists (not BA), below 🙂

How Business Analysis Benefits Your Projects

While it may seem to many that the benefits of business analysis are obvious, the truth is that many businesses don’t completely understand how analysis can help their business. In actuality, business analysis can be the glue that holds a business together.

What do Business Analysts Do?

Business analysts help to make work easier to understand by breaking it down into smaller and more manageable pieces. Testing and developing is also made far easier by business analysts as a result. They also help to keep all projects on task by documenting their scope.

Support

Sometimes during challenging projects, project managers can become overwhelmed by reports, budgets and schedules. Business analysts can help by providing their support, both to project managers, their teams and their sponsors.

Communication

They also help to keep communication lines open by filling in any gaps when there is a breakdown. As well, any confusion as far as requirements, testing or scope can be eliminated with the explanations and assistance of a business analyst.

An Understanding of Benefit Increase

Professional business analysts understand how to increase a company’s potential benefits. Not only can they uncover new business needs, but they can ensure that the priorities of a business are focused on value.

What 2015 Holds for Business Analysts

There are many exciting predictions for 2015 as far as the role of business analyst is concerned.

They will be asked to take on several project roles, including testing and project management. Many of them will also begin to offer their services on a specialist basis, such as scoping, cost-benefit analysis and IT project requirements.

Those who already have a background in business analysis will continue their migration to more influential positions in different areas of an organization. As a result, their title may change from ‘business analyst’ to a more appropriate moniker. However, this may also cause more confusion and disagreement over their exact responsibilities and job description.

Hiring a Professional Business Analyst

Companies questioning whether or not to hire a professional business analyst or a project manager are urged to ask themselves what kinds of value each can bring to a project. In some cases, a project manager may have analyst experience. That being said, it is important to determine how well they can examine facts and other information, whether they can ask the right questions and perform thorough research. Finally, they must be able to aggregate and distill information into several charts, workflows, and other documents.

Any professional business analyst being considered for a spot on your team should have experience in the IT discipline you require. While this may seem like an obvious consideration, there can be a world of difference between one IT discipline and another.

Effective documenting, problem-solving skills, and industry knowledge are other qualities that a professional business analyst should possess. They should also have current core competencies and be motivated and self-directed.

Finally, a business analyst should have the communication and skills necessary to work as a team to solve problems.

Don’t forget to leave your comments below.

Don’t Skip the Analysis When Moving to Shorter Iterations

In most organizations, the days of multi-year, single release, all-or-nothing waterfall projects have come to an end. Instead, teams (agile, waterfall and everything in between) are trending toward smaller, shorter iterations. They hope smaller iterations will reduce cost, shrink time-to-market and improve quality.

Though speed may seem to get better, unfortunately very few organizations see the expected benefits. In fact, increased costs and huge quality issues seem to be the norm for teams transitioning to shorter iterations.

Why aren’t teams finding benefits in shorter iterations? It’s a lack of analysis!

Shorter iterations (agile or not) seem to add time pressure to all components of a project. As teams try to deliver faster, they take shortcuts—thinking analysis is not needed with such small changes. Many teams mistakenly think the iterations are so small that the solution is understandable without the analysis. They try to work faster and in smaller chunks. Analysis gets lost in the shuffle of shorter iterations.

The time pressure of short iterations causes teams to forego analysis on multiple levels:

  • They don’t want to “waste time” outlining the big picture at the beginning of the project.
  • They push to solution without understanding user needs and without evaluating multiple options.
  • As teams “chunk” the project into tiny iterations, they lose track of the relationships between the whole and the parts.
  • As the “chunks” are defined and developed teams forget how the chunks relate to each other.
  • Feedback loops between and across iterations do not exist.

When organizations operate without shared understanding of the big picture and the interdependencies between iterations, they miss some really big stuff! Those big misses result in:

  • grumpy sponsors, users, CEOs, CIOs
  • a huge overwhelming backlog of defects/enhancements/rework
  • increased cost
  • increased time

We still need analysis! We need the big picture! We need to understand relationships, dependencies, upstream, and downstream. We need to analyze, inputs, outputs, data relationships, user goals, exceptions, business rules, scenarios and data flow—even if we’re agile. We need to move the business forward strategically with every release instead of spending our days beating down the backlog like it is a to-do list.

How do organizations shorten iterations successfully?

On a recent flight, I witnessed great analysis in action. A gentleman sitting in front of me had his laptop open in a way that I could clearly see a requirements spreadsheet on his screen. The spreadsheet listed all of his requirements, traced requirements to releases, and traced requirements to user value points/key functions.

He was working hard on this flight! He built and analyzed graphs showing where releases, requirements and value points intersected, and where defects through various testing phases were impacting releases and the key functions of value. He was slicing and dicing all the data and looking back at process flows to analyze the impacts.

I was so impressed! My primary thought was: “Wow, imagine how much better off organizations would be if they could develop and utilize this type of analysis! We used to do this as BAs on larger projects, but it seems to have been lost in smaller iterations.” What was really cool about this guy’s work—I could tell by the number of releases and the release dates that he was working with smaller iterations. Call me a total BA nerd with how I spend “me time” in flight!

So, here are a few things to keep in mind if your team is one of the many struggling with the transition to shorter iterations:

1. Analysis happens in all phases of a project. Agile projects, waterfall projects, big projects, small projects, ALL projects require analysis. Most projects begin with high-level conceptual analysis and gradually dig deeper as the project evolves. The guy on the airplane, for example, was in the middle of a testing phase – which explains the depth of detail.

2. Chunk outside in. When your team starts defining iterations, be an advocate for slicing and dicing based on user needs and value. Every iteration should deliver value to the user. You should not have iterations that deliver databases or interfaces or protocols. You should have iterations that deliver credit card processing, customer account balance reports, and password change notifications.

If your projects are divided into technical components that are not value focused, be an advocate for cross-team analysis with other projects to identify the user value streams and analyze as a team. If you are using an agile approach with user stories, don’t neglect User Story Maps and many of the old-fashioned analysis techniques to help analyze the data, rule, and process dependencies between user stories.

3. Manage change. Projects need enough up-front, big picture analysis to understand how the users and downstream functions are impacted. So many teams have defaulted to processes that chunk work out in tiny non-value added pieces with no traceability to customer value, solutions or downstream impacts. As the project evolves and changes, no one understands who or what will be affected by changes. This lack of analysis causes a TON of rework and defects (some teams calling them “enhancements”).

4. Evaluate your backlog. If you have a giant backlog of defects & enhancements, you probably have an analysis problem. Analyze the backlog! In many cases, the origin of an enhancement/defect is 5 layers back…the original requirement still has not been met after 5 attempts!

You should be able to locate the source of your analysis problem and make adjustments for future projects. Here are a few tips:

  • Take time to trace the enhancements/defects backwards through your process.
  • Look at all the items in the backlog and analyze how they are all related.
  • Group items that impact the same user groups.
  • Group items related to the same processes.
  • Analyze the backlog as a whole vs. peeling off each item in isolation.

5. Advocate for analysis time. Our primary goal should always be producing a high-value product for our stakeholders. Sometimes that means we need to educate others about the importance of certain project tasks. Effective analysis minimizes project risk. We need to make time for analysis, or at least do a high-level analysis to show others that more is needed. Use visual models to help others understand why analysis is important. Help the team understand how the right techniques and models make analysis efficient.

6. Analyze while eliciting. Analysis and elicitation go hand in hand. It’s up to us to make sure we are enabling ourselves and stakeholders to analyze requirements as we discuss them. This is done through probing questions, using visual models, and effective facilitation techniques. When we elicit information we must go back and analyze it in order to know what else to ask. Analysis and elicitation are not separate phases, we do them together. For example, we might draw models and pictures while eliciting to get deeper dialog. We analyze as we go, by adding to our visuals and pausing to ask probing questions. We use collaborative elicitation techniques that make our stakeholders pause, think and analyze too.

When it comes down to it, no matter how agile, or how small a release or project is… it still needs proper analysis to get results!

Don’t forget to leave your comments below.

BABOK Version 3 vs. Version 2 – Taming the new Guide – Part 3: BA CORE CONCEPT MODEL (BACCM) and Perspectives

In our continuing series on BABOK version 3 vs. version 2, we conclude with the two major additions made by IIBA: the BA Core Concept Model™ (BACCM) and an all-new section containing five perspectives on Business Analysis. This article provides a summary of the new BACCM, a practical definition of the six core concepts, and an example of each. This article also describes the new Perspectives and provides examples of the common elements in all the Perspectives.

BA CORE CONCEPT MODEL (BACCM)

One of the key changes in the BABOK® Guide version 3.0 is the introduction of the Business Analysis Core Concept Model (BACCM). This model defines the framework for all business analysis work, and can be applied across industries, methodologies, projects, and organizational cultures. It shows the interrelationships among six core concepts: Needs, Solutions, Changes, Stakeholders, Value, and Contexts. There is no order to these six concepts that can be read in a variety of different patterns. Let’s look at each of these six concepts and then some of the ways each relates to the others.

Figure 1 below, published by IIBA in the BABOK® Guide version 3.0, shows the BACCM.

Needs refer to business problems that require solving or opportunities that can be seized. Needs are satisfied by Solutions.

Solutions are the products and services that provide ways to take advantage of opportunities and solve business problems. Solutions are developed through Changes consisting of one or several projects, programs, or initiatives. Examples include installation of commercial software and changes to the current processes, development of a new medical device, creation of a marketing campaign, or implementation of new regulations.

 LARSON july6Figure 1: Business Analysis Core Concept Model

Changes are the steps involved in transforming Needs into Solutions. Note that the word “Change” is used in the BABOK® Guide in lieu of the terms “Project” and “Program.”

Stakeholders are individuals or groups that have Needs, an interest in the Solution, and/or are affected by the Changes.

Value. Solutions need to provide Value to the organizations and Stakeholders. If Solutions do not provide Value, they have not met the Need. Business analysis is really all about delivering Value to the organization.

Contexts are all those things that affect and are relevant to the Changes. This is the environment in which the Solution will be developed and includes such things as organizational culture, as well as the culture of the various countries that might be involved, languages, organizational process assets and environmental factors, constraints like weather, seasons, or other things happening at an organization or within a division or department.

Let’s look at an example of these interrelationships.

Need. A sponsor is concerned about losing market share to a competitor. One of the problems that contributes to this loss is the limited information provided by the set of Order reports she currently receives. Her Need, then, is the limited Order information inhibiting her ability to make good buying decisions.

Solution. After some analysis and a business case, the business analyst has recommended commercial business analytics software as a Solution. This is a complex Solution that will involve multiple projects addressing such things as processes, software, and new technology to name a few.

Changes. The Changes to the organization will be significant. The analysis of the current state and definition of the future state done during Strategy Analysis will need to be refined and expanded. Some of the Changes include designing new processes, purchasing new software, modifying data structures in existing interfacing applications, capturing new data, building technical ways to transition to the new software, and more.

Stakeholders. Stakeholders including buyers, merchandisers, advertising staff, distribution centers, retail store personnel, customer service specialists, several vendors, and many areas in IT will be affected globally.

Value. This Solution will provide Value to the sponsor, many Stakeholders, and the organization. The business case included a cost/benefit analysis which showed that although the costs were high, the organization would start seeing a benefit within a year. Several solution performance measures were identified during Solution Evaluation to help measure the realized value.

Contexts. Since this is a complex project with globally distributed Stakeholders, there are many Contexts that need to be considered. Each country’s laws and regulations, the various national cultures, as well as the different departmental cultures will affect the development of the Solution. For example and speaking generally, the distribution staff tends to be casual, the buyers more goal-driven and direct, and the advertisers more expressive. In addition, one of the facilities is in central Europe, which has recently experienced massive flooding. Finally, monsoon season is approaching India, where some of the technical and support staff are located.

Understandably not all Solutions and Changes are as complex as this one. This example was meant to provide an understanding of each of these six core concepts and how they fit together.

Perspectives

The BABOK® Guide Perspectives are focused areas that need to be addressed depending on the nature of the project. Each Perspective provides how business analysis work is completed and its unique characteristics on projects with these Perspectives:

  • Agile
  • Business Intelligence
  • Information Technology
  • Business Architecture
  • Business Process Management (BPM)

Some projects will have multiple perspectives. A business analytics application, for example, might have elements from all five perspectives.

Each perspective is organized into five sections:

  • Change scope (think project scope) includes such things as which areas of the organization are impacted and will be affected by the approach taken. For example, the Agile perspective alludes to a constantly changing scope. The BPM perspective contains four typical lifecycle stages and several methods to outline the scope.
  • Business analysis scope includes the scope of the business analysis work, including which artifacts or work products will be produced and which stakeholders will be involved in the change. For example, the Agile perspective notes that the amount of rigor applied to documentation, a business analysis work product, is dependent on the nature of the project.
  • Methodologies, approaches, and techniques. Each Perspectives might have some specific methodologies or approaches that are unique to that Perspective. Scrum, for example, is an Agile Methodology. Information Technology has its own development life cycles. As an example of a technique, Prioritization is listed as a general technique, but in the Agile perspective MoSCoW prioritization is listed as an Agile-specific type of prioritization.
  • Underlying competencies include those that are most relevant to each perspective. They do not have to be unique and might be relevant to other Perspectives as well. For example, the Communications and Collaboration technique is listed as an underlying competency in the Agile perspective. Collaboration Games is listed as a general technique. Communications Skills is listed as a general underlying competency.
  • Impact on Knowledge Areas shows a mapping of specific activities relevant to the Perspective to the BABOK® Guide tasks. For example, the Agile Perspective discusses the relationship to the Requirements Life Cycle Knowledge Area, stating that requirements are defined with increasing detail and that validation of requirements is done at the end of each iteration. The BI Perspective mentions overcoming barriers to utilizing new analytic tools and techniques in Solution Evaluation.

This article has provided a summary of the new BACCM and Perspectives with some examples to help decipher these new concepts. The overall series of articles gives an in-depth look at the new BABOK version 3. The new Guide represents a major increase in content and improvement over version 2. Our goal was to explain the major changes and additions, and to structure and simplify it. Please respond with your comments, questions, and any disagreements.

Don’t forget to leave your comments below.

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.