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.

Output

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!

Conclusion

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!

Why doesn’t anyone listen to the customer?

The tired cliché about the customer always being right does not always sit well with IT professionals, software developers, or even project managers. In private meetings, I have heard many contentious thoughts expressed:

“The customer does not know what he wants.”

“The customer does not understand what he’s asking.”

“The client is stupid.”

“This client is a flake.”

Wow! What’s going on here? Part of the explanation for this “failure to communicate” probably stems from the way that requirements are often generated – especially in projects. The customer begins with a problem, a need, or an itch to be scratched by a new software solution. He presents his challenge to—usually— marketing or business development professionals who assure him that XYZ Company can make his pain go away.

I can’t help but think of the classic picture of the “Tire Swing Cartoon” that depicts the mis-communication of requirements.  How the initial requirements are created depends on who is in the room while dream and reality crash together. In all likelihood, the company bidding for the project will include project management staff in putting their bid together to provide creativity and a dose of reality—although this is often done under the duress of a fixed cost and delivery schedule.

Eventually agreement is reached on basic deliverables, schedule, and cost among these parties (with emphasis on the soon forgotten “basic” word). In the pleasure of the moment, future problems are expected to be resolved through requirements management by the PM.

The customer’s role is not over when the contract is signed, however. Most good projects call for concept demonstrations, prototypes, and beta-test versions of the software before the customer accepts delivery and the contract terms are fulfilled. It is in these feedback sessions between the users and the developers that frustrations may manifest and charges fly: why doesn’t anyone listen to the customer?

Now, don’t get me wrong, I believe the stepped process in developing, refining, and final acceptance is an essential best practice in creating software for good project management. But as the proposed solution begins to emerge and be displayed, it is typical that users will want more and want it differently. Because users are not coders or system architects, they will express their desires in ways that do not appreciate the level of effort required or the implications of what they are asking. Nor do they understand the effect on cost and schedule to comply with their requests.  Even with new software methods like Agile development, a customer is not going to understand software problems any better than they do in a traditionl project management methodology.

That’s the PM’s job. It is also the PM’s opportunity to work with the users to better understand their needs and to explain in non-technical terms how the user can get what he wants, what the changes and additions will cost, and how they impact the schedule, cost, and quality/scope (see the Project Triangle)

“Good project managers recognize that every decision has opportunity costs. If you decide to add more features, quality must drop, or the schedule must slip. If you decide to cut the schedule, features must be drop or quality must drop. There is no way around the natural tradeoffs of resources, time and quality.”  – Scott Berkun in The List of Reasons Ease of Use Doesn’t Happen (November 2002)

The PM must also be adept at translating the user’s world to the developers. He or she must listen to the customer and try to discern what is really meant by, “can I download this on-line data to a database on my notebook?”

One effective technique to gain a handle on real customer requirements is to create a “Concept of Operations” or use- scenario before a line of code is written. This user-centric step helps the customer understand what they will be getting and provides feedback to developers when the cost of change is much lower – as opposed to later in the development process. You can read Karen’s paper on “The Performance-Centered Design & Development Methodology” for more information.  Company XYZ may also find that it is very helpful in this early part of the process to call in an outside professional to facilitate the dialogue between the end-users and the developer and PM staff.

If you have any tricks or techniques that facilitate listening to the customer, please share them via your comments.  Everyone benefits from sharing good ideas.

 

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

ProjectManagement.com

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

beyondcenter

Pushing the Edges Out ...

projectxpert

Just another WordPress.com site