How do requirements for products and other project deliverables get defined?

I thought I was supposed to get a full set of requirements from one group, but instead it seems like that group only cares about a couple of elements. How do we create a full set of requirements that will make all the customers of this project happy and show the rest of the team what to do?
Sometimes the point group that is the logical source of product/deliverables requirements (such as a particular business group, or marketing) does care more about a limited number of aspects, and maybe the small set of items they're harping over doesn't make total sense to the team. (Could the color of the box really matter that much? Or what do they mean, "Just make it competitive with what Company X's product does"?) The reality is that you may or may not get a full set of project deliverables requirements from anyone. And as project manager, you should be making sure you believe that all the right customer-facing people have had input to the project requirements.

So what do you do? This is what the project kickoff process during Initiation should be used for. Take the bull by the horns and pull together your initial core team, including your customer representatives—whoever it is that understands what the customer wants, and what the company wants to accomplish with this project. The core team members should include a cross-section of those who work directly with the customer (Marketing, Sales, Service, a business group, certain business analysts, the lead sales guy, the executive who wants this project done), those who will develop the "product" (engineers, technologists, designers, any group that is developing the main contents of what this project is creating), and those who will support the main creative team (Quality, Operations, etc.). Pull this team together to discuss the requirements of the customer and the business.

Hold this "kickoff meeting" early in the project. It can be structured using our Project Kickoff Meeting Agenda and Guidelines. The goal is to focus the effort on developing the top-level requirements for the project's main deliverables. Start this meeting with an overview of the business objectives and the proposed outputs of this project, so the team understands the context. Some companies create high-level Business Requirements Documents (BRD) or Marketing Requirements Documents (MRD) early on, as part of proposing a new project idea, to capture all the things the customer-facing groups think may be needed. If your organization has such documents, they could be sent out ahead of time and then brought to the kickoff meeting for reference. Other organizations don't create these documents until after a Project Charter exists. Whatever the case, those documents are a logical step in the requirements process, because they lay out the next level of detail of the customer-facing groups' view of deliverables, important scope or functionality, etc.

The outcome of the kickoff meeting would be a draft Project Charter or Project Vision document that gets specific about the deliverables the project will create, and suggestions for updates to the BRD or MRD if those documents were brought as reference. That info won't be enough for everyone to take off and implement those deliverables right away; you still have detailed requirements definition to do for each deliverable. But the kickoff sets up that detailed requirements generation properly. The team has discussed the project's objectives together, why those objectives call for certain deliverables to be created, and, at a high level, what those deliverables must do or contain. By the end of the Initiation phase, the Project Charter reflects the team's first cut at what set of deliverables this project will actually take on. (It may not be everything that got asked for initially!) That list will likely get refined during the planning stage.

The team can now go forward in the planning phase, to specify requirements for each deliverable in more detail, investigate different ways to implement them, make decisions, and create a project plan. The format for the detailed requirements will of course vary greatly depending on what the project is and what those deliverables are. Examples of different requirements documents are shown in our Product Requirements Specification, Software Requirements Specification, Technique Brief: Requirements Cards, and Use Case Specification.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.