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 Sue Burk

The Link Between Business Analysis and Project Management Processes

Check out the discussion on Project Management.com entitled: “Is Business Analysis Properly Linked to Project Management within the PMBOK® Guide?".   The PMI® Guide to Business Analysis (Includes The Standard for Business Analysis), slated for publication later this year, will be a great resource to identify and clarify the linkage between business analysis and project management efforts. The upcoming guide to business analysis also speaks to the relationship between business analysis and program and portfolio management.     

We’ve offered a lot of entries in this blog which let folks know that that the business analysis guide and standard will cover the relationship between project management and business analysis efforts and the collaboration between those responsible for them.   For example, please see Laura’s recent blog entry PMI's Business Analysis Standard - What You Have to Gain  and Cheryl’s entry  How-Business-Analysis-Compares-with-Project--Program-and-Portfolio-Management, just to name two. 

But, if you don’t have time to go back through all of our blogs, here is quick summary of some of the ways The PMI Guide to Business Analysis and the included Standard will provide the link:

  • It presents business analysis thinking organized by business analysis process groups and knowledge areas, a structure which will be familiar to anyone who has spent time with A Guide to the Project Management Body of Knowledge: (PMBOK® Guide). At the same time, the business analysis process names are clear enough that those business analysis practitioners who are less familiar with the PMBOK® Guide will be able to see the linkage as well.
  • It reminds us that the business analysis thought process can be undertaken by anyone who has responsibility to help an organization identify and define problems and opportunities and think through potential solutions, not just by someone who has the title or role of business analyst. Indeed, some of the work which project managers do requires business analysis thinking, and the Guide and Standard point out PMBOK® Guide processes which align with business analysis processes.
  • It reminds us that while some business analysis efforts are totally focused on business analysis, others are complementary to project, program and/or portfolio management tasks and still others support project, program and/or portfolio management tasks.
  • It points out the necessary collaboration between those who are responsible for project management and those who are responsible for business analysis.

It’s been absolutely necessary and important for The PMI Guide for Business Analysis to articulate the link between business analysis and project management.  And, do keep in mind that the Guide is more than a linking document; it will provide an understanding of business analysis which applies to all delivery lifecycles, from predictive to adaptive.  It will stand together with its previously published companion volume, Business Analysis for Practitioners: A Practice Guide as a great resource for learning about business analysis practices and business analysis thinking.

 

 

Posted by Sue Burk on: April 21, 2017 02:25 PM | Permalink | Comments (11)

Sorting Out Overlapping vs. Complementary or Supporting Processes

 

As Cheryl mentioned in her recent blog entry, business analysis is a competency needed across projects, programs and portfolios.  She gave you a sneak peek at how we clarified the relationship between business analysis and project, program and portfolio management (which I’ll refer to as "management" for the remainder of this blog).   But wait, there’s more!  As the core team began to frame the content we were developing, we realized that we were delving into areas where we referred to work which is often considered part of management.  And so we had to think hard about how we would distinguish, for example, how business analysis efforts figure into creating  a project charter or deciding how to engage stakeholders.   We were sure that the efforts were not overlapping in a redundant way, so how best to explain the differences? Certainly, the product focus of business analysis and the project/program/portfolio focus of management is one difference, but what else would we need to call out?

Two patterns emerged for us for situations in which there was overlapping effort, both of which were based on collaboration of business analysis and management:

  1. Some business analysis efforts are complementary to management tasks.  So, for example, management has a strong and primary role in determining a stakeholder engagement and communication approach.  Whether determined in a formal or informal manner, those responsible for business analysis define aspects of that approach for business analysis in collaboration with management and with stakeholders. 
  2. Some business analysis efforts are supporting tasks for management.    For example, business analysis is needed  for the preparation of a project charter, where those responsible for business analysis “collaborate on charter development with the sponsoring entity and stakeholder resources using the business analysis knowledge, experience, and product information acquired during needs analysis and business case development efforts.”   As we have mentioned in earlier posts, we are trying to focus on business analysis as a discipline rather than the role of the business analyst. We use Ellen Gottesdiener and Mary Gorman’s, It’s the Goal, Not the Role as a motto on our team to remind ourselves of this important distinction.  Seen in this light, "business analysis thinking" in support for charter development is performed by everyone who has responsibility for the necessary analysis, regardless of role or title.

All and all, thinking through how to present the relationship between business analysis and management reinforced for us the  value of having PMI address business analysis: by looking at the nature of the relationship between management and analysis efforts, highlighting how some aspects of management efforts involve business analysis and also aligning the vocabulary between the disciplines,  PMI will help improve the collaboration between management and business analysis that is so critical for successful projects. 

Posted by Sue Burk on: February 09, 2017 08:15 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)

Business Analysis and Project Life Cycles

In our most recent post, Cheryl explored how business analysis can be used whenever products, services or processes are being created or enhanced, or when seeking to understand customer needs. She gave some great examples of how business analysis can be applied not only to IT projects, but within non-IT environments as well.  In this post, let’s take a brief look at the relationship between business analysis and the life cycle used on projects which develop or enhance products, services and processes.

Within the PMBOK® Guide, project life cycles range from plan-driven predictive life cycles, such as are used on plan-driven building construction projects or “waterfall” software development, all the way to change-driven adaptive life cycles, such as are used in lean building construction or  the publishing industry or in marketing or in agile and lean software development.  The project activities within these life cycles often differ in many ways; they are generally of differing duration, sequence, and concurrency.  They often are conducted with different levels of formality, and different techniques and tools.   They often differ on when and how the product is delivered to its stakeholders for feedback. These life cycles also differ in whether there is an expectation that project team members will focus on one role or will be able to take on other roles in addition to their specialties.    

Despite the differences between the life cycles, there is still a lot of commonality between them.  One important area of commonality is that no matter what life cycle is used, you still have to understand the problem you’re trying to solve in order to consider solution options to address it.  Business analysis practices are at the heart of that commonality.  No matter what the life cycle may be, business analysis thinking is needed to help identify and confirm stakeholders, to define and confirm scope, to clarify the understanding of the problem at hand, to understand the usages which the solution must support, as well as to prioritize how the solution will be delivered. Business analysis thinking is also needed to articulate the solution to whatever degree of detail is necessary and sufficient to guide those who have the expertise to architect it or design it or construct it, or to test to confirm that it meets expectations.

Activities which enable elicitation, analysis and all the other business analysis knowledge areas need to occur, no matter what the life cycle may be.  For example, using models can be a great help to a project. Models created as part of a project using an adaptive life cycle may be much less formal than those created as part of a project using a predictive life cycle, yet they serve the same purpose: to help people think and reason together to understand a problem and its solution.

You can expect the Foundational Standard in Business Analysis to highlight the commonality of business analysis thinking which needs to take place in any project while honoring the differences in how that thinking is accomplished ::-).

Perhaps you have examples of how the same kind of business analysis thinking occurs during predictive and adaptive life cycles?  Or maybe you have a differing perspective.  Either way, we’d love to hear from you!!

Posted by Sue Burk on: June 20, 2016 05:37 AM | Permalink | Comments (7)

How Important is it to Become an Advocate for Business Analysis?

Categories: Business Analysis

Very important! As Cheryl Lee said last week, “Business analysts (BAs) are sometimes seen as the annoying siblings who ask a lot of silly questions that hinder progress on projects. Organizations are sometimes unsure on how to leverage business analysis in order to deliver successful outcomes.” 

Let’s face it, business analysis is an aspect of initiatives that sometimes gets shortened or skipped. It’s not that business analysis is unimportant; some just believe other work is more important.

Finding some root causes

So why does this happen? Those of us who already know the value of business analysis do not need to be convinced. PMI’s Pulse of the Profession In-Depth Report on Requirements Management tells us that the #2 reason why projects fail is poor requirements, where most business analysis is focused. Many of us (project managers, business analysts, testers, trainers, developers, etc.) understand how important business analysis is. So, are there just too few of us? 

I recently went to a meeting on land conservation, where the very inspirational keynote speaker, Dr. M. Sanjayan, had a wonderful message from which we can learn. 

To summarize, he said, as an advocate for a cause, be careful that you’re not just talking to others who are already convinced. Instead, focus on those who do not yet care as much. Help them know why—from their perhaps skeptical perspective—it is in their best interest to care.  Dr. Sanjayan used an interesting turn of phrase—rather than “how we can save nature”, he focused on “how nature can save us”.

So I would say we also need to direct our message to those who are not yet convinced about the importance of business analysis and frame it in terms which directly impact the folks to whom we are speaking.  Promote the idea that business analysis is not just “nice to have”, but rather “something you can’t be without.”  

So what can YOU do?

Here are a few ideas, hoping that you have more to share ::-)  (No, that’s not a mistake in my smiley; mine always wear glasses ::-)).

  • Consider setting up a forum so that those who already know the value of business analysis can share ideas and experiences.Brainstorm a list of folks who need to learn more about the value of business analysis and what topics would be of interest to them and invite a wider audience to the forum.
  • Set up a fun in-person or virtual event where folks can try business analysis techniques on non-work problems to see how business analysis can clarify ideas. Visual modeling techniques are particularly appealing. For example, how about a process model for how to coordinate a trip by your hiking club? Or a little data model to structure the information kept about your book club?
  • Have a presentation or roundtable discussion at a local PMI chapter about how BA/PM collaboration can support successful project work. For ideas, check out the collaboration points in PMI’s Business Analysis for Practitioners: A Practice Guide (free for PMI members to download!).
  • Cheryl created a wonderful BA Community in her Ontario PMI Chapter.  You can do the same in your chapter and invite people inside and outside the chapter.
  • Set up an executive forum where executives can learn from a speaker to gain more top-down recognition and sponsorship for business analysis.One of the agile user groups to which I belong has a yearly executive half-day meeting where executives present to executives. One attendee recently reported that his exec immediately latched on to what the presenter provided and went on to convey the message to all of his reports.That’s powerful stuff!

Your thoughts? What topics would you suggest to advocate for business analysis to the as-yet-unconvinced? Looking forward to learning from all of you ::-).

Posted by Sue Burk on: April 22, 2016 06:27 AM | Permalink | Comments (21)
ADVERTISEMENTS

"America had often been discovered before Columbus, but it had always been hushed up."

- Oscar Wilde

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events