Viewing Posts by Sue Burk
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’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.
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:
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.
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 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!!
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 ::-)).
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 ::-).