Adapting Business Analysis Processes for Adaptive vs Predictive Life Cycles

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

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


Categories: Business Analysis


As you’ve likely heard, the SME review is complete for PMI’s business analysis standard and we will soon be in the public review stage. With that we want to share a little more of what you’ll find under the covers. We have included a variety of helpful things in our attempt to come up with a product that is friendly to the adaptive, predictive, and the “anywhere in between” members of the community. One of the critical constructs we created to address this very topic is what we on the team colloquially call “the tailoring tables”.

Let me back up a moment and explain that for each of the processes, we certainly try to explain in text how the process might vary depending on whether you use an adaptive or predictive life cycle on the project, program, or portfolio. However, we wanted to also offer a tool for readers to quickly summarize the essence of how each process might vary, so it’s not buried in text – that tool is the set of tailoring tables. Within the guide, these tables describe three common aspects of how business analysis could be tailored based on your selected project life cycle:

  • Process Name – what the process is called can vary
  • Approach – how or timing of when you perform the process might vary
  • Deliverables – the things you produce when performing the process might vary

Every process includes a table describing how the process is commonly tailored with regards to the topics above for adaptive versus predictive life cycles.

One key phrase in that previous sentence is “commonly,” which means this content is not a rule or policy, but rather a guideline. For example, if we said that in adaptive life cycles, requirements are typically represented in user story format, and your organization has reason to write them in use cases instead, then by all means you should produce use cases. Similarly, there is nothing in this guide indicating that user stories cannot also be used in predictive life cycles, even though we don’t explicitly say they can. I mention this because this is probably the most prevalent feedback we got about these tables. Some of the SME reviewers felt like the predictive tailoring suggestions might be helpful in an adaptive project or vice versa. We agree! We just had to also offer something more useful than saying “you can do anything in any life cycle” so we reflected on common practice and used the reviewer feedback to help tweak what we missed.

Here is an example of what this table might look like for the Define and Elaborate Requirements process.

©2017, Project Management Institute, Inc.

That is “tailoring tables” in a nutshell. Whether you love or hate them, we welcome your feedback. You can formally (or informally!!) share your thoughts in the public review process of course, too.

Posted by Joy Beatty on: February 23, 2017 04:37 PM | Permalink

Comments (9)

Please login or join to subscribe to this item
Perhaps I did not understand the point about "an example" but I firmly believe that the worst thing we can do when we are creating a BOK is to tied it to some method. In the example you are talking about user stories. But user stories are not the tool for each agile software development method. Some methods use Use Cases. I firmly believe that we need to be "method independent" when we are working in something generalistic like a BOK.

We do not need to adapt the business analysis process to adaptative or predictive life cycles. That will depend on the method you use. A method will be created based on a life cycle process that is based on a life cycle model (life cycle models are two: adapatative or predictive). So, we need to be "method independent" when we are createing a BOK. We need to be clear that (in my humble opinion) a BOK must not describe the dynamic component of the discinpline.

Sergio, I think we might just disagree here. Generally a BOK does talk about concepts, but to ignore various life cycles would leave the language so vague it would be useless or, at minimum, ignored by the agile communities. If all I did was write about something called "requirements" and didn't address the fact that different life cycles might use different names for that informaiton is going to be offputting to the agile folks who don't use that word.

That said I agree we wouldn't perscribe a "must do" for naming, how-to, methods, etc. Just suggestions of how you *might* adapt it in different life cycles.

Thank you very much for your answer. This helps me a lot to improve myserlf. What I tried to say is the way you named and tried requirements will depends on your method. As I menitioned you are taking abour User stories but Use cases are used by lot of other methodos. For example, DSDM. We must mainteined the BOK as generalist we can. That is my point.

I'm curious to see what you think after it comes out for public review! I feel like we did job of giving the variety of names that things are called for exactly that reason!

Sure. But I just curious ti see what the community said. I hope lot of,people wilñ participate on that. Thanks

Hi,
I'm still not happy with the distinction you made between adaptive and predictive, since in many of the tables in the BOK there are two aspects mixed. One is the lifecycle aspect (I like to call it the lifecycle approach) - this is about timing of the processes within the lifecycle of the initiative. The other one ist the formality aspect. That depends mostly on risk of initiative and regulations that apply to the initiative.
Many people tie liefecycle and formality aspects together - but that's not really the case. There is a tendency to use predictive approach with more formality and adaptive approach with less formality nowadays - because of the historics of adaptive approaches within the last 20 years. But if you look at the roots of adaptive approaches back to the sixties, it will be clear that there is no tight relationship between the two aspects.
I recommended to separate both aspects if you want to keep the tables - I agree that these tables are a good hint for many people working in business analysis. But I would like the tables to be more precise about the aspects - to help business analysts to select proper methods regarding applicable aspects.

Hi,
I'm still not happy with the distinction you made between adaptive and predictive, since in many of the tables in the BOK there are two aspects mixed. One is the lifecycle aspect (I like to call it the lifecycle approach) - this is about timing of the processes within the lifecycle of the initiative. The other one ist the formality aspect. That depends mostly on risk of initiative and regulations that apply to the initiative.
Many people tie liefecycle and formality aspects together - but that's not really the case. There is a tendency to use predictive approach with more formality and adaptive approach with less formality nowadays - because of the historics of adaptive approaches within the last 20 years. But if you look at the roots of adaptive approaches back to the sixties, it will be clear that there is no tight relationship between the two aspects.
I recommended to separate both aspects if you want to keep the tables - I agree that these tables are a good hint for many people working in business analysis. But I would like the tables to be more precise about the aspects - to help business analysts to select proper methods regarding applicable aspects.

I have to correct myself as I have now read the complete public exposure version. Very good stuff, indeed.
The reworked tables are now O.K. for me - only the first few still mixed the aspects.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"I never resist temptation, because I have found that things that are bad for me do not tempt me."

- George Bernard Shaw

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events