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