If you ask a person studying for a PMP exam, what is the most important area in the domain of project management, the correct answer is "communications". After all it has been documented that on average project manager spends up to 90% of his/her time performing communication activities such as conducting meetings, writing project documents and potentially eliciting requirements via one-on-one interviews.
While I wholeheartedly agree with this notion, I tend to think that the domain of communications is a bit too general to be designated as "the most important thing in project management". I would like to offer to look at this issue from a slightly different perspective:
If you were allowed to write just one project document on your project, which one would you choose?
My answer to this question is the “Requirements Specifications Document”. While some of you may vehemently disagree with me and mention Project Charter and Project Plan. But let us just think about this for a while. The domain of project management is divided into ten knowledge areas (see Figure 1)
Figure 1
Let us examine the impact of scope on other knowledge areas:
Time Management: If you don't have a detailed requirements document can you develop a work breakdown structure and create a network diagram (project schedule)?
Example: The project can take way longer if the customer decides to add a “swimming pool” feature to his villa design.
Budget Management: Can you create a detailed project budget - including human resources required and expenses on equipment and materials - until you have a baselined requirements document?
Example: Will the customer choose a $5-per-square-foot type of flooring or a $150-per-square-foot one?
Quality Management: Can you define the acceptable quality levels and tolerances until you know all of features of the product?
Example: Can you plan the quality management process for the new adjustable car seat until you know all of the required features?
HR Management: Can you predict what kind of professionals you would need on your project team?
Example: Will the customer decide to create a garden around his house? As a result will you need a landscape specialist?
Risk Management: Is it possible to identify all of the risks on your project until the requirements document is finalized?
Example: Will the company make a decision to change the standard operating procedure and, as a result you will be facing a risk of employee resistance?
Communications Management and Stakeholder Management: Can you identify all of your project stakeholders (including your own team members, external consultants and suppliers to name a few) before you decided on a definitive set of features?
Example: Will the new system affect the supplier invoicing process? As a result will you have to add A/P representatives to the stakeholder register?
Procurement Management: Will you be able to identify all of your suppliers?
Example: Standard kitchen refrigerators can be easily purchased at multiple retail locations, while a specialized high-end ones need to be ordered ahead of time.
So here is my question:
If you were allowed to create only one document on your project, which one would you chose?
- Project Charter
- Requirements Specifications Document
- Project Plan
- Something else
Please leave your opinion by posting your comments below.
About the Author
Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca
- Please follow me on Twitter:
- Like our page on Facebook:
- Connect with me on LinkedIn:
- Subscribe to my RSS feed:
Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.