Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.

Is There a Personality Profile for the Project Manager and Business Analyst?

Written by Elizabeth Larson on . Posted in Articles. 4 Comments on Is There a Personality Profile for the Project Manager and Business Analyst?

PersonalityProfileDuring a presentation on the topic of the BA and PM roles recently, someone asked me a question about personality types. She asked if there were, generally speaking, certain personality traits for PMs vs. BAs. I asked the crowd what they thought. Here are some of the responses.

  • Big-picture and details. A BA said that she thought BAs have a broader perspective. They are more “big-picture,” and PMs are more detailed, she asserted. I asked the PMs in the audience what they thought and they said, as we might suspect, that PMs were more big-picture and that BAs were more detailed.
  • Intuitive/logical. Another BA suggested that BAs are more intuitive. Again, I asked the PMs what they thought and they thought PMs were.
  • Introvert/extrovert. Another suggested that BAs are more extroverted while PMs are more introverted. The PMs disagreed. For those not familiar with these terms, In general extroverts tend to be energized by people and introverts by thought and imagination. Extroverts tend to like to socialize and introverts tend to like their own private space. Extroverts tend to make quick decisions and introverts usually need more “think” time. Extroverts tend to speak and then think and introverts vice versa.
  • Thoughtful vs. action-oriented. Someone suggested that PMs are more action-oriented while BAs more thoughtful, for which there was more agreement than on any other point.

I believe that both BAs and PMs share all these traits and more. Both need to see the forest and trees, both need intuition and logic, both BAs and PMs need to act and to consider, and both need to interact with others and be alone. However, I think they use these traits at different points in the project and for different reasons.

Big Picture/Details

Both the BA and PM roles require us to both understand the big-picture and keep track of the details. As they progressively elaborate requirements from the highest-level business need to the detailed functional and non-functional requirements, as they trace requirements, as they elicit and model requirements, and as they ensure that the ultimate solution solves the business problem, BAs have to keep both the big-picture and the details in mind.

 A few ways in which PMs need the big-picture perspective include working with the sponsor on the Project Charter and project objectives, making presentations to senior management to justify funding requests, and ensuring that all the details of the project trace to the project objectives. As PMs detail the project management plan, including the baselines, the communications plan, the estimates and schedules, the resource plans, as well as when executing and monitoring  the plans, they need to keep track of a multitude of details.

Intuition and Logic

 If, indeed, intuition is “keen and quick insight” (dictionary.com) or “understanding without apparent effort” (Wikipedia), then we could argue that both BAs and PMs need it. If logic is “reason or sound judgment” (dictionary.com) or a “tool for distinguishing between true and false” (cited in Wikipedia), then both BAs and PMs need logic as well.

Back in the proverbial dark ages, I had a consultant tell me that I was “very logical, for a woman,” and I took that as the greatest of compliments. A few years later, when “female intuition” was still considered a negative attribute for serious women in business, I proudly noted how intuitive I was to my boss. I remember that he quickly retorted that I wasn’t intuitive, but rather that my experience gave me what appeared to be intuition about such things as what to recommend, estimates, people’s behaviors and motives, etc. I agree that the more experience we have, the more easily we can navigate uncharted territories. However, I have found that some of us need less data for our decisions, and some more. I’m not sure, though, which role uses more intuition and which more logic.

Introvert/Extrovert

I would be hard-pressed to categorize either PMs or BAs as either type. There are times on a project when we need to interact intensely with others and times when we need our alone time. For the BA, each of the BABOK® Guide 2.0 knowledge areas has tasks and techniques that favor one or the other, but both are needed to complete all tasks. For example in Elicitation, the task to conduct elicitation activities requires more extroversion, while documenting the results requires more introversion. In the PMBOK® Guide developing the team requires more extroversion and creating the various management plans requires more introversion. In an online article in Forbes on November 30, 2009, Jennifer B. Kahnweller convincingly argues that introverts make the best leaders (http://www.forbes.com/2009/11/30/introverts-good-leaders-leadership-managing-personality.html ). Perhaps the most effective project professionals are “ambiverts,” hovering close to the center on a continuum from introversion to extroversion.

Thoughtful/Action-Oriented

 Although there are times on a project when we need to act and times when we need to listen and to step back and consider alternatives, generally speaking the BA is more thoughtful and the PM more action-oriented. The PM is more focused on delivery of the end product on time and within budget, so there is more of a tendency to act and act quickly. In general, BAs need to ensure that the end product actually works the way stakeholders want it to work, so there is more need to analyze alternatives and impacts and ensure stakeholders come to consensus on the requirements, which will take more time, consideration, and patience.

Enough for now! I want to explore this topic of personality traits for PMs and BAs more extensively in future blogs.

Don’t forget to leave your comments below

The PM and BA Role; a Deeper Dive

Written by Elizabeth Larson on . Posted in Articles. 3 Comments on The PM and BA Role; a Deeper Dive

In November I wrote about whether or not the roles of PM and BA could be combined into one. I received wonderful responses, all of which broadened my perspective. Although I remain convinced that in most circumstances both roles are preferable, I understand that certain conditions, such as project size and corporate culture, may dictate whether or not one person plays both these roles on the same project. Another factor is that from a high-level view the skills seem similar. However, once we dive deeper into the business analysis and processes, the overlap lessons.

Today I’d like to explore the amount overlap between the two roles somewhat more deeply. Because of the need to use a common set of terms, I’m going to base my discussion on the Knowledge Areas (KAs) found in both the BABOK® Guide 2.0 and occasionally refer to the PMBOK® Guide Fourth Edition. Let’s start with the BABOK® Guide’s KAs. A mnemonic to help remember the KAs is PEACEUS. Think of all the “pieces” in the BABOK® Guide. PEACEUS stands for:

Knowledge Area Knowledge Area Highlights
P Business Analysis Planning and Monitoring Just for the business analysis phase(s): determine if the project will be waterfall or agile, identify stakeholders, estimate activities, decide which processes to use, determine metrics, monitor business analysis work.
E Elicitation Prepare for elicitation event, hold the event, document and confirm the results.
A Requirements Analysis Organize, prioritize, specify, verify, and validate requirements, including modeling requirements.
C Requirements Management and Communication Baseline requirements, manage changes, trace requirements, document requirements, present requirements for approval, manage re-use.
E Enterprise Analysis Define business need, assess gap between “as-is” and business need, determine how to approach the solution (“to-be”), define the scope of the solution, and develop a business case for undertaking a project to meet the business need..
U Underlying Competencies Qualities, knowledge, and skills that business analysts need to have to be successful, such as trustworthiness, systems thinking, ability to negotiate and communicate, and business knowledge to list a few.
S Solution Assessment and Validation Determine if the organization is ready for the change, figuring out how to implement the change, and allocate requirements to different projects, phases, releases, or iterations.

On the surface it appears that there are significant overlaps. For example, collecting requirements appears to be an area where there is confusion over roles and the potential for conflict. Another area is that of procurement, particularly relating to the Request for Proposal (RFP) processes. Another area for role overlap and conflict is scope management. Enterprise analysis is about defining the solution (product) scope. The PMBOK® Guide describes the need to detail out the scope of the product and the criteria needed to accept the product.

It seems to me that although there are areas of potential overlap, there are some significant areas that require unique skills. The table below shows some of the areas of overlap and uniqueness.

Knowledge Area Areas of Overlapping Skills Requiring Specific BA Skills
P Business Analysis Planning and Monitoring Identifying stakeholders, defining activities, estimating activities, developing metrics, monitoring the work. Determining if the project or phase should be waterfall or agile, planning the processes needed to complete business analysis.
E Elicitation All these areas potentially overlap. Many of the skills are required by both the PM and the BA. Skills for eliciting some requirements activities require a different skill set. For example, if the elicitation event is to prototype a new set of web pages, create use cases, or elicit data requirements, specific business analysis skills are useful.
A Requirements Analysis Not too much overlap. This area does include defining assumptions and constraints, but it’s a stretch to say there is much overlap here. Organizing project work is very different from organizing and prioritizing requirements. Specifying requirements, which is where the modeling happens, for example, requires a specialized skill set that doesn’t overlap with those of the PM.
C Requirements Management and Communication There are many overlapping communications and presentation skills. Although baselining, documenting, and tracing requirements are discussed in the PMBOK® Guide, I believe that it takes unique business analyst skills to effectively complete these activities. Also, managing re-use is a unique skill.
E Enterprise Analysis Defining the solution scope requires similar skills to decomposing deliverables into a work breakdown structure (WBS). After much agonizing about this one, because this was work I did as a PM, I can be convinced. Except for defining the solution scope, all the processes in this KA, can be more effectively handled by the BA,
U Underlying Competencies All project professionals, both PMs and BAs, need these competencies.
S Solution Assessment and Validation Assess organizational change. With the possible exception of assessing organizational change, this KA requires a unique set of skills to determine if “the solution meets the business need and facilitate its implementation” Babok® Guide introduction to Chapter 7.

I believe that if we were to take these processes within each KA down to the tasks within each process, we would see even more uniqueness. So for now, I continue to think it best to separate the two roles where possible.

Don’t forget to leave your comments below

Who Should Model Requirements? Business Analysts or Project Managers?

Written by Elizabeth Larson on . Posted in Articles. 3 Comments on Who Should Model Requirements? Business Analysts or Project Managers?

During a recent client visit I encouraged the use of modeling as a way to uncover hidden requirements and expectations. One of my clients expressed her rather strong opinion that modeling requirements was not and should not be a part of business analysis work. Oh, she could accept the fact that uncovering gaps between the “as-is” and “to-be” using process models made some sense, but she was adamant that this gap analysis should be done by a business SME, not by a business analyst (BA). As to data modeling, well that was technical in nature and if done at all, she said, it should be done by the technical IT staff. Use cases were helpful to the testing staff, but were clearly technical and were not to be done by BAs. Prototyping? This should be done by developers-no question about that one!

I was surprised at this reaction, which was expressed so emphatically. Perhaps she had no experience modeling requirements and felt insecure about her ability to do so. Perhaps she assumed that the norm for her organization was the norm for the industry. Perhaps she thought that models were truly technical in nature. Perhaps the line in the sand between business analysis and design was clear in her mind and modeling of requirements went into the technical bucket. Perhaps she thought that “solution” requirements (functional and non-functional) had no place in business analysis.

Is the real answer the consultant’s mantra “it depends?” In this instance I’m not convinced that it is. It seems to me that business analysis has to be concerned with what affects the business. If we’re creating a new web page or modifying one, we want to be sure that the navigation makes business sense (process modeling), that the information on the page is flexible and correct (data modeling), that how our customers interact with the website works for them (use case modeling). And I know that when we show people pictures, we uncover requirements that they would never have thought of.

Do these models have to be completed by a BA? No, they don’t. They can be performed by anyone in the organization who has knowledge of and experience in creating these documents. Having just said that anyone can model requirements, however, I’m now going to go out on a limb and make the case that BAs are best suited to model them. Here’s why:

  1. Modeling is a great way to uncover expectations-those unarticulated requirements that are rarely revealed at the beginning of business analysis, if at all. One of the advantages of modeling is that it provides a structure that encourages questions. Business analysts are in the best position to understand this structure and ask questions of the business subject matter experts (SME)s. They also are in the best position to interpret the answers and understand the impacts of responses they receive. Also, BAs generally recognize the importance of asking a variety of questions from multiple perspectives. Creating different models (business process, data, use case, low-tech prototypes) provide these different viewpoints (more about which in a future blog).
  2. Being consultants and liaisons, BAs are in a unique position to understand the business and to translate the requirements into something the designers can design and the builders can build. They can also translate the technical design back into something the business clients can understand and approve.
  3. BAs who can model requirements will almost certainly see gaps that jump out at them, screaming to be addressed. BAs, it seems to me, are uniquely qualified to address these gaps in a way that serves the business and makes sense technically.
  4. BAs are probably more likely than technical staff to go to the business to get questions answered. At the risk of gross generalizations, technical people may have a tendency to answer the questions themselves, without getting input from those who will be most affected-the business users.

My advice is to recognize that business modeling is best done during the business analysis phase(s) of a project and is best done be those who understand their importance in eliciting requirements.

Don’t forget to leave your comments below

Influencing the Project Manager

Written by Elizabeth Larson on . Posted in Articles. 6 Comments on Influencing the Project Manager

Much has been written about how business analysts can effectively influence subject matter experts, sponsors, vendors, and so forth. I thought it might be interesting to relate how a BA influenced me when I was a project manager I had started a job as a project manager in an organization in which the project managers, almost all of whom rose through the technical ranks, were expected to gather (yes, gather, not elicit) requirements. There was no formal definition of requirements, let alone any pretense at doing business analysis. Project managers all had their own way of documenting requirements, most of which was brief and folded into the design specification. Each project manager was expected to meet with SMEs, but not spend too much time. They weren’t productive, of course, unless they were working on “the important stuff.” I was lucky. When I started at this company, I was “given” the organization’s first BA as an experiment to determine if this new position of business analyst added value to the project and to the organizations.

I choose the word “given” carefully. The powers that be said something to the effect of “Starting on Monday, Kristin (not her real name) will join your team. Let’s see what she can do for you. Good luck.” I’m not sure what they were expecting. It turned out, however, that Kristin was a gift, indeed. She had many talents, one of which was to subtly but effectively give me work direction and she quickly became my trusted advisor. Here are just a few examples.

A new team member, Joanne, showed up unannounced and unexpected one day to work on our project. The project was undefined and the only thing we knew about it was its name and the name of our sponsor. Well, here came Joanne out of nowhere, asking where she should sit and what she should start working on. She said that she had seen a yellow sticky on her phone directing her to join our team (this is not just urban legend. It really did happen). I was at a complete loss. I was about to ask her to wait until we had more definition of our project, but Kristin gently urged me to find a spot for Joanne, and suggested that she start analyzing the current documents and interfaces. This work was important would keep her productive while we tried to get the project more structured.

Another instance occurred at a cross-functional requirements meeting. Several SMEs were unhappy about the direction of the project. Conflict arose between two business areas, both of which were vital to the success of the project. I was about to make a decision in favor of the area funding the project when Kristin suggested that perhaps I should meet with the sponsor, which I did. Such advice, while in all honesty was not completely welcome at the time, turned out to be well-advised. It didn’t take me long to realize that she was absolutely right. The decision was not mine to make.

Yet another time I was ready to recommend a change in project scope. One of the business SMEs requested an enhancement, insisting that he could not use the system unless this enhancement was added to the project. Kristin researched alternatives and suggested that the request had some pretty significant business and technical impacts. She recommended that the request be its own separate project. She convinced me that trying to add it to the current project, even if the sponsor authorized it, would not only cause the baselined scope, time and budget to change dramatically (my main concern), but more importantly that the request didn’t align with the business problem or project objectives we had defined. She explained this to the requester, who withdrew the request. I updated the project sponsor with the good news.

One last example; It was Kristin who taught me the importance of defining the business problem. I had always documented the project solution without much thought given to what problem it was solving. However, one time a sponsor wanted “just a little enhancement” on a project. After Kristin convinced me of the benefit of defining the problem, we realized that the enhancement would not solve the problem. Kristin was able to convince me and I was able to convince the sponsor that to solve the problem the current system needed to be scrapped and replaced.

These are just a few examples. It seems that she constantly persuaded me to take some kind of action. Her suggestions were always based on her experience and research, as well as her good analytical and critical thinking skills. I quickly came to trust her suggestions. Although I didn’t always want to listen to her advice, I almost always did and almost always with a good outcome.

Don’t forget to leave your comments below

Can You Be Both PM and BA on the Same Project?

Written by Elizabeth Larson on . Posted in Articles. 4 Comments on Can You Be Both PM and BA on the Same Project?

One of the most frequently asked questions I still get from my clients is whether or not one person can be both a PM and a BA on the same project. The answer, of course, is yes, they can. A related question, though, is whether or not they should. I think there are really two different answers to two different questions.

If the question is could the BA and PM play the same role on the same project, my answer is that I can think of many situations where a single person could perform both functions. For example, if the organization does not recognize the importance of either role, if it doesn’t have enough resources for both roles, if a project is known to be “small,” when the team has worked together and is a high-performance team, one person could play multiple roles. Functioning in both roles on one project can work, especially when it is clear to everyone which “hat” is being worn at any given moment.

On the other hand, we might ask under what circumstances would it make sense for the BA and PM to play the same role. For me this is a harder question to answer. Here are some considerations:

  1. Generally speaking, there is an inherent difference of objectives between the two roles. The PM’s role is to meet the project objective (PMBOK® Guide Fourth Edition Section 1.6). The BA’s role is to help organizations to reach their goals (BABOK® Guide 2.0 Section 1.2). This is a subtle but important difference. Organizations usually complete projects to help them meet their goals. Project objectives are more specific than organizational goals. Put another way, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.
  2. Another difference is one of focus. The PM typically focuses on the project-creating baselines and managing project constraints, communications about the project, resolving issues about the project, getting the resources working on activities and tasks. The BA typically focuses on the end product. However, those lines are not always clear- cut. According to the BABOK® Guide 2.0, BAs do need to focus on the project when they plan and monitor the business analysis work, which is part of the project. That is, planning how the business analysis work will be completed, how formal the work will be, what documents, if any, will be produced, what approach will be taken, how the work will be tracked and reported etc. is project work. The focus is on the project, not the end result.

However, doing project work as part of business analysis does not mean that the roles of PM and BA overlap. The project manager gets input from a variety of people on the team including the BA and uses that information to manage the project.

Although the PM may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. It seems to me that:

  1. It takes time to do both jobs well. Certainly on “large” projects, it is a full-time job to manage the project and to manage the end product requirements. Trying to do both will usually mean increasing the risk and compromising the quality of both the project and the end product.

    One of our clients recently completed a study on separating the two roles, which had previously been combined. This assessment was undertaken in part because during different phases of the project, the PM role was neglected, and during other phases the BA role was. They concluded that on most projects both roles were needed and recommended the separation.

  2. Because there is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want to deliver the end product on time and within budget. Business analysts want to ensure that customers can actually use the end product once it has been implemented.

    I can almost hear an internal conversation the combined PM/BA might have: the PM voice, sitting on one shoulder, says “But this has to be complete by Jan. 15th so we need to take these shortcuts.” The BA voice, sitting on the other shoulder, says “But we need to take time to do this right. If we put this into production now, it will cause defects, rework, workarounds…” The PM voice replies “if we don’t meet the date, we’ll destroy all their trust in us.” The BA voice says, “If we don’t get this right, we’ll destroy all their trust in us.” When we wear multiple hats, which voice do we listen to?

Personally, I have found it helpful to have both roles on projects, even when the project is “small.” So although it may not be necessary to have both a PM role and a BA role on every project, it sure makes sense on most.

Don’t forget to leave your comments below