Skip to main content


5 Myths About PMI’s Business Analysis Certification

In this article I aim to debunk some of the misinformation I often hear surrounding PMI’s Professional in Business Analysis (PMI-PBA) certification in hopes of providing better clarity to support improved decision making.

Background: The PMI-PBA certification hit the market in late 2014. It’s not quite three years since its launch, but it is doing well; having now attained credential holders in 82 countries. The idea that PMI was developing products in the business analysis space was shocking to some, but PMI has been recognizing the importance that requirements play in achieving program and project objectives for years. For those who are familiar with “A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition” (PMI, 2017), it’s no surprise to hear that successful projects require the effective use of business analysis. It makes complete sense why PMI would be investing heavily to raise awareness about the relationship between mature business analysis practices and organizational performance. In “Business Analysis Leading Organizations to Better Outcomes” (2017), PMI reported that organizations with high business analysis maturity, demonstrate above average performance across all key organizational success metrics—including:

  • Financial performance (69% versus 45%),
  • Strategy implementation (66% versus 21%),
  • Organizational agility (40% versus 14%), and
  • Management of individual projects (62% versus 29%).

So there should be no question on why PMI cares about business analysis and has set out to develop a top-notch professional credential to help organizations improve their capabilities to deliver on their strategic objectives.

Despite approaching its 3-year anniversary, there is still confusion about what the PMI-PBA is all about. As with many new products, there are early adopters and there are those that take a wait and see approach; certification is no different. For those who adopt later – there may be weeks or months spent researching, discussing, or listening to others share their experience and knowledge. This is the time where there should be sufficient and accurate information to base discussions and decisions on; and there is – on! Unfortunately, (as I have found firsthand) there are some postings, presentations, and conversations on social media that are perpetuating a misunderstanding about the scope, structure, and value of the PMI-PBA. I don’t believe it is being done on purpose or maliciously—I think it is a byproduct of the community misunderstanding PMI’s objectives and the product characteristics. I hopefully clarified PMIs objectives above—so let’s set the record straight on the PMI-PBA product.

5 PMI-PBA Myths

I have assembled a short-list of the top five misguided statements I have heard about the PMI-PBA. Hopefully this article provides you better information and helps to dispel the misinformation. If you are considering a PMI-PBA, hopefully this information helps you further your discussions with your manager and professional contacts. At the end of the day, the decision to pursue a PMI-PBA or not, is owned by those who must make the investment. Be wary of taking the advice of consultants and peer business analysts who convince you that a certification is right or wrong for you. Everyone needs to perform their own analysis, because each person’s situation is different. This article isn’t about convincing you one way or the other, it’s simply intended to provide you factual information to assist you in your decision making process.

Here we go…the top five myths about the PMI-PBA:


Myth #1: The PMI-PBA is an entry level credential.

This is absolutely false! You can debunk this misinformation by taking a look at the eligibility requirements in the PMI-PBA Handbook downloadable from PMI’s website. To be eligible to take the exam, you must demonstrate either 7,500 or 4,500 hours of business analysis work experience and 2000 hours of business analysis experience working on projects. The 7,500 or 4,500-hour requirement is determined based upon your educational background. Further details are listed in the PMI-PBA Handbook. These hours were not randomly selected. An extensive role delineation study was performed by an external third party and the results indicated that these were the hours required in order to demonstrate competency in business analysis. The PBA exam is also structured to include scenario-based questions which rely heavily on experience not book knowledge to answer. From my personal experience taking the exam, I can attest to the fact that the PMI-PBA is clearly developed for experienced professionals.

Myth #2: The certification confines business analysis to projects and programs.

Completely false! PMI research has shown that 83% of business analysis is performed on programs and projects in highly mature organizations, but this does not mean that PMI defined business analysis only to this context. You can debunk this misinformation by taking a look at PMI’s definition of the term portfolio which states it consists of “projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.” “The Standard for Portfolio Management Fourth Edition” (PMI, 2017) is more than managing projects; hence PMI’s business analysis standards do the same because business analysis is discussed in the context of how it is performed in support of portfolio, program, project management and operations. The “Business Analysis for Practitioners: A Practice Guide” (PMI, 2015) provides an entire chapter, Needs Assessment, that discusses pre-project business analysis activities. Later this year you can take hold of “The PMI Guide to Business Analysis” (PMI, 2017) which goes further than the practice guide in explaining how business analysis supports portfolio, programs, projects and operations. Keep in mind that how business analysis is defined is based on extensive research, not any one person’s idea of how it should be defined. 

Myth #3: The PMI-PBA was developed by a group of project managers.

No, sorry this is false too! I can see where some people might think this is the case, but PMI definitely used a team of experienced business analysis professionals from around the world and across industries to develop the PBA exam questions. PMI continues to do so too, because the test bank is refreshed on an ongoing basis. New exam writing initiatives ensure that the PMI-PBA exam questions remain relevant and reflect the latest thinking as presented in PMI’s standards and confirmed across the profession. Those assisting in writing new exam questions are just as experienced as the original development team. I think I should also mention that all PMI-PBA exam questions once written, are also reviewed by experienced business analysis professionals. Additionally, each exam question is required to be backed by at least two independent business analysis references. I don’t want to forget to mention that exam writing teams also have access to extensive PMI research. This credential is absolutely developed by business analysis professionals for business analysis professionals.

Myth #4: The certification is for project managers or PM/BA hybrids.

I can’t say this statement is completely false, because there are some PM/BA hybrids or project managers who qualify to sit for the PMI-PBA exam BUT not all project managers and not all PM/BA hybrids are eligible. In fact, not all business analysts are eligible! In my response to myth #1, I indicated the work experience requirements. It is these requirements that dictate eligibility, not your job title. Product owners, business analysts, project, program, portfolio managers, requirement managers, IT analysts and numerous other titles may be included because it’s not the job title that matters. What does matter is the number hours of ‘business analysis’ experience you possess. You demonstrate your experience on the PMI-PBA application. Therefore, if you are doing any of the work discussed in PMI’s business analysis standards, you are performing business analysis and may qualify to sit for the exam. It’s worth checking out the eligibility requirements to see if you qualify – regardless of your job title!

Myth #5: PMI has defined business analysis as a subservient role to project management.

Oh gosh no! I think it’s time we debunk this PM/BA subservient concept, it’s been around a long time and it’s not how we operate at all if we want to be successful. PMI research shows that highly mature organizations encourage high levels of collaboration between their portfolio, program, project management, and business analysis professionals (“Business Analysis: Leading Organizations to Better Outcomes” [PMI, 2017]). We are all part of the same team and we will jeopardize our success if we fail to collaborate. PMI has not defined business analysis as a subservient role. In fact, the “PMI Guide to Business Analysis” and “The Standard for Business Analysis” publishing this year will sit among some of PMI’s most prestigious standards” – the “PMBOK® Guide,” “The Standard for Portfolio Management” and “The Standard for Program Management.” Business analysis is no less important, but equally important for organizations and individuals to understand and embrace.

I hope my responses to the top 5 myths about the PMI-PBA helps to dispel some rumors, reduce confusion, and allows for improved decision making when it comes to researching a professional certification in business analysis. Remember, PMI may be the Project Management Institute, but this doesn’t mean PMI only serves project managers. It’s not practical to think this way. Those who have experience working on ‘successful’ change initiatives within their organizations can attest to the fact that it’s a collaborative effort. We can’t succeed by separating our business analysis professionals from our project management professionals! This is one of the reasons I am encouraged by the contributions PMI is making to the business analysis profession and even more encouraged to see that recently ranked the PMI-PBA as the highest paying business analysis certification on their list.

Certify or Not to Certify – That is the Question

I do not have a certification. I do not have a string of capitalized initials after my name.

I do not need to have the affirmation that I am knowledgeable, skilled, or experienced by having extra ink printed on my business cards.

However, perhaps you do have a certification; a string of initials after your name, and a deserved sense of pride that goes along with that accomplishment. After all, to be able even to submit a CBAP application you must have 7500 hours of BA experience that is verifiable. Yes, I can see how that certification can entice many toward that elusive “pot of gold” career game-changer.

A certification can be worth the pursuit as much as it cannot be. The variables to determine a value-added proposition to your career are many; are parabolic, and are personal. Many times, a certification is pursued under the guise of the qualification for employment. I will tell you this: if an employer states a CBAP as a requisite qualification for a job, then perhaps that company does not understand what they even want and why! I say this because it is all about the numbers:

  • There are approximately 6700 CBAPs worldwide.
  • There are approximately 2500 CBAPs in the United States.
  • There are approximately 120 CBAPs in Minnesota; 70 in the Minneapolis/Saint Paul metropolitan area (where I live).

There are no hardcore statistics, but there are estimated 1.5 million analysts in the US. There are an estimated 5,000 BAs in Minnesota. 120 CBAP certifications are 2.4 percent of the BA population. If an employer requires CBAP certification to be considered for a job, then their population sample to choose from will be very slim. The good news is if you have a CBAP, then you are a shoe-in for the job!

Does it matter to your career if you are certified? In the above example, it certainly could. But what about a break out of the ‘value-added variables’ I eluded to above:

  • How long have you been in this career path?
  • Do you have formal training?
  • Have you been mentored?
  • Is your experience industry specific?
  • Are you a member or an officer of a professional organization?
  • Have you been published, a speaker at an industry event, or provided training in your field?

I feel the above list of variables could certainly trump a certification. I say this based on the premise of the resume; what is the first section of a resume (excluding a summary)? It is work history/experience. The second section is education. The last section, typically, is professional certifications, awards, accomplishments. Personally, I have over 25 years’ experience in various industries. The pursuit of a certification would not be prudent since it will render me no value. I am at the top of my field in title, experience, and compensation. Should I choose to focus on a different industry, then perhaps a certification can add value, especially if that industry is in high demand of filling job vacancies, like in the field of security. If an individual with 5 years’ experience and that many years out of college ask me about certification, the conversation will be very different and very PRO-certification as well.

I have focused mostly on a CBAP so far. There are other certifications that can enhance one’s career if a BA is looking to diversify. Many BAs also pursue a Project Management Professional (PMP). Some look to Agile and pursue Certified Scrum Master (CSM). There are security certifications, business process certifications, change management certifications, IT specific type analyst certifications, and on and on and on.

To determine if a certification will help you or is worth the investment in time and money, you must perform a career assessment and lay out your future goals. Do you want to follow a career path of the technician or the manager? Is your current job title a stepping stone for a bigger goal or is this job title going to be prefixed with “Senior” or “Lead”?

One thing that may be a bit tricky is to acquire a certification as a means of entry into an industry. If I am a Senior Business Analyst and pursue a certification in security, a Certified Information Systems Security Professional (CISSP), will I be guaranteed a job in the security field? Considering that I have been in the healthcare industry my whole career, perhaps not. However, as stated above, this is a high-demand industry, so perhaps that will be the golden ticket for securing a job. These are all things to consider.

Some industries do require a certification as a requirement for entry; law, medicine, financial planner, for example. Until there is regulation, a certification will not be a mandatory requirement for entry into whatever that industry job world could be from project management, business analysis, or scrum. Regulation of business analysis will probably never happen, which means that the ones who are certified, may stand out as unique, and perceived as experienced, but certainly do not corner the market unless the certification process is abused, that is. I have seen the following in a LinkedIn profile (the name is changed to protect the guilty):


If you were an employer, would you be impressed or not?

As an employer, I feel if you are going to spend all your time certifying, how can I trust you actually know anything on an expert level of any of those fields? Some people may be impressed with quantity; I say err on the side of quality. I would say pick one, two, perhaps three certifications and just do those well. It just looks like some people are really good at taking tests.

In every job, technology focused or not; there is a distinct path of the flow of information. When you start a job at a company, understand what the information being used is. Where is the information generated; the source? How does it pass to the users? How is it stored and where? How is it loaded into the storage?

Is it manipulated/transformed in any way? How do the users of the information use it to perform their jobs?

From my experience, a certification for a job in a company is not necessary because in some cases knowledge and experience trump a certification. Conversely, a certification at that point in your career where you have significant experience can be what it takes for you to propel to the next level in your career. A certification is not the silver-bullet remedy to acquiring the job you want.

Certification is a badge of honor to wear proudly. Regardless of the reason or motivation to certify, the bottom line is simple. Perform your job well, and you honor your certification initials at the end of your name. Perform your job poorly, and you tarnish your certification and your peer’s certifications. Once you certify, you are an ambassador for certified professionals.

To choose certification or not to choose certification – that is the question.

Top 5 Reasons Organizations Should Support Certifications

There will always be a debate about certifications and whether organizations should support them. Some feel they are an essential and growing part of professional life. Others feel a credential does not make practitioners a better business analyst, Agilist, or project manager. Both sides have a point, and the debate will continue.

What is undeniable, though, is what we see as the organizational benefits for supporting certifications and credentials. Support can include (in no certain order): providing time to study for a certification exam, paying for certification classes, hosting study groups and forums, and incorporating credentials into hiring and promotion practices. We’re sure there are even more.

Related Article: Business Analysis on its Path to Maturity

Here are the top five reasons organizations should support certifications and the benefits to those that do:

1. Facilitates a common language and set of techniques.

An industry standard and credentialing process, like the PMP or CBAP, unites practitioners across organizations and countries. Take the PMP, for example. Prior to the PMBOK and its framework, most organizations managed projects according to their own methods or those from a proprietary vendor. The large push to get project managers certified with the PMP helped organizations use a common language for common processes and techniques that had previously different terminology. This leads to increased mutual understanding which, in turn, increases quality and reduces re-work. Recruiting is also improved, and managers can hire with more confidence when candidates use common concepts and terminology.

2. Provides an avenue for employees to show dedication to a profession.

More than one CIO has told us they value certifications for the dedication that employees show when pursuing and achieving one. We couldn’t agree more. Some people will take initiative on their own and be self-motivated to achieve one independently. They are valuable staff members (and in the minority). Most people need some encouragement and a path for getting a credential. However, we don’t advise the routine use of credentialing as a way to weed out employees who don’t achieve one, but that is a subject for another blog.

3. People learn a lot when studying for credentials.

Successful, credentialed participants are almost always more effective at work. The reason is the amount of learning that has to take place in order to pass an exam. Even those of us who have been on the job and who have had training related to our industry (business analysis, project management, Agile), come to realize what we don’t know. Using my experience as an example, I (Rich) thought I understood project management until I studied for my PMP. Hah! What a mistake! Doing my prep work of reading, attending a class, and doing practice exam questions woke me up to the reality of what I did not know. Many hours of study later, spread over several months, got me ready to pass the exam. My studying also gave me increased PM knowledge which I still use to this day when managing projects and programs.

It is well to add here that some certifications usually result in more learning than others. “Broad industry standard” type exams like the PMP, CBAP, and PMI-ACP require rigorous study because of their scope. Almost invariably those studying for these exams encounter many “aha” moments, paradigm shifts, and new understanding as they study and find gaps in their knowledge. Our research shows it takes 100 hours on average of study time to prepare for the CBAP, for instance.
Another type of credential requires less study. These exams are narrowly focused and usually relate to proprietary methodologies, like the CSM, IREB, PRINCE2, BRMP, and ITIL. These types of certifications rely on a training class focused on key concepts after which candidates take an exam, often at the end of class.

4. Demonstrates commitment to employees.

Leaders in most organizations would say they are committed to employees. Saying it is one thing, but demonstrating it is another. Pay is one way, but people would not work for you without it. Promotions? Same thing, but to a lesser extent. Choice projects? Not everyone can work on them.

Providing the professionals in our organizations with a path to a relevant credential is a practical and meaningful commitment. It is a demonstrable form that employees will appreciate and will contribute to their long-term loyalty. We know this from first-hand experience.

“If you look after your staff, they’ll look after your customers. It’s that simple.”
Sir Richard Branson

5. Better employee retention.

This last point may seem counter-intuitive if you fear that helping people gain a credential only helps them land a new job. Anecdotal evidence exists that if you don’t train people, and don’t support them in advancing their knowledge and skills, they will likely leave sooner1. The quote from Henry Ford sums up this point.

larson april ba

What do you think? Are there other reasons that organizations should support (or not support) certification? Please weigh in with your comments.

1. See Training Magazine, April 2013.

5 Easy Ways to Make the BABOK® an Irresistible Read

“Are you kidding me, Yamo?”  If that was one of the first thoughts that came to your mind when you saw this post, I wouldn’t be surprised.

A few business analysts think that the BABOK® is a dry read. It may be for various reasons, and we will explore a few of them and what to do about it by diving into five ways to make the BOK talk to you. The latest edition of the BABOK® is version 3 and adds new elements to how you could leverage it as a practitioner.

After all, BABOK® is about showcasing a disciplined approach and framework to help businesses change effectively. And anything that entails discipline is not necessarily a gripping Star Wars trilogy that will get you hooked from the first word to the last.

So, why do you think BABOK® comes about as a dry read?

There are a few aspects of BABOK® that make the readers miss a few essential elements. For example, not being able to relate to a few tasks, detailed explanations of a few tasks that you “think” that you never did, or just the overwhelming feeling that you have to remember too much.

Reading and getting hooked to the BOK is an acquired taste. If you have ever had the experience of trying sushi for the first time (you know the very thought of eating raw or semi-cooked fish can be a big turnoff) and transitioning from anxiety to eagerly looking forward to eating it – you will know exactly what I mean.

In this post, I would like to share five ways in which you can make the BABOK® really interesting to read as a practitioner.

1. Understand how the Knowledge Areas, Underlying Competencies and Perspectives Are interrelated

One of the most useful ways to understand the different knowledge areas is the WHW practitioners’ narrative. Whenever I am teaching a prep course or speaking to practitioners on how to apply the BABOK®, I make sure to illustrate this. This essentially translates to understanding how each of the knowledge areas aligns with what we do as business analysis
Practitioners, in conjunction with underlying competencies and perspectives. According to BABOK V3.0, a Knowledge Area can be defined as:

… areas of specific business analysis expertise that encompass several tasks

and it’s also important to emphasize that:

Knowledge areas are not intended to represent phases in a project.

So, what is the “WHW Narrative“?

When you look at the diagram below from the BABOK®, you realize that there is an interrelationship between the different knowledge areas:


(Source: BABOK® V3 – used with permission from IIBA®)

The WHW Narrative looks at the relationship between knowledge areas, underlying competencies, and perspectives. It does this by asking the following three questions and grouping the Knowledge Areas (KAs) under them:

W – What Does a BA Do? – These are the innermost KAs. The tasks that are part of these knowledge areas are “What” we do as business analysis practitioners (at the core of it).

H – How Does a BA Work? – These are the KAs surrounding the inner KAs. The tasks that are part of these knowledge areas are “How” we go about doing business analysis.

W – Who is An Effective BA? – The ‘Who’ encompasses the Underlying Competencies, BA core concept model and perspectives. Treat this as skills, knowledge, and personal traits of an effective practitioner as well as the ability to understand how to apply business analysis tasks in different contexts and project types. So, this defines “Who” is an effective BA.

So, if we were visualize this, our diagram above would look like as shown below:


In Conclusion: Use this narrative to relate back a task to your practice. As you go through the different tasks in these knowledge areas, use the WHW practitioner’s narrative to help you see the trees and also the forest.

[Hat tip to one of my friends, Jonathan Nituch to introduce a part of this to me]

2. Open the Doors of Curiosity – The Secret to do it

When you read the BABOK®, how can you create curiosity?

George Loewenstein, a professor at Carnegie Melon University, came up with what’s called “the information gap theory of curiosity” and it’s, hands-down, one of the best ways to create curiosity on demand.

Quite simply, curiosity, as defined by Loewenstein, is an innate human behavior that’s triggered when people feel there is a gap between what they know and what they want to know. (Source – The Itch of Curiosity).

Loewenstein then goes on to explain how this gap influences people to take action (such as reading more, using information in BABOK®, or performing better business analysis).

But the question remains: How can you do it?

Here is how: When you are reading the BABOK®, try and do the following two things to help propel your curiosity:

  1. The form and shape in which you do this task currently – introspective or retrospective curiosity.
  2. How can you do this task better – prospective curiosity.

3. Use a Real-World Case Study (Past or Current)

Some of us learn better by using examples and by using something that we can relate to. If you have used wireframes or screenshots as part of your requirements package or even provided a written example of a formula for a mortgage loan or amortization calculator, you will know what I mean. Examples standout and help with greater understanding and make the study material more relatable.

Sometimes your brain responds better to something that is more tangible. For example, if I use the following formula to tell you that force increases as mass and acceleration increases – it may not make immediate sense.

F = m*a

[Force = (mass) times (acceleration) ]

However, if I tell you that a 100 kg ball falling from a height of 10 meters will create more damage than a 10 kg ball falling from a height of 1 meter (or same height) – you will be able to visualize the impact.

So, when you read the BABOK®and when you are going through the different tasks, create your own “fictitious” case study to relate the tasks to. You could also pick your current project (or one from the past), to relate the tasks to.

4. Turn Headlines to Questions

The tasks and techniques in the BABOK® have a standard repeating structure. It is useful to convert these repeating elements into a set of questions that can help you better understand the material. Questions, by their very nature, help develop your comprehension.

For example:

Techniques – could be “How to conduct stakeholder analysis?”

Stakeholders – could be “Who all could be potentially involved in this task?”

Elements (Slightly different) – could be “What are the key considerations to keep in mind?” and a self-directed question for every element:

Type of project or initiative – could be “What kind of project am I working on?”

Communication formality – could be “How formal should my communication be?”

5. Plan to take CCBA or CBAP Exam

After you’ve gone through and rationalized the “Why Should I do CCBA or CBAP?” question, you should consider prepping for the exam. One way to make the BABOK® “irresistible” is to use the “fear of failure”.

So, when you have set your eyes on taking up the exam, you will be forced to study the BOK, and you will hopefully apply the first four ways of this post to make it an interesting read.

Which of these five would be your favorite way to make the BOK irresistible? Do you have any tips of your own to share?

Please use the comment space below to provide your comments, questions and feedback.

Why the Scrum Product Owner IS a Project Manager, part-2

In the first part of this post we began to explore the Project Management quadrant of my 4-Quadrants of Product Ownership model. When I introduced the 4-Quadrants in this post or blog post, I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:

1. Product Management
2. Project Management
3. Leadership
4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Manager area. I think because many had a view to traditional project managers they’d worked with in the past, and they were having trouble mapping these skills into the role of Product Owner.

Next I’ll continue the deep- dive exploration of aspects of that quadrant, with three more areas:

5) End-to-End Project Release Planning

One of the central activities of SAFe is conducting a 2-day PSI (Potentially Shippable Increment or Release Train) planning session as a team. The event is focused on mapping work (Epics & Themes) or the “ask” from a business perspective to each teams’ ability to commit to User Stories that meet the ask.

The planning takes an end-to-end view, so from:

  • Requirements and visualization
  • Architecture – system, UX, DevOps
  • Through construction
  • Testing (functional, non-functional, automation development)
  • Covering operational readiness (DevOps deployment, documentation, training, customer readiness, etc.)
  • Deployment to Production

In other words, it takes a “Concept-to-Cash” view to ALL of the work required to deliver on the goals, themes, and features for the release. And keep in mind that the PSI is planned in a series of sprint-level increments, so it is an iterative plan.

In SAFe, there is a role entitled Release Train Engineer or RTE. They are largely responsible for facilitating and orchestrating an effective PSI-planning event.

Even if you’re not implementing the SAFe framework, many Agile organizations and teams leverage some sort of release-level planning activity—particularly in at-scale Agile. It just makes sense to have a view to a larger picture before letting loose multiple Agile teams towards an unplanned goal.

I would argue that the individual Product Owners and the Chief Product Owner are incredibly important to effective release planning. Not only to “set the stage” with the “ask”, but to be there during the planning to answer questions and to help the teams make appropriate scope tradeoffs as they try and deliver on your goals.

I would even say that Product Owners should become “students of” release planning techniques, approaches, and models. Even with an RTE or similar role, you’ll want to partner with them to ensure you and your teams have a solid plan. Here’s a link to a PDF article that explore various forms of release planning in much more detail.

6) Stakeholder Management

I remember distinctly in traditional projects where our C-level team would “call in” the project managers for portfolio level tracking. Often they would never see or interact with the individual teams. Instead, the project managers were the sole lenses for each project.

This placed a tremendous burden on the project managers to effectively “manage” stakeholder information sharing, expectations, and their reactions. Some were good at it and others were not. Some had more trust with stakeholders, which mattered a great deal too.

Often you could draw a direct correlation between projects that were going well versus not, by the maturity and skill of their project managers stakeholder management.

As we move to Agile contexts, this sort of stakeholder management is still largely relevant, but now it falls to Product Ownership to handle expectations management. Often it focuses on reinforcing the importance of your Stakeholders and Senior Leadership to “fully engage” with your/their Agile practices.

For example, getting them to regularly attend sprint demo’s, release planning, Scrum of Scrums meetings, and even circulating around daily Scrums will give them a strong sense for progress, challenges, and where they might help.

But you’ll still need to provide a “buffer” between your teams and your stakeholders, so that they effectively understand and react well to the transparency and the adjustments being made.

Note: this crosses into the Leadership Quadrant of the 4-Quadrants to some degree. This is one of those nuanced areas that really make a difference in your overall success. I often challenge the Chief Product Owner (or other Product leaders) to think about who and how they’ll be thoughtfully and actively managing their stakeholders.

7) Project Retrospective

Clearly you’re involved in each sprint retrospective that your teams conduct. And I want to encourage you to fully engage in each one of them. But that being said, I also think you need to take your feedback acquisition “up a level”.

Your Sprint Reviews are a wonderful ceremony to gather feedback from your Stakeholders and Leaders. Please don’t miss that opportunity to gather their feedback as you deliver each increment. And don’t always assume that you’re getting it either. I’ll share a story to make that point.

I was talkin Software Devg to the EVP ofelopment at a conference not that long ago. He was describing the interaction in a recent Sprint Review or Demo. He said:

Bob, I threw a 5 to represent my reaction to the demo, but I wanted to throw a 2. In truth, the demo was terrible and I believe the team failed to meet customer needs in their development efforts. I just felt very uncomfortable giving that sort of negative feedback in front of a large audience. I pulled aside the Director of that team later, and I gave her my feedback.

I actually challenged him to speak the truth” in future reviews. I tried to make the point that it was important to be transparent with feedback as well. Sure, craft it carefully, but if a demo sucked and you said it was great, that is setting a very bad precedent. He responded:

You’re right Bob, but we are located in the South and have a culture of thoughtfulness and care when giving bad news. It will take me (and us) time to get over this cultural barrier. But I can’t imagine “telling truth” for quite some time.

Clearly you need to work incredibly hard to get all forms and types of feedback out from your stakeholders. Be aware of your cultural norms and figure out creative ways to get the truth on the table so you and your teams can address any deficiencies or misses.

SAFe has a release-level retrospective at the end of each PSI. It’s a cross-team, ALL stakeholder meeting where issues are discussed and improvement action-plans are formed. So there are multiple “layers” to the feedback and reflection opportunities.

I’ve written several other posts that explore the power of Sprint Reviews beyond simply showing software:

I wanted to remind you of one of the reasons I developed the 4-Quadrants in the first place. It’s because of how hard the Product Owner role is to perform well. It’s an incredibly deep and broad role that requires tremendous effort and skill. It also requires quite a bit of time.

I often joke, and it’s not really a joke, that I’ve only met 4-5 Product Owners who could perform all aspects of the 4-Quadrants by themselves. Ever! What this implies is that it’s OK to ask for help. In fact, you’ll most probably need to get help in your role.

If you have Project Management strengths and skills, then take some of this on yourself. If you don’t, then look for someone else in the organization with these skills and strengths to help you out. For example, in SAFe environments, you might want to make the RTE a partner or best friend.

But the KEY is to find or ask for help if you need it in the quadrants where you are weakest.

Wrapping Up

I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. But whether you like the 4-Quadrants model or not, this work is there for you regardless. The key is to be aware of it, get someone covering it, and to do it very well.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve shown you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,