Building the Foundation: The BOK on BA

by , , ,
A new collaborative blog featuring the contributions from the core team members of PMI's Foundational Standard in Business Analysis. This blog will provide the community with insight into PMI's development of the standard to generate professional discussions about the content in advance of the scheduled reviews.

About this Blog

RSS

View Posts By:

Laura Paton
Joy Beatty
Cheryl Lee
Sue Burk

Recent Posts

PMI's Newest BA Standard and the PMI-PBA Credential

An Update On PMI's Consensus Based BA Standard: The Final Phase

The Link Between Business Analysis and Project Management Processes

Party Like a Business Analysis Rock Star!

PMI’s Business Analysis Standard – What You Have to Gain

Viewing Posts by Joy Beatty

Adapting Business Analysis Processes for Adaptive vs Predictive Life Cycles

Categories: Business Analysis

As you’ve likely heard, the SME review is complete for PMI’s business analysis standard and we will soon be in the public review stage. With that we want to share a little more of what you’ll find under the covers. We have included a variety of helpful things in our attempt to come up with a product that is friendly to the adaptive, predictive, and the “anywhere in between” members of the community. One of the critical constructs we created to address this very topic is what we on the team colloquially call “the tailoring tables”.

Let me back up a moment and explain that for each of the processes, we certainly try to explain in text how the process might vary depending on whether you use an adaptive or predictive life cycle on the project, program, or portfolio. However, we wanted to also offer a tool for readers to quickly summarize the essence of how each process might vary, so it’s not buried in text – that tool is the set of tailoring tables. Within the guide, these tables describe three common aspects of how business analysis could be tailored based on your selected project life cycle:

  • Process Name – what the process is called can vary
  • Approach – how or timing of when you perform the process might vary
  • Deliverables – the things you produce when performing the process might vary

Every process includes a table describing how the process is commonly tailored with regards to the topics above for adaptive versus predictive life cycles.

One key phrase in that previous sentence is “commonly,” which means this content is not a rule or policy, but rather a guideline. For example, if we said that in adaptive life cycles, requirements are typically represented in user story format, and your organization has reason to write them in use cases instead, then by all means you should produce use cases. Similarly, there is nothing in this guide indicating that user stories cannot also be used in predictive life cycles, even though we don’t explicitly say they can. I mention this because this is probably the most prevalent feedback we got about these tables. Some of the SME reviewers felt like the predictive tailoring suggestions might be helpful in an adaptive project or vice versa. We agree! We just had to also offer something more useful than saying “you can do anything in any life cycle” so we reflected on common practice and used the reviewer feedback to help tweak what we missed.

Here is an example of what this table might look like for the Define and Elaborate Requirements process.

©2017, Project Management Institute, Inc.

That is “tailoring tables” in a nutshell. Whether you love or hate them, we welcome your feedback. You can formally (or informally!!) share your thoughts in the public review process of course, too.

Posted by Joy Beatty on: February 23, 2017 04:37 PM | Permalink | Comments (9)

How the Business Analysis Standard Could Have Helped an Agile Transition

Categories: Business Analysis

While the team is collaborating on PMI’s business analysis standard, we have been very conscientious about making sure we are not favoring predictive over agile approaches, or vice versa. We are focusing on covering topics as inclusively as possible, while also offering suggestions on how to adapt activities to any approach. I promise we will have more to say on this in future posts!

For now, I wanted to share some examples to demonstrate we are being agile-friendly when developing the standard. Our work is based on community research to understand what common and best practices are. However, we also learn a lot when things do not go as smoothly as desired, so it is interesting to think about those situations also.

One particular experience in a large organization actually inspired many ideas for me. This large global organization was making a transition from a waterfall to an agile delivery approach, and like many others, ran into some issues. Here are the most critical issues with which our business analysis standard could have helped.

Issue #1: Throwing the baby out with the bathwater

This organization previously demonstrated really strong business analysis practices in waterfall approaches. They understood projects’ business objectives, they created detailed visual models to guide their requirements, and they wrote nice requirements statements. However, during the transition to agile, the business analysts were scrambling to find a role. They jumped right in to help write user stories and acceptance criteria—not a bad idea in and of itself. However, that is all they wrote—lots and lots of textual user stories. The entire team filled the backlog with user stories simply by brainstorming to see what came to mind. Then, the team prioritized the user stories based on what the business said was most important instead of looking at the business objectives. It is as if they forgot all of their good business analysis practices when they moved to an agile approach!

We hope to help: This business analysis standard will hopefully be a reminder, evidence, and explanation of how business analysis is just as important in agile approaches as in others. For example, the team could still create visual models to help identify or explain user stories and acceptance criteria. Similarly, the business value or business objectives are perfect to help prioritize the backlog against something other than intuition.

Issue #2: Being an agile purist

This organization had previously been coached that being purists was the only way to deliver with agile approaches. Their biggest and highest risk project was using agile practices, but the others were not. Not surprisingly, this generated a lot of tension between the waterfall projects wanting to only receive interface requirements up front and the agile team not wanting to commit to what they would build or need in their attempt to be purists. The solution they eventually landed on was to temporarily create agile requirements documents. Many agile purists would have cringed! However, the agile teams documented “just enough” about what they would need from the waterfall project teams so those teams could plan for the interfaces. They documented a little bit about each interface they knew about up front with the equivalent of business requirements.

We hope to help: The standard will help offer suggestions about how to adapt business analysis practices for agile approaches, but they are only suggestions and are clearly labeled that way. As Cheryl nicely explained in a recent post, there are many ways to perform the business analysis processes. This team would be the first to admit there is no one size fits all “way” for any of these practices, including the agile ones. Organizations have to determine how they wish to use (tailor) the guide to the culture and operating environment of their corporation.

Issue #3: Waterfall communication style for agile interfaces

When the organization first started using agile on the large project that interfaced to many others, they had excellent communication within the agile team. However, they neglected to plan for similar levels of communication with the non-agile teams. The reality is, they probably needed more communication with outside teams than with their own. There were so many interfacing project teams that just jotting down requirements about interfaces was not enough; it took a somewhat intimate understanding of the interfacing systems to know if the details were all understood. By the end of the project, the agile team actually had a full-time resource whose job was to talk to all the interfacing project teams on a regular basis to identify areas of risk, points of conflict, and high priority interface requirements.

We hope to help: The collaboration points from Business Analysis for Practitioners: A Practice Guide were well received in the community because they help you think through how you might collaborate with project managers. This standard will continue that spirit with even more ideas about whom you might collaborate with and on what!

PMI’s business analysis standard probably won’t be the answer to all problems that organizations face in their transition to agile. However, I can assure you there will be a substantial amount of content about what things you can do with business analysis in agile.

Posted by Joy Beatty on: August 26, 2016 10:12 AM | Permalink | Comments (5)

Business Analysis: Models for Everyone

Categories: Business Analysis

I’ve been anxiously awaiting the time to write this post because it is about something near and dear to my heart – analysis models! Models are by no means new to the business analysis profession, but I’m thrilled to say that the use of them has become much more prevalent – almost mainstream – over the last five to ten years. Given that, you would naturally expect the PMI foundational standard in business analysis to have a home for them, much like they are in section 4 on Requirements Elicitation and Analysis of Business Analysis for Practitioners: A Practice Guide.

As described in the practice guide, models are visual representations that efficiently arrange and convey information in a concise manner. Models can be in the form of diagrams, tables, or structured text. Models are used in planning, analysis, design, construction, training, coaching, and many more roles. There are many types of analysis models and the following table shows the ones we found to be most prevalent, and are therefore covered in the practice guide. The models are grouped by categories in this table to help you think about the kinds of models that exist more precisely than just listing them. Most projects, programs and portfolios will need to use at least one model from each of these categories. In fact, the table of models is sort of a model in itself because it organizes information for better understanding!

Category

Definition

Example Models

Scope models

Models that structure and organize the features, functions, and boundaries of the business domain being analyzed

  • Goal and business objectives model
  • Ecosystem map
  • Context diagram
  • Feature model
  • Organizational chart (described in Business Analysis Planning)
  • Use case diagram
  • Decomposition model (described in Business Analysis Planning)
  • Fishbone diagram (described in Needs Assessment)
  • Interrelationship diagram (described in Needs Assessment)
  • SWOT diagram (described in Needs Assessment)

Process models

Models that describe business processes and ways in which stakeholders interact with those processes

  • Process flow
  • Use case
  • User story

Rule models

Models of concepts and behaviors that define or constrain aspects of a business in order to enforce established business policies

  • Business rules catalog
  • Decision tree
  • Decision table

Data models

Models that document the data used in a process or system and its life cycle

  • Entity relationship diagram
  • Data flow diagram
  • Data dictionary
  • State table
  • State diagram

Interface models

Models that assist in understanding specific systems and their relationships within a solution

  • Report table
  • System interface table
  • User interface flow
  • Wireframes
  • Display-action-response

Table source: PMI, Business Analysis for Practitioners: A Practice Guide

The when, why, and who of it

As analysts, models help us create order out of information so that we can find inconsistencies, gaps, and extraneous information. Analysis models also help us to represent information so that others can consume it. Our business stakeholders, construction teams, testing teams, executive teams, and managers all use models to understand what the product needs to do and why.

But wait, what about agile?

Sue’s recent post highlighted how business analysis is applicable in both predictive (such as waterfall) and adaptive (such as agile) life cycles. As she points out, models are useful in both life cycles! The choice of models, formality of their representations, or timing of their use might vary from adaptive life cycles to predictive life cycles. But frankly, those same things vary from any waterfall project to any other waterfall project also. There is no “one size fits all” approach to modeling. In agile approaches some scope and goal setting models are more likely to be created early in the project to get a lay of the land. However, more detailed models to identify acceptance criteria are used just in time to plan iterations as part of elaborating backlog items.

All industries

If you work outside the software or IT arenas, you might be wondering whether analysis models are even applicable. The short answer is absolutely! However, some models are better than others. For example, some form of process flows or use cases can be used to describe how users will use or interact with anything – be it a shopping center layout, an insurance claims process, a city intersection, a turn signal on a car, or a rocket ship. On the other hand, some models such as display-action-response models are only useful if there is some kind of a user interface to be specified.

I once met some engineers from a company that builds heavy machinery. They didn’t work on software, but rather they were in the product design department for the physical machines. Once introduced to analysis models, they quickly adopted business objectives models, process flows, and feature diagrams to improve their requirements and design work.

What to expect

PMI’s foundational standard in business analysis will explain analysis models in general, describe why we create them and how we analyze them, and offer a visual template for many types of models. Business Analysis for Practitioners: A Practice Guide offers more depth on when you use each of the models, how you use each of them in relation to requirements, and an example of each model. The two publications in combination will provide a wealth of knowledge for those just getting started in the modeling space or a quick lookup reference for the more experienced professional.

Like I said earlier in the post, there are so many different types of analysis models. I’d love to hear what the community thinks about models. What are your favorite models? Are we missing any key ones that you’d like us to consider for inclusion in the standard? Do you really like or not like any of the ones I listed here?

Posted by Joy Beatty on: June 30, 2016 11:55 AM | Permalink | Comments (8)

Business Analysis and Successful Outcomes

Categories: Business Analysis

In my previous post, I talked about the need for executive buy-in on business analysis activities and some ideas on how to grab their attention. And as I mentioned in that post, they are not our target audience for PMI’s foundational standard on business analysis so we need to find other ways to win their support. In this post, I’ll explore another avenue to attract executive attention—­delivering successful outcomes.

Executives care about the business outcomes they are funding with their projects. As business analysts, we have to show the link between our analysis and the project’s success. First, we need to measure whether we’ve met project goals or delivered successful outcomes.

But how do we measure that? What should we even be measuring? Should we measure a reduction in missed requirements? Or whether our business analysis deliverables are done on time? No! (Well, at least not for the purpose of getting your executive team to buy into the value of the business analysis role.)

A phrase I love to say quite often: remember, requirements are just a means to an end.

At the end of the day, doing good business analysis work or producing perfect requirements is not actually useful if it doesn’t lead to successful outcomes. Launching successful products is a worthy end goal. Delivering business outcomes is a worthy end goal. Delivering the desired business value is a worthy end goal. Business analysis, I’m sorry to say, is not actually a worthy end goal.

That said, business analysis helps identify the business problems that need to be solved or the opportunities that can be capitalized on. Business analysis helps elicit the objectives the team is striving to deliver. We help identify the risks that will keep us from being successful, the assumptions about our objectives that might derail us, and the requirements that help ensure we construct the solution that delivers success. We work in lockstep with our business stakeholders and IT stakeholders every day to enable alignment between the organizations, so that the solutions delivered solve the business problems. (The Needs Assessment chapter of the Business Analysis for Practitioners: A Practice Guide describes identifying problems and opportunities in more detail.)

So the good news is that business analysis is 100% necessary to deliver those aforementioned worthy end goals. And while executives don’t all value business analysis yet, they do in fact value business outcomes. And therein lies the key to their hearts … or minds at least! If we can help deliver successful projects, then we can be reassured that the business analysis we perform is successful, which hopefully leads to executives supporting our cause.

Some takeaway points to think about:

  • Define measurable business objectives: Do you have these defined for every project you work on? The only way you can deliver successful business outcomes is to understand what success actually is. Business Analysis for Practitioners: A Practice Guide describes Goal Models and Business Objective Models as mechanisms to capture these in chapter 4.
  • Plan to measure: Surprisingly, most organizations don’t come back to measure objectives after the fact, so plan for how measurement will happen (including building in features to support measuring success if needed).
  • Go back and measure: When its time, measure whether the objectives or success metrics were achieved. Failure is OK as long as you grow from it. And you can’t grow if you don’t know you even failed, so don’t be afraid to measure this.
  • Report on success (or lack thereof): Summarize the results and make sure they are reported to executives.

I’d love to hear what others’ experiences are with defining success measures and actually measuring them. I think this is one of the hardest things we do as business analysts, so please share with us your successes, failures, funny stories, horror stories, or questions you want to pose!

If you are interested in learning more about performance measurement, you'll want to take a look at PMI's Foundational Standard on Business Analysis when it comes out for public review in 2017!

Posted by Joy Beatty on: May 06, 2016 11:35 AM | Permalink | Comments (5)

How to Get Executive-Level Support for Business Analysis

Categories: Business Analysis

It probably goes without saying that PMI’s foundational standard on business analysis has a pretty obvious audience—those who actually do business analysis as part of their everyday job. In fact, it’s pretty unlikely executives or CIOs are going to pick it up for some light reading. That’s why I wanted to use this post to help those of us doing business analysis day-to-day think about how to make sure our executive-level managers get value from what we do, and even better—that they recognize it!

A couple of weeks ago, Cheryl’s post zeroed in on the value of business analysis (and this standard!), highlighting that poor requirements management—a key component of business analysis—is one of the top reasons that projects fail. So we all know that our executives should value business analysis, but do they?

Checking in: Do Executives Really Care?

Think about your own organization—does your CIO truly care about business analysis and whether you do it well? What about your CMO, CFO, or even CEO?

PMI’s Pulse of the Profession In-Depth Report: Requirements Management: A Core Competency for Project and Program Success showed that top management and executive/project sponsors do not fully value requirements management as a critical competency. 9% don’t value it at all, only 36% fully value it, and the majority (55% only somewhat value it. My experience is that some CIOs do care, but they will also cut scope on business analysis when budgets are tight. In fact, within the last couple of years, there was pretty upsetting news in our industry when a US corporation (that we will keep nameless!) completely cut the business analysis function as part of its move to an agile approach.

However, we also know from PMI’s Pulse of the Profession report that when top management and executives fully value requirements management, their companies are significantly better at meeting business goals. In fact, the percent of projects that meet their goals goes from 44% to 66% when executives value requirements. So, while all executives might not value business analysis today, if we can get them on board with our mission and the time we put into good requirements work, our organizations will be more successful. And as follows, our executives will be successful. So do our CIOs care about what we do? Directly—probably not. But indirectly—very much so!

So let’s talk about how we can generate more direct support.

Attract Executive Attention

As Sue pointed out in her post, we have to spread the word and be advocates for business analysis. Part of this is evangelizing what we do up organizational hierarchies to the executive level. The goal is that one day executives will understand the business analysis role, support it, and fight for it in budgets. So how do we get their attention?

Executives love metrics to help them better understand the state of the organization. One approach is to report out on business analysis related metrics. Here are a few suggestions of metrics you can start with:

  • Business objectives exist: These represent the measurable end goals for the business, so start by measuring whether they are even defined for projects. They can’t know if projects are successful if we don’t define end success. For example, maybe set a revenue growth target for the project.
  • Business objectives achieved: Did projects achieve the business objectives? Even if the answer is no, at least you now have transparency with executives about that and that you will take steps to do better next time.
  • Interim success metrics:  Sometimes the end business goals can’t be measured until well after a project is complete, so look for something to demonstrate your project is on track to meet its goals. Examples might be new customers registered, user adoption of a new solution, or increases in customer satisfaction.

We’d love to hear your feedback on this topic. Do your executives care about business analysis? Do they support your teams by allocating enough time to good business analysis practices? What have you done that successfully got their attention?

And check back next week for a related post. I’m going to discuss how business analysis can help define and achieve successful business outcomes that executives very much care about.

Posted by Joy Beatty on: April 29, 2016 12:52 PM | Permalink | Comments (14)
ADVERTISEMENTS

If we do not succeed, then we run the risk of failure.

- Dan Quayle

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events