Skip to main content

Tag: Business Analysis

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.

Want a Successful Agile Team? Include a BA!

My client’s project struggled for direction. The team spent 4 months trying to determine what to build. Then, most of the team quit. A new team formed with the imperative to “just get something in the hands of the end user.” The team achieved this in 2 months, but now they realize the value, purpose, and priorities of the project are unknown. In discussing next steps, the Development Lead Manager asks:

“Why would we need a business analyst? Can’t the developers just talk with the end user? Isn’t the problem the users don’t know what they want?”

Agile teams often overlook the role of business analysis or assume the Product Owner fulfills this role. Show me a team struggling with quality, product reworks, and delivering value, and I’ll show you a team with no business analyst.

Successful BAs Help With Communication

The biggest benefit provided by a business analyst (BA) is communication. Expressed as an Agile value, business analysts help with customer collaboration over contract negotiation.

Business owners and developers speak different languages. In many cases the developer has a natural tendency to think they know how to build a solution without the need for clarification. The business owner struggles to express needs in terms of priority and treats every idea or suggestion as equally important. The result of this is an incomplete solution and an unhappy customer.

Having someone there to get everyone on the same page and agree is critical. The business analyst is an honest broker for building the right solution, defining the acceptance criteria, and seeking clarification when needed. The business analyst is constantly facilitating discussion, documenting requirements, and testing and validating the solution.

The goal of Agile software development is working software over comprehensive documentation. A common conclusion is that developers matter and non-developers are unnecessary.

When a software product team is successful, the developers and designers (those making the tangible product) get all the credit. When the product team does not succeed, the blame is on ill-defined requirements, poor testing, or lack of management.

As a result, management tends to overlook the BA role when forming a team. Since the work of the business analyst on the Agile team is non-tangible, it is easily forgotten. This is like building the next best search engine but omitting the server capacity necessary to handle the traffic load – a disaster waiting to be discovered.

BAs and the High Performing Team

So what does a high performing team with business analysts look like? It is a team which responds to change quickly and easily over following a plan. What leads a team to success is really about preparation: determining the value, purpose, and priority before investing time and money.

The business analyst brings preparation and planning to get stakeholders’ perspective. These advance conversations discover those insights in advance, so the approach is from a value-first, holistic solution rather than functional perspective.

The high performing team also gets feedback early and often. The business analyst will solicit and facilitate this feedback throughout the process, even more often than just at sprint reviews. Getting the feedback sooner means the team doesn’t make mid-stream course corrections or deliver an unsatisfactory solution.

In the end, it is about individuals and interactions over processes and tools. There is no single correct answer for implementing Agile principles and values on a team. In the same fashion, there is no single correct answer for how a business analyst works with an Agile team. If there is a project with many repeatable steps and few unknowns, a BA is not necessary. But when the team relies on stakeholder input, the product is new or a significant change, or your Product Owner struggles to break down features to stories, the team needs a business analyst or team of BAs to succeed.

Don’t forget to leave your comments below.

From the Archives – The Value of Business Analysis: Assessing Organizational Readiness

Originially Published 10/27/14

One of the key roles of Business Analysts in the solution implementation process is to assess the readiness of the organization to take full advantage of the new solution. This is the role in which the Business Analyst acts as a Change Agent in the organization. Whether this is a software enhancement, new system implementation, business architecture, business intelligence, data, business process, product change, or change implemented by a customer, supplier or regulator, effective communication of the upcoming change to all affected by the change is important to preparing the organization to capture the expected benefit of the change.

The Goal

The goal of an organizational readiness assessment is to make sure that all affected parts of the organization, inside and outside the organization, is ready for a change that is about to take place within the organization. Effective communication is the key element in informing the organization that a change is on its way. The communication plan should include a description of the change, why this change is necessary and being made, how it will impact all the parts (business units) of the organization and the necessary steps of organizational change to prepare for the change. When the change is big enough, simple communication may not be enough to prepare the organization for the change, and training requirements need to be identified.

External Initiated Change

Sometimes a change is initiated by an external organization or agency that impacts your organization. This may be a customer, supplier or business partner that makes a change for their organization that impacts yours; such as they change a system interface you use to get information to or from them, or they change a business process that impacts your processes. Sometimes this is a regulatory agency that enacts a new legislation or guideline that your organization must conform to. This mostly impacts organizations in heavily regulated industries such as financial services, pharmacy or biotech.

Internal Change Affecting Others

Your organization may make a change of its systems or operations that affect your customers, suppliers or business partners. Your communication plan must extend beyond the walls of your organization; you must inform your business partner(s) of the upcoming change, timeline and the expected impact upon their organization.

Internal Change Affecting Only Your Organization

Then there is the change that affects only your organization. Whether this is a system change or operational change, effective communication throughout the organization may determine the success or failure of the change. It may not be that the solution or change was bad or inappropriate for the organization, but the acceptance of the change was not successful. This could simply because affected business units were not informed or prepared for the organizational change; or possibly just not prepared in time for the change.

Elements of the Organizational Readiness Assessment

When assessing the readiness of the organization for an upcoming change, you must assess the organization’s culture, operations and impact of the change on the organizational units. Proper assessment of these elements will give a full picture of the state of the organizational preparedness to make the necessary change to use the new solution.

Culture Assessment

Assess the beliefs, attitudes and feelings of the affected people within the organization and their willingness to accept the proposed change. The goal of this assessment is to determine whether the affected people understand the reason for the change, whether they believe that the change will be beneficial to them and the organization, and they understand why the change is required. So, in general, you trying to determine if the people affected by the organizational change want this change to be successful.

Operational Assessment

Assessing the organization’s operations determines whether the organization is able to take advantage of the new capabilities of the change, and evaluate whether the people within the organization are prepared to make use of the new solution. Determine if training is necessary and has been performed, whether new policies or procedures have been defined, whether IT systems are in place to support the new solution are in place, and whether the solution is capable of performing at the required level to give the organization the expected benefit.

Impact Assessment

Impact assessment assesses whether the people within the organization understand how the change will affect them. Some things that need to be examined are the functions, location, tasks and concerns of these people and the impact of the change on these things.

Transition Requirements

From this organizational assessment you may be able to identify transition requirements; capabilities needed to get from the current state to the new solution. Once the new solution is implemented these capabilities are no longer needed. Training is such a capability. Training on a new or enhanced system, new procedures or business process may be necessary, but once everyone affected is trained continual training is not necessary. For a system migration, it may be necessary to migrate data from the old system to the new system. Once the data is transferred, it will not be necessary to perform that function again. You may have manipulated servers or system communication channels to move that data more easily and quickly. Once the data is migrated, you may remove those capabilities.

Implementation Plan

The organizational assessment may identify transitional requirements, and these may become part of the Implementation Plan. The implementation plan is the plan for implementing the new solution, or how we get from current state to the new solution. The implementation plan will identify the culture, operational, systems and stakeholder changes that must be made to make full use of the capabilities of the solution being implemented. This is the essence of the organizational change; the execution of the implementation plan takes the organization from its current state through the changes necessary to prepare for the main organizational change to take place.

Conclusion

Changes within organizations aren’t just made, they are planned then executed. Assessing the state of the organization and the steps the organization must make, on a culture, operational, technical and stakeholder impact level is necessary to ensure that the organization will gain the most benefit from the new change solution. Proper organizational readiness assessment will help ensure that the organization is prepared to implement a new change solution for the organization and take full advantage of the new capabilities of that solution.

Don’t forget to leave your comments below.

What is your Business Analyst Brand?

I give complete credit for this article to Bob “the BA” Prentiss. I had to privilege and pleasure of hearing his keynote address to the Southwest Ohio Business Analysis Regional Conference (SOBARC), hosted by Cincinnati IIBA Chapter. It was a very entertaining and thought provoking presentation. So I invite you to consider “What is your BA Brand?”

Did you know that you had a brand? What is a brand? Many think it is a marketing tool that companies use to sell their products and services in the marketplace. Absolutely correct; don’t you think that Apple, Google, B2T Training, The Solarity Group, Bob the BA, and Watermark Learning have brands?

However did you know that you, an individual Business Analyst in your company, have a brand? What is your brand? The more important question, what do you want your brand to be?

These are the questions that Bob “the BA” Prentiss asked us at the recently concluded SOBARC conference during a very inspirational keynote address. He gave excellent tips on how to brand yourself and make yourself distinguishable among the business analysts in your organization.

whittenberger May26whittenberger May26 IMG002

One thing that impressed me during Bob’s presentation is that he never went up on stage; he delivered his entire presentation walking among the audience. When he asked the audience “What do you think about Bob the BA?” He received the joking answer “pushy”. He did not get upset, but rather took a negative and turned into a positive. He continued to discuss how we from time to time have to change the mindset and the way of thinking of some of our business and technical stakeholders to create that “shared vision”. Ending that thought with “sometimes pushy, yes I can accept that because sometimes that is what it takes to get the job done”.

So, did you know that you create your brand every day at work? So what is your brand, and what do you want it to be? As ‘Bob the BA’ puts it “Be consistent, creative, memorable, have a signature that ‘you’ cocktail…” is how you develop a great brand.

So are you consistent?

Do you consistently deliver your work deliverables on time? Early? Late? Do you “own” your work assignments? How do you want to be remembered? What is the impact to your projects and service work? Can your teammates count on you to deliver? Do you communicate to your Project Manager and other team members to properly set expectations? How is the quality of your work? That will be remembered, possibly most of all. Do you take extra time to put the professional touches, add that craftsmanship, on your work before sharing it with the team? Just a word of caution, don’t allow the professional touches make your work consistently late.

Are you creative?

Do you just take a template for an artifact and fill it out? Have you ever added something to a template? Have you ever questioned why a particular section is in the template, or challenged that it should not be in that place or in the template at all? How creative are you on your business analysis techniques? Do you just do typical individual or group interviews (discussions with business stakeholders)? When is the last time you facilitated a brainstorming or wireframing session?

Are you memorable?

Six months after a project ends, will the business stakeholders remember you as the business analyst that worked on that project? What will they remember about you? Will they say “typical BA”, “nothing special”, “shoddy workmanship”; or will they say “excellent BA”, “knows their stuff”, “kept me engaged”, “enjoyed working with them” or other favorable feedback on your work. How will you be remembered?

Are you passionate?

Do you enjoy your work and does it show in your daily work? Are you passionate about the BA role? Do you look forward to going to work every day? Will feedback come back that you’re a passionate BA? Do you go that extra mile for your business stakeholders and other team members? How will you be remembered?

The Message

I recently attended an IIBA meeting in Dayton, Ohio entitled “Craftsmanship for Analysts” by Terry Wiegmann. The message was the same as Bob the BA’s message: “Cocktail your brand”. Continuously improve, but stay consistent in your message and work. I don’t intend to take anything, or keep anyone, from seeing either of these professionals speak. In fact, I encourage anyone that has the opportunity to go participate in any of Bob or Terry’s presentations, do so; you will receive a lot from the experience.

Did this post get you thinking about your brand, and your daily work? How will you change to make your brand what you want it to be?

Don’t forget to leave your comments below.