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."