How to avoid project failure

Author : Vance VanDoren, Ph.D., P.E., Control Engineering

07 December 2009

Automation projects don’t always go smoothly. Learn 10 signs of impending failure and 7 ways system integrators say you can stay on track.

Although not an engineer himself, poet Robert Burns once wrote, “the best-laid plans of mice and men go oft awry.” Automation engineers know a lot can go wrong when designing a machine, programming a computer, or building anything that involves automation equipment, computers, and sensors.

Mistakes happen, of course. And, when it comes to computer programming at least, about two-thirds to three-quarters of all projects fail outright or do not meet some of their budget, schedule or functionality objectives. This is the finding of the Standish Group’s annual Chaos Report, which is based on surveys of several hundred IT professionals collectively responsible for thousands of software development projects.

10 reasons for failure
The underlying causes cited by the survey’s respondents have varied from year to year, but these are often the top 10:

1. Incomplete requirements;
2. Lack of client involvement;
3. Lack of resources;
4. Unrealistic expectations;
5. Lack of executive support;
6. Changing requirements and specifications;
7. Lack of planning;
8. Didn’t need it any longer;
9. Lack of management; and
10. Technology illiteracy.

Industrial automation projects may or may not fail as often as software development projects, but the reasons for failure are very similar, according to a less formal survey recently conducted by Control Engineering. All 1,800+ system integrators listed in the Automation Integrator Guide were asked to describe why an automation project might fail, what signs point to impending trouble, and how those problems can be avoided. Not surprisingly, several respondents agreed with the Chaos Report’s finding that “incomplete requirements” is the #1 problem.

As Dale Feldhaus, IP controls department manager and senior associate at SSOE put it, “System integration projects don’t fail at the end, they fail in the beginning due to the lack of focus on and definition of the project goals and integration requirements. By the time the control system integrator is awarded the job, if the following steps have not been completed, or have been completed poorly by the process engineering team, the probability of success is greatly diminished.”

7 ways to succeed
Feldhaus’s steps for project success include:

1. Define project goals;
2. Develop project scope and schedule;
3. Establish multi-discipline project team;
4. Define the mechanical process;
5. Develop functional process controls descriptions;
6. Develop network configuration drawings; and
7. Develop equipment and programming specifications.

Only after all of these steps have been completed by the client’s process engineering team can the system integrator get started with the design and implementation of the automation system itself.

Gordon Kilgore president of CQS Innovation agreed. “If the customer cannot agree on the definition of their needs, we will be wasting time (dollars) either waiting for them to decide or redoing the work when they do decide.” He added that “the best way to deal with that problem is to get a separate time and materials contract for the development of the project spec. Then we can iterate until decisions are made.”

Having incomplete requirements is also symptomatic of a lack of client involvement, said Dick Ciammaichella, director of control system integration for The RoviSys Company. “Sometimes the client does not wish to review and approve functional specifications in the early phases of project before implementation engineering begins. This is a problem waiting to happen because there may be a disconnect in communications, and, at the very least, the client has no buy-in.”

Conversely, too much client involvement can be a sign of incomplete requirements, said Randy Pals senior staff engineer at Ipact. “A customer that forces him/herself frequently into the workings of the project team, especially early in the project, indicates that the requirements are being determined on an impromptu basis as the project proceeds.”

Management issues
Although they ranked as common causes of IT project failure in the Chaos Report, lack of executive support and internal resources were cited only rarely as typical causes for automation project failure.

After all, a system integrator’s business depends on being able to apply “the right resources with the right skills/knowledge to the project,” said Larry Ray, vice president of industrial automation for Maverick Technologies. He added that many of the problems on the Chaos Report’s list can be avoided if “the integrator’s project manager stays on top of the deliverables, anticipating and preventing problems early in the process.”

Several respondents reported that their clients often fail to appreciate how important their own human resources are to project success. In particular, “switching horses in the middle of a project is a sign of potential impending doom,” said Rick Lamb, president of SpecPlus! Automation.

“Switching the interface staff on the customer side (project manager, primary contact, etc.) often results in a re-interpretation of the specifications as the new person may see them, a change in direction for the project, or at least a re-examination of many of the decisions made on the project to date,” Lamb said.

Lamb added that “the only way to ensure continuity after a change in personnel is to have well-documented specifications, meeting notes, records of issues and decisions already resolved, as well as implementing the project according to specific standards for programming methodology, documentation, project management methods, etc. If the customer does not have specific standards, the integrator should provide his own standards and reference examples for the way in which the project will be approached.”

Changing requirements
Re-interpreting project specifications or changing them outright once the project is underway can be as much a sign of trouble as starting the project without clear objectives.

“Frequently changing requirements often means that the customer doesn’t know exactly what he wants,” said Mike Walden, business development director at Control Systems International. “It may show up as multiple revisions to the system architecture drawings, constantly changing I/O list, or the lack of a clearly written functionality description. This is a sure way for the integrator to lose money and for the customer to end up frustrated and late.”

Walden added that this too is a management issue. “The integrator must hold fast to his standard operating procedure to require approved-for-construction drawings or specifications before system development takes place. It is tempting for the integrator to want to be flexible and supportive of the customers frequently changing requirements and offer to keep adjusting functionality until the day before the factory test.”

“But even if the customer is not managing the process, the integrator has to. To do it well, the integrator has to be able to identify a cost associated with constant change. When the customer recognises the consequences of frequent changes, he will ensure that decisions are made quickly and firmly.”

Outside suppliers
The integrators responding to Control Engineering’s survey also cited several warning signs of project failure that are not as common in the IT industry, or at least not common enough to be mentioned in the Chaos Report. Dean Fenton, president of Applied Systems Engineering cited problems with outside suppliers:

• Delivery of critical hardware not on schedule;
• Service contractors not mobilised or started on schedule; and
• Equipment by others not on schedule

To avoid disaster, Fenton advises integrators and their clients to “provide timely support to these outside sources with the information or decisions needed to keep them on-track.” After all, contractors working for system integrators can’t do their jobs without their clients’ involvement any more than integrators can.

A related issue not expressly addressed in the Chaos Report is communications between integrators and their clients and between integrators and their suppliers. Communications can make or break an automation project as reported in “How Communications Help Integration Projects Succeed,” Control Engineering, April 2009.

For example, said John Gunst, packaging systems design manager at Power Engineers, “far too many integrators do not produce documentation throughout the course of the project. That usually means they haven’t really started, but since the client does not speak the controls language, they have no idea nothing has been done.” And without documentation, there’s no way to know if a project is done, let alone successful.

Author Information
Vance VanDoren is consulting editor for Control Engineering. Reach him at controleng@msn.com. He also produces the annual Automation Integrator Guide (AIG) in print and online. The online guide is a searchable online database of more than 1,800 automation system integrators and contract engineers. The printed guide includes Featured Listings, application articles, and the results of the System Integrator of the Year competition. The printed guide mails with the December issue of Control Engineering. Find the online guide at www.controleng.com/integrators.

Make your project work

1. Define project goals
2. Develop project scope and schedule(s)
3. Establish multi-discipline project team
4. Define the mechanical process
5. Develop functional process controls descriptions
6. Develop network configuration drawings
7. Develop equipment and programming specifications

6 legal questions to ask when a project begins to go wrong
When a project starts to go wrong, here are six questions to ask, according to Shawna Meyer Eikenberry, associate with the law firm Baker Daniels, in the firm’s Oct. 12, 2009, Automation Law & Tech Construction newsletter:

1. What does the contract say?
2. What have the parties communicated about the issue in dispute?
3. How can we best document our position?
4. Do we need to make an official demand or request?
5. What are the timing requirements?
6. Do we need a lawyer?

Contact Details and Archive...

• Control Engineering