Project delays: Identify the issue and keep the customer happy
Every person working on a project should be able to answer these five questions: Who? What? When? Where? and Why?
If you have ever studied the newspaper business, then you have probably learned that every story must answer these five questions: Who did the deed? What did they do? When did they do it? Where did it happen? Why did they do it?
The same is true of working on projects; every person working on the project must be able to answer those same five questions about their role on the project in order to be successful. They should also be able to answer those questions for the other people on the project to prevent gaps and overlap.
So let’s break this down a bit. There’s very little difference in saying to a customer “I forgot” and “It’s someone else’s mistake”—in their mind, the “who” is you. Either way you have a disappointed and often unhappy customer.
Similarly when it involves the “what,” what was it someone forgot to do? It doesn’t matter what you forgot, just the fact that you forgot it.
“When did it need to be completed by,” is one of those questions that does become critical the further and further you get into the project. Every topic on the project schedule has a well defined due date and maintaining that is a key performance indicator of the project.
For most projects the “where” falls into two categories: in the design office and on site. The question is still pertinent because if you are not expecting to do something until you get to site, but your customer is expecting to test it before going to the field, you have a disconnect that must be resolved.
Now we come to the one question that may seem out of place on a project, but in reality for controls projects it is a very important question. In fact, before starting to configure any control function it may be the most important question. “Why this control function has to be programmed this way” is a very important question, but one that is often not well understood. Many times the person programming the controls has no clue about what’s going on outside of the controller, so they doesn’t see the importance of some of the choices made during execution. Is the loop direct or reverse acting? Is the final control element increase to open or increase to close? Is the process exothermic? Is the process reaction linear? Is the final control element sized correctly? Is the sensor linear? Are permissives required? How about interlocks? What’s the difference? Does the control need to be failsafe? And the list goes on.
The times I forgot to ask “Why?” were the times I ran into trouble during checkout and startup, usually with the customer asking me the “Why?” questions. Why isn’t that valve doing what I thought it would? Why is that motor not starting? Why is that motor starting when it shouldn’t? Why isn’t it stopping when the level in the tank is too low? Why do I have full flow when the valve is only 10% open? Why does my pump sound like it’s pumping rocks?
What problems might you have avoided if you’d only asked a few more “Why?” questions?
This post was written by Bruce Brandt. Bruce is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
- Events & Awards
- Magazine Archives
- Digital Reports
- Global SI Database
- Oil & Gas Engineering
- Survey Prize Winners