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

Sorting Out Overlapping vs. Complementary or Supporting Processes

How Business Analysis Compares with Project, Program and Portfolio Management

An Update on PMI's Standard in Business Analysis

How the Business Analysis Standard Could Have Helped an Agile Transition

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

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 (0)

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

Definition

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.

Focus

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.

Scope

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.

Roles

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.

Success

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 (10)

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.

Publication

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 (17)

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)
ADVERTISEMENTS

"There are three kinds of lies: lies, damned lies and statistics."

- Mark Twain

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events