I have always believed that for a project someone, either on the client side or on the contractor side, must know the complete scope. As an estimator, I always try to acquire a complete understanding of the project by identifying a Scope of Work document or, if that is not available, then speak to several different people to get a better understanding of the scope. I am constantly surprised by how vague most documents are about scope, and how nobody ever seems to know the complete scope.
The following could be a typical situation in many cases:
Client’s Team: Everybody in the client’s team thinks that the contractors are the professionals, so they must know the scope.
Contractor’s Team: Contractor team members think that the client knows what they are paying for and so the client team members should know the scope.
Project Managers: Most Project Managers, instead of being managers of projects are mostly managers of people. They think that if they can get the right team, the project can be executed.
Project Engineers: They act like mini-project managers, and they too end up managing others without trying to grasp the technical scope.
Procurement Team: Procurement personnel are mostly concerned with placing a contract or purchase order and believe the scope to be the purview of the technical team. They go through the whole procurement process without ever understanding the real scope as such.
Coming to the technical team, it is even more surprising. Every discipline somehow does their bit but are never sure what the overall scope is or what the boundary limits are. Process engineers do the basic design, equipment list, process flow diagrams, but, for example, they may not be sure whether supply of all chemicals are in the scope of work. They may also not be clear what additional non-process equipment might be needed to complete the project. Electrical, instruments, civil, mechanical discipline engineers similarly provide their part of the basic design and item list, again most being oblivious of the complete project scope, some even missing less obvious items related to their own disciplines.
Many interfaces between the various disciplines are sometimes missed. A good example would be the cable trenching – the electrical discipline would not include it and say it is the civil group’s scope and the civil group might sometimes miss it saying the electrical discipline should consider it. Similarly, actuators on piping valves go missing as it could be either a piping item or an instrument item and sometimes both disciplines either omit it from their scope or both include it and there could be a chance of double dipping of scope and hence cost.
Finally, when the overall design comes to the estimator from the various disciplines, the information when added together generally does not complete the picture. Most estimators complain that the scope to be estimated is not clearly defined, and therefore they very promptly proclaim that the accuracy required of the estimate cannot be achieved.
The basic idea behind this complaint is that the estimators will, in isolation, produce an estimate for a defined scope and would have no role to play in defining the scope. I think, in some situations, where coincidentlly no other person is joining the dots, the estimator can step up and help in this aspect. Estimators are responsible for bringing it all together anyway and come up with a number to bid or set a budget. Therefore, they do somehow have to know the complete scope, even if some of it is based on similar projects executed in the past. Estimators can make data related to cost, scope and other technical aspects of similar past projects available to the entire team, and thus assist in completing the overall scope definition. This in turn will help the project and the technical teams to provide the right inputs to estimating thus helping achieve the required estimate accuracy and helping the whole team understand the project / proposal scope better.
Estimating as a function can start taking responsibility for the complete scope of projects and fill this very common gap in some situations.

Vikhas has made a good argument for estimators stwitching the SoW together. I must insist, however, that the PM owns the estimate. It will be compiled by the PE with the estimator sitting next to him. All the lead engineers and the Construction Manager should sign off on it.
I grant that this doesn’t happen often but we should always aim for the target.
The PM should ensure that there are estimate milestones to mark progress and ensure the accuracy of the final estimate.
Thanks Tony
The scope of work (SOW) is based on the scope of facilities (SOF) and the scope of services (SOS). Both SOF & SOS must be well defined to get the SOW. In my experience as a process engineer on the side of consulting firms, I have observed all the issues developed in Vikas Khaitan arguments. Congratulations Vikas!
Thanks a lot for your encouragement Alfonso.