You know that you should not be up this late because you have a meeting with your project team first thing in the morning. But you simply cannot put the book down. The latest novel by your favorite author is one of the best you have ever read, and you are so deep inside the protagonist’s head that you lost all track of time. It is the turning point for the main character, so you sigh deeply and concede that you have to read just one more chapter.
As you finally put the book down and rest your head on your pillow, you think about how well the author lays out the characters and plot. Being an avid reader, you recognize that this particular novel is written in third person omniscient point of view. The thoughts, desires, needs, and motivations of the characters in the book are all there for you to examine and absorb. With this point of view, it is easy to relate information about and between each character in the story. When any novel is weaved in such a way that the reader gets lost in the pages, when he or she understands each character’s plans and goals, and when there is insight into potential outcomes, the writer has done his or her job well.
As project managers, our objective is not to present a best-selling novel to our stakeholders, but we should be creating well thought-out and complete (as possible) requirements documentation as if we are writing from the third person point of view. It is up to us to make sure that the requirements are in tune with each of the stakeholders’ desires and needs and, of course, what the project goals demand. To accomplish this, we must get inside their heads to make sure we understand the thought process behind the requirements.
In the PMBOK® Guide a requirement is defined as “a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.” It is important to note that just like many things in business (and in life) one person’s definition of satisfying a need may be a lot different from another person’s.
Achieving an as-perfect-as-possible requirements document takes time and effort, and like writing a novel, this part of project management, in my opinion, can be an art. Just as a writer might have several drafts of his book before it is ready for publication, so too will the PM have a requirements document that may go through several iterations before the final version will be circulated to the team (and even final versions can be subject to change). Each requirement needs to be dissected and assessed to determine if any errors in assumptions or conflicts between individual stakeholder input exist. Key in this requirements gathering process is that the project manager has a good understanding of what each one means. You do not need to be a subject matter expert, but you do need to have a high-level understanding of the requirements. Make sure you ask your stakeholder enough questions if you do not grasp the purpose of the requirement so that you can document it accurately. In other words, get inside the stakeholder’s head to extract exactly what he means, not just what he says. Make sure it aligns with the project charter and scope, and insure there is a clear vision of how it fits in the plan. Everyone, not only the stakeholder, should be able to understand the purpose of each requirement.
If conflicts arise between what one stakeholder requires and what another stakeholder desires, a good course of action might be to meet with both of them to discuss the nuances and come to a common ground. Resolution may not come at once, but the conflict must be addressed as soon as possible. The solution may become apparent while creating the cost or risk management plans; or perhaps it is a time or quality concern that will dictate how to proceed. It is possible that a conflict will not be fully resolved until the proof of concept phase. It is in everyone’s best interest to try to resolve issues while insuring the best possible outcome. But keep in mind, that while stakeholder “A’s” requirement may have initially been deemed more in line with the project goals, since requirements management is iterative, it could happen that Stakeholder “B’s” requirement may turn out to be better suited to the project.
Ultimately, it is the PM’s job to make sure that all documented requirements are clear, concise, and achievable. Each stakeholder and project team member should be able to read the document and envision how each requirement contributes to the project. It should be apparent that the PM has put in the time and effort necessary to develop the requirements story that will engage the team and propel the project to a successful outcome.