Project Management

PMI’s Foundational Standard in Business Analysis…the Value Proposition

From the Building the Foundation: The BOK on BA Blog
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

This week I thought it would be fun to engage the community by providing a bit of insight around what is in store with PMI’s Foundational Standard in Business Analysis. I have seen the question posed more than once, “Why do we need this standard?”

As we mentioned at the product launch, PMI was waiting to hear from the community after the unveiling of Business Analysis for Practitioners: A Practice Guide.  Did the community want and need more? Was the community wanting to see PMI move forward with the development of a foundational standard to support the business analysis profession and serve as a reference for the PMI-PBA®?  Well, the answer was very clear by the feedback received, and so here we are developing the standard!

The core development team brainstormed ideas for building off the success of the practice guide while also addressing the most recent trends in the industry and the needs/desires of the community. So let’s take a look ahead… 

  1. The new foundational standard in business analysis will align well with the PMBOK® Guide, and by doing so will help project managers and other team resources understand how the work of business analysis aligns to the work of project management.  The business analysis standard will align and integrate the knowledge areas and process groups presented in the PMBOK® Guide to help address the confusion surrounding how business analysis is performed in relationship to project management.
  1. But wait!! Business analysis is performed outside of projects, and therefore equally important will be the alignment to PMI’s Portfolio and Program Management standards. There has been much misinformation in the community regarding the scope of business analysis and therefore this alignment should help address those concerns.
  1. Now our team would be remiss to simply frame up an IT-centric waterfall-based standard. We know business analysis is performed on a lot of projects including IT ones; but we also recognize the importance of understanding what business analysis looks like in iterative and adaptive project life cycles too. PMI’s Foundational Standard in Business Analysis will embrace adaptive (agile) project life cycles as much as predictive (waterfall) approaches.  And while I am talking about the breadth of this standard, let me also mention “across industries”. So think of this new standard as a one stop reference for business analysis across life cycles, across project types and across industries.
  1. Speaking of one stop reference, one of the biggest thrills for me in seeing PMI move forward on these business analysis initiatives, is that for the first time in our community PMs and BAs can have standards that align, use a common vocabulary, and emphasize the desired and well-needed collaboration that many organizations struggle with. By having these two critical disciplines under one PMI umbrella, teams can easily obtain complementary resources required to make their projects, programs and portfolios successful.
  1. Also, PMI’s Foundational Standard in Business Analysis will continue to utilize the collaboration points that the community so loved with the practice guide. We aren’t stopping by looking solely at the PM and BA roles, but instead are looking at how business analysis resources work across the organization with many role types to perform business analysis successfully.
  1. Last, but certainly not least, let me also share that we really put the focus on business analysis and not business analysts. Does this seem odd?  Well let me explain that many adaptive life cycle projects such as Scrum, don’t recognize the role of the business analyst explicitly and so we need to evolve too!  Ellen Gottesdiener and Mary Gorman so eloquently state this point in “It’s the Goal, Not the Role” and this team is really taking this to heart. The objective is to focus attention on how business analysis supports the end goal - successful product delivery, regardless of job title performing the work. We continue this thinking within PMI’s Foundational Standard in Business Analysis.

We hope you are as excited as we are about the evolution occurring with these critical disciplines and being able to finally align and come together under one umbrella, share a common framework and language and move us towards a shared understanding of what it takes to perform business analysis. We can’t wait for you to engage with us further during future review processes and help contribute to this advancement in business analysis to support project, program, and portfolio efforts. 

So what do you think?  What are you looking forward to seeing and what ideas are valuable to you and your organization?

Posted by Laura Paton on: May 20, 2016 08:09 AM | Permalink

Comments (25)

Page: 1 2 next>

Please login or join to subscribe to this item
Well, first of all, let me say that because english is not my first language perhaps I missunderstood some of the statements above. My comments: 2-"business analysis is performed outside projects..." and during the project too. I mean, business analysis is performed before a project exists, during the project (covering the five process groups) and after the project ends.

3-"We know business analysis is performed on a lot of projects ..." the worst thing the PMI can do is to tie business analysis discipline to projects. It does not means that business analysis is not used in projects. But the worst thing the PMI can do is to mention about projects inside the business analysis standard except for the collaboration points. Worst is to tie business analysis to life cycles. One of the duties of business analyst is to select the life cycle that best fits into the initiatite. So, please, do not put a list of life cycles inside the business analysis standard unless for a simple reference because lot of initiatives follows a life cycle created for the initiative itself. If you want to reference life cycles models please put a reference to the papers but the original onces.

6-"adaptive life cycle projects such as Scrum, don’t recognize the business analysis role..." please sorry but let me say that this is not correct. Business analysis is there but in case of SCRUM the name is not business analyst while in other adaptative life cycles like DSDM you will find the role and the name. So, business analisys role can be named with any other name (as today happends inside the organizations) but it is still there. You can see the IIBA´s Agile BABOK extension as a good point of reference. I have used and I have made research in the most famous agile software development methods (today, most of them becomes agile solution delivery methods) like DSDM (I earn the practitioner and coach certification on this method and I was part of version 1 and 2 author team), SCRUM, XP, FDD, ASD, Crystal Clear, LSD and Agile Unified Process and you can identify the business analysis role sometimes with a different name. On the other side, I have teached business analysis courses to people who works with some of those methods performing some role because those people understood that in fact they was business analyst.

Hi Sergio, we indeed understand that business analysis is performed pre-project, and this standard will address that point. We emphasize as well, any delivery method. We are focusing on 'business analysis' not 'business analyst' as many roles perform the work. If I understand your notes above, you/I agree to both points.

In my opinion, to have a very clear distinction between many terms (even they are overlapping), we should have the following key terms:
- Business Analysis (discovery and evaluation of needs),
- Project,
- Program,
- Portfolio

including the following categories of processes:
- analyse
- governance
- management
- control

PS: In many languages, the business term has a pejorative sense (”To make money”). A clear definition a ”BUSINESS” term is crucial.

Thanks Gheorghe, you can count on a robust glossary being part of this standard.

In the spirit of the brilliant "it's the goal, not the role" and looking at business analysis beyond projects, an additional focus on business analysis as it relates to innovation would be timely and valuable.

I like that thinking Elizabeth!

Amen Elizabeth (hehehehe). In the organization where I am working right now this is the focus we take (in fact the organization have create a business unit named "innovation and transformation") and it will happend by implementing agile at organizational level (following the way of USA DoD NSF/Agility Forum). But beside that, I hope people understand that business anlysis is critical success factor to implement innovation environments (let me say, really innovation environment because unfortunatelly today innovation becomes a buzzword).

Thanks for the piece Laura

Hello laura, i m very exciting by this project... Even if my English could be better!
I hope i could you help to give you some French and Europe experiences about BA...

First, I want add an important part, something very different between PM and BA: personality or behavior... And the very important competencies to underlying : soft skill... BA is not a technical skill, is a relational skill, link creator

Second: many questions are about what are the deliverable which BA are responsible, in a project BA, is it accountable about Scope? And PM about Time and Cost?

Good luck to the team

Cedric, sorry for intervene. You have two type of scopes: Product scope (in fact, product/service/result. The thing you will create) and Project scope. Project scope is defined from Product Scope. Inside Project Scope time and cost is included. The business analyst is accountable for Product Scope. The Project Manager is accountable for Project Scope. It that not means that both do not have to work closelly. For example, while it depends on your life cycle, you can find that pre-project activities to create a business case are on charge of buisness analyst but she/he must include somebody that understand about project management no matter most of the times that person will not be the project manager assigned to the project if the business case is approved.

Cedric, I think you'll be happy with what we are providing in the standard on soft skills and competencies. Obtaining a strong understanding on deliverables and level of formality of such deliverables across life cycles will also be a take-away with this new standard. No need to flip through multiple source materials because you are working on a project that is using an adaptive project life cycle!

Sergio did a great job answering the scope question...I concur with his points.

On another note, I failed to mention that this new standard is much bigger than 'project BA'. Although we know a lot of business analysis is performed on projects, this standard will address business analysis broadly. Business analysis supports programs and portfolios, and you'll walk away with a great sense of these relationships and the value business analysis provides inside and outside of projects.

Thank you very much Laura. And thank you very much to you and the team about the standard scope definition. it is great for a lot of business analysis which are working with this scope definition like myself. And for other with a more limited scope too. As you know, when the standard will be published, most of the companies will put their attention about business analys role on the standard definition due to PMI reputation.

Just one question that came into my mind when I read Laura's "On another note...": As far as I encountered BA work, BA does not only support projects, programs and portfolios - it also might support company initialization. Maybe it's academic question, but doesn't that mean, there's also BA work outside programs and portfolios - e.g. during definition phase of company / portfolio?
That's what I call "different levels" of BA work.
But you can see company founding as a project or program, of course. So maybe there's not BA work outside programs/portfolios. What do you think?

Sorry for intervene but Rolf point is critical to consider. Based on my personal experience and after working in worlwide project and making some personal research the answer is; YES: And it is critical (if you see my other comments in multiple forums) to understand this when the new standard is created. I do not agree with you Rolf (and sorry if I missunderstood) about talking of "levels". That is because I made lot of concerns when the IIBA created a multi level certification. A business analyst must not be consider (in my humble opinion) as a multi level role. We need to sustain the basic. And with the basic we need to determine the tools and knowledge that best fits (in the case of a BOK that is proven) or can be used to be close to assure that the right solution is creating to solve the buisness problem. When I was part of BABOK creation I was one of the advocates to include things related to know organizational life cycle as a tool. This was not included and it is ok for me. But this type of knowledge, closed to you can learn into a MBA, is critical for a business analyst.

Hi Sergio. I might not have been clear enough about what I mean with "Level". It's not about certification levels or employment / departmental levels, but levels of view on (or maybe level of) "the thing" (as you called it in some of your comments). A (somewhat simplified) list of the levels: company level, business view of product/service, technical view of product/service, level of component, level of module. It's all driven by "the thing" not by process structure (which would be companies processes, portfolio / program / project / subproject).
The levels I think of are the levels you move around in your work - until you get deeper when developing / realizing a solution. For me that level concept is very important not to dig too deep too early in finding / developing a solution. And it's important when you talk about a solution - different stakeholder need Information at different levels about the thing and the solution.
Maybe "level" is not the right word in English - please correct me then - but I came across that early in my carreer and the concept helped me a lot to stay focused and systematic.
I agree, that we should not talk / think about certification levels when collecting a BOK. Certification levels are something more on the commercial side of "certtification industry". My experience with BA work is that you will need nearly all methodology, tools etc. at all levels of work (use my notion of levels). So it makes no sense for me to distinguish - the only differentiation that might make sense would be experience levels - or (if you want to make more money out of certification levels) specialization on different work areas. But that comes after the BOK collection and should be left out at our discussions on the new standard.

Sergio - to what of my two questions you answer YES? They go into different directions, so I'd like to know to which you go.

Page: 1 2 next>

Please Login/Register to leave a comment.


"I don't know much about being a millionaire, but I'll bet I'd be darling at it."

- Dorothy Parker