Is it the responsibility of a project manager to gather requirements for a project? The answer would be NO if you lived in a perfect world. However, not too many of us live in a perfect world. So, the answer is a definitive…Yes, No, Sometimes, Maybe, Never, and It Depends.
There’s really not a black and white answer to the question of whether a project manager gathers requirements. It can vary from company to company and depends upon the number of resources available, the skillset of these resources, and even the culture of the company. This article will talk about project management requirements gathering and provide a basic understanding of how the requirements gathering process works.
Should a Project Manager Gather Requirements?
This is a bit of a different question than if it is the responsibility of a project manager to gather requirements. The question is really SHOULD a project manager gather requirements. In the purest sense of requirements gathering it is not within the wheelhouse of a project manager to gather requirements.
Think about project management and the project managers you know. They are typically date driven, collaborative by nature, and rally the troops toward reaching a common goal.
Business analysis and requirements gathering require a different skill set. Requirements gathering involve the person lingering a bit longer than others would. It requires that they probe deep into the problem or conversation at hand and uncover every possible scenario, regardless of how small or inconsequential.
You can see this dynamic at work when there is a project manager and business analyst assigned to a project.
The thing about project management is that it is deliverable and date based. The project manager will push the business analyst for a date when the requirements will complete. The business analyst’s response is that they have just one more person, or meeting, or requirements session to go through before they really feel as if all requirements have been captured.
In an ideal situation a Project Manager would not be used to gather requirements. Requirements are about comprehensiveness. Project management is about movement within previously defined parameters of scope, cost, time, and quality.
Despite this fact, many project managers will find themselves in the unenviable role of playing an ad hoc business analyst tasked with gathering requirements. It could be that the company is short-handed, or that the BAs have been pulled over to another project. Or, there could have been requirements that were missed early on and the path of least resistance is to get the project manager to fill in the blanks.
One thing about project management is that project managers are a versatile bunch. They’ll dig in where there’s a need and do what they can to help out. The following is a guideline of what you can do as a project manager if you’ve been tasked with this activity.
There are four main steps that must be undertaken in the requirements gathering process. These are:
- Gather Information: Information gathering is the process of uncovering as many sources of requirements as possible. This includes identifying the current users, future users, and even past users of the product or process.Find out what they liked, didn’t like, or didn’t use about the product or process that is looking to be improved. Identify those who are removed 2 – 3 times away from the direct users.For example, is there an executive that uses a report that a direct user of the product or application produces? Is there an interim system that needs to consume the data that the product or application produces?These are all things that must be taken into consideration to make sure there is not one stone left unturned. It’s a sad thing to get to the end of a project and realize that a particular stakeholder group was overlooked and their needs were not met.What is the best way to gather this information? There are a number of ways that range from one-on-one conversations to large groups.
One of the most effective ways of gathering requirements is to have a room of about 10-12 people that represent different constituencies that are stakeholders of the product or application. One thing about project management is that it forces us to be in front of people on a regular basis, so this shouldn’t be too much of a stretch.
Throw up a screen with a projector or get the over-sized pads and easels with adhesive on the back. Have everyone come up with their ideas as to what needs to be done to either start, improve, or fix the product or process that is being discussed.
Record these on your laptop or on the over-sized adhesive pads. You’ll begin to a see a theme develop of people’s needs and concerns. Once you’ve heard the same concerns repeated 2-3 times you are now in a position to start prioritizing the requirements.
Ask everyone in attendance to force rank what is the most important on the list they just produced. Start with the Top 3 – 5 as you move into the next step.
- Convert into Requirements: The next thing to know about project management requirements gathering is to convert the needs identified above into actual requirements. This may involve further conversations with those who identified the Top 3-5 items discussed above.Use tools that you have at your disposal such as creating process flows, swim lane diagrams, or other software tools you use when you learned about project management.Create the requirements in a way that is easy to understand and grasp. Anybody can make something extremely complicated and hard to understand. It takes true genius to take the complicated and make it graceful, elegant, and easy to understand.Think about project management and how complicated it was until someone took the time to break it down for you and explain it clearly. Do the same with your requirements.
- Document in a Tangible Way for Easy Approval: The next step that needs to be taken once the requirements have been established is to compile it into an easy-to-approve document. This document should consist of what you heard from the sources that provided you with the information at the outset.Show how this converts to the requirements that the rest of the solution, and ultimately the project, will be based upon.
- Test the Requirements: The final step is to test the requirements to verify everything has been captured. This is similar to testing a product or application to make sure all the functionality that is supposed to be there works.Have the experts vet out the requirements to ensure to a high degree of certainty that nothing has been missed. You now have the basis for a solid set of requirements that will serve as the rock solid foundation for the rest of the project.
It’s less than ideal if a project manager concerns himself with requirements gathering rather than project management. But, there are going to be those times when you have to step up as a project manager and fill in those shoes. You just have to realize that you are now wearing a different hat and need to look at things a bit differently.
Mastering this skill will allow you to not only become a person who knows a lot about project management, but can help the requirements gathering process as well.
Try ProjectManager.com FREE for 30 days and you’ll be pleasantly surprised how much we know about project management. As a matter of fact, Jason Westland, ProjectManager.com’s CEO wrote the book on Project Management! He wrote the best-selling book “The Project Management Lifecycle” and is an author for “CIO”, “Computerworld” and “Channel World”. He also authors the “Project Management Advice” bi-weekly newsletter which is read by 1 million people around the globe.