I remember one instance when I was teaching my “Project Management Masterclass” for the executive team of a North American port authority. The purpose of this class was to introduce this group of people to the core fundamentals of the project management science and convince them to seriously consider implementing this methodology at their organization.
This workshop has been highlighted by many interesting discussions and even heated arguments about the domain of project management, the value of planning and the role of the project manager. However the most interesting – at least in my humble opinion – exchange took place when I started describing the “dos” and “don’ts” of requirements gathering and analysis:
Me: When documenting requirements the project manager should always make sure that words like “fast”, “acceptable”, “efficient”, “flexible”, etc. do not appear in project management documentation.
COO: And why not?
Me: Well, you see, although these words are perfectly acceptable in “normal life”, they are considered to be ambiguous in the domain of project management …
COO: And?
Me: OK, let me share a very simple example with you. For instance, if the requirement states, “The car shall be fast”, it can later be misunderstood by the project stakeholders. Some of them will think 100 km/hour is fast enough, while others will insist on a speed of 300 km/hour. And yet, another group will ask for a speed of 500 km/hour. This will most likely create an unnecessary confusion and lead to conflict in the middle of the execution stage of the project.
COO: But we always use these words in our documents!
CEO: (interrupting the COO) Do you, guys, remember what happened on our recent “New Cruise Ship Terminal” project? We claimed in the project charter that we would build a state-of-the art facility and let that word slip into all other documents …
Me: And what happened?
CEO: We had several stakeholders on this project: ten cruise ship companies, federal, provincial and municipal governments and the port authority itself obviously. Do you think all these fourteen stakeholder groups had one opinion about what “state-of-the art” means or fourteen different points of view? Cruise lines were keen on automating all the processes, federal government focused on extra security, provincial government worried about the impact on the environment and the municipality demanded energy efficiency and sustainability. And all of these features had to be state-of-the-art! We went $200 million over the budget trying to please everybody …
What lessons can be derived from this exchange? First, always try to avoid including such words in the project documentation. Second, if your stakeholders continue insisting on this terminology, always challenge them with a simple question:
“When you say <ambiguous term>, what exactly do you mean?”
If the person knows exactly what he or she wants, they will undoubtedly explain this to you. On the other hand, if the word in question was used just to appear witty, the stakeholder will most likely drop that demand.
And finally, do not get upset if you feel like you are under a constant barrage of ambiguous terminology when eliciting requirements from your project stakeholders. It is your job as a project manager (or a requirements analyst) to identify those words and ask for the clarification.
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.