Hosting a Successful Requirements Meeting

Arguably, one of the most important phases of a project — getting everyone on the same page – occurs during the requirements meeting(s). The meeting with staff to develop the project requirements is the culmination of the initial effort to create a project charter, scope, schedule and budget. The work of deciding how to get from nothing to accomplishing project goals happens through the process of the requirements meeting.

Now I am not talking about the “high level requirements” that organizations use to get a project approved (And unfortunately sometimes sent out for bid).  This level of requirements is more for bounding and high level scoping – not useful if you are trying to actually define a set of tasks or detail out the what and how of the project.  High level requirements are great for preparation.

We used to joke – sometimes with more than a smidgen of truth – that the project manager would tell developers to begin coding, while he or she went off to find out the project requirements. However, having been dipped in the sacred waters of the “Guide to the Project Management Body of Knowledge,” we know now that collecting requirements falls under the process of Project Scope Management, as part of developing the Project Management Plan.

Preparing for the Requirements Meeting

Clearly defining the detailed tasks needed to complete modules, add functionality, or build a system begins with the vision of the project’s outcome, tempered by the reality of time and budget. Next, the top-level objectives that drive the requirements are defined through a process that involves all stakeholders – clients, users, senior management, organizational strategist and key project staff.

Assuming that the organization has not already documented the high level requirements, you can use several tools and techniques to gather objectives and top-level requirements. I have found that “scenarios of use” and “use-cases” work best with most stakeholders because they help crystallize vague objectives into understandable activities. Process maps, flow charts and decision trees can be used effectively with developers.

The project manager’s goal in conducting these pre-requirements meetings is to create a coherent list of high-level requirements that will be presented to the development staff to create the detailed project requirements.

Running the Requirements Meeting

First off, let me warn the new project manager that the requirement meeting is rarely a single event. Depending on the size and complexity of the project, multiple meetings should be anticipated. Before the meeting, provide all attendees with the information distilled from the interviews with users, customers and other stakeholders including comments from the scenarios. If your project has a Concept of Operations, that should be added to the pre-meeting review materials.

Break the meeting up logically using either the project work breakdown structure or development modules. Make sure everyone is comfortable, has available linked communications, notepads or sticky notes and a projector, whiteboard or electronic white board to capture ideas and decisions. Then, like Alice in Wonderland, begin at the beginning, continue through to the end, and stop.

Unlike Alice, though, project managers should plan to iterate at least once more through all steps to assess and integrate the impact of later decisions on initial ones. PMBOK suggests applying group process optimization techniques such as facilitation, group decision-making, and breaking up into small groups with timed feedback requirements. The requirement’s meeting is done when everyone understands what the detailed requirement are and how meeting each detailed requirement integrates toward a task and deliverable in the WBS. Developers should have a general idea of how to approach each task and understand the operating environment for both coding and execution. They also know how success will be tested.


The result of the requirement’s meeting is a document, a requirements management plan and a requirement traceability matrix. The requirements document should be dated and versioned, as updates may occur based on change requests or risks realized during execution.  Now you have a baseline of scope for the project!


While no two projects are the same size or complexity, they all have “scope” and requirements as a common element.  You may have to tailor the steps or process to fit your project size, but don’t short change this critical step when doing
a project.  Many a PM has been wounded in battle because they didn’t take the time to get the requirements right!

5 Responses to “Hosting a Successful Requirements Meeting”

  1. Jim Yates - Fulcrum UK Says:


    A very useful post, particularly as it addresses an stage where projects often go wrong. It is very difficult to recover if you set off on the wrong foot!

    It is also important to bear in mind that different groups / specialisms may use the same words in different ways and have different understandings of specific aspects of the scope. [They have different mental models] Care is needed to tease out these differences as they are often the root cause of subsequent problems. Similarly, some groups may defer to those they believe have more relevant knowledge in a particular area – this is one of the ways in which you get “The Emperor’s new clothes” Syndrome. My blog post covers some of these issues.

    One thing which is clear to me is that PMs need excellent facilitation skills and this is often overlooked in their training.

  2. Automation Centre (@Acentre) Says:

    One more thing I’d suggest for discussion during a requirements meeting is the value of the project, how its success ties-in to organizational goals. If everyone in the planning group is on the same page as to the ultimate purpose of the project against company objectives, it eliminates misunderstandings, facilitates planning and helps minimize potential scope creep.

    Joe MacNish

  3. deepak Says:

    Thank you for another useful post, specially for people like me who are yet get enough experience on project management. In my situation, I get the projects once they pass through sales people and Solution Architects. It becomes really necessary for me to hold initial meeting with customer’s “point of contact” and involve my technical resources to understand the tasks to be performed. I got some points that I can follow.

  4. Sunshine systems Says:

    A very useful post, particularly as it addresses an stage where projects often go wrong. It is very difficult to recover if you set off on the wrong foot!

  5. Project methods – Waterfall versus Agile « Fear No Project – A Project Management Blog Says:

    […] a fatal flaw–they depend on accurate requirements. The problem with this dependence is that requirements are often wrong. He discusses giving teams the ability to work with clients to find out what the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site

%d bloggers like this: