Project Management

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


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

How Business Analysis Compares with Project, Program and Portfolio Management

As Laura mentioned in her last post, we just wrapped up SME review and are gearing up for public review very soon! THANK YOU to all the wonderful SMEs that took the time to read and provide feedback that was clear, complete and easy to understand. It was deeply appreciated while plugging away at over 1100 comments. We value the effort that it took our SMEs to review and comment, so we ensured all feedback was carefully evaluated.

There were a few interesting themes we noticed within the feedback, one of them being the relationship between business analysis with project, program and portfolio management. I wanted to pick on this point, as there is a lot of confusion and even misconception within the public on the scope of business analysis being covered in PMI’s business analysis standard.

Business analysis is a competency needed across the project, program and portfolio. Portfolios include work at a strategy level and operations, per the definition of Portfolios: “Projects, programs, subportfolios, and operations managed as a group to achieve strategic objectives.” In other words, the scope of business analysis within PMI’s business analysis standard includes work to support strategy and operations.

Based on valuable feedback from SMEs, our team incorporated changes to ensure:

1) The scope of business analysis was clarified, and

2) The relationship between business analysis with project, program and portfolio management was made much clearer.

In addition to adding verbiage to address (1), we added the following comparative overview of business analysis with project, program, and portfolio management to address (2).


Business Analysis

Project Management

Program Management

Portfolio Management


The set of activities performed to identify business needs, recommend relevant solutions and elicit, analyze, specify, communicate, and manage requirements.

The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.

The application of knowledge, skills, tools, and techniques to a program to meet the program requirements and to obtain benefits and control not available by managing projects individually.

The centralized management of one or more portfolios to achieve strategic objectives.


Solution: Something that is produced to deliver measurable business value to meet the expectations of stakeholders (i.e. new products and enhancements to products)

Project: A temporary endeavor undertaken to create a unique product, service, or result.

Program: A group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually.

Portfolio: Projects, programs, subportfolios, and operations managed as a group to achieve strategic objectives.


Product scope is defined as the features and functions that characterize a solution.

Project scope is defined as the work performed to deliver a product, service, or result with the specified features and functions.

Programs have a scope that encompasses the scopes of its program components.

Portfolios have an organizational scope that changes with the strategic objectives of the organization.


Those who identify business needs, recommend and describe solutions through the definition of product requirements.

Those who manage the project team to meet the project objectives.

Those who ensure that program benefits are delivered as expected, by coordinating the activities of a program’s components.

Those who coordinate portfolio management staff, or program and project staff that may have reporting responsibilities into the aggregate portfolio.


Measured by a product or solution’s ability to deliver its intended benefits to an organization, and degree of customer satisfaction.

Measured by product and project quality, timelines, budget compliance, and degree of customer satisfaction.

Measured by program’s ability to deliver its intended benefits to an organization, and by the program’s efficiency and effectiveness in delivering those benefits.

Measured in terms of the aggregate investment performance and benefit realization of the portfolio.

Hope you enjoyed that sneak peek. Stay tuned for more information on the public review process. We look forward to seeing your comments!

Posted by Cheryl Lee on: January 26, 2017 10:44 AM | Permalink | Comments (14)

An Update on PMI's Standard in Business Analysis

Kicking Off 2017 – An Update on PMI’s Standard in Business Analysis by Laura Paton PMP, PBA

Happy New Year to all!  What better time to reconvene our discussions on this blog and to kick-off our year by providing the community an update on PMI’s business analysis standard. We apologize for going silent for a few months, but we have been so busy trying to hit our deadlines that we took a little time off from updating the blog. The great news is, the project is staying the course and is right on schedule!  I think it is safe to say you can continue to see more information about the project on this blog in 2017.

Let me step back to bring everyone up to speed on the journey so far. If you have been following this blog you would know that PMI approved a project to develop a full consensus based standard in business analysis last year. In fact, the project kickoff meeting occurred January 20th, 2016. The development team worked diligently in the spring and early summer months and delivered a draft in August. A call for subject matter expert reviewers was conducted through PMI’s Volunteer Management System and a team selected.

Subject Matter Expert (SME) Review

We invited over 30 SMEs to participate in a Subject Matter Expert Review process and the engagement was amazing. SMEs provided over 1100 suggestions and improvements   and the development team took several weeks to analyze the feedback and update the draft.   The contributions obtained from this very experienced group of SMEs have definitely helped to elevate the quality of this product. 

Public Review

 As PMI editing is cleaning up our adjudicated draft, preparations are being made to prepare for the public review process; after all this is a full consensus based standard. This process is an opportunity for the community across the world to review and provide feedback and suggestions back to the development team.

We anticipate more communication when we are ready to launch the public review process, but for now I can tell you that we are right on schedule to make this happen in Q1 of 2017.


Once the review window closes, the development team will be hard at work reviewing and considering the suggestions made by the community. The window of time needed to analyze and action on the public feedback is unknown until the team has a sense for the size of this effort, which is heavily dependent on how much feedback is received. Once the public review window is closed, the development team will be able to provide further information regarding next steps and associated dates. Based on the progress made thus far, the development team is optimistic of delivering the final product in Q3 so PMI can publish in Q4, 2017.

In Closing

If you are new to this blog, you may want to review PMI’s project announcement which is where this work all started. If you would like to know more about the value proposition of this product you can review that discussion here or feel free to review any of our past blog posts to follow the journey thus far!  We are excited for you to be part of our review team, so stay tuned for more information announcing the launch of the public review process.

Posted by Laura Paton on: January 12, 2017 10:32 AM | Permalink | Comments (20)

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)

How to Choose What to Use (and what not to lose)

As Cheryl most excellently – and tastily ::-) –   described in her recent blog, the business analysis standard will provide an abundance of business analysis practices for consideration.  These practices will be described in terms of business analysis thought processes which have inputs, tools and techniques and outputs.  When practitioners have a chance to consider so many possibilities, one of the first things that might come to mind is “How do you choose what to use?”  As a consultant, when I have been asked that question in the context of customizing a methodology, I usually start off with the classic, unsatisfying answer, “It depends”.  When the business analysis standard is available, that answer will not change, but the standard will be very, very, very helpful when you make your choices, precisely because it will be organized in terms of processes – things to think about and to do – rather than as a less structured inventory of tools and techniques or concepts. Looking at process-sized chunks will help you choose how to customize them!  And here are some other thoughts which will help you:

  • In working from Cheryl’s wonderful analogy, consider the “appetite” of your project or organization for using the processes. In my own experience, I’ve seen many a well-thought-out methodology arrive in an organization and later get discarded or diminished not because it was not a good approach, but because we humans were skeptical or uncomfortable or fearful in some way about adopting it. If the appetite is low and the need is great, it’s important to think about ways to increase the appetite as well as to choose what to use. As Daniel Mezick noted in his book “The Culture Game: Tools for the Agile Manager”, it is really, really important for people to consciously “opt in” when becoming part of an agile team. I absolutely agree and I’d also offer that consciously opting in – at a personal or organizational level – is important for the adoption of anything!
  • Consider how much latitude in customization is appropriate for your project or organization. I’ve sadly observed folks who used a tool or technique in a way which was not intended, and then when it did not produce the desired results, they blamed the tool or technique or the methodology which included it rather than how they customized it; soon afterward, the tool or technique or even the entire methodology disappeared. This is not to discourage customizing how you use a process to support your project or organization: after all, the processes which you will find in the standard are meant to be customized ::-) .Instead, take care that the way you customize still provides the value which you expect to get.
  • Consider the costs associated with your choices for tools and techniques and how or whether you will formally document outputs.  As analysts, we usually love to be very precise, but sometimes “good enough” really is “good enough” ::-). If you are dealing with problem spaces involving health, safety or finances, your choices may need to be more formal or constrained or regulated, yet you may be able to find less costly ways to comply sufficiently, while still getting the value you expect from a process.
  • Together, all the processes which you will find in the standard represent “business analysis thinking”. All are needed. Please do not totally “lose” any of them, although some may be used so very, very lightly that all that is needed is to say “yes, we thought about that” ::-).
Posted by Sue Burk on: August 12, 2016 01:29 PM | Permalink | Comments (5)

Create the Perfect Meal with PMI’s Business Analysis Standard

Laura provided A Glimpse at PMI’s Upcoming Business Analysis Standard in her last post. As we get closer to the SME and public review processes, I thought this week, we could discuss how to use the standard. I hear this quite often, “Our organization doesn’t follow the standard”. But…a standard is not prescriptive, so you can’t really “follow” it. 

In this week’s post, I’ll demonstrate how to use PMI’s standard in business analysis by providing a cooking analogy (because I love to cook…and eat). A standard would describe what it means to cook, suggest cooking techniques and tools you could use to make a particular menu option, and indicate required ingredients to make that menu option. For instance, when making a pasta dish, at the bare minimum, you need pasta and water (inputs). You may use the following cooking techniques to make pasta: boiling, baking, stir-frying and maybe the following tools: pot, pasta strainer, and tongs. The standard can be used in conjunction with Business Analysis for Practitioners: A Practice Guide (The Practice Guide) in case you need information on how to perform a technique or use a tool.

The standard will not provide the recipe to make the pasta dish—that’s up to you and your organization to create and tailor the recipe to your needs. There are many ways to perform the same process, as there are many recipes to make a pasta dish. You may also decide to make a simple pasta with tomato sauce one night and a multi-layered baked lasagna another night. Each of the business analysis processes in the standard can be performed with varying levels of formality dependent on multiple factors, like project life cycle, risk and complexity to name a few. The Practice Guide and standard will provide suggestions to tailor menu options if you’re looking for a simple vs. more complex recipe (i.e. adaptive vs. predictive considerations). Processes may also be tailored to accommodate stakeholder preferences, the same way a dish may be tailored to accommodate a customer’s request for alfredo instead of marinara sauce.

The methodology is like a multi-course prix fixe menu that the restaurant (organization) offers, from which the chefs (those who conduct business analysis) can pick and choose the menu options, and their associated, tools, techniques and ingredients. If the restaurant is striving for uniformity, the chefs can choose from among the recipes that the restaurant wants them to use. The menu (methodology) can also be tailored for similar reasons to why you may tailor a recipe (process). For instance, the prix fixe menu may provide the option to choose between a slice of cheesecake or the chocolate lava cake to top off your meal. Every process might not be used on every project, program or portfolio either, and that would be ok. It’s similar to how one wouldn’t order every item off the menu at a restaurant (although there have been occasions where I was tempted to test out the full dessert menu).

I was speaking with Liz Moore, another business analysis community member here at, on how her organization adopted the business analysis framework described in The Practice Guide. First, when asked why it decided on PMI’s product, she replied, “The Practice Guide provided the inspiration for this internal framework primarily because it was practical and aligned to the project management framework while remaining true to the principles of business analysis.” Similar to how a chef cannot run a restaurant alone, a business analyst collaborates with many others to implement products and services. The Practice Guide and standard highlight the many collaboration points with other key players allowing for better alignment between professions.

Liz’s organization recognized that “there are various teams within the department who provide solutions for different stakeholders; we knew that each would apply the framework in a unique manner.” To accommodate this, they decided to define different use cases to reflect the various usages of the framework. I thought that was brilliant since use cases allow for flexibility on how a process may be implemented through alternate paths, while still ensuring consistent business analysis practices across the organization.

We would love to hear if there are other creative ways to implement a business analysis framework via the comments below! Or feel free to send me a direct message with any must-try recipes ;)

Posted by Cheryl Lee on: July 29, 2016 09:09 AM | Permalink | Comments (6)

"Put all your eggs in the one basket and - WATCH THAT BASKET."

- Mark Twain