Skip to main content

Tag: Lean

The Agile BA: In Search of the Elusive MMF

FeatureArticle Jan15 GalenMany agile teams are familiar with the requirement artifact called the User Story. I often teach agile requirements in organizations and my favorite analogy for the user story is a lightweight use case on a 3×5 card. I tell everyone it’s not a ‘good’ analogy, but it does work for envisioning. Another way to look at a user story is that it defines an “executable chunk” of functionality that can be completed within a team’s sprint interval. So that bounds the story in size and complexity. It also dictates that it needs to be demonstrable in the sprints’ review; supporting a done-done state.

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be VALUE-ated by the team or customer. I frame things in terms of themes of stories, which is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic or collection level, it greatly simplifies your prioritization. It also has more meaning from the customers’ perspective; since they tend to think in terms of features or workflows and not the more granular stories[1].

A variation on this theme (pun intended) is the Minimal Marketable Feature/Product or MMF/MMP. This concept originated in the Kanban and Lean communities. Eric Ries also explore it quite a bit in his Lean Startup [2] book. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF/P is larger than a theme. It could be equivalent to a Larger-scale Epic Story and require many sprints and/or teams to complete. However, once completed, the team will usually physically deliver the MMF/P to the customer; for example, pushing it into a production environment.

MMF Driving Synchronization and Clarity

Recently, I’ve been coaching teams that are struggling with their focus. There’s an anti-pattern that affects many teams where they start sprinting before they understand the business case and intent for their release(s). Sure, they’re delivering a continuous flow of stories. But they don’t necessarily understand the minimal set of functionality that their customers are looking for so the usability and cohesive value can be missing.

Not having this clearly articulated up-front becomes a fundamental problem for them. Quite often their customers have an expectation of delivery that are quite different from what the team is sprinting towards delivering. Consequently, there’s no collaborative clarity around what the MMF or MMP is between the team and the stakeholder.

One nice way to connect the two back together is to establish a view towards each releases’ MMF. Part of defining the MMF is the round-trip discussions that occur as the teams estimate and/or size up the stories and features within the MMF. The customer reevaluates whether they truly need that functionality given the investment of time. This collaboration dove-tails quite nicely into release planning, which I’ll be discussing in more detail in future articles, as the team narrows into fitting the MMF into a specific release window.

I’ve even seen multiple sorts of MMF’s developed for release planning; for example, a UX MMF that tries to capture usability and interaction flows vs. the cost of implementing them. Or, similarly, an Architecture / Refactoring MMF that tries to guide these sorts of trade-offs within a single or series of planned software releases.

MMF or MMP Simplicity

When a team is defining their minimal marketable feature or product, I want it to fit on a single sheet of paper. I’m looking for the elevator pitch or ‘essence’ of the product to be described.

I often ask for what needs to be in the product to be defined, but also what doesn’t need to be in the product. Occasionally, I use a “What’s IN versus What’s OUT” chart to get the point across. It defines the must haves and the must not haves for the MMF (or MMP). It turns out the crucial part of the chart is the gray area in between these two dimensions and the discussions that surround understanding the minimal set of functionality. 

Often features will move back and forth. Features will get broken down and some aspects move from one column or the other or they are removed entirely. These are usually quite dynamic and potentially heated discussions as the teams are pushing back on what’s feasible and the stakeholders are demanding more. The common denominator in the discussions is priority and value; trying to keep everyone focused on what’s truly important to solve the customers challenges.

So, no Gold Plating or Wishful Thinking allowed!

Let me give you an example to help illustrate this concept. If we were doing a simple collaborative white-boarding tool for agile teams, the following example in Figure 1 might be a reasonable MMP definition to start discussions across your team.
Galen Jan15 Img02Visually as we added something to the left, we’d need to either de-scope something or move it off to the (white) or (gray area) for further discussion. They are an implied BALANCE within the chart; that is the work detailed within the MMF is feasible for the team to deliver. And you might ask—who determines where it’s feasible? Why, the team themselves!

Caution: There is Minimum. Then there is Viable

There’s a wonderful Harvard Business Review blog article where David Aycan discusses additional nuances associated with the notion of an MMF. He makes the point that quite often today, in our fervor to hit the ‘minimum’, we over-simplify features and products and lose customer and business viability.

I haven’t seen this pattern that much myself; I usually see the reverse, or teams incessantly trying to build “too much”. But, he connects it to Eric Ries’s Lean Startup work and I have been around enough people who are passionate about those ideas that I can see it happening. Regardless, I’d recommend you read his post. 

I think the key is for us to focus on minimal and viable as much as possible when we’re framing reactions to our customers’ needs.

Finally, a Trip to MoSCoW

I first encountered the MoSCoW method for prioritization within the DSDM agile methodology . DSDM lies within the agile family of methods, but is nearly unused in North America. It is much more popular in Europe and leveraged mostly for traditional, larger-scale projects. It has some interesting dynamics that are similar to RUP-style methods.

MoSCoW prioritization is a technique for breaking requirements, or stories & features, down into four specific categories for consideration, discussion, and execution. They are:

  • Must Haves – will not release without these features and capabilities being present
  • Should Haves – high priority features
  • Could Haves – moderate priority, fit if time allows, but deferrable
  • And Won’t Haves – features negotiated out of this release for now

When prioritizing your backlog, it helps to place these four ‘buckets’ on a wall or table and to visually discuss and move stories around from one to the other. 

Many groups come up with some sort of ratio that helps with this. For example, out of 100 stories, perhaps only 10-20% should effectively be Must Haves and 20-30% might be valid Should Haves. This gives you some general guidance on how to compose stories into an MMF or, more often, an MMP definition.

You might want to try Moscow as a facilitative technique when you’re prioritizing. My experience is that it helps to drive discussion and encourages the team to wrestle with truly “must haves” versus everything else.

Wrapping Up

There is never enough time nor sufficient team capacity to do everything. Yet, today’s leaders always seem to be pushing teams beyond their abilities; creating unhealthy tension and the possibility of team’s disastrously committing to more than they are capable of delivering.

Instead, the notions of Minimal and Marketable help teams and stakeholders define a clear set of value-based functionality that can be negotiated before committing to a release plan. Another attractive aspect is that they form a ‘baseline’ understanding that can be adjusted based on the teams challenges and changing business needs.
Whether you are part of an agile project or not, consider leveraging MMF’s as part of your project chartering and commitment processes to focus in on the minimal set of customer expectations that still provide high value.

Thanks for listening,

Note: parts of this article are inspired by Bob’s forthcoming 2’nd Edition to Scrum Product Ownership: Balancing Value from the Inside Out, which will be available on Amazon in early March 2013.

Don’t forget to leave your comments below.

[1] A common anti-pattern is for teams to break stories down into too finely grained units. For example, only having 1-2-3 point stories. The intent is to have fine visibility, but the effect is to get lost in the ‘weeds’ and lose the big picture of the sprint and release.
[2] Eric Ries, Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

Elements of Requirements Style, Part 3

One of the most common types of requirements problem is missing information. Either entire requirements could be absent—which are hard to spot, being invisible—or individual requirements are missing information that help make them fully comprehensible. In this article, the third in a series of four, I’ll present some examples of both kinds of problems, along with some recommended solutions.


When requirements lack important bits of information, it’s hard for all readers to interpret them in the same way unless they make precisely the same assumptions. For instance, a functional requirement might describe a behavior without identifying the triggering cause that leads to that behavior:

The system shall generate an error report and forward it to the user.

This requirement doesn’t identify the stimulus that leads the system to produce the error report. Another common mistake involves missing descriptions of how possible exceptions should be handled. In the previous example, what should happen if no errors occur during the processing being described? It’s unspecified, thereby leaving it up to the developer to decide what to do. Options include:

  • Do nothing (an assumed default perhaps).
  • Present a “Congratulations! No errors found.” message but do not generate a report.
  • Generate an empty report and forward it to the user.
  • Generate a report stating that no errors were found and forward it to the user.

Perhaps we add the following requirement to address the case in which no errors are encountered:

If parsing is successful, the system shall not generate an error report.

This is another description of the system doing nothing, though, as I discussed under “Negative Requirements” in a earlier article in this series. It would be better to state what the system will do if no error is encountered, even if it is to simply continue the processing.

Another kind of incompleteness occurs when requirements describe system behaviors that involve some type of symmetry. Suppose you’re specifying the functional requirements for a bookmark feature in a Web browser. You might say:

The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.

So, the user can collapse the bookmark tree, but what if he wants to expand it again? It’s easy to overlook that sort of symmetrical or reverse operation. To remedy this, either you could add a second requirement stating that the tree can be expanded, or you could alter this requirement to say “…in a collapsible and expandable hierarchical tree structure.”

If you omit the reverse operation, the customer and the BA might assume that the missing portion of the symmetrical requirement is implied. If you request an undo capability, of course you want a redo capability as well, right? But implicit requirements make me nervous. They involve too many assumptions about the knowledge and thought processes that other stakeholders must have to ensure that we all get what we expect in the final product. I know of a organization that developed its own tool for editing and storing source code in a database, with no written requirements. Unfortunately, they forgot to include the ability to print the contents of the database. The team members no doubt assumed that a printing function would be included so didn’t even think to mention it. They didn’t mention it, and they didn’t get it.


Boundary values in numerical ranges provide additional opportunities for creating ambiguity, as well as being places to look for missing requirements. Suppose you’re writing software for a point-of-sale system and you need to comply with a business rule that states, “Only supervisors may issue cash refunds greater than $50.” An analyst might derive several functional requirements from that business rule, such as the following:

  1. If the amount of the cash refund is less than $50, the system shall open the cash register drawer.

  2. If the amount of the cash refund is more than $50 and the user is a supervisor, the system shall open the cash register drawer. If the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.”

But what if the amount of the cash refund is exactly $50? Is this a third, unspecified case? Or is it one of the two cases already described? If so, which one? Such ambiguity forces the developer either to make his best guess or to track down someone who can answer the question definitively. This is an example of the BA generating an inconsistency between a higher-level piece of information—the business rule—and the functional requirements derived from it.

You can resolve boundary ambiguities in one of two ways. The previous requirement #1 could be rewritten as, “If the amount of the cash refund is less than or equal to $50, the system shall open the cash register drawer.” This preserves the original intent of the business rule and eliminates the ambiguity.

Alternatively, you could use the words inclusive and exclusive to explicitly indicate whether the endpoints of a numerical range are considered to lie within the range or outside the range. To illustrate with a different example, you might say, “The system shall calculate a 20% discount on orders of 6 to 10 units, inclusive.” This wording makes it perfectly clear that both endpoints of the range, 6 and 10, lie within the range subject to the 20-percent price discount. You still need to review a set of similar requirements to make sure the range endpoints don’t overlap, though. For example, note the inconsistency between the following two requirements:

  1. The system shall calculate a 20% discount on orders of 6 to 10 units, inclusive.

  2. The system shall calculate a 30% discount on orders of 10 to 20 units, inclusive.

The boundary value of 10 is incorrectly included in both ranges. Using a table to show this sort of information is more concise and makes these kinds of errors more evident:

Units Purchased  Discount Percentage
1-5 0
6-10 20
11-20 30
21+ 40

The final article in this series on writing high-quality requirements deals with several fiendish sources of requirements ambiguity: synonyms, pronouns, abbreviations, adverbs, and others.

Don’t forget to leave your comments below.

Capturing Implicit Requirements


A typical SDLC project starts with a requirements-gathering exercise followed by an analysis phase. During the requirements analysis phase, a detailed study is done in order to identify the different pain areas that would be addressed by the software that would be delivered. Often we come across situations, or more appropriately, business scenarios, wherein the requirements are not clearly documented.  They are vague and do not provide any clarity as to what exactly is expected. This leads to ambiguity, and finally, a software that delivers everything except what the client asked for! Unfortunately, this discovery happens during the user acceptance phase. Defects are identified that inadvertently point to requirements that have not been clearly captured/documented. A standard reaction of the business users would be, ‘We thought that this was going to be delivered…it is an Implicit requirement!’ Once we hear this statement, a typical ‘passing the buck’ game starts between the IT department and the Business Users.

This situation could have been easily avoided if the Business Analyst had taken the efforts to identify the implicit requirements. A key responsibility of a Business Analyst is to define the Scope of the system that is going to be built, and in this process, ensure that the Explicit as well as Implicit requirements are clearly documented.

Understanding Implicit Requirements

Let us begin with understanding the difference between an Explicit and an Implicit requirement. Usually, the requirements that are stated by the business users in the different meetings and interviews are categorized as Explicit requirements. These requirements are the easiest to capture. They are usually supported by loads of Documentation, or for that matter, even a legacy system screenshot!

Implicit requirements are the hidden or ‘assumed’ requirements. Business users expect these to be delivered and hence may not feel the need to explicitly mention them in the business meetings. It could be challenging to actually define the scope as there is no clear-cut documentation or boundary available. The keyword here is ‘scope’. Let us try to understand this with a very simple example:

User requirement: 

Screen to capture the following employee details:

  1. Employee number
  2. Employee name
  3. Department

Implicit requirement: 

  1. Capture Designation as well

Since it is an Employee data capture screen, the business users would assume that there is a field to capture Designation as well. This would definitely be an Implicit requirement. But is it right to assume that this is the ONLY implicit requirement?

For instance, I can add a couple of other implicit requirements, such as:

  1. Duplication check required on the ‘Employee number’ field
  2. Should have the facility to Search for an existing Employee

Here is where the dilemma starts. Some Business Analysts would totally agree with my listing of implicit requirements, but I am sure there would be many others in the Business Analyst world who probably disagree. For instance, Search facility could be provided as a separate screen, and hence that would be a separate requirement altogether.

The key point here is to recognize that capturing the implicit requirement is more of a need than a luxury.

Another example would be in a data processing centre where the performance of a data entry operator is measured by the number of entries that have been done in the system. For example, consider a typical airlines scenario wherein millions of passengers travel daily. A data entry operator in such a scene would have to enter hundreds of passenger coupons in the system and his KRA or performance is measured on the basis of the number of coupons he enters in the system. In such a scene, the Business would need a system that would capture data quickly and in a highly efficient manner. Here, the implicit need is that the data capture form has to be designed in such a manner whereby the maximum data/information on the form can be entered using the keyboard rather than using the mouse. In other words, maximum information must be enterable using keystrokes rather than using the mouse.

If this implicit requirement is missed out, then we end up in situation where the data entry operator would never meet his KRA, and looking at the bigger picture, the airline would miss its SLA. This could lead to tarnishing the airline’s image and would ultimately impact its business.

Scope Control

If documented well, Implicit requirements can be used as an excellent tool to control the scope, which in turn will lead to lesser defects and finally a Satisfied Customer! But at the same time if the boundaries for the requirements are not clearly documented, it can be misused and will lead to Scope Creeps, huge defects and a Dissatisfied customer.


This leads us to the conclusion that the Business Analyst community would have to use certain proven methods to define and bound the scope. A cost-benefit analysis will be the ideal way to deal in this situation. There may be a scenario wherein an endless list of implicit requirements inadvertently increases the cost with no visible benefits. On the other hand, it is quite possible that by deciding to incorporate minimal implicit requirements, the client would reap huge benefits.

In a nutshell, in order to ensure that the implicit requirements are never missed out, we would need to take a step back and always try to understand what exactly the Business user is looking for and if we have really understood this need. To conclude, we Business Analysts do play a role of ‘the Truth Seeker’ and thus need to unravel what lies beneath, in our quest of understanding Business requirements!

Don’t forget to leave your comments below.

Aruna Parameswaran : A technical person with 12+ years of experience who moved into a Fucntional role by choice. Working as a Business Consultant with an IT organization and have led the Requirements phase of multiple implementation projects across geographies,primarily Asia-Pac and UK with some exposure to the US geography. Have spent the last 6 years specializing in the Life Insurance domain in the UK and Asia-Pac regions

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.                                    


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.


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.


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.


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 (, 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).

Facilitating a Requirements Validation Meeting with Ease!

The Problem

 Ensuring that a requirements document is accurate, complete and fully supported by key stakeholders, can be critically important.  Unfortunately, requirements validation sessions can be protracted and challenging.  Often, the goal of the session is to gain agreement among various stakeholders on a lengthy, detailed requirements document.  This can certainly be a tall order, but it can be done! 

Consider these Suggestions

  • Ensure that all key stakeholders are present at the session. Oftentimes, senior managers or other extended team members will participate in this important session. Ensure that the meeting is on their schedule far in advance.
  • Conduct pre-meetings with relevant functional groups to work out the details, review appendices, etc. Ideally, there should be no major surprises at the validation meeting.
  • Ensure everyone comes to the meeting prepared by expressing the importance of each person reviewing the document in detail. Give the group a choice of whether to review the document in detail during the session (2 day offsite) or review it individually offline and only conduct a high level review and discuss questions during the validation session (2-3 hours). Most groups will opt for the shorter meeting.
  • Ask participants to send their questions three days prior to the session and follow up with anyone who has not sent their questions by the stated due date.
  • At the beginning of the meeting ask each person to introduce themselves and their role in case there are new faces in the room. Also, provide a high level overview of the project before getting into any detailed requirements discussion to ensure everyone has appropriate context.
  • Define any assumptions or acronyms at the beginning of the meeting to avoid misunderstandings
  • Assign specific SMEs to lead the discussion for individual sections of the document.
  • Ask for a volunteer to be the timekeeper and another to document key decisions or action items on a whiteboard or flipchart.
  • Ensure that the requirements document is well organized with prioritized requirements.
  • Post IEEE standards for well formed requirements (Accurate, Consistent, Complete, Traceable, Prioritized, Unambiguous, Modifiable, Verifiable and Testable) on the wall (or on a slide if using collaborative software). As you review individual requirements, ensure that each requirement meets this checklist.
  • Document traceability within the document and across documents.
  • Let participants know that signatures will be expected at the conclusion of the meeting. Ensure that participants sign the document on behalf of their organization.

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. a boutique professional development corporate training firm.  Her firm operates and, an online resource for meeting facilitation tips, training, and instructional DVDs.  Her latest publications are “Are You Running a Meeting or Drowning in Chaos?” and “5 Secrets to Virtually Cut Your Meeting Time in Half!”  She can be reached at [email protected]