Building the Foundation: The BOK on BA

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” ::-).

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 ProjectManagement.com, 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 ;)

I thought it would be fun this week to share further insight with the community around PMI’s business analysis standard. Many people have asked me how the project is progressing, what the end product will look like, and when the community might be able to be part of bringing this work to life. I thought it was a great time to provide you an update in these areas.

A Bit of History

In November of 2015, PMI announced plans to move forward with building a business analysis standard.  The decision to do so was based on the success of Business Analysis for Practitioners: A Practice Guide and the tremendous amount of positive feedback PMI received about the guide. In late January 2016, PMI conducted a kickoff to begin the development work.  Today a mere six months later, there is much to share with the community!

Value Proposition

As I discussed in my May post, this new standard has a lot of strong value propositions, including…

• Providing a common business analysis vocabulary for all portfolio, program, and project teams,
• Focusing broadly on defining business analysis for all roles who share responsibility for performing business analysis activities,  and
• Defining and explaining business analysis so it is understood by and relevant to all teams, regardless of the lifecycle chosen to develop and deliver the end product.   

Sue Burk discusses the “commonality of business analysis thinking” in her June post and explains why this broad viewpoint is so important today when speaking about business analysis.  

A Status and a Look Forward

I am pleased to share that we are ahead of schedule!  Tasked with setting vision and scope and developing the initial draft content, we are wrapping up the first round of writing. We are reviewing the draft internally and plan to share with an initial team of subject matter experts (SMEs) in late September. If you are interested in taking part in this initial review process and meet the stated eligibility requirements, consider applying for a role on the SME Review Team.  The application window opens today 7/14/2016 via PMI’s Volunteer Relationship Management System (VRMS).  The requirements to participate in the SME review process are posted there.

Once subject matter experts share their insights and guidance, we will begin incorporating suggested modifications to the content. This work will continue throughout quarter four of 2016.

Starting the year off with much momentum, the project progresses to the public exposure phase in Q1 2017. During the public exposure draft process, the public will obtain full access to the content revised and enhanced by the guidance provided by the SME review team.  The public exposure draft process is your opportunity to shape the development of this standard to ensure business analysis work is defined:

• commonly,
• globally,   
• broadly, and
• for any life cycle selected.

More information about the public exposure phase will be forthcoming as the project progresses.

What to Expect in 2017

You can expect that the business analysis standard will be of high quality and will be a highly valued product in the industry.  PMI will continue to bring much needed attention to this important work.  The thousands of talented professionals, who work in the business analysis field, will shape this standard into a pragmatic and usable description of business analysis that future product teams can leverage and learn from for many years.  

It is an exciting time for the core development team as we look forward to giving you the opportunity to further build upon what we started. Are you looking forward to having a glimpse of PMI’s business analysis standard? If so, please tell us what areas of business analysis you are most interested in checking out?

I’ve been anxiously awaiting the time to write this post because it is about something near and dear to my heart – analysis models! Models are by no means new to the business analysis profession, but I’m thrilled to say that the use of them has become much more prevalent – almost mainstream – over the last five to ten years. Given that, you would naturally expect the PMI foundational standard in business analysis to have a home for them, much like they are in section 4 on Requirements Elicitation and Analysis of Business Analysis for Practitioners: A Practice Guide.

As described in the practice guide, models are visual representations that efficiently arrange and convey information in a concise manner. Models can be in the form of diagrams, tables, or structured text. Models are used in planning, analysis, design, construction, training, coaching, and many more roles. There are many types of analysis models and the following table shows the ones we found to be most prevalent, and are therefore covered in the practice guide. The models are grouped by categories in this table to help you think about the kinds of models that exist more precisely than just listing them. Most projects, programs and portfolios will need to use at least one model from each of these categories. In fact, the table of models is sort of a model in itself because it organizes information for better understanding!

Table source: PMI, Business Analysis for Practitioners: A Practice Guide

The when, why, and who of it

As analysts, models help us create order out of information so that we can find inconsistencies, gaps, and extraneous information. Analysis models also help us to represent information so that others can consume it. Our business stakeholders, construction teams, testing teams, executive teams, and managers all use models to understand what the product needs to do and why.

But wait, what about agile?

Sue’s recent post highlighted how business analysis is applicable in both predictive (such as waterfall) and adaptive (such as agile) life cycles. As she points out, models are useful in both life cycles! The choice of models, formality of their representations, or timing of their use might vary from adaptive life cycles to predictive life cycles. But frankly, those same things vary from any waterfall project to any other waterfall project also. There is no “one size fits all” approach to modeling. In agile approaches some scope and goal setting models are more likely to be created early in the project to get a lay of the land. However, more detailed models to identify acceptance criteria are used just in time to plan iterations as part of elaborating backlog items.

All industries

If you work outside the software or IT arenas, you might be wondering whether analysis models are even applicable. The short answer is absolutely! However, some models are better than others. For example, some form of process flows or use cases can be used to describe how users will use or interact with anything – be it a shopping center layout, an insurance claims process, a city intersection, a turn signal on a car, or a rocket ship. On the other hand, some models such as display-action-response models are only useful if there is some kind of a user interface to be specified.

I once met some engineers from a company that builds heavy machinery. They didn’t work on software, but rather they were in the product design department for the physical machines. Once introduced to analysis models, they quickly adopted business objectives models, process flows, and feature diagrams to improve their requirements and design work.

What to expect

PMI’s foundational standard in business analysis will explain analysis models in general, describe why we create them and how we analyze them, and offer a visual template for many types of models. Business Analysis for Practitioners: A Practice Guide offers more depth on when you use each of the models, how you use each of them in relation to requirements, and an example of each model. The two publications in combination will provide a wealth of knowledge for those just getting started in the modeling space or a quick lookup reference for the more experienced professional.

Like I said earlier in the post, there are so many different types of analysis models. I’d love to hear what the community thinks about models. What are your favorite models? Are we missing any key ones that you’d like us to consider for inclusion in the standard? Do you really like or not like any of the ones I listed here?

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!!