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.

Three Tips for Solving the Communications Dilemma

Written by Elizabeth Larson on . Posted in Articles. 2 Comments on Three Tips for Solving the Communications Dilemma

Recently I talked to a colleague with a communications dilemma. She wondered how she should communicate with her various stakeholder groups. Thinking out loud she pondered, “When I’m with business people, I always try to use business language, including their acronyms, which I’ve gone out of my way to learn. But what about when I’m talking to the technical experts? Should I talk techie to them?” She went on to say, “I write a lot of proposals. I have some stakeholders who let me know right away about typos or if my grammar is not exactly right. I have other stakeholders who have told me that my writing style is too formal and that I shouldn’t use such correct grammar. They feel it’s intimidating and unfriendly.”

As BAs and PMs we know we’re supposed to be good communicators, but what exactly does that mean? We are trained to be aware of others’ communication style. We use our intuition, empathy, and awareness of body language to “read” others. But is that enough? And does that apply equally to our written and our verbal communication? What about the language we use? I have always loved the quote from the poet William Butler Yeats, “Think like a wise [person] but communicate in the language of the people.” Does that mean, however, that when we are talking to someone who misuses the language, that we should match our language to theirs? I don’t think so. Matching the communication style does not necessarily mean mimicking their language. However, we do want a communication style that makes our stakeholders comfortable.

How can we solve this communications dilemma? Here are three tips for both written and verbal communications that can help.

  1. Take the time to keep it simple. We are all aware of the wisdom of keeping it simple, but simple doesn’t mean easy. Simple doesn’t mean careless. It is often harder to keep it simple, because keeping it simple requires thought, precision, and a good command of the language. I find that it takes a great deal of thought to write concisely and say everything I want to in language that all stakeholders will understand.
    That same principle of simplicity applies when we paraphrase, or restate what was said in different words while keeping the nature of what was said intact. I think paraphrasing is one of the most difficult skills to master. It requires the ability to take in a lot of information, to synthesize it, to concentrate on what is being said, and at the same time to rework the ideas to make them understandable. It’s tough work!
  2. Be correct without being pretentious. When we use incorrect grammar or when we don’t bother to check our work, we run the risk of being judged poorly, of reducing our credibility, and of not being taken seriously. On the other hand, when we use ornate language and complex sentence structure, we run the risk of losing our audience. I remember taking a multiple choice test in high school where the correct answer was “It is I who am going shopping.” Wow. And of course there’s the famous line from Churchill. Apparently his editors rewrote a sentence to make it grammatically correct, and apparently he responded with the famous line, “This is the sort of bloody nonsense up with which I will not put,” pointing out the ridiculous nature of obscure grammatical rules. In a nutshell, I think we should strive for communications that are both intelligent and clear.
  3. Use language that both technical and business people understand. I have found that when I use technical language with business people, they have a harder time understanding me than if I use business language with technical people. Using business language, then, tends to be more easily understood by all stakeholders. As a project manager working on software development projects, I always encouraged the developers to use business terms, even when the subject was technical in nature. For example, instead of saying DB17, I encouraged the team to talk, even among themselves, about the Price Change database.

Another example I use is that when we need to find out about data business rules, we might walk into a requirements workshop and ask about the cardinality and optionality, but we’d probably get some blank stares. However, we can translate those concepts into questions our SMEs can understand and answer. For example, we might ask if end-users can set up customers who don’t have any accounts. Or what information the end-users need to enter before they can leave the web page. I have always believed that translating technical concepts into business English, while annoying to some team members and technical whizzes, has always been worthwhile. It encourages us to focus on the business need rather than the technical solution.

Finally, let’s look at the intent of the communications. If we all understand each other and what we’re trying to say, then I believe we are communicating effectively, even if our grammar isn’t perfect or we don’t use the right words. And I believe that most stakeholders get that and won’t judge us harshly. However, for those stakeholders who want each “i” dotted, let’s proof our work. It will help build our credibility. The key is to know our stakeholders, but that’s a topic for a different day.

Don’t forget to leave your comments below!

Mystery Fiction – The Business Analyst as Detective

Written by Elizabeth Larson on . Posted in Articles.

My husband and I belong to a mystery book club. Every month we read and discuss a book loosely categorized as mystery fiction. Recently one of the members asked whether the book we had just discussed was really a mystery. Good question, since each of us had different ideas of what distinguished a mystery from other forms of fiction. During the ensuing discussion I kept thinking about the similarities between mystery fiction and business analysis.

Mystery novels are concerned with crimes and their detection, which typically involves finding clues and recognizing which are important and which are not. At the crime scene there are a myriad of objects, some or none of which might help solve the mystery.

Effective business analysts are also concerned with detection-of a different sort. They need to detect the business need and related requirements. Like detectives sorting through objects at the scene of the crime, business analysts need to sort through information-lots and lots of information-in order to discover business needs. Like many of the great detectives, they need specific characteristics, qualities, and skills, such as:

  • Ability to solve problems creatively. We often tell ourselves to think outside the box. I don’t know about you, but when I try to force creativity, I usually get stuck. What helps me develop creative solutions is introspection and quiet time, giving my mind a rest and a chance to process and cull the information it’s taken in and eliminate the unimportant details. Fictional detectives rest their minds in different ways. Doyle’s Sherlock Holmes plays the violin. Christie’s Jane Marple knits. Some, like Poe’s Auguste Dupin, need to sit and think. In Poe’s “Purloined Letter” the narrator states, “For one hour, at least, we [he and Dupin] had maintained a profound silence.”

After clearing the mind, a creative solution often appears. This is known as the Eureka effect, named after the ancient Greek Archimedes who is said to have solved a problem in a public bath. Also known as the “Aha moment” or “breakthrough thinking,” I call it the “bathroom cleaning syndrome” after a business analyst I knew solved a difficult problem while cleaning the toilet. Whatever we call it, inspiration often occurs when our minds stop concentrating on the problem at hand and we are free to put the pieces of information together in a meaningful way.

  • Using intuition while checking out the facts. In many detective novels, it’s the bumbling police inspector who makes assumptions, but our detective heroes go for the facts. P. D. James’ Adam Dalgliesh’s “reputation for never theorizing ahead of the facts is legendary, yet his success at solving complex cases in record time is astonishing.” [1] Dragnet’s famous Sergeant Joe Friday always asks for “just the facts, ma’am.”

Other detectives rely more on intuition, but understand that hunches need to be verified with facts. Jane Tennison, played by Helen Mirren, is the Detective Chief Inspector in Prime Suspect. [2] DCI Tennsion almost immediately knows who the prime suspect is, but the main narrative is constructed around verifying her initial hunch.

We BAs use our intuition all the time. We have hunches about why some solutions will work and why others will not. I believe it is essential to listen to our intuition, which is probably based on our experience about what has worked or not in the past. It’s this experience which helps us synthesize a lot of information quickly, even when the situation is entirely new. Although we should not ignore our hunches, we need to check them out. This verification is accomplished in lots of ways, using a variety of elicitation techniques. Depending on the problem or issue we’re trying to solve, we may need to observe, complete research, facilitate a meeting, or conduct an interview, for example. These are the same techniques used by our detectives to verify and discover information.

  • Focus. Good detectives and BAs are focused on the task at hand, which allows them to observe, listen to, and absorb a great amount of information. In mystery fiction Miss Marple is acutely aware of her surroundings, taking in lots of information through her senses, and processing it quickly. Her ability to gain trust is also helpful. She wanders through the crime scene almost unnoticed, as she observes and listens purposefully and intensely. Also a master at understanding non-verbal communications, she readily recognizes such emotions as fear, anger, and remorse.

Business analysts need to focus during elicitation activities. Many BAs complain of having to play multiple roles, which makes focus difficult. When we multi-task, we lose some of our concentration. It is harder for us to observe, listen, absorb, and read the non-verbal cues which are critical in our facilitator role. We might fail to ask important questions, and business analysis usually takes longer or is less effective.

  • Ability to thrive in ambiguous situations. We often hear about the need for BAs to tolerate ambiguity. I think that effective detectives and business analysts are those who not only tolerate, but actually thrive in ambiguous situations. Following a one-size-fits-all process would be boring and more importantly would not get the desired results. For detectives and BAs there is no one process to follow. Rarely is the “case” clear cut. Some organizations, though, believe that if we only had a requirements process, we’d be able to churn out effective business analysts. I wish it were that easy! Having processes is great but not sufficient. Some inexperienced BAs struggle with ambiguity. I believe that BAs who long for clear-cut situations will find business analysis too frustrating for a long-time career.

The ability to thrive in ambiguous situations also allows detectives and business analysts alike to create structure from chaos. We are often amazed when Miss Marple, who is tolerated but not taken seriously, that very Miss Marple who has sat, listened, and observed but said little, is able to put the puzzle pieces together. We are equally amazed when business analysts can synthesize all the information they’ve accumulated during elicitation activities, put it together in meaningful ways, and are able to create understanding and gain consensus. How, we wonder, can they be so effective at sorting through so much and making sense of it all? That’s the mystery, I guess.

Don’t forget to leave your comments below.

[1] Mystery! website, http://www.pbs.org/wgbh/mystery/detectives/dalgliesh.html

[2] Granada Television and Mystery!

 

Bad Business Analysts, Project Managers, and Relationships

Written by Elizabeth Larson on . Posted in Articles.

Larsons_Main_Feb8The “Bad” BA or PM. Is there such a thing, I wondered, when our editor asked for blogs on this subject? In giving it some thought it seemed to me that there may not be any bad business analysts (BAs) or project managers (PMs), but there certainly are some bad BA and PM practices. I’ve compiled a list of some of my favorites. As an aside, some of the worst BA/PM behavior occurs when the relationship between these two critical project roles struggles. In this blog I address bad BAs, bad PMs, and bad BA/PM relationships.

Bad Business Analysts

The “B-A-A-H-d BA”. That’s right. The BA who acts like a sheep. I’ve met many of them over the years. These are the BAs who lack courage. They do not see themselves as influencers, but rather as order-takers. They seem to forget that they are high-level management consultants who “recommend solutions that enable the organization to reach its goals.” (BABOK® Guide Version 2.0, Introduction, Section 1.2).

These b-a-a-a-h-d BAs:

  • Answer “you want it, you got it,” when given a solution. It may not occur to these BAs that when given a solution, it is necessary to find out what business problem is being solved or what business opportunity is being seized. These BAs may not know what questions to ask, or they might be afraid to ask the right questions. Either way, they tend to plow ahead with the requirements of the proposed solution without understanding the real business need. Not too long ago a client told me, “When the sponsor says they want something, who am I to question it?”
  • Bleat “Baaaah as they follow the pack. I have seen knowledgeable and experienced BAs go along with the business subject matter experts (SMEs) even when they are aware of business and technical impacts and dependencies. As above, they might not be comfortable asking questions or providing their insights and advice.

The “BAD idea BA” who thinks that all ideas presented are bad. We call these BAs initial rejecters. For these BAs, no idea has merit until it has been thoroughly analyzed. Do ideas need to be analyzed? Of course! Do risks need to be addressed? You betcha! But initial rejecters can be viewed as complainers who push back on all new ideas. Effective BAs, on the other hand, understand the importance of a positive, helpful, and non-combative attitude.

The “B-A-H-d Humbug BA” These are the BAs who listen politely to the business SMEs and then turn around and ignore them. I have actually heard one of them exclaim, “They don’t know what they want, so I’ll give them what I think is best for them.” Another equally well-intentioned BA once told me “I have a lot of experience and know what’s best for them. “

Bad Project Managers

When our editor asked for characteristics of a bad PM, I said to myself, “That’ll be easy. As a PM, I’ve made every mistake in the book.” Below is just a sampling of the mistakes I made as a BAD PM.

  1. Telling the business SMES “I’m sorry you can’t have that feature or function. It’s out of scope.”
  2. Asking a business SME at the beginning of a requirements workshop, “What are you doing here?”
  3. Not nailing down the project objectives during Initiating.
  4. Because of a tight deadline, telling the developers that they needed to focus on project tasks rather than answering questions of and being mentors to members of other development teams.
  5. Hoping that a team conflict would go away and thus taking too long to resolve it.
  6. Not recognizing that we were in analysis paralysis until the sponsor blew up in total frustration.
  7. Letting methodology get in the way of providing good customer service.
  8. Omitting lessons learned and/or not spending the time to review lessons learned from past projects.
  9. Not communicating the team’s accomplishments regularly to the powers that be so they could get the recognition they deserved.
  10. Not understanding the importance of team dynamics in project success.

Bad Business Analyst and Project Manager Relationships

There are some project professionals who when acting alone as a BA or as a PM are “good,” but get them together and the project becomes a battlefield. These are the PMs and BAs who can’t seem to work well together.  Here are some examples of “bad” BA/PM relationships. Most of these examples stem from each role not understanding the other, from not defining roles and responsibilities, and from not having an understanding of the work involved or the empathy for the difficulties of the other role.

  1. Both the PM and BA think it’s their job to define the business need and project objectives.
  2. PMs who think that the BA plays a subordinate role on the project. They don’t understand that for the project to succeed, it’s best for the relationship to be peer-to-peer.
  3. PMs who think that the BA’s job is nothing more than elicitation and documentation.
  4. PMs who think that it is their job to plan the business analysis work.
  5. PMs who micromanage the business analysis effort.
  6. BAs that confuse business analysis with project management.
  7. BAs who keep the PM out of the communication loop.
  8. BAs who promise new and changed features without discussing the project impacts with the PM.
  9. BAs that become aware of business risks and don’t notify the PM.

These are just a sampling of bad BAs, bad PMs, and bad relationships.

Don’t forget to leave your comments below.

Kicking the Hornet’s Nest

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Kicking the Hornet’s Nest

ElizabethLarson_Dec28-29_CroppedOK, you Stieg Larson fans, I’m not Lisbeth Salander, the heroine of the best-selling trilogy. I have neither her wits nor her strength. But I have kicked a few hornet’s nests in my career. Some of these nests were full of angry hornets and some full of non-aggressive bumblebees. However, every instance reinforced the importance of doing the right thing for the organization, even if it meant getting stung.

The Nest Full of Angry Hornets

In one organization I was acting as both a PM and a BA. My manager asked me to put together a project request for a business director in an area completely outside of my expertise. I met with the person I had assumed would be the sponsor, but who didn’t seem to understand why I was there. I asked lots of questions and didn’t got a cozy feeling that the business problem had been defined or that this person would be an engaged sponsor. I wrote up my findings recommended that we not pursue the project until we defined the business need and a business case and had gotten a sponsor on board. When I presented these findings to my manager, I was brusquely told me that this was not what he was looking for and that I should put together a project request.

I then decided to kick a little harder. I went back to the business director and asked more questions and talked him through the information needed for a project request. So far so good. But when I asked him to sign it, he refused. I explained why his signature was important and asked if there was someone else that should sponsor the project. When he asked why I couldn’t sign it, I discussed the relationship between signing the request and owning the project. I kicked a bit harder and said I’ be happy to manage the project but not own it. I returned to my manager and explained the situation. I’m not sure what happened, but the project just sort of disappeared. It wasn’t given to another PM, nor put on the list of active, future, or deferred projects. It just disappeared. It seemed to me that convincing management not to proceed with the project was a major success. I was delighted with the outcome, because had we gone ahead without a real business need and sponsor, it would have been a nasty project indeed.

I remember another instance when I kicked the nest with a less positive outcome. I had just joined a company with about two dozen project managers who were expected to do both project management and business analysis work. Each week we met to discuss our projects and issues. I remember that the first meeting I attended seemed to drag on endlessly. I was bored and impatient and wanted to move to a more interesting topic. I offered what I thought was a solution to the problem they were discussing. The conversation stopped. All eyes turned in my direction. I started to justify my approach, but then all eyes turned away and other voices rose over mine. The issue continued to be addressed, but when I tried to speak, two dozen hornets buzzed angrily around me. Later, one of the PMs pulled me aside and told me that the organizational culture required that new members didn’t speak up until they had been there several months. I broke the rules. I guess I was perceived as trying to usurp the queen bee’s place, and the nest would never allow that to happen. I learned what I should have known-listen and understand before speaking. A great lesson, but one that’s difficult for hornet nest kickers like me.

The Non-Aggressive Beehive 

I once kicked at what I thought was a hornet’s nest. The project had an unusually ridiculous deadline. We were developing software and every time we turned around, it seemed, we experienced technical difficulties that slowed us down. The staff became frustrated. I had verbally told our management and the sponsor that the project might be delayed. The VP in charge of all the application software was displeased. “I don’t want to hear any excuses,” he said.

Were technical delays excuses, I wondered. Surely anything beyond my control was easily explained and a reason to delay the project completion. Or so I argued with myself. What to do-what to do? I went through a period of mental hand-wringing before deciding to go back to my management consulting roots. I asked the team to keep track of the amount of down time caused by technical delays. After initial grousing and grumbling, the staff complied. Once I had gathered enough statistics, I analyzed them and put together my findings and a recommendation. With fear and trepidation I set up a meeting to present the findings and recommendation to Management, who much to my surprise were enthusiastic in their praise of the approach and who actually agreed to extend the deadline.

I do believe that one of the great attributes of trust is courage. If we always act in what we believe to be the best interest of the organization, as risky as it sometimes seems, we will need to kick a few hornet’s nests, but that’s OK. It will likely earn respect. Sure we’ll get a few bites, but hopefully we’ll develop immunity to the sting and continue to recommend the right things.

Don’t forget to leave your comments below.

Requirements Management 101

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Requirements Management 101

Elizabeth_Larson_feature_imageThe following is an excerpt from the book Practitioner’s Guide to Requirements Management, Part I: Requirements Planning, written by the authors.                                    

Overview

Requirements management, like project management, is a discipline comprised of inputs and outputs, tools, and techniques, processes and activities, but just for the business analysis effort. Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements. Get a quick introduction or refresher on this important topic.

We will briefly look at a few of the key ingredients in managing requirements, including what gets created during planning, documenting “good” requirements, traceability, and managing changes.

Requirements Management

The discipline of planning, monitoring, analyzing, communicating, and managing requirements.

Planning

Two of the key outputs from requirements management are a planned and communicated approach to business analysis and a requirements management plan.

The business analysis approach. The approach that we take to business analysis work is primarily concerned with the type of framework, method, or methodology we use to capture our requirements. The approach is the cornerstone of our effort, and it determines how we go about collecting and managing requirements. It describes the processes we will follow and the templates, if any, that we will complete. the approach will probably be different for different methodologies  and frameworks. For example, prioritizing requirements on an Agile project is different from prioritizing them on a Waterfall project. In choosing an approach, we need to make sure that it’s communicated to all appropriate stakeholders and that they are onboard with the approach that will be taken.

The requirements management plan (RMP) describes how the business analysis work will be completed. It describes processes for how requirements will be documented, traced, prioritized, baselined, and changed. We might also think of the RMP as a collection of the plans that are used to manage business analysis. The RMP can be a formal set of documents with many subsidiary plans, such as a business analysis communication plan, business analysis risk plan, estimates for the business analysis work effort, and many more. This type of RMP might be appropriate for larger, riskier projects. On some smaller efforts the RMP can be an informal roadmap. In either case, it is subsidiary to the overall project management plan.

Documenting “Good” Requirements

Requirements documentation. Requirements are always documented, either formally or informally. Requirements might be documented as part of a detailed requirements specification, in the form of a short text known as a user story, or as part of one or several models, such as a business process, data, or use case model, or as a prototype or mock-up. There is no right way or wrong way to document requirements, as long as all the requirements are understood by everyone who hears or reads them–which means they need to be “good.”

What makes a Good Requirement?

In order for a requirement to be worth managing, it must be useful. To be useful, a requirement has to be understood by all key stakeholders. Sponsors and business subject matter experts need to know that the ultimate solution will solve their problem and meet their objectives. Developers need to understand how to design and build the final product. The testing staff needs to be able to find and remove any defects the product may have. Change managers (Human Resources staff, consultants, business managers, etc.) need to understand how the end product will affect the organization. If a requirement is not clear, some or all of the components that comprise the product could be defective. To that end requirements must be clear and unambiguous, consistent, complete, concise, and confirmed (validated and verified). They must also be testable and traceable. Here are some tips to make requirements “good.”

  • Describe what is needed rather than how the need will be implemented.
  • Use units of measure or specific words to reduce ambiguity. So, “less than five seconds” is preferable over “fast,” for example.
  • Use a glossary to reduce ambiguity. As new stakeholders become involved over the life of the project, a glossary can prevent misinterpretations and increase productivity. It is also helpful to include an acronym reference list with the glossary for easy access to those acronyms.
  • Keep sentences concise and simple in relationship to number of words and grammatical structure.
  • Organize and group requirements into a hierarchical list, with high-level requirements broken down into sub-requirements as they are uncovered.
  • Uniquely identify each requirement. Use a hierarchical numbering system (1.0, 1.1, 1.1.1, 1.2, etc.). Such a scheme can be used to more easily trace requirements (see below).
  • Remove redundant requirements or clarify requirements that seem similar but are really unique.
  • Use graphical models, diagrams, and prototypes where appropriate.

 Traceability

Requirements traceability is a structured way to keep track of requirements. Requirements are traced back to their source, to themselves as detailed requirements are discovered, and throughout the project. Tracing requirements back to their source is sometimes called backwards or upwards traceability and involves linking requirements to the identified business problem, business objectives, and project objectives. Figure 1 illustrates the concept of backwards traceability.

Elizabeth_Larson_Figure1Figure 1 – Backwards Traceability 

 

Tracing requirements throughout the project is called forwards allocation or forwards traceability and involves documenting the linkage between the requirements and other requirements, and requirements to the design, development, testing, and deployment work products. Figure 2 illustrates the concept of forwards traceability.

 Elizabeth_Larson_Figure2Figure 2 – Forwards Traceability

 

Requirements traceability aids requirements management by ensuring that each requirement:

  • Adds value. By tracing each requirement, its value in helping the organization solve its problems and meet its objectives becomes apparent, thus helping the organization focus on doing all the right things and only the right things.
  • Belongs in the approved scope. Requirements that cannot be traced do not belong in the project. Scope management is one of the biggest project challenges, so traceability is a useful tool in controlling scope.
  • Is actually delivered at the end of the project or project phase. Once the right requirements have been identified and agreed upon, it is important to ensure that all the pieces needed to satisfy those requirements are designed, built, tested, and delivered.

Traceability also aids in determining impacts and interrelationships, so that:

  • The cost of each requirement and requested changes can be more easily estimated.
  • Testing coverage can be planned.
  • Risks can be more easily identified, and a risk response plan developed.

Traceability Tip

Use traceability to help ensure that each requirement is linked with project deliverables, project objectives, business problems, and business objectives, thereby preventing rogue requirements from sneaking into the project.

Managing Changes

An important part of requirements management is handling changes. During requirements planning, processes to handle changes are established, including who requests changes, who authorizes them, and who vetoes them. The “who” might be an individual, or it might be some type of change control board. Once the change process is approved, it is necessary to follow it. The approved process depends on the business analysis approach taken, and might vary from project to project. For example, the process for handling changes on an Agile project might well be different from a traditional project. Regardless of what that process is, however, it must be communicated and agreed to by affected stakeholders.

Summary

We have looked at a few of the key ingredients in managing requirements. They included planning tasks of determining the approach and creating the requirements management plan, which needs to be appropriate for the business analysis effort. As we do the business analysis work, we document “good” requirements in the format and to the level of detail required for the project at hand. Finally, to help control the scope, we trace requirements and manage changes.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) 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).