“We MUST have this product in 15 Months.  Can it be done?”

“Why is it taking so long to complete the engineering on this project?”

“I can have a contractor on site to begin building next week.  How long before you can provide him the design?”

……………………………………………………………………………………………………………..

These are fairly typical questions that are often asked at the start of a project.   The answers are best presented and understood by a project schedule.

The project schedule is simply a graphical illustration of a project’s execution plan. 

It is an invaluable tool.  The schedule provides all parties with an understanding of the interrelationships between activities and serves as a vehicle for achieving BUY-IN from all of the team members. Each team member has a role and commitment for meeting the objective. Its greatest value is its ability to identify the CRITCAL PATH i.e. those tasks, activities, and durations that dictate the overall duration of the project.

The project schedule  illustrates ONE method for achieving the stated objective within the required time frame.  The key word is “ONE”.  There are other execution plans that can result in a successful project but the duration, cost and quality will be different.

It is important to understand that changes to the schedule will always impact both cost and quality.

The original schedule and activities rarely remain unchanged throughout the course of a project.  As the “unforeseen”, “unpredictable”, “unanticipated” or “unexpected” events surface, the details of the schedule must be reviewed and revised to find another path to success.

So what purpose does a schedule serve?

The schedule is an invaluable tool for organizing, evaluating, and forecasting how a project is being executed.  As problems arise, the schedule can be used to evaluate alternative paths for achieving success.  The schedule can provide guidance in identifying problems early in a project.  If, for instance, a project activity was scheduled for three months, and in the first month only twenty percent of the task was completed, the team can entertain methods to recover the lost time.

The “Generic” Project Schedule

Although every project is unique, and its execution plan is specific to its goals and objectives, there are some common rules and tendencies of project schedules that are not project specific.

The purpose of this article is use a simplistic “generic” schedule to illustrate some of these rules and tendencies. The schedule attached is “generic”.  It is a “straw man”. Many who read this will justifiably critique many of the activities, task durations, and links.  Because the schedule is “generic”, it lacks depth and detail.  However flawed this “generic” schedule may be, it illustrate some guiding principles that govern project execution and reinforces some basic “Rules of Thumb” that are common to most projects.

General Schedule

Schedule Assumptions

Before highlighting some general conclusions that can be drawn from this schedule, it is proper to address the basic assumptions.   

1. This is a “generic” schedule for a typical heavy-industrial EPC project. 
2. The equipment associated with this project is lumped into two categories: (a) Long Lead Items, e and (b) “Off the Shelf” equipment.  Long Lead Equipment is typically customized equipment for the process that requires significant time to design and fabricate.  The “Off the Shelf” type equipment i.e. pumps, heat exchangers, and fabricated tanks are standardized and much of the design information is available in catalogues, and delivery to the site is relatively short.   A true project schedule should have each major piece of equipment or group of equipment identified with its appropriate activities and time frames.
3. The schedule starts from a point where the process is generally understood.  For the purpose of this example the process has flow sheets, “space allocation” level general arrangements, and a written definition of the project process and scope.  This level is often referred to as a Level 1 or 2 Front End Engineering Package.
4. In an attempt to minimize the overall duration, much of the review process that is necessarily associated with “Owner review” is not included.  These external reviews will extend the overall duration of a project.  The number and time associated with these reviews are typically company specific.
5. The schedule is based on awarding construction of the project immediately after concluding Front End Engineering but BEFORE any significant detail design has been prepared.  This is not necessarily the method preferred by many companies but this approach typically reduces the overall time frame for the project and removes the award of construction from the critical path of the project.

This schedule utilizes a concept that most engineers and constructors do not readily admit to.  It allows for the fact that the CORE design documents (P&ID’s, Equipment Arrangements, Single Lines, etc) are susceptible to change as the project progresses.  These changes can be caused by a number of events but the most significant cause is due to refinements/clarifications around purchased equipment.  As the accuracy and quantity of information becomes available, these Core Documents often require adjustment.

The key to efficient project execution is “no change”.  One preaches this concept to everyone associated with a project.  The fact, however, is that change does occur often due to necessity.   One cannot wait for ALL the information to become available before one starts design.  In the present “fast track” fashion of executing projects, one similarly cannot wait for all the design information before one starts construction.  Consequently, there are “surprises” along the road that require some changes to the base documents. 

This schedule concedes that these changes occur as technical information is received from the equipment suppliers. 

The schedule assumes that the Constructor cannot and will not wait for all the design documents to be finalized before he begins construction.  This can be a dangerous practice because it opens the door to change orders.  The alternative is to wait for ALL the information to arrive before the constructor is allowed to proceed in the field – this typically would impose an unacceptable schedule extension.

The Generic Schedule lacks detail in the construction phase.  Much of the detailing associated with construction is dependent on the physical arrangement of the site and the process itself.  For instance, it is typical that a project can be broken down into areas and the staging of the workforce is dependent on the number of areas.  Often the design also can be staged by areas allowing for earlier releases of some areas. 

Guiding Principles and “Rules of Thumb”

Although a good deal of detail cannot be added to a schedule without a definition of the process and physical arrangement, the “generic” schedule does illustrate some key principles and “rules of thumb” that are common in most projects:

1. The first and most obvious guiding principle is that the work cannot be completed until all the design is done.  Obvious but a concept that many people would prefer to ignore.
2. The overall duration, from beginning the Front End Engineering to mechanical completion is 19 months.  Add commissioning and startup and you have a 21 month schedule.  This duration can be compressed ONLY by altering the governing interrelationships or activity durations.  For those Owners that wish for a schedule duration of 12 months, there is a lot of “short cutting” that will be required.
3. The scheduled task durations on this schedule are not particularly lenient.  In fact, many would argue that they are aggressive.  Even with a fairly aggressive approach to executing a project, the overall duration results in a 21 month schedule.  This time frame is reasonable for an aggressive, “fast track” project.    
4. The duration to prepare the Front End Engineering package is 11 weeks.  This aligns well with a general “rule of thumb” that states that a decent FEE will take no less than 2 ½ months to properly develop.   The minimum time frame for developing an FEE is six weeks.  The critical element defining the FEE duration is the time it takes to get equipment information and the need to review these documents in detail prior to “casting them in stone”.  Most companies would allow from four to six months to develop these documents.
5. One of the critical path elements during the FEE process is the time duration required to establish price and technical data for the process equipment.  This duration can be reduced through a variety of ways including (a) having an historical database of equipment to allow reasonably accurate estimates of this equipment information,  (b) standardized equipment such as pressure vessels, heat exchangers, etc. that allows one to estimate without bidding, (c) vendor relationships that allow preliminary information in shorter durations.
6. Although this schedule does NOT show Permitting as a critical path item, it is only because the duration assumed for acquiring an environmental permit is three months.  If this duration were extended to 45 days, it would impact the overall project schedule.  Obviously permitting can have a significant impact on the overall schedule duration.
7. The biggest critical path element on the schedule is the procurement, drawing delivery, fabrication and delivery of equipment.  This fact raises a red flag.  One should begin purchasing equipment as soon as possible AND the delivery dates must be met.
8. As is ALWAYS the case, the critical path in construction goes through piping and then instrumentation.  Hence, getting the piping materials to the field, and beginning this effort is key to the schedule. 
9. Note that the P&ID’s are not complete before the first piping drawings have been delivered for construction.  This is contrary to the opinion of many constructors that continually press for “final” P&ID’s.  Although the P&ID’s are the “roadmap” for the design of a process, the final P&ID’s will typically have to be adjusted to reflect the physical arrangement of the piping.  Hence there is a period of time during design were the P&ID’s lag behind the detail construction drawings.
10. Although the overall duration of this schedule is “sobering”, the schedule shows some opportunities for reducing the overall schedule.  The KEY is to get the design information to the design force ASAP, followed by getting the material and drawings to construction ASAP.  It’s a fairly simple rule – you can’t finish the project until the information is available and the material has been delivered to the site.
11. It is not uncommon for the Constructor, upon award of the work, to mobilize on site as soon as possible.  From the schedule one can see that this is a waste of time and money.  This can result in excessive costs in the field as this schedule demonstrates.
12. The overall construction duration for this “generic” project is approximately 12 months.  The detail design duration is slight longer than seven months plus the FEE package.  There is an overlap of three to four months between construction mobilization and completion of design.  In reality, one should anticipate longer design durations and a larger overlaps than are illustrated in this schedule.

Shorter Schedule Durations

Many capital projects are expected to complete in shorter time durations than this generic schedule reflects.  This schedule illustrates through the critical path (elements in red) that there are specific time durations that must be attacked in order to achieve significantly shorter project schedules.

The equipment delays are an obvious opportunity to shorten duration.

The other obvious opportunity is to establish a greater overlap between design and construction.  Although a real opportunity, all parties must work in unison to accomplish this overlap.  Communications between engineering and construction must be improved, and the information flow must be integrated.  Oftentimes the constructor should be prepared to receive “PARTIAL RELEASES” of drawings to keep the field forces working.  One may look at bulk material orders early in the design process to reduce the delay between drawing releases and receiving material in the field.

Lastly, one needs to carefully look at the commissioning and startup sequences with an eye on developing an opportunity for overlap in these functions while maintaining a safe working environment.

ALL of these opportunities for schedule compression will have an impact on both cost and “quality”.  An unwillingness to admit to this relationship does NOT make the relationship untrue.  It simply leads to unrealistic expectations and objectives.

Conclusion

A detailed design/procure/construct schedule provides a project with the opportunity to commit to paper the activities, durations, and interrelationships that are required to meet the project objectives.

The project schedule illustrates only ONE path to the final objective.  However, changes in the schedule will result in changes to both cost and quality.

Although one CAN achieve compressed schedules beyond the illustrated 21 month schedule, these compressions are not without cost.  The general rules and guiding principles illustrated above will still persist and can only be improved upon by a conscious commitment from the project team.

The two rules are simple:

1. There must be rules, and
2. Rules are made to be broken.

THERE MUST BE RULES

Clearly the first rule is practiced throughout industry.  Rules can be as simple as setting the starting and ending time for the work day, or as complex as a set of procedures for preparing, checking, and issuing engineering documents.  Most of our society is governed by rules.  Some of them have been considered serious enough to be expressed as Laws.  Others are more subtle and may be addressed as simply good etiquette. 

The principle is simple:  Rules provide predictability and regiment to an otherwise disorganized effort.

The second rule, however, is more controversial.  This second rule is the rule that provides the opportunity for every company, every organization, and every society to excel beyond the ordinary.  The second rule is NECESSARY if an organization wishes to progress and learn from its shortcomings.

RULES ARE MADE TO BE BROKEN

Before one can implement the second rule, one must fully respect and understand the first rule.  Every rule has been developed over time for a reason.  For instance, everyone starts work at 8 am in an organization where communication and teamwork are required to execute the work function.  An assembly line requires workers at each station working in sequential order to complete the assembly.  One person missing makes the entire assembly process come to a halt.  The organization, hence, has a rule that ensures everyone is on the assembly line.

In every case it is far more important for the workforce to understand the REASONS for a rule than simple to memorize the rule.  We are surrounded every day by organizations that train their people on the rules without providing them with the intellectual building blocks to truly understand the reasons for the rule.

Each rule is typically driven by cause and effect.  The rule has been established based on reasons.  It is also expected to cause specific RESULTS.

The workforce must truly understand the REASONS for a rule and the expected RESULTS.  This understanding provides them with the ability to BREAK the rule when the REASONS are not specifically valid or the RESULTS will not be those expected by the rule.

A rule is often predicated on assumptions.  If the assumptions that were the basis of the rule are not valid, then the rule is often not valid!

In today’s business world, and for that matter society, we often emphasize the first rule and fail to recognize the second.

Businesses that operate under the first rule without the second end up with a distorted sense of accountability.  They hold the employees responsible for operating under the rules without providing them with the freedom or responsibility to achieve the expected RESULT.  The employee or society is not asked to UNDERSTAND the purpose of the rule and the RESULTS are often mediocre or, in some cases, counterproductive.

 The following are some simple examples that may help to illustrate the point.

EXAMPLE 1

The Print Room requires that all drawings are submitted for copying and distribution by 3 PM every day.  This is the RULE.  The intent of the rule is to minimize print room employee overtime and provide them with the opportunity to operate in an organized, predictable fashion.

The workforce is presently preparing a set of construction documents for issuance to the field for construction.  The schedule indicates that they must be issued this Friday in order to be in the field on Monday morning.

In preparing these documents, the design workforce fails to complete them by 3 PM.  No one informs the print room that they are behind schedule nor suggests that the print room rule must be broken in order to meet the project needs.  Consequently the print room doesn’t start issuing the documents until Monday morning.

The result is a schedule date missed, additional costs to the construction effort, and/or a change order for construction delays.

The rules were followed and the results were mediocre or counterproductive.

The workforce followed the first rule, but was not empowered with the SECOND rule.

EXAMPLE 2

The procedures for estimating an engineering project is that each department prepares an individual work hour estimate and these estimates are totaled by the project manager in preparation of the proposal.  In the case of one proposed project, the bulk of the design work is electrical and mechanical, with a minor amount of structural and civil work.

Each department prepares the estimate including the structural department and the civil department.  The estimates are totaled, the proposal is submitted, and the work is lost based on proposed cost.

In the follow up, the marketing department determines that the competition had far fewer structural and civil costs because their proposal planned on combining the drawings for civil and structural on one drawing instead of multiple drawings proposed by your firm.

The first RULE was followed, but no one suggested that the RULE could be broken to the advantage of the client and the engineering company by combining the minor discipline drawings into one.

The rules were followed and the results were mediocre or counterproductive.

EXAMPLE 3

The site rules for Quality Assurance require the piping superintendent to provide Quality Assurance with a schedule of the welding to be performed on a given day.  Prior to insulating this welded pipe, Quality Assurance is required to sign off on the welds.

Upon completion of a set of critical welds, the piping group waits around for Quality Assurance to inspect and sign off on the welds.  The welds are completed at noon.  The insulators are staged to begin insulation.  No one from Quality Assurance shows up until quitting time.

The Rules were followed and the results were mediocre or counterproductive.

Conclusion

The examples used above are deliberately obvious and non-controversial.  The writer has used the above set of TWO rules throughout his career to empower the workforce and remove the often used excuse of “simply following the rules”.  The writer has added one more caveat to these rules:  When a rule is to be broken, inform one’s supervisor before hand or be fully prepared to defend your action afterward. 

The writer could have used some far more controversial examples to illustrate the point but these examples may have overshadowed the principle.  The second rule, RULES ARE MADE TO BE BROKEN, truly forces management to BELIEVE in the rules, and provides some creative and exciting opportunities for the workforce to improve both their environment and the work product.

Let is suffice to say that a workforce that is not both empowered and accountable is a mediocre workforce and the product, although predictable, is equally as mediocre.

Before one empowers a workforce to “break the rules”, one must make sure that the workforce truly understands

1. The REASONS for the rule AND,
2. The Accountability associated with breaking the rule.

If one can train a workforce to work within this expanded role, the results can push the envelope and expectations, and redefine the work environment.

Once a project has been properly defined, one typically has to determine both a schedule and budget for the project scope.  This stage of project scope development is the most painful:  Everyone has agreed on what they WANT and now it is time to convince them of what it will COST in both money and time.

Everyone involved in the development of the project scope has an opinion of what the project will cost.  Senior Management has an EXPECTATION for what the project will cost.  It is now time to replace fiction with fact (or at least attempt to replace unsubstantiated fiction with a more grounded fiction!).  It is now time to ESTIMATE the cost of the project and agree on a budget.

It should be noted that the procedure is a TWO step process: (1) establish an estimate, and (2) agree on a budget.  One typically would expect the BUDGET for a project to be BASED on the estimate but there are some managers that would prefer not to admit to this concept.  In some cases, especially when the estimate far exceeds the original expectations, the budget is often simply a “wish” or “challenge” instead of a reasonable expectation.

The Estimate

There are a number of different techniques and processes that can be employed in establishing a project estimate.  Every company typically has its own preferences and systems for preparing the estimate.  Many have a number of different methods which they feel have differing levels of “accuracy”.  Quite honestly, the purported level of accuracy of one method versus another cannot be easily substantiated, but the level of accuracy is specifically intended to “modify expectations”.  If one claims that an estimate is accurate to ± 50%, then one has planted the seed for corporate executives to reasonably understand if the final costs differ substantially from the original “estimate”.

Regardless of the purported accuracy of the estimate, the budget typically does not allow for variance.

Most companies are looking for a BUDGET that is at least within a 5 percent accuracy, OR a “not to exceed” figure.   Note that we are addressing company policies concerning BUDGET versus ESTIMATE accuracy.  The estimate is simply a stepping stone to establishing a budget.  Regardless of the estimating accuracy used to support the budget, once the budget is agreed to and accepted, the method used to establish this budget becomes unimportant.

The distinction between a project budget, and the estimate used to establish the budget, is often conveniently forgotten.  If your method of developing an estimate is only accurate within 10 percent, and your management’s expectations on budget control is “Not To Exceed”, then it seems reasonable that the budget for the project must be established ten percent HIGHER than the estimate.  Logical but not Realistic!

The purpose of this article is not to address the different methods of estimating and their anticipated accuracy – we will address this in future articles.   The important principle to understand is that the estimate accuracy must be accounted for when establishing a budget.

The Budget

The budget is, in many respects, an agreement between the company and the project manager.  It quantifies expectations.  Each company has different policies and expectations concerning the project budget.  Most expect that the budget will not be exceeded and have procedures in place that require senior management approval for expenditures beyond budgeted amounts.

The budget is a primary tool for controlling the project.  The project manager must constantly compare expenditures and forecasts against the budget to control the project.

Because the budget is the primary tool for controlling a project, it should be broken down into sufficient detail to allow the manager to measure the project against the budget on a regular basis.  The writer strongly suggests that this budget breakdown structure be flexible to allow for proper project control.  Its structure will reflect the intended execution strategy.   It should NOT be dictated by the structure of the estimate nor the business accounting structure.

For instance, if the project is to be executed by awarding four subcontracts for construction, the estimate should be reapportioned to reflect these subcontracts, and the budget broken down in this same fashion.  Hence, when a subcontract is awarded, the budget and the bid align, and the project manager can reasonably forecast the project regularly without having to constantly manipulate figures.

Similarly, the budget should have a line item, or multiple line items, for “CONTINGENCY”.

Contingency

Contingency is a nebulous concept that lacks an agreed-upon definition.  The dictionary defines contingency as “an event that might occur in the future, especially a problem, emergency, or expense that might arise unexpectedly and therefore must be prepared for” or “provision made against future unforeseen events, e.g. an allocation of funds in a budget”.  The key word is “unforeseen”.

Estimate Contingency

An estimate is developed based on a project scope.  If the project has reasonable definition, there is a basis for developing reasonably detailed capital cost estimates.  For instance, with the use of P&ID’s and Equipment Arrangements, the size, material and quantity of pipe can be quantified.  This quantity of pipe is “reasonably accurate”.  It is a known.  In order for this quantity to become a line item on an estimate, however, a cost must be assigned to it.

There are a large number of assumptions that must be made to take this QUANTITY of “known” material and assign a cost to it.  One must assume (1) a price for the material, (2) a cost for the support materials to hang the pipe, (3) a labor productivity rate for installing the pipe and supports, and (4) a labor hourly rate for this labor.  In addition to these ASSUMPTIONS, one must determine the level of accuracy of the quantity takeoff.  Typically, this quantity is adjusted to allow for the accuracy of the takeoff.  This adjustment is NOT contingency i.e. it is not addressing an unforeseen issue.

A detailed estimate is a compilation of all of the “knowns”, assumptions and factors.  The writer strongly recommends that ALL of these assumptions and factors are carefully reviewed and challenged as an estimate is developed.  These factors and assumptions are NOT, however, CONTINGENCY.

Once the estimate is built up from the “knowns” as defined in the project scope, a contingency must be applied to the estimate.  This contingency, the estimate contingency, is specifically applied to address the unknown or unidentified issues that are normally encountered in the execution of a project.  This contingency does NOT account for unknowns OUTSIDE THE SCOPE of the project.  For instance, it does not account for adding a spare pump to a process system – the need for spares should have already been properly addressed in the project scope.  The addition of a spare pump is an out-of-scope change to the project and must be addressed by a change order.

If the estimate is built on a fairly detailed project scope, and the estimate itself is detailed, the contingency is relatively small.  Although not intended as a rule, this estimate contingency should normally be in the range of 5 to 10 percent of the overall estimate.

The sum of all the estimate parts, including the contingency, is the estimate.  This estimate has a level of accuracy based on the estimating technique.

Budget Contingency

Once an estimate has been developed it serves as the basis for developing a budget.

This can be a difficult step depending on the final estimate value as compared to management expectations. It is not uncommon for the project estimate to exceed management’s expectations for the project. 

The purpose of this article is not to address the negotiations that will ensue with an estimate that exceeds expectations.  One word to the wise, however:  the budget must be supported by an estimate.  If the estimate must be reduced, the project scope should be reduced to reflect these “savings”.

For the most part, the budget should be identical to the estimate.  However, one must take into account the company’s policies and procedures before agreeing on a budget.

First, remember that the estimate has a degree of accuracy.  If the budget policy in the company is that the budget is a “not to exceed” appropriation, than the budget must be increased, by an “insurance” contingency, to address this issue.

Secondly, if the company is unwilling to accept “changes” to the project scope, and their policies allow this type of “scope creep”, than additional monies must be added to the budget to address this scope growth which would normally be addressed with budget change requests.

Summary

Contingency is a concept which is applied a variety of ways by different organizations.  Regardless of the use of the term, there are specific, definable applications within a project for the proper application of “contingency” funds.

Project contingency must address both unforeseen and historically, predictable costs.  These contingencies can be categorized as:

1. Estimate Contingency that allows for unforeseen costs within the project scope.
2. Budget “Insurance” Contingency that addresses a corporate budget control philosophy of  “Not to Exceed”, and
3. Scope Growth Contingency that reflects the corporate casual attitude toward “scope creep”.

Each company and project may have a need for each of these contingencies.  Each contingency should be addressed during the development of a project scope and budget.  Each should be identified separately in the budget and a project controls methodology put in place to monitor, control, and forecast them.

A previous employer of mine once quipped “At 5:30 each evening our company assets walk out our door and I pray each morning they return!”

The capital projects business i.e. the design and construction of major facilities, interacts with two of the larger service businesses: Engineering and Construction. Although these businesses are often marketed to distinguish themselves from one another, they are, for the most part, simply the sum of the individuals working for them – They are pure service companies.

There is little doubt that for ANY given company, the team of people employed to execute a project will have an impact on the results. In fact, the results of a project are impacted by any ONE of the people assigned to a project. The final project is a direct result of every, and any, single individual assigned to it.

This is a very important concept. This premise is stating that the final product is irrevocably linked to every individual that has worked the project.

Admittedly, the difference in the product may be insignificant. For instance, if a document distribution clerk fails to mail the final drawings to the field on the day it is ready, will the project success truly be affected? Eight times out of ten, the answer is “no”. But it could have an impact. It could be as significant as delaying the completion of the project by a day, or costing the project overtime charges in order to complete the tasks.

It could be more subtly. The Project Manager has promised the Owner and Constructor that the drawings went out and, over time, the Owner and Constructor lose confidence that the Engineer is capable of meeting his commitments.

The point of this example is to simply emphasize that, in a service company, the quality and commitment of the people is a key attribute of a successful company. The quality of the people is directly related to the quality of the Company and the quality of the projects they deliver.

A Brief History of Service Companies (Engineering and Construction)

Once one accepts the concept that the people make the company, the Business model for the company must take this into account.

The writer has been involved with the Engineering and Construction business for almost four decades. As with any business, the methods of managing and controlling these businesses have changed significantly over this period of time.

Four decades ago, the capital project business worked at a relatively slow pace. Projects were built in three to five years from conception to completion. Typically the engineer was employed to design a facility and the engineering product was completed before the construction ever begun.

Engineers were contracted with typically on a multiplier basis and these multipliers were significantly higher than today’s rates.

The inflation rates of the 70’s changed the capital project business forever. The traditional time frame for designing and then constructing a project were imposing huge financial burdens on the cost of a project. With double digit inflation, the cost of completing a project could double during the execution of the project.

The solution was to shorten the overall duration. The result was overlapping engineering and construction durations which spurred the concept of EPC contracting.

Over the decades, as competition in the service industries increased, the pressure on both engineering and construction was to reduce the “multipliers” that were traditionally common in the industry.

The industry responded by reducing the multipliers but changing the contract structure as well. Support personnel such as managers, secretaries, document clerks, IT personnel and similar, who had previously been handled as overhead and “included in the multiplier”, were now billable to account for the reduction in multiplier rates. Overhead groups were carefully scrutinized and reduced or eliminated.

As pressure on “rates” continued, service companies changed some of the contract terms and conditions to allow for further “reductions” in rates. Liabilities and warranties were monitored to reduce the “risk” in order to reduce the “rates”.

In the past, the higher multipliers allowed service companies to “save for a rainy day”. The higher profits allowed these companies to “coast” through temporary downtimes and carry valued employees from one project to the next. Over the decades, the numbers of companies that receive the higher rates and the ability to carry valued personnel have diminished significantly.

The service companies now monitor “billable hours” religiously and the threshold for non-billable hours continues to shrink.

The New Services Business Financial Model

This new business model has resulted in service businesses that must hire and fire personnel on a weekly basis based on present workload.

This management technique, however, has some highly undesirable consequences.

The market continues to drive the rates for service companies lower. Many companies have even established offices in a multiplicity of foreign countries where salary rates are significantly lower allowing the company to reap higher profits while delivering lower rates to their client base.

The employees of these service companies have come to accept the inevitable – if there is no billable work, they no longer have employment. The natural reaction to this policy is two-fold: (1) the project is not “finished” until there is another project that will employ the people, and (2) the employee has learned to “look out for himself” i.e. when a project is ending without another obvious project to follow, he finds another employer.

The final product of the service company has suffered from these practices:

• Project overruns during “slow times” are predictable.
• The loss of key project team members as a project nears completion during slow times is predictable.
• The biggest loss from this practice is the loss of highly valued employees.

The Inevitable Business Downturn

The new services business model is focused on minimizing overhead and non-billable hours. The employees have become aware of the practice and have learned to proactively protect themselves.

Company loyalty, a trait that was common in the service industry three decades ago, has almost disappeared.

Once a downturn is evident, the managers of a service company must address the morale of their workforce.

If they do not convince the employees of their long term security, the employees will begin to leave. They will leave on their own terms and their own schedule – and these terms and schedules will work to the detriment of ongoing projects.

If management fails to address the downturn, the FIRST employees that they will lose are the most VALUABLE employees. Why? These employees are the most marketable.

If management fails to address the downturn, the employees that will be left in the company are, in fact, the LEAST valuable employees. The cream of the organization will have plenty of opportunity to find a more secure position somewhere else.

The Core Employee

Over the years, I have had the misfortune of experiencing a number of these downturns. As a manager I was typically well prepared. Biannually, I would ask my supervisors to rank every employee in my office or department. I would ask them to provide this ranking both by title i.e. all the engineers AND simply by person.

Typically I would have three to six direct report supervisors so I would have six to twelve lists that I could review. Clearly there was a bias – those people that worked directly for the supervisor were always ranked slightly higher than those that were not. However, when these lists were combined, one attribute ALWAYS remained the same: The top twenty percent of the people and the bottom twenty percent of the people were ALWAYS the same.

The supervisors all agreed that there were unquestionably a small percentage of the workforce that was the most valued people in the organization.

In most cases, not unsurprisingly, these were also the highest paid people in their respective salary range.

As a manager, I would make it a practice throughout the downturn to call these top twenty percent of the employees into my office, individually and as a group, and emphasize to them how valuable they were to the company. I would promise that I would leave the company before they were laid off.

They were MY CORE EMPLOYEES. They were the KEY PERSONNEL that made the Company as successful as they were. They were the asset that distinguished my service company from others.

A Better Business Model

The purpose of this diatribe is to suggest that a Core Employee concept would be a unique basis for a service company business model. A formalization of this policy MAY be enough to reignite the COMPANY LOYALTY principle that has recently become extinct.

The concept is simple. Every year, at annual review time, one identifies a minimum of twenty percent and a maximum of thirty percent of the present workforce as CORE EMPLOYEES.

One would execute a contract with these employees, signed by a Corporate Officer, that simply states:

1.  The employee has been designated as a CORE employee. 
2. The company will do everything within its power to protect their employment within the company. 
3. If the company determines that it is necessary to terminate the employee’s full time employment they will:
   1.  Maintain, at the company’s full expense, all benefits i.e. medical insurance, life insurance, disability, etc. for a designated period.
   2. Provide a salary of 70 percent of their base salary for a designated period.
   3. At the first opportunity realized by the company, the CORE employee will be reinstated to full time employment.

The duration and percentage of base salary are variables; each company should determine these based on their previous business experience. My recommendation is a minimum of 70% of salary and nine months to a year duration.

The objective of this Core Employee policy is obvious – it should provide sufficient insurance to make your most valuable employees comfortable that their jobs are secure and, if unforeseen events occur, they will have income and time to find alternative employment.

There are some management criteria that can be exercised around “core employees”.

First, it should be clear that becoming a core employee is dependent on the quality of work performed and it takes time to establish this metric. Hence, one must be an employee of the company for a period of time before one becomes eligible. My suggestion would be about three years.

Second, the value of core employees will probably differ between “departments”. The Company would need to make this distinction. For instance, the Project Management staff may be more “valuable” to the company than the staff in the shipping department. Hence, the overall company management would identify appropriate percentages of the staff by department.

Additionally, there should be a range of core employees. For instance, this example has suggested an overall low of twenty percent and an overall high of thirty percent. Once again, this would be dictated by overall company management.

Lastly, and most importantly, the designation of Core Employee must be renewed regularly. This is not intended to be a “tenure” policy. One doesn’t achieve Core Employee status and get to lay back and rest. As a Company grows and shrinks, keeping the Core Employees within a range of total workforce population dictates changes to the designated Core.

The assessment of Core Employee designation would be concurrent with an annual review.

Conclusion

The concept of Core Employees is not alien; I used it as a management tool over the years to try to reassure my most valued employees of their importance.

The implementation of a Core Employee Policy, however, may serve to revitalize a business sector that has become complacent and disheartened by years of abuse. This policy could help distinguish those service companies that truly believe that THEIR people are the differentiator between themselves and the competition.

The company had just completed a large boiler project. The project had been done in 2D CAD. We knew the work hours invested in the design by area and by discipline. We decided to ask a team of four engineers and designers to take the information for one area and, from scratch, redesign it in 3D.

The logic was reasonable. We knew the hours used for piping in 2D in this area and we would compare it to the hours required to complete the design in 3D. The design team was given the equipment arrangements and the P&ID’s from the original project – exactly the same support documents as the 2D team had originally been provided.

The results were OUTSTANDING! The 3D Design was completed in 38 percent of the original 2D Design work hours AND 20 percent of the time schedule! The argument was settled! The 3D tool was FAR SUPERIOR! … Or was it?

Although we thought we had a level playing field, after further evaluation we had stumbled onto a far more significant finding: The traditional methods of engineering a project are highly INEFFICIENT!

We quickly realized that providing the 3D Design team with completed equipment arrangements and P&ID’s was NOT providing a level playing field. We had given the 3D team a HUGE head start!

This experiment provided insight into something far more valuable than the value of 3D design versus 2D design. It provided practical evidence of the true controlling factor of overall engineering efficiency: INFORMATION FLOW.

In every engineering discipline the rule is simple: Regardless of when you start the work, it cannot be FINISHED until all the information required to finalize the design is available.

The engineering of a complicated project requires a lot of decisions and information. One must develop the process flow diagrams, specify equipment, develop P&ID’s, purchase equipment, verify the equipment sizes and utility requirements, design foundations and structures to house the equipment, design utility systems, and then … build it.

The information flow is enormous. The workflow is complicated and includes a number of reiterations.

The example above demonstrates that the huge advantage that the 3D team had was a set of finalized equipment arrangements and P&ID’s. ALL of the information was available BEFORE the detailed design of the piping systems was STARTED. It became clear that the over 60% of the work effort and 70% of the duration invested in the development of piping was inefficiencies associated with collecting information, and rework associated with incorrect assumptions!

Regardless of when you start the work, it cannot be FINISHED until all the information required to finalize the design is available. As a Project Manager, what does this tell us about the proper method of executing and staffing a project?

Don’t Staff the Work Too Early

The fact is that once you allow the project to staff up, it is very difficult to back this staffing down.

Allow the information flow to build.

Stockpile.

Make sure you have a reasonable inventory of “information” before you allow the workforce to expand. It’s a lot easier to control the ramp up than it is to cutback the staffing.

Focus on Long Delivery INFORMATION.

It is fairly common to schedule the purchase of long delivery EQUIPMENT as early in the project as possible. Although this is important to ensure an efficient construction schedule, the need to focus on long delivery INFORMATION is equally as important.

Work on the Information you have – try not to guess.

Remember that the larger the workforce, the more difficult to keep them well coordinated. If there are areas of the project that are still not properly defined, keep the design force AWAY from them. If the equipment can vary in size or utility requirements dependent on the equipment supplier, direct the workforce to stay away from the area. The odds of guessing EXACTLY right are poor.

Consider the judicious use of “HOLDS” on documents. If there is an area, processes, or piece of equipment that has not been properly defined, consider placing them on HOLD. Put the HOLD on the engineering drawings and publish them. These HOLDS serve as a method of informing both the internal team, and the Owner, of areas that need attention to allow the workforce to proceed efficiently.

Conclusion

The flow of information on a project, the accuracy of this information, and timely decisions is the most important factor impacting the efficient engineering of a project. The fact that a schedule completion date is looming ahead does NOT, by itself, dictate the staffing requirements. Without the proper information, the end can NEVER achieved.

The workhours and time duration required for every given task are highly influenced by the amount of information available. Strategically, it may be wiser to wait on staffing a task until more information is available and investing more effort in obtaining this information, than simply staffing per the schedule.

Regardless of when you start the work, it cannot be FINISHED until all the information required to finalize the design is available.

Why the strained relationship between these two parties?   There are two reasons:

1. An inherent lack of respect for the value the other party brings to the table, and
2. Fear of having weaknesses or errors exposed to the Owner by the opposite party.

The Engineer

The engineer’s role on a project is to develop a concept to a level of design detail sufficient for the Constructor to convert the concept into “iron and steel”.  The engineer is legally responsible for the technical suitability of the project.  He dictates to the constructor EXACTLY what to build.  It is not surprising that the constructor often feels like a “second class citizen” under this arrangement.  

The constructor  feels he has something of value to offer the project.  He believes his knowledge and experience, his understandings of cost and schedule, can make a difference in achieving the Owner’s objectives.  The constructor wants a place at the table and is often left out or overlooked during the early phases of a project were his input could help the most.  It is not uncommon for a project to be fully developed including budget and schedule before theConstructor is ever involved. 

The constructor’s minimal involvement at the early stages of a project result in a the Constructor feeling less than an equal partner in the project relationship initially.  This balance, however, shifts as the project progresses.

The Constructor

The Constructor’s role is to facilitate the plan that is defined by the Engineer’s drawings and specifications. 

The Constructor converts the concept into a “breathing entity”.  He singularly carries the project across the finish line.  Although he doesn’t have the Owner’s “ear” at the beginning of a project, he typically has direct contact with the Owner during the longest phase of a project (Construction) AND he often has his “ear” at the end of the project.

The Constructor has the ability to be the “savior” of a project – often at the expense of the Engineer.

During the execution of EVERY project, some unanticipated problems will arise:  Late delivery of equipment, unexpected weather conditions, problems acquiring the desired components, etc..  At this time the Constructor is often asked to address the problem or alter his original construction plan to accomodate the problems.  The Constructor can, and often does, manage to successfully maneuver around these problems.  Often, however, he uses this opportunity to emphasize his importance to the project.  It is not uncommon, as these problems arise, for the Constructor to take “pot shots” at the Engineer.   He will point out the impact on cost and schedule when drawings or equipment are delivered late.  He will chastice the Engineer for not anticipating these problems, or the Engineer’s unwillingness to participate in problem solving in a timely fashion. 

 These unanticipated problems are common during the execution of a project.  The Engineer has learned to be wary of the Constructor.  

Reality

Whether factual or not, there is a mutual lack of trust and respect between the Engineer and Constructor. 

When the Constructor asks to deviate from the original plan, the Engineer suspects the constructor is trying to cut corners in order to improve his profit.

When the Engineer insists on reviewing the Constructor’s progress, the Constructor questions his motives.

The fact is that many Engineers are not properly trained in construction techniques and not appreciative of the challenges of building a project.  Similarly, constructors do not fully appreciate the Engineer’s responsibilities, nor the impact that “minor” construction deviations may have on the overall project.  

Due to this uncomfortable relationship between the Engineer and Constructor, we have developed demarcation lines of responsibility and communication to define each party’s responsibilities.

In order to defend each other’s “turf”, the Engineers and Constructors have built an arbitrary wall between both parties.  This wall is often referred to as the “Engineering Deliverables” i.e. the drawings and specifications.

Although these “Deliverables” serve as a useful division of responsibility, they also act as a WALL that prevents each party from developing a better understanding and respect for each other.  Often this WALL, if not breached, contributes to project inefficiencies. 

This article is not intended to serve as a detailed definition of “engineering deliverables”.    The number and type of these deliverables have not changed significantly for decades.

Decades ago, capital projects were typically executed at a more leisurely pace.  It was not uncommon to complete the entire engineering of a project before construction was even started.  In the 1970′s this approach was altered due to a highly inflationary period in which time was literally money.  This decade marked the emergence of a new method of executing projects focused on reducing the overall schedule time.  This method required an overlap between the engineering phase of a project and construction.

As the drive to reduce overall schedule accelerates, the original engineering deliverable breakdown was subjected to greater pressure.  The constructor required engineering deliverables sooner, and the engineer reluctantly began to further breakdown these deliverables to support the project schedule.

 This continued pressure on the engineer to deliver documents to the field in support of the project construction STRESSES the already uncomfortable relationship between Engineer and Constructor.

Today, the Engineer is asked, correctly, to breakdown the Engineering Deliverables into smaller and smaller packages to support the ability of the Constructor to compress the schedule. 

When this approach is not enough, the Engineer may be persuaded to make multiple releases of these deliverables to further compress the schedule.  For example, the piping drawings may be released “For Material Procurement”, and then released “For Construction”.  These steps make sense, but all parties need to understand the INTENT of the release and HONOR the intention.  The Engineer is painfully aware that once the drawings are released to the Constructor, the Constructor may use the documents for purposes that the release was not intended.

Both the Engineer and the Constructor are guilty of not recognizing or disregarding the consequences of using these early drawing releases for purposes beyond the intent. 

The Constructor often mobilizes on site before the engineering data is available to effectively allow the start of construction.  This practice often results in the Engineer issuing “preliminary” information to meet the constructor’s demands.  This “preliminary” information often results in errors in the field and consequent added costs and schedules extensions.  

Both parties refuse to be honest with each other.  Engineering will hoard information that IS available for fear Construction will act on the information too soon and then hold it against them.  Construction demands ALL the information immediately even though they don’t have enough manpower on the site to start ALL the tasks simultaneously.  Both parties distrust each other.  Neither party will compromise for fear of being taken advantage of.

Contracts between the Engineer and Constructor are often fraught with threats.  A recent contract between and Engineer and Constructor imposed daily penalties on failure to meet schedule commitments.  At the end of the project, the Constructor used an expediting report for purchased equipment as the basis for penalties.  The expediting report scheduled every activity the Engineer was going to do or be responsible for:  Prepare specification, Release for Bid, Quotation Analysis, Purchase Requisition, Purchase Order, Approve Vendor Drawings, Fabricate Equipment, Deliver on Site.  There were over 500 pieces of equipment that were being tracked by this report.  This amounted to over 4,000 individual scheduled dates.

At the end of the project, the Contractor claimed that 1,000 dates were missed with a consequent penalty of approximately 1,500 days of penalty.  The project duration, from start of engineering to end of construction was less than 540 days yet the Contractor was claiming more than four years of delays!

A marriage of necessity

There are many opportunities to improve project performance on cost and schedule if the mutual distrust of Engineer and Constructor can be resolved.  The first step is to establish reasonable respect between both parties.  If a project is to be truly successful, both parties must be successful.  Both will have significant challenges to overcome on any project.  Working together, these challenges can often be overcome.

FIRST, both parties must LEARN their partner’s business!  This shouldn’t be a superficial education.  An engineer is not a qualified engineer unless he has spent some time in the field as, at a minimum, a field engineer.  No less than six months, preferably for a year – From beginning to end of at least one project.

A Constructor is not a qualified constructor until they have spent some time in the Engineer’s office.  This applies to craft supervisors and up!  Once again, this should be from beginning to end of at least one project.  They need to understand the impact an engineering decision may have on the final product.

SECOND, jointly develop the project schedule.  Both parties must participate.  Don’t be surprised at the first outcome of a project schedule.  The writer has been involved in this effort innumerable times and the initial project schedule NEVER meets the project objective.  Engineering always takes too long and so does construction.  Once the initial schedule is developed, both parties can negotiate with each other to meet the final objective.

Look at the critical path.  Breakdown critical path elements into additional details.  Look at alterning “traditional” procedures that can reduce the overall duration. 

Although the critical path elements are important, don’t overlook the other items.  Make sure both engineering AND construction resource load the schedule to ensure that people are available and can be introduced into the project on a reasonable ramp up rate.

Break the project down into sufficient detail to allow as much flexibility in staffing as required.  One need not issue ALL the concrete foundation drawings at the same time, HOWEVER, both parties need to be able to predict which drawings will be issued and when.  If construction expects the drawings and they don’t arrive, they must scramble to keep their workforce gainfully employed. 

In reviewing the schedule, both parties must discuss “float”.  It is important for both parties to understand that the schedule “float” is not the singular possession of either party.  Both the engineering manager and construction manager must understand that they must communicate regularly, with the schedule as the roadmap, in order to forewarn each other of potential schedule issues.

LASTLY, but most importantly, review the Engineering Deliverables and the terminology associated with the drawing.

It is important for the Engineer to understand WHICH drawings are used by Construction, and WHEN.  Both parties should also consider the “releasing” of these documents.  Can additional document releases IMPROVE the overall schedule?  Does the Constructor truly understand the level of information on each of the releases?  Is it clearly understood that the use of these early releases WILL result in rework and inefficiencies?

Conclusion

The engineer and constructor are both required in order to complete any project but their mutual distrust of each other continues to be a significant roadblock to achieving efficient and cost effective project execution.

Few, if any, engineers OR constructors have had the privilege of working on BOTH sides of a project.  There are enormous opportunities to improve project performance when these parties plan, communicate, and execute together.

The fact is that the Engineer’s product has NO VALUE until it is built, and the Constructor can’t deliver anything without the Engineering product.

They are confronted with problems and are expected to provide solutions.

That is their training.  This is the career choice they made.

The byproduct of this constant search for answers is their never-ending search for the BEST DECISION.  The Perfect Solution.

After decades of experience I must confess that when it comes to Project Execution, there is no such thing as the BEST DECISION.  There are too many variables that interrelate.

What engineers must LEARN is, when it comes to designing a project, there are many GOOD Decisions and some bad decisions.

What engineers must LEARN is, regardless of what decision is made, there is ONE WAY to make a GOOD Decision BAD!!

Regardless of the decision, regardless of the direction a project takes, the BEST way to make a GOOD decision BAD is to REVISIT IT!

The art of managing a project is to take enough time to make reasonably good decisions and then NOT TO REVISIT the decisions.  If the Engineer didn’t come up with the idea early enough, he needs to save the idea until the next project!

Engineers are notorious for questioning reasonably good decisions well after the fact.  Arbitrary CHANGE is POISON to a project.

Take enough time to make GOOD, “well-thought-out” decisions and then DON’T LOOK BACK!

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. 

1. Written description
2. Physical Layout
   1. Site Plan
   2. Building Layouts
   3. Equipment Arrangements
   4. Process Flow Diagram
   5. Piping and Instrumentation Diagram
   6. Electrical Single Line
   7. Equipment List
   8. Instrument List
   9. Process Control Philosophy
   10. Control System requirements/Supplier
   11. Equipment
       1. Data Sheets
       2. Price Quotation
       3. Equipment Delivery Quotation
       4. Design Criteria
       5. Project Schedule
       6. Project Capital Estimate
          1. Estimate Assumptions
          2. 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

A simple concept that can be applied to many aspects of one’s life. For instance, how do you satisfy your employer? Meet or exceed expectations? How do you satisfy your children? Meet or exceed expectations? How to you satisfy your wife? Your co-workers? Your employees?

A simple concept. Not so simple to achieve.

In the case of satisfying a client, there are two, not so obvious, issues that need to be addressed: (1) Who IS your client, and (2) What are his expectations?

Who is your client?

This is not always an obvious answer. Often times you have a contract with company “XYZ” that is being administered by one or more parties. The “client” is the one or more people that will ultimately decide whether the project is “successful” or not. The “client” is the individual(s) that determine whether you will have additional contracts with this company. The “client” may be the one that is capable of campaigning for you in your company or his.

Clearly there are a number of parties within company “XYZ” that may be your client. In fact, the “client” may not even work for company “XYZ”. The “client” may be someone within your own company! If your company is focused on protection of profit margin more than ensuring that the Owner is satisfied with the effort, the “client” may have to be your own management! You better know this before you begin to execute the work.

In many cases, the “client” is a combination of people. Before you start the work, you need to come to a conclusion of “who” the client is, or maybe the prioritization of who the client is. For instance, you may conclude that the Owner’s project manager is your first priority to satisfy, followed by the Owner’s operations manager, and then the Owner’s maintenance manager. It is important that once you have formed an opinion of who the client is, you communicate that both internally and externally.

It is suggested that you don’t come to the conclusion of “who the client is” without sharing your thoughts with the Owner. If you do this tactfully, you often help the Owner recognize the sensitivity of this issue. The Owner may help you categorize who in his organization is “most important”. Of course he typically is going to tell you that he is the deciding vote, but your addressing this issue with him will help him understand how critical this is to HIS success, and how sensitive you are to meeting HIS expectations.

When conflict arises, you can return to these discussions with the Owner. You can help him recognize that some decisions will ultimately satisfy one group in his organization while alienating others.

Let the Owner shoulder some of the responsibility for managing expectations.

What are the Expectations?

Not a simple question but, once again, a question that must be asked and understood PRIOR to starting the work.

What shouldn’t be missed in this part of the exercise is that it is a TWO part issue. FIRST, understand the expectations. SECOND, if the expectations are unrealistic, MODIFY the expectations to something that can be achieved.

The second part of this issue is the part that is overlooked often and ultimately results in failure.

UNDERSTAND THE CLIENT’S EXPECTATIONS

FIRST, understand the expectations. Ask the client – he’s the one that ultimately judges whether he is satisfied or not. Attempt to QUANTIFY the expectations. Don’t allow them to be subjective. For instance, how important is it to finish the work within the original budget? More or less important that finishing within schedule? Is two week’s improvement in schedule worth an overrun of the budget? By how much? One percent? Ten percent? Is early completion worth anything? How about completion below budget? Under budget better than early?

Expectations can typically be quantified very easily. They often involve cost, schedule, and quality of the installation. Quality is typically a given and must be focused on early to properly understand. Quality is often more important to those that ultimately are not judged as the high priority “client”.

While you are attempting to quantify “expectations” use this time to help address YOUR expectations of the client. The issues that often influence your ability to work within budget and schedule are untimely “changes”, and the Owner’s inability to review and approve in a timely manner. Make sure that the client understands how crucial this is to your ability to satisfy him.

MODIFY THE EXPECTATIONS TO SOMETHING ACHIEVABLE

More important than understanding the client’s expectations, is to MOLD these expectations to something that you can succeed at.

If you estimated the task to cost $10,000 and the “client” expects it to cost $5,000, there is no purpose in your proceeding into the work. You have already failed.

It is up to the Project Manager to sell the Owner on expectations that are reasonable. One can either convince the Owner that $10,000 is the best that he should hope for, or change the scope of work to something that can be delivered for $5,000. If you fail to convince him, or modify the work product, you can never succeed.

The success of many companies and people are based on this SINGULAR PREMISE. There are many people that are truly unspectacular other than their ability to sell low expectations. If an Owner is convinced that a project would be highly successful if it can be completed in two years, and you manage to complete it in 18 months… you are a HERO! Don’t undersell yourself. Try to make it easy to succeed!

Communicate

This is the most important aspect of “Meeting Expectations”. If you now know WHO the client is, and what his EXPECTATIONS are, you need to clearly communicate this to your team. It is no good for YOU to understand the client and expectations, if your team is working for their OWN interpretation of who the client and expectations are.

This is a very common problem in engineering companies. It is probably the nature of an engineer. They have an opinion and they tend to be very pig-headed about it. They tend to know, better than the Owner, what the Owner wants or needs. Or they have a relationship with the Owner’s maintenance manager and they are responding to HIS interpretation of success instead of YOUR interpretation of success.

The Project Manager is responsible for steering the effort toward the objective. He needs to clearly communicate to his team. He needs to SELL his understanding of the client expectations to the team. The Project Manager needs to constantly monitor the individual efforts to ensure they are working toward a common goal.

Conclusion

The concept is simple. Meet or Exceed the Client’s Expectations.

The techniques to accomplish this concept are far more complicated: Listen, Interpret, Prioritize, Negotiate, Modify, Communicate.

Based on the above definition, an engineering company provides a service.  Arguably, a construction company provides a service as well.

There are those that would argue that an engineering company provides a product.  They do, in fact, produce drawings, specifications, and reports.  But each of these are simply a depository for the labor of engineering.  A previous employer of mine once commented that all of his assets left the building at 5 pm every evening and, he hoped, they would return at 8 am the next morning.

The truth is that most engineering companies (and construction companies) have NO assets other than the people that work for them!  This is a simplification of the business but is basically true.

Managing a service company is straight forward.  One hires people, and sells their efforts at a price that exceeds the cost of thier salaries.  Simplistically, if the income from thier effort exceeds the cost of the salaries, the company makes a profit.

There are more issues than these that I will cover in detail in a separate section, but for the purposes of this writeup, the base concept is to sell the labors of your employees for more than these labors cost.  Hence a profit.

Now that we understand the basic principles behind running a service business, let’s see what you, as a CONSUMER, can learn from this principle.

Most of us do NOT do business with service companies that often.  Most of the things we purchase every day are PRODUCTS, not SERVICES.  Hence we have a lot of experience working with businesses that produce PRODUCTS but little working with SERVICES.  When we have to purchase a SERVICE we often are unfamiliar with methods of purchasing this service properly.  Before we address this issue, we need to have a deeper understanding of how a service business is managed.

MANAGING A SERVICE BUSINESS

As stated previously, a service business makes money by recieving more money for the effort of its employees than is paid for their salaries.

In its simplest form, an employer pays an employee $10 per hour and charges $15 per hour for his services.  A gross profit of $5 per hour.

The simplest way for a service business to charge for their services is to charge the consumer by the hour.  Most service companies prefer this method.  It GUARANTEES them a profit!  The plumbing company charges you $60 per hour and pays the plumber $20 per hour.  A GUARANTEED profit.

From the consumer’s perspective, what is wrong with this arrangement?  Well, the consumer doesn’t know how much the repair is going to cost!  Will it take one hour or ten hours?  Will it be $60 or $600?  The consumer is used to purchasing PRODUCTS not SERVICES. 

From the employee perspective, what is wrong with this arrangement?  Well, what if the employee is an EXCELLENT plumber and the other employees are mediocre?  Will the plumbing company pay this employee more because he is more productive?  THE ANSWER IS NO! 

If the plumbing company makes money for every hour BILLED, then any good business man understands that the highly PRODUCTIVE employee finishes the task in LESS hours.  LESS HOURS MEANS LESS PROFIT!  The value of a more productive employee in a service business that predominantly sells services BY THE HOUR is LESS!!

The simply fact is that the objective of a service business THAT SELLS BY THE HOUR is to employee the least productive people they can find!

 Although the free marketplace tends to balance this tendency out, one must be cognizant that purchasing services BY THE HOUR provides a clear incentive for the business owner.  Clearly if a business ultimately develops a reputation of providing “unproductive” services, the business will fail. 

What should the Consumer learn from this example?  Well if you call a Plumber for help, and the problem is obvious (i.e. the water heater needs replacement) and he is UNWILLING to give you a firm price, then go somewhere else!  He doesn’t have faith in his employees to complete the task in a reasonable, predictable number of workhours!

Most service businesses have to be able to provide services under BOTH contract styles: By the Hour, and Fixed Price.  As such the business must be managed to support both contract styles.  What should the consumer learn from this?

Well, if you are willing to contract by the hour, the employer will be happy to provide the services.  Any of his employees can satisfy this need.  In fact, the least productive employees will provide the BUSINESS with the greatest PROFIT.

If, however, you want the service for a FIXED PRICE, the business does not have as many options.  Clearly the most productive employee completes the job in the least number of hours, hence the lowest cost to the business.  Chances are that your work will be assigned to some of the most productive employees to maximize the profit to the business.

LESSONS FOR THE CONSUMER

1. Beware of the service business that is ONLY willing to provide you services on an hourly rate.  There are no incentives for the business to minimize the number of hours to be expended in completing the work.
2. The most productive employees are not likely to be assigned to the hourly contracts.  They need to be saved for the more demanding fixed price work.
3. If the consumer contracts by the hour, the responsibility for MANAGING this work falls on the shoulders of the consumer.  The business gains nothing to ensure the work is done efficiently – they actually lose profit.

LESSONS FOR THE EMPLOYEE

1. If your Employer only contracts hourly, your value is NOT enhanced by your being more productive.  If you are more productive, you are actually LESS valuable.
2. If your Employer only contracts hourly, there are NO incentives for your employer to keep you during lean times.  You are easily replaceable.  You represent only “so many pounds of meat” on a seat.
3. There is very little likelihood of “job security” with this employer.