How to Make Your Project Fail

Ten missteps that can spell disaster...and how to avoid them

Share Print Related RSS

 

Too many control projects fail to meet their cost or schedule targets, result in installed controls that fail to perform up to expectations, or simply leave the customer dissatisfied. When this happens the blame is usually placed on difficult technology, software and hardware performance issues, impossible customers, late changes, incompetent engineering organizations, or unreasonable cost and schedule targets. However, most project failures are really failures of project management to recognize and deal with the issues.

No project management effort can enable a project to be done for less money or in less time than is possible. But good project management can recognize staffing, technology, communication, cost, and schedule problems early and deal with them objectively while there is still an opportunity for good solutions. Good management plans for nearly all types of problems before they occur. Overall, good project management can deliver the project that is promised.

With more and more control projects being done lump sum (which shifts the cost risk to the engineering organization) and more done standalone rather than part of a larger, multi-discipline project (which eliminates the possibility of diluting control cost overruns), the pressure to deliver on commitments has increased substantially.

Many engineering organizations have seen much of their control project business change from reimbursable to lump sum only in the past few years; and they are still trying to adjust. Many industrial organization "customers" also are learning how to work under the competitive lump-sum concept.

Control projects are different from other types of projects. An earlier article ["What's So Special About Process Control Projects?" CONTROL--March '03, p43] covered some of those differences. However, like all projects, control projects require knowledge of basic project management tasks.

Control engineers who have held lead roles for years have learned how to do projects, possibly by trial and error, but many still need improvement. Less experienced engineers often have little clue as to the tasks necessary to lead a project. Unfortunately, little information has been published specifically on the management of control projects. Some of the best information is in short courses such as the one offered by ISA (www.isa.org).

The Dubious Top 10 List

Over years of experience in managing projects, I've devised a list of sure-fire methods to kill a control project. Doing even one of the things on the accompanying top 10 list (Table I) can cripple a project; doing several almost guarantees failure.

This list focuses on project and project management tasks and lifecycles rather than the equally important area of general management skills and techniques: things like leadership skills, relationship skills, team-building, conflict management, motivation, meeting facilitation, decision-making, and communications. These general management skills are very important, and lead control engineers should learn all they can about these areas using the books, articles, and short courses that deal with them.

Table I: Top 10 Ways To Torpedo A Project

10.

Keep the plant running and ignore any need for long-term improvements.

9.

Push projects you "know" are good rather than taking the time to do a justification.

8.

Outsource to achieve the lowest possible price, and transfer all the risk to the engineering organization.

7.

Begin detail design immediately.

6.

Keep the design fluid throughout the life of the project.

5.

Maintain an arms-length relationship between the industrial company/engineering organization and control suppliers.

4.

Be optimistic that no problems will occur.

3.

Get the work done first and then see where the cost and schedule come out.

2.

Avoid the hassle of milestone reviews.

1.

Avoid having the engineering team and the industrial company stakeholders talk with each other.

 

In this top 10 list, "industrial company" refers to the ultimate customer of the automation work and includes packaging, utilities, tank storage, warehousing, distribution, detention, building control, and other areas with similar automation opportunities--as well as actual manufacturing.

"Engineering organization" refers to the engineering or engineering/construction organization that designs and possibly constructs the project, whether that organization is inside or outside the industrial company.

Let's discuss them in reverse order.

10. Keep the plant running and ignore long-term improvements.

· Reduce the number of control engineers in the plant to the lowest number possible, preferably zero because they have no real value.

· Encourage any remaining control engineers to work on the crisis of the moment to best support the day-to-day operation of the plant.

· Assume there are no benefit opportunities from new controls since they weren't in the original plant design.

· Don't hire outside help to work on identifying new benefits from controls since no funds are available in the current economic climate.

· Believe that internal staff can do as good a job as any outside help in identifying improved controls, even though they never have time to do it.

· Accept that since this department has not been identified as a growth area for the company, no funds will be available for improvements.

· Ignore any control improvements that are identified since they will require capital, which is not available.

· When outside help is sought for identifying and defining improvement opportunities, use an engineering organization that has a history of selling multimillion dollar systems rather than one that can identify specific, cost-effective benefits.

· If no benefit opportunities are identified that require a project to implement, you will not have to execute the project. The only good project is a dead project.

What should be done: Plant engineers familiar with the operation and trained in identifying benefits are the best source of identifying long-term improvements that deliver real benefits. In fact, this is the only purpose of having plant control engineers. If there are inadequate internal resources, hire outside help.

9. Push projects you know are good rather than taking the time do a justification.

· Decide what new control system or functionality you want and then try to develop a justification for it.

· Focus on making the control system work well (low variability of controlled variables, all loops in highest design mode, alarms rationalized beyond safety needs) since those things are easier to identify and measure than monetary benefits.

· Don't commit to any solid benefit numbers since you will just be expected to meet them.

· Only list benefit numbers in a justification that you have demonstrated.

· If a manufacturing manger in the industrial company likes a project, support it whether it's justified or not.

· Manufacturing managers should not make the effort to study proposed control functionality and understand how it can help the operation. Controls can only be understood by the control engineer.

· Manufacturing mangers should require absolute proof before they will support any new benefits.

What should be done: All projects should have a complete justification based on best estimates of specific benefits--not arbitrarily based on industry benchmarking and also not "proven," since benefits can be really proven only after they are installed.

8. Outsource to achieve the lowest possible price and transfer all the risk to the engineering organization.

· Do only a skeletal requirements definition and work out the details after the engineering contract has been awarded since industrial company engineers are always tight on time.

· Industrial company engineers shouldn't get any outside help to prepare the Customer Requirements Definition because only they know what they want; also, they don't want to give any one engineering organization an advantage in bidding process for the project.

· Completely revise the requirements definition during the bidding process as new ideas are developed and to answer the many bidder questions.

· Engineering organizations should always bid when asked even if the requirements definition is incomplete since in today's buyers market you must bid all projects to try to get work.

· Engineering organization salesmen should bid the job without technical engineering input to save time and cost.

· The industrial company should award the contract to the lowest engineering organization bidder regardless of qualifications since they can't prove that organization cannot do a good job.

· If the start date slips, keep the same end date. It's the job of the engineering organization to meet tight targets

What should be done: Partnerships between customers and engineering organizations will yield the best overall result and give the lowest overall price (and still allow fixed-price contracts).

7. Begin detail design immediately.

· Since projects are often started late but still hold to the original completion date, it is important to get started with ordering equipment, developing drawings, and doing programming immediately to give some leeway on the schedule.

· Engineering organization sales personnel should help by committing to an early production of visible results to impress the potential customer -- like ordering equipment within two weeks of the start of the project execution.

· Management of the industrial company should push for drawing and programming production within the first few weeks of the design to be sure the project is off to a good start.

· There is no need for the customer to complete his input early since he can always make changes after he sees the final design.

· Avoid having experienced engineers involved in project planning so younger engineers will be able to learn from their mistakes.

· When changes are required by the customer, the engineering organization should make a quick guess of the cost and schedule impact of the change so they can give the customer immediate feedback.

· There is no need to prototype systems because they will usually work the way you expect them to work.

What should be done: In control projects more than other projects, it is imperative that a complete overall or front-end design of the project be done before beginning any detail design.

6. Keep the design fluid throughout the life of the project.

· There is no need to make a special effort to get all of the customer input early in the project. When the customer sees the final design, they will be able to really determine what is wanted, and a good schedule will allow time for changes at the end of the design.

· Innovations are very important to maximizing the financial benefit from the project. These innovations,“whether better ways of doing things or newly released vendor product capabilities,“should be incorporated whenever they are identified so the design can be as good and as up-to-date as possible, even if it means changes late in the design process.

Figure 1: Freezing Point

While it's important to consider suggested changes and especially innovations, the design should be frozen late in the front-end engineering to eliminate the cost and errors inherent in changes.

· Construction bid packages need only cover the basic information that needs to be built. Details can be identified for the construction contractor anytime during construction.

· If all of the design details are not completed before checkout, they can be completed easily in the field. In fact, many design details are difficult to pin down before actual field operation.

· The engineering team should always adjust the project scope and details to give the customer everything they want,“whenever the customer identifies desirable features--or the engineering organization may not get future work from the customer.

What should be done: Consider all innovations until late in the front end engineering, and then freeze the design (Figure 1) to eliminate the cost and errors inherent in changes. Make sure all aspects of the design are completed and validated prior to installation in the field.

5. Maintain an arms-length relationship between the industrial company/engineering organization and control suppliers.

· Make sure the competitive bidding process is completely objective by not talking with suppliers before bids are requested.

· Industrial companies should not enlist the help of any engineering organization to help scope and justify the project or develop the Customer Requirements Definition since they do not know the plant as well as the industrial company personnel and it would give that engineering organization an unfair advantage in bidding for the work.

· Industrial companies should follow the rule that the worst engineering group is the one they used last and the best one is the one they haven't used yet. This ensures that they will never use the same engineering group twice.

· Don't ask suppliers too many questions or you may learn things about system performance that will upset the project plans.

What should be done: Partner with suppliers by making early or multi-project supplier selections so the suppliers can work to help optimize the design and achieve the lowest overall life cycle cost.

4. Be optimistic that no problems will occur.

· Risk is unavoidable so there is no reason to worry about it.

· There are so many things that can go wrong on a project that it is impossible to consider all of them in advance.

· The only thing you can do with unexpected events is to deal with them when they arise.

· Assume there will be no errors in programming until proven otherwise at start-up.

· Assume that others whose work interfaces with the work you are doing will know what to do to properly mesh with your work.

· Always assume that vendor specifications and features listed in their literature are true as written and that the equipment will perform as promised.

· Know that the vendor meant for you to interpret their documents the obvious way.

· Assume that if you think you may be able to get a software package or hardware system to do a particular interface, information, or control task, you will probably be successful.

What should be done: In the planning stage, carefully consider all the things that can happen on the project and develop alternatives to deal with them. Throughout the life of the project, constantly review this list of risks so problems can be dealt with as soon as possible.

3. Get the work done first and then see where the cost and schedule come out.

· Projects tend to take a certain amount of time and cost a given amount of money regardless of how much budgeting and scheduling is done in advance, so it is not worthwhile to spend much time planning cost and schedule.

· When the start of a project is delayed by slow approval or extensive bid evaluations by the customer but the completion date remains the same, the engineering group should just do the best they can to complete by the desired end date.

· If no schedule can be developed that meets the desired completion date, just give the project your best effort and hope that things work out.

· If during the project the customer determines that an earlier completion is needed, agree to try to meet the date,“the most important thing is to do what the customer wants.

· It is unfair the control work is the last to be completed in a multidiscipline project, so control engineers should avoid being rushed to complete their work.

· If the engineering group sales personnel bid the job for less money or time than seems reasonable, the engineering group should not say anything and just try to meet the bid.

· If too much pressure is put on cost and schedule, the engineering team can always reduce quality to meet the targets.

What should be done: Fully plan cost and schedule early in the project and constantly monitor them using earned value. Whenever deviations are predicted take aggressive action. Never agree to work to a completion date for which no realistic schedule of activities can be developed.

2. Avoid the hassle of milestone reviews.

· Milestones are often not well defined and occur at different times in different parts of the project, so there is no one good time to do a milestone review.

· When milestones are defined, select easy to identify points such as "equipment on order" even if these points in the project do not represent meaningful review points.

· It takes so much time for milestone reviews that it is not really worth the effort.

· The team knows whether they have done the things that need to be done at each point in the project so a formal review is redundant.

· Engineers find that having someone check their work is demoralizing and thus the review is detrimental to morale.

· Team members spend so much time getting ready for the review that the real work on the project suffers.

What should be done: Always hold formal reviews at least at the end of front-end engineering and at the end of the project,“each using an outside facilitator.

 

Figure 2: A Perfect Diamond

To bring focus and balance, the customer and the engineering team should jointly develop and maintain a scorecard of customer satisfaction; and customer representatives should work to support the overall design methodology.

1. Avoid the time-consuming activity of the engineering team and the industrial company stakeholders talking with each other.

· It's usually so hard to get everyone together for a kickoff meeting at the beginning of the project that it is really not worth the effort.

· Even identifying all the key stakeholders in the industrial company is a real hassle; and the industrial company's representative doesn't even want them all in a meeting since they might have different input.

· Discussing plans for dealing with major gaps or inconsistencies in the Customer Requirements Definition at the kickoff meeting is not productive and just gets people upset.

· Engineering organizations should assume the customer knew what was being requested in the Customer Requirements Definition and the customer included in the CRD everything that was wanted so there is no need for further reviews with the customer.

· Customers are more interested in a good project than anything else, and the engineering organization knows better than anyone else what it takes to have a good project, so it is not really necessary for the two to talk very often. The engineering group should just deliver a good project and the customer will be happy.

· It's best to wait until the design is under way to get the varied customer input in the industrial company because the users are best able to identify what they don't like after they can see some design output.

· Don't invite the customer representative to the engineering team project meetings since it is better for the customer not to know about any problems.

· The engineering team should not let the customer representative see the design before it is completed since he will just want to change things.

· Demonstration of the integrated system to the customer representative should be avoided since it takes too long and the system will probably fail and give a bad impression.

· Industrial companies should assign a new employee as customer representative so he/she can get experience; and they should change the customer representative once or twice during the life of the project to give others a chance at the experience.

· The lead control design engineer in the engineering organization should not return customer phone calls too quickly or he/she will assume that you are not busy.

What should be done: Engineering organizations must put the customer first (Figure 2) but still balance customer satisfaction with scope, cost, and schedule.

Vernon L. Trevathan, PE, PMP, has worked in process control and project management for 40 years, mostly with Monsanto in engineering and manufacturing management positions. He is an ISA Fellow, currently consults and teaches in project management for control, and may be reached at trevathan@ieee.org.

Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments