Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, has been the CEO for Watermark Learning as well as a consultant and advisor for Educate 360. She has over 35 years of experience in project management and business analysis. 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 the several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, and spending time with her 6 grandsons and 1 granddaughter.

Who Should Define the Business Need?

Written by Elizabeth Larson on . Posted in Articles.

Ask a business analyst (BA) who should define the business need and you might hear that it is the BA’s role to do so. After all, the business need defines the business problem or opportunity, which BAs have to understand in order to recommend appropriate solutions. BAs know that all requirements should link to the business need, so it is important to spend the necessary time to truly understand it.

 Ask a project manager (PM) the same question and chances are they will say the same thing–that they are the ones who should determine the business problem or opportunity. They know that their project will not succeed if it does not help support organizational goals and if it does not solve real business problems. The business need becomes the project’s foundation. Just as requirements link to the business need, so does each project objective and deliverable. Since PMs are accountable for meeting the project’s objectives, many PMs want a part in defining the business need.

Who’s right? Who should define the business need? Does it really matter? I think it does matter, because the person who articulates the business need usually ends up owning the project. I do not believe it is in the best interest of the organization for either the BA or the PM to take ownership of the project. That is, they both need to be accountable for delivery of the end solution and for ensuring that that solution meets the business need, but not for the need itself.

Before we look at who should define the business need, let’s describe what a business need really is and its interrelationship with the project and the requirements. In order to meet its goals, an organization usually undertakes many projects, and the projects that have the greatest chance for success are those that help the organization reach its vision, strategic direction, and business objectives. Ideally projects are prioritized based on business need (problem/ opportunity) and the business case (costs vs. benefits), because the need describes the pain and the benefits describe the relief.  So before a project can really begin, the business need and business case are defined, either formally or informally.

Defining the business need occurs before the project is sanctioned by the project charter, that important document is ideally written by the sponsor, often with the help of a PM. The information in the project charter, including a high-level description of the end product or solution, is input into the requirements processes, which in turn produce the requirements that are input into the definition of scope at a level of detail sufficient for the planning processes. Of course, the requirements get further elaborated during the one or many phases of business analysis work, but each needs to help solve the original business problem or contribute to the business opportunity.

So who should define the business need? The PMs, because they have to meet the project objectives? The BAs because they have to define the solution requirements? I’m going to suggest that the person or group requesting the project should define the business need, and that person or group needs to be high enough in the organization to sell the idea, to get the organization enthusiastic enough about the endeavor to fund and prioritize it, and to rally the necessary business resources. I believe this responsibility is best handled by a sponsor, steering committee, regulatory or compliance body, or a fairly high-level Subject Matter Expert (SME). Project managers and business analysts are most effective when they are neutral facilitators, not owners. Both roles need to make recommendations and can certainly recommend which projects to undertake, but they are not the ultimate decision-makers.  They work with and advise decision-makers. However, when PMs and BAs move away from advising and into decision-making, facilitating and advising become far more difficult.

Although it’s the requesting organization (to use PMBOK speak) that defines the business need, I believe that the BA is in the best position to work with that person or group to help them articulate the real need and the extent of the need. BAs can help describe how bad the pain is or how great the opportunity. I think there is a vital difference between defining the need and helping the requestor define the need. That difference is one of advising versus deciding. And the PM? Although the PM can advise the sponsor on the writing of the Project Charter, the bulk of the project management work begins once the project has been approved and sanctioned and authority given to the PM.

Don’t forget to leave your comments below

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

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

During 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 BA and PM Role; a Deeper Dive

Written by Elizabeth Larson on . Posted in Articles.

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

Where We Were in 2009 and Where We’re Headed in 2010

Written by Elizabeth Larson on . Posted in Articles.

Co-authored by Richard Larson

At the close of 2008 we made seven predictions about business analysis and project management trends for 2009. How did we do? This article looks back at our predictions for 2009 and forward to new ones for 2010.

1. 2009 Trend – Convergence of PM and BA Roles.

As the economy tightens, organizations will decrease their project budgets. But, they still need projects done, so look for organizations to try and combine the role of the BA and PM on projects. Project managers will be asked to do more requirements elicitation and analysis. Business analysts will be required to manage more projects. Oh, and by the way – you will need to do that in addition to your normal roles!

How’d we do? It appears that many organizations are, indeed, either merging the roles or completing feasibility studies on combining the roles. Here, also, is a sampling of the comments received in response to my December 2009 blog asking whether or not one person could fill both roles, I received:

  • Johnstde 95% of my projects require me to do the jobs of BA and PM.
  • Drusso The points made agree with trends we’re seeing with our clients and opportunities
  • gmmba, Truth be told. When I am evaluating resumes for BA opportunities, I look for BAs with solid Project Management experience. When I am evaluating Project Managers, I look for solid BA experienc
  • a gues I may be moving to a PM/BA type role and it is unnerving coming from a straight BA positio
  • Hkmartin Some people are skilled in both PM and BA work and can easily shift from one role to the other
  • abhikashyap22 ,My answer to your question will be a “Yes”. A person can perform a BA role and a PM role on the same project.

2010 Trends
Look for some companies to continue to question the separation of roles, while others recognize the importance of the business analyst and keeping it separate. Look for some attempt at role delineation (see 2010 trend summary at end) and how BAs, PMs, and testers can all work together effectively. Organizations will continue to expect business analysts to test requirements, although there will be a growing awareness that the testing process is different from business analysis.

2. 2009 Trend – Greater Emphasis on Requirements in Project Management.

The PMBOK® Guide Fourth Edition “Collect Requirements” contains a number of requirements elicitation techniques. They are a subset of the techniques described in the BABOK® Guide 2.0, so BAs also need to be familiar with these.

How’d we do? It appears that the topic of collecting requirements as part of project management is wide-spread. There have been numerous presentations, webinars, and articles on this topic. The term “Collect Requirements” has crept into our common project vernacular. There are many blogs and discussions about collecting requirements, including who should collect product requirements vs. project requirements, as well as what level of detail should be collected and when. This topic has helped fuel the debate about the role of the project manager and business analyst and who should be responsible for what.

2010 Trends
Organizations will continue to struggle with the role definition of the BA and PM and where the two overlap, such as who is responsible for defining the business problem and product scope. Look for organizations who value both roles to further define responsibilities. Also look for more business analysis Centers of Excellency (COEs) to tackle not just roles and responsibilities, but also requirements processes and templates that can be used during business analysis.

3. 2009 Trend – Change in Requirements Approaches.

We see a continued trend in business analysis techniques continuing into 2009. Here are some to consider:

  1. Slightly less reliance on use cases and movement towards user stories and scenario-based requirements.
  2. Less emphasis on requirements specifications, more emphasis on modeling, prototypes and diagrams.
  3. More requirements management. There will be continued increase in business analysis and requirements planning in 2009. We see more and more organizations using traceability to control and mage product scope

How’d we do? We did pretty well on the first two and part of the third.

  • User stories, along with the agile approach (see below) have been adopted in many organizations.
  • While many organizations, particularly large companies, document requirements in a formal specification, others are opting for less formality on some projects. Also, many companies are using models to supplement textual requirements lists.
  • We’re seeing an increase in the number of organizations that understand the importance of tracing requirements and understand the relationship between traceability and managing scope. In addition, many companies that have adopted Agile methods participate in release and iteration planning. However, in 2009 we anticipated more wide-spread adoption of other business analysis planning processes, such as creating a business analysis work breakdown structure (WBS) or estimating business analysis tasks.

2010 Trends
Organizations will move to documenting requirements appropriately for their projects. They will continue to recognize that one size does not fit all. Waterfall project teams will move to less documentation where it makes sense, understanding that over documenting can be as detrimental as not documenting enough. More organizations adopting Agile methods will understand when documentation is important (for contracts and regulatory compliance, for example) and not use Agile as an excuse for omitting all project discipline. Increasing adoption of requirements management tools will contribute to greater requirements management for organizations who employ them.

4. 2009 Trend – Increased Use of Agile Approach and Techniques.

Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue as organizations adopt Agile techniques and the industry adopts commonly accepted practices.

How’d we do? The adoption of Agile methods, especially Scrum but also including XP, exploded in 2009. The use of Agile is one of the hottest topics at both project management and business analysis conferences, in the blogosphere, and within PMOs and COEs. Scrum user groups continue to grow in numbers and numbers of attendees. The BABOK® Guide is developing an Agile extension.

2010 Trends.
We anticipate that the adoption of Agile methods will continue to increase. There will be more realization within organizations that using Agile methods is not an excuse for lack of discipline, that automated testing tools might be needed to achieve significant benefits, and that techniques such as facilitation and modeling are still important. More organizations will implement methods such as Scrum, and will continue to get positive feedback from both the team and the business clients.

5. 2009 Trend – BABOK® Continuing to Have an Impact.

The practice of business analysis is being positively influenced by the Business Analysis Body of Knowledge (BABOK®). The BABOK® Knowledge Areas of Enterprise Analysis are beginning to gel in organizations, as is the need to do requirements planning. We’re seeing more formality and standardization in the methods, say, of doing business cases, or using traceability to manage requirements.

How’d we do? The number of IIBA members and chapters continue to grow. There were 5,000 members at the end of 2007 and 11, 707 as of January 2010. The number of Certified Business Analysis Professionals (CBAP) continues to grow as well. There were 301 as of January 2008, 479 as of January 2009 and 827 as of January 2010 (IIBA Newsletters). There have been more comments by discussion group members and in articles and blogs that acknowledge the BABOK® Guide as the de facto business analysis standard. However, regretfully, we think that use of BABOK processes such as Enterprise Analysis or business analysis planning has not increased significantly.

2010 Trends
Both project management and business analysis will be recognized as essential to project success. The number of CBAPS will continue to grow worldwide as the tasks and techniques BABOK becomes more widely adopted. In 2010 there will be more of an effort to understand the role of the PM and BA (see above). The relationship between Enterprise Analysis in the BABOK and Portfolio Management in the PMBOK will be the subject of presentations, articles, and blogs. PMI and IIBA will collaborate to clarify the roles and handoffs between project managers and business analysts. This effort will improve the practices of both professions, although they will likely be subtle shifts.

6. 2009 Trend – Business Intelligence Continues to Grow.

This area of information systems has been growing steadily and 2009 promises to have no letup. As BI tools and techniques improve and solid benefits are realized, organizations will invest more and more in this tactic. Since BI relies heavily on tools such as Business Objects or Cognos, the underlying business requirements can be easily overlooked in favor of what the tools can produce.

How’d we do? The need for BI continues to grow, as well as the reliance on automated tools. The attention paid to BI requirements analysis has lagged, unfortunately.

2010 Trends
There will be a continued reliance on tools. Organizations will look to predictive analytics as a way to compete. There will be recognition that the BA is needed to elicit and analyze BI requirements. In his article “Building the Basics Is Key to Launching a Successful BI Program, (Sean: Please link”(http://www.businessintelligence.com/article.asp?id=166&pagenum=2), author: Gary Garris states “Striking the right balance between the type of information required and the framework for delivery requires a defined and methodical approach built on solid governance principles that merge business drivers with appropriate enabling technologies. Look for more articles and webinars on BI requirements in the months ahead.

7. 2009 Trend – “The Economy, Stupid,”

As a past political slogan said: A slumping economy tends to affect travel and training budgets, and this one is no exception. That translates into fewer trips to national conferences or travel to out-of-state training classes. Have you noticed the big increase in webinars as a way of exchanging information and interacting virtually without travelling? Watch for more of the same in 2009.

How’d we do? As the economy continued to slump, the number of webinars increased dramatically. Many national and regional conferences had fewer attendees than the previous year. BAs and PMs have found new ways to get and share information through social media and virtual discussion groups.

2010 Trends
“Discretionary” budgets will continue to be tight. Travel funds for conferences will not increase significantly. Webinars will continue to be a quick, inexpensive way to increase knowledge and obtain credits for recertification. In addition to the continued growth of social media, both virtual and online training will increase as many organizations’ training budgets remain static or decrease.

Other 2010 trends include opposing forces in these areas:

  1. Roles. Look for both more role delineation (PM and BA, BA and tester, for example) as well as less role delineation as Agile team members wear multiple hats.
  2. Governance. Look for more governance on some types of projects, such as BI and less governance on those using Agile methods. Look for a move towards more standardization of requirements processes and templates (established in growing numbers of Centers of Excellence), and less with Agile projects. More business process management and more formal and informal process modeling as a way to uncover the gaps in what an organization currently does and what needs to be done as a result of implementing a new product or software.
  3. Tools. There will be both a greater reliance on tools (such as Agile testing tools) and more adoption of low-tech tools, such as low-tech prototypes.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Should Business Analysts Model Requirements?

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Should Business Analysts Model Requirements?

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

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]