An observation of project management practices in various industries confirms that in many instances the scope management in general and scope definition in particular ends to be viewed as exclusive technical areas, which leads to several of very legitimate questions frequently asked by many of my colleagues:
- "If the project manager is to lead the project should he also lead the product definition stage?"
- "If scope size and complexity have a direct impact on project timing and budget, shouldn't the project manager be aware - at least a high-level - of how the technical team arrived at the current scope in order to be able to make trade-off decisions?"
- "Our engineers (designers, developers, architects, etc.) are very good at design, but not very skilled at interacting with customers and extracting the requirements from them. What should we do in this scenario?"
Finally and most importantly, what about enterprise or multidisciplinary projects? With the size and the complexity of projects growing it is not unusual now that the project scope encompasses the entire organization. Let us look at a couple examples from different industries. Note to the reader: these are the two of the five projects we will analyze in detail and create project scope management documentation for throughout this book.
Port Authority - The Container Terminal Construction Project
The first one is the - as it was initially labeled by the senior executives - "construction of the new container terminal" project. The logic at the top of the port authority literally was, "since this is a construction project, there is no need to worry on our end; we will just outsource the construction part to the contractor."
But a very quick analysis discovered the following situation (see Figure). The organization consisted of multiple departments including real estate, public relations, legal, marketing, planning engineering IT, logistics and security divisions to name just a few. It turned out that each one of these departments had its own portion to contribute to the overall larger scope of the project. In other words, real estate department had to purchase the land required for construction. They had to perform this task in close collaboration with the legal department that made sure no local laws or by-laws were broken. PR department was responsible for working with federal, state and municipal governments to communicate the plans and the progress of the project and to ensure that their interests are considered in the project.
Furthermore, the marketing department representatives had to start their "cheerleading" dances for their Asian partners in order to promote the yet-to-be-built port facility. In the meantime, the planning division had to oversee the design of the new facility and pass it over to the engineering department that would be responsible for finding the contractor and monitoring him during the execution stage. At some later point, the IT specialists were supposed to set up the entire network in the new building including hardware and software. And finally, the security people had to ensure that the new facility conformed to the federal government's security standards.
So, here is the key question: is this really "just a construction project"? And since it is obviously not, what techniques, standards and methodologies should be used in capturing the scope? Should the project manager utilize the engineering or architectural standards? But they are not very suitable for documenting the IT or marketing requirements ... Or should each department write its own separate scope document? But in that case is there a chance of dependencies between different scope elements that will most likely overlooked if the requirements are captured in different documents and are written in different "languages"? For example is it possible - let us consider the most primitive example for simplicity sake - that the server room designed by the architects will be of inadequate size and/or design for the needs of the information technology people?
This is an excerpt from my new book “Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects” that is being published by CRC Press The book should soon be available on Amazon.
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.