How to Avoid Project Failure
Automation projects don’t always go smoothly. Learn 10 signs of impending failure and 7 ways system integrators say you can stay on track.
Vance VanDoren, Ph.D., P.E., Control Engineering -- Control Engineering, 11/1/2009
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:
-
Incomplete requirements;
-
Lack of client involvement;
-
Lack of resources;
-
Unrealistic expectations;
-
Lack of executive support;
-
Changing requirements and specifications;
-
Lack of planning;
-
Didn’t need it any longer;
-
Lack of management; and
-
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.”
 One problem with an automation project often leads to another like falling dominos, says Matthew Hartman, manager of engineering at Outbound Technologies Indiana. “Schedule slip is always the first to go. When the schedule starts to slip, that means that somebody has missed the scope. It starts taking longer than expected. Then you add more resources to catch up. Then you miss your budget” and the project fails. |
7 ways to succeed
Feldhaus’s steps for project success include:
-
Define project goals;
-
Develop project scope and schedule;
-
Establish multi-discipline project team;
-
Define the mechanical process;
-
Develop functional process controls descriptions;
-
Develop network configuration drawings; and
-
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 recognizes 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 mobilized 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.
For more advice from the survey’s respondents, see the on-line version of this article at www.controleng.com. For more advice specifically about the benefits of proper planning see “Planning Cuts Automation Project Risk,” Control Engineering, September 2009.
-
I found your article on How to Avoid Project Failure in Control Engineering's November issue very interesting. I really think it is a good interpretation of why and how a project can either fail or succeed. One thing I found interesting was how you explain that a project fails a lot of the time because of a change of personnel during the project or a change of scope during the project. For example, a different PM is brought in, mid project or the owner/client changes his mind about what he wants. I do agree with that somewhat, but sometimes a change of scope or a change of personnel is what is needed to make a project successful. Sometimes, I think it could actually help your project if the project is headed in the wrong direction. I found your article very useful and interesting and I will be reading your future articles.
Robert D'Amico - 2009-14-12 09:23:08 CST -
I cannot agree more on the reasons listed in it. I would just like to point out some aspects regarding the first reason for project failure- 'Incomplete Requirements'. It carries the burden of being subjective on behlf of the contractor. I’m sure, that customer never said: “The project failed because we gave incomplete requirements to the contractor”. It would be ideal if customer was capable to give a full set of the requirements. But if he knows all the detailed requirements, why wouldn’t he do it himself? Quite the opposite; usually the customer finds a company with an expert in the field to pursue their project. I believe it is up to that company to discover and fill in the gaps, to have clear requirements to begin with. It has to be a part of system engineering process. As Theodore Rubin said: “The problem is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem.” In this case, if you have problems with the requirements, first you have to be an expert to identify them and then resolve them and most importantly, plan accordingly.
Armen Amirbekian - 2009-7-12 16:58:41 CST -
While the article was informative and made me think about a lot of my experiences in developing new systems. Our parent company Crossfire Consulting has become scrum masters and agile developers for the specific purpose of avoiding project failures. For us feature creep has been a big issue and our clients have been notorius for expanding the work we do for them. I was wondering if an article about how we are applying these skills would be beneficial.
Our number one client is the Verizon which happens to be moving toward Machine to Machine activities.
I am working on M2M I noticed that your magazine has an article looking at wireless M2M. I would like to invite you to our conference to meet with the wireless M2M speakers at our event.
Carl Ford - 2009-7-12 16:56:36 CST -
I found it interesting that you wrote about the Chaos Report finding that "incomplete requirements" are the #1 problem. The idea that a project missing certain goals or focus in the beginning stages mainly affect how it fails in the end. In working as an Architect in a firm focused mainly in public work such as schools, libraries and fire departments, I find this to be very true. In dealing with unsure clients, mainly boards of multiple people with many different backgrounds they all seem to have different directions and ideas for each project individually. It is very rare that the client establishes a set definition of their needs and are constantly changing the scope of work. These problems lead to many change in the schedule and the budget.
I think it true that some problems can be avoided if the project manager stays on top of the deliverables. But many times it is even beyond the project manager and it is up to the client to deliver the solution, which in many circumstances can affect the schedule with delays if no procedure was ever put into place for such a situation. Beyond this circumstance it is very important to have some sort of standard to go by for each project and to reference similar project notes. It does make sense that even when a client doesn't know what he/she wants then it is up to the integrator to stick with whatever standard operating procedure is in place. Many times even though the clients are similar, their needs and requirements are very different. To establish only one set standard of operation would only be plausible in certain aspects of a project.
Regarding communication with the client I feel that in my field it is standard practice to constantly take notes and document everything precisely for the client. This in turn communicates very clearly to the client their role as to what is needed from them and how the project is running. I feel that communication and documentation are a few of the key elements in creating a successful project from beginning to end.
Cole Podolsky - 2009-7-12 16:54:36 CST -
After reading your article in November's issue of Control Engineering, I found myself reflecting on a project I worked on two years ago. My company was the system integrator for a network of military-deployed communication vehicles for the defense ministry of a small, but rapidly expanding, country. I was a mechanical engineer assigned to oversee various operations in the integration and development of a prototype system.
While that stage of the project was a success, the effort was ultimately scaled back and eventually put on hold. The economic downturn was a major factor, but there were certainly management and communication failures early on that indicated trouble. Of the top ten reasons you listed, two particularly stuck out in my mind. First was a lack of client involvement and second was frequent change in requirements and specifications.
The client was flaky and non-committal to some engineering decisions early in the project, and it was reflected in the constant revision of system documentation and the comments after milestone reviews. The quote in your article from Ciammaichella sums it nicely; “Sometimes the client does not wish to review and approve functional specs... This is a problem waiting to happen because there may be a disconnect in communications, and…. the client has no buy-in.” This was precisely why, even after prototype generation, key components of the system were still being hashed out. This, of course, describes the second point of changing requirements and specifications.
At the time, all fingers, at least the project engineers’ fingers, were pointed at our customer. They were blamed for the time-consuming missions to obtain solutions to problems that suddenly no longer existed. I realize now, through the experience and as a pupil of project management, that the burden of failure fell just as equally, if not more so, on our own management. Failure to take some of the steps that you describe greatly diminished our ability to work with the customer effectively and define project goals. I only wish my managers had a crystal ball, or this article.
Domenic De Rubis - 2009-7-12 16:50:08 CST
How to Find the Ideal System Integrator
06/01/1998A New Name and a New Look
12/15/1998
View All Control Engineering Webcasts from CTL
