Adapting Business Analysis Processes for Adaptive vs Predictive Life Cycles
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:
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.
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 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).
Hope you enjoyed that sneak peek. Stay tuned for more information on the public review process. We look forward to seeing your comments!
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.
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.
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.
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.
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.