Project Scoping – Part 1
Project Scoping – Part 1
In the execution of a capital project, there are three distinct phases: Scope Definition, detail design, and construction. No phase of a project is more important or has a greater influence on the ultimate success or failure of a project than the Scope Definition.
Scope Definition is often referred to in the engineering business as Front End Loading (FEL) or Front End Engineering (FEE). Regardless of the terminology, the purpose of Scope Definition is to define a project in a fashion that interlocks four crucial attributes of a project into one cohesive entity: project content, cost, schedule, and quality.
There is no better insurance for project success than the proper preparation of a project scope. Conversely, there is no amount of project controls or management tools that can properly recover a project with a poor project scope.
The project scope will be the vehicle that converts an Owner’s “vision” into a specific set of documents that eliminates any duplicity or vagueness. If a project scope is properly prepared, the Owner should be able to delegate the execution of the project and, upon completion, be satisfied with the result without qualification. His “vision” of what he wants or expects is clearly identified in the scope.
These are extremely difficult goals to achieve. If the scope is properly defined, the required skills of the detail engineer or constructor are greatly reduced. If the scope is weak, one hasn’t properly identified the project objectives and the probability of a successful project is poor.
The Team
The groups of people capable of developing a project scope are diverse and highly valuable. They must have a thorough understanding of the project objectives, engineering and construction. One person is rarely capable of developing a proper project scope by himself. A team of people is typically required.
The obvious primary participant in scope development is the Owner.
The Owner’s role is to define his “vision” and to ensure the final product meets this vision. Remember, a proper scope addresses four attributes: content, cost, schedule and quality. As such the Owner’s organization may have one person capable of defining all of the attributes, or this knowledge may be spread amongst many. All must have input into the scope development.
Depending on the nature of the project, the Owner may also be the expert on the process or manufacturing technique employed in the project. Consequently, the Owner must bring this knowledge to the table as well.
Although the Owner is clearly the primary participant in the development of a project scope, there are skills and talents required that are often not available within the Owner’s organization. Unless the Owner’s organization has a staff specializing in engineering and construction of capital projects, it is highly unlikely that the skills necessary to develop a proper project scope are resident exclusively within the Owner’s organization.
The engineering and construction skills, quite honestly, are often overlooked and are often the CAUSE for project failure.
In order to complete a proper project scope one must develop significant detail that is often overlooked or never considered by an Owner’s organization. These details, or “Oh, by the ways”, all cost money and time. If they are not considered during the project scoping effort, they will result in either a dissatisfied owner, an inordinate amount of change orders, or both.
In addition, schedules and estimates must be developed – components that are not normally the venue of an owner’s organization.
For these reasons, it is wise for an Owner to consider employing an outside company to provide these additional services. The methods used to evaluate and contract with these outside companies is important but will be left for another discussion.
The project definition requires a large number of diverse skills that often leads to a large team of people assigned to the task. THIS IS A MISTAKE!
The weakness of assigning large teams to any task is need for coordination and communication. There is no product that mandates clear, concise, and consistent content than a project scope definition. If a project scope definition has conflicting statements or information, the value of the product is greatly diminished.
With this in mind, the team responsible for the preparation of the project scope should be as small as possible. This small team must collect information from a wide variety of specialists and stakeholders and convert this input into a detailed, clear, and consistent product.
In order to minimize the team, the people employed in this effort are unique. They have, of necessity, a wide scope of knowledge. They must be a “Jack of all trades, Master of Many”! They must be able to hold intelligent conversations with specialists in many divergent fields, understand the issues, and convert that understanding into documents and drawings that clearly ensure the project needs will be met.
So, if the product must be detailed and the team must be small, how do you ensure that both objectives can be achieved? The process requires proper and constant communications, and sufficient time to properly review, revise, and update the product.
Communicate
The responsibility for preparing the Project Scope should be maintained by a small group of people. They must, however, collect thoughts, opinions, and positions from a diverse group of people. This is accomplished through meetings, sharing drafts of the Project Scope, entertaining comments, and simply communicating.
Communicate regularly, and insist on input. Meet with the team, briefly, at least every other day. Meet with stakeholders, and specialists, looking for input, once a week. At each meeting, remember to address all four aspects of the scope (content, schedule, cost, and quality) with the participants. Don’t allow the participants to ignore the relationship between these components.
The team members need to be highly experienced and “Jacks of Many Trades”. Find people that can wear multiple hats. Use the “specialists” to REVIEW the scope but be careful NOT to use them to DEVELOP the scope. The specialists typically have “pet” areas of interest that they will expend inordinate time focusing on at the expense of the overall objective. The specialists NEED to be involved, but they are best involved in the meetings and reviews – not the product development effort.
Time
The time necessary to develop a proper project scope is often not appreciated. The writer has been involved in a number of these efforts. The schedule for these efforts have ranged from two weeks to nine months.
Clearly if the time period is too short, the proper definitions, detail, communication and review is not possible. On the other hand, if the period is too long, the cost is excessive, the changes in direction are uncontrollable, and the driving force for the project tend to be diluted.
One needs to distinguish between a project scope and project development.
Project development, by implication, means change. Clearly if a project needs “development” than the scope is unclear. Those projects that are still in development will obviously take far more time to scope than those that are well understood.
The simplest way to determine if a project is still in development is to evaluate the engineering documents. Specifically the process flow diagrams and P&ID’s. If these documents are not final, then the project is still in “development”. Don’t waste your time trying to develop a Project Scope on a project still in development.
If, one the other hand, these documents are “final”, then you are prepared to develop a project scope. What is meant by “final”? This is a significant question and the key concept that can answer this concerns “CHANGE”.
Once the project scope definition effort is complete, the Owner MUST accept the premise that there will be NO CHANGES. This means that the Process Flow Sheets and P&ID’s cannot be “revised”. There will not be a need to “add another piece of equipment” or “add another pipeline”. Depending on how the project scope is developed, the line size may also be fixed.
If the process is not ready to meet this “NO CHANGE” criteria, then the project is not ready for scope definition. To proceed with a scope definition without meeting this criteria is a formula for DISASTER.
Please note that there are many projects that ultimately result in changes to these basic documents. This is normal. However, the changes were NOT made out of necessity. The changes are made because the BENEFIT of the CHANGE out-weights the COST. These are discretionary changes that are not NECESSARY.
Once again, if a project cannot meet this “acid test”, the project and/or owner is not ready to develop a project scope definition.
If it takes more than four months to develop a project scope one would probably conclude that the project content was never truly understood. Many of the issues associated with project scopes that extend beyond four months are associated with the manufacturing process. In retrospect, the reason for taking so long to develop the scope tends to be that the manufacturing process was never fully understood. In these cases, the project scoping effort was really an R&D effort in trying to define the process properly.
There are many that will attempt to define the project scope in an extremely short period of time. The results are typically poorly defined and the four attributes (content, cost, schedule and quality) end up not being meshed properly. For instance, the schedule does not reflect the actual project content, or the cost estimate does not reflect the projected schedule.
As a guideline, the writer would suggest that the MINIMUM time to develop even the simplest project scope is about 10 weeks. More technical project scopes will typically take four to eight weeks longer.
Remember, only a portion of the time is spent developing the scope. A very significant portion of the time MUST be spent reviewing and refining the scope.
Project Scope Components
There are a varying opinions of the components that comprise a properly defined project scope. The content is far more important than the list of products. Simply keep in mind the final objective: the Owner’s vision is clearly defined by the documents. No surprises.
The primary reason for project failure is CHANGE. It doesn’t matter whether the change was justified or frivolous. CHANGE erodes away at the framework of a project. Uncontrolled or untimely CHANGE will ultimately ensure project failure.
The purpose of the Project Scope is to define the project in sufficient detail to ensure that there are NO CHANGES!
There are those that are probably laughing to themselves right now. They are telling themselves that the concept of NO CHANGES is a noble objective but not realistic. I would suggest that those that doubt that a project can be run without changes have been associated with projects without proper scope definition and/or poor management.
So what are the proper products of Project Scope? The following could be used as a guideline.
- Written description
- Physical Layout
- Site Plan
- Building Layouts
- Equipment Arrangements
- Process Flow Diagram
- Piping and Instrumentation Diagram
- Electrical Single Line
- Equipment List
- Instrument List
- Process Control Philosophy
- Control System requirements/Supplier
- Equipment
- Data Sheets
- Price Quotation
- Equipment Delivery Quotation
- Design Criteria
- Project Schedule
- Project Capital Estimate
- Estimate Assumptions
- Detail Breakdown
This is a reasonably accurate list but it should not be considered inviolate. The list is developed in support of the objective – not visa versa. The objective is to develop a clear understanding of the Owner’s expectations. There is no reason to develop a document that doesn’t serve this objective.
This is an important principle. The quality of a project scope is NOT measured by the amount of paper that is produced. It is only logical that the more paper and documents, the more likely that there are conflicting statements and the recipient of this definition will not read all of the documents!
Clearly the documentation required to define a commercial building is far less complicated than that required for an oil refinery!
In future portions of this writeup, the definitions and objectives of the various components of a project scope will be addressed. At this time, however, we will leave that subject and address two other vital concepts: Change Control, and the Interdependence of the primary objectives.
The Management of Change
One of the rules of good project management, regardless of phase, is Change Control. In the case of Project Definition, change must be anticipated. The fact is, as a project is defined, the Owner often must balance the realities of content, schedule, cost and quality. As the Owner becomes aware that his desires for content often conflict with his desire for schedule, cost or quality, CHANGE is inevitable.
In fact one of the primary byproducts of developing a project scope is the reinforcement of Owner expectations.
It is the project manager’s responsibility to keep the Owner and stakeholders focused on this interrelationship and, ultimately, achieve buy-in from all participants.
One vehicle for keeping this balance properly communicated is “Change Management”.
The writer uses a simply method of communicating potential changes. This vehicle also does well modifying Owner expectations to something closer to reality.
The vehicle is “Meeting Notes”!
It is important to record all the decisions that are made during the evolution of the Project Scope. The best way to do this is to keep and distribute relevant meeting notes. The Meeting Notes should not voluminous. They should be focused on documenting only three categories of information: Items discussed (brief), actions required, and decisions reached. An example of a typical set of meeting notes, with emphasis on decisions reached is shown below. 
Note that the Decisions Reached section of the Meeting Notes measures each decision under three (or four in the example) distinct criteria: cost, schedule, and quality. In the example above, one of the decisions made in the meeting was that all pumps on the project will have an installed spare. Alongside this item, the notes indicate that this will have an upward influence on the cost, schedule and quality of the project.
At the end of each week, the Project Manager compiles these decisions made into a list and summarizes the impact on cost and schedule with an “Order of Magnitude” impact.
This allows the Owner to either adjust his expectations on the overall project OR change a decision made during the week!
The compilation of the Project Projection is an effective method of informing senior management of the overall direction of the project scoping effort. One should not be surprised that this document will elicit some of the most direct comments and directions from Management.
This is going to cost too much! We need the project completed sooner than this! You are sacrificing availability for initial cost – not acceptable!
Typical comments. Exactly the purpose for issuing the document.
It is important to understand that none of the four attributes of a project scope can stand alone. They are all interrelated. The scope, schedule, cost and quality are not isolated characteristics of a project. One cannot determine the schedule for a project without having a basis AND IMPACT on content, cost and quality. Similarly the project cost cannot be estimated or MODIFIED without impacting content, schedule and quality.
This interrelationship is not supposition; it is FACT.
More to come in Part 2
