Engineers…they are the people who design, build, or maintain engines, machines, or structures. They fix things that are broken and typically look for solutions rather than creating problems. Some engineers proclaim themselves as being “solutions driven”…but are they? Solutions driven people work proactively to resolve problems. Individuals will hunt for the solution while a team will band together and work diligently to find it. To them, finding the solution is paramount but without consideration of other aspects the time and effort expended may be disproportionate to the value created. The real issue is not just about finding the solution but defining the problem. If it’s not fully defined the risk of a greater difficulty being created and jeopardizing a project outcome can occur.
Project Problems
Problems can arise on any project. There may be unclear project goals, unrealistic deadlines, ineffective communication, inadequate risk appreciation, and inappropriate resources and budget. We also have change because of overt variations, uncontrolled scope creep and, sometimes, self imposed cock-ups.
Despite the reason for changes there will, inevitably, be the need for the resolution of some technical issue or other. These, in turn, may affect the project in terms of increased costs, delays, and disruption but also future operations and maintenance. And in resolving the issues it will often fall on an engineer or engineers to provided solutions and, just as importantly, for the Project Manager to manage them.
Engineers
Engineers are trained through various means including academic study, vocational courses, apprenticeships, and hands-on experience. Usually, they approach things in a logical and systematic manner based upon established and oftentimes rigorous practices rather than a hit and miss approach.
When problems arise, most engineers will want to solve it, or at least try. They will work wholeheartedly to resolve matters, and this can be costly in terms of both time and effort. There is also the cost of wasted effort if alternatives are not considered or constraints are not recognised. If engineers jump to an early conclusion or make matters more complex than they need to be, or work in isolation with their own opinionated views we have what is known as “Engineer’s Disease.”
Engineer’s Disease
Before computers (i.e. BC) and armed with trig tables, slide rules, and graph paper life was fundamentally simpler. Today with computing power almost beyond imagination and incredible analytical software many engineers will turn to sophistication rather than simplicity to get the best solution even though a good one will be good enough. However, with sophistication can come complexity and the more complex an issue the harder it can be to find a solution. In respect of problems Einstein once said, “If you can’t explain it simply, you don’t understand it well enough” and simple communication is one cure for it.
Engineers
In general, can be notoriously bad when it comes to communication. The use of technical jargon and trying to explain complex ideas in layman’s terms to non-engineers can lead to frustration on both sides. Effective communication becomes difficult and, ultimately, can stop.
But communication is essential to understanding by both the sender as well as the receiver. A former CEO of IBM, Thomas J. Watson, said that “The ability to ask the right question is more than half the battle of finding the (right) answer.” and finding the right question to ask also requires communication.
Communication
The proverb, “A problem shared is a problem halved” reminds us that by talking things through we can have a better understanding of them and even find solutions. However, for some of our ‘solutions driven’ personnel actions speak louder than words so rather than talking they rush to a solution without recourse to discussion. In so doing they may fail to fully understand what they are trying to solve. As they focus on a solution, they cannot see the bigger picture and may inadvertently ignore the possibility of wasted time and money. They also ignore the views of other people and in so doing miss the opportunity to consider alternative approaches as well as the risks that may result.
“Knowledge is power” and in any organisation there can be a reluctance to share matters, particularly if problems are self imposed and there is a fear of blame. If problems aren’t shared then the project team are kept in the dark or, in some cases, can be blissfully unaware of a problem until it hits the fan. However, our engineer’s who are in the know will have hunkered down and beaver away in a communications blackout.
Project Engineer Syndrome
Sharing is the proverbial way of finding a solution. However, sharing can also be seen as an admission of not being able to resolve something and asking for help. If pride gets in the way of sharing, then problems that should be escalated are kept under wraps. Unfortunately, with pride there can easily be a waste of precious time until, at best an answer is provided or, at worst, pride is swallowed and there is a cry for help. Inevitably, expeditious solutions are wanted and demanded but they may end up being cheap and nasty.
Quick fixes may be heroic and save the day but if not properly thought through they may not only be abortive but may make matters worse and waste time. Sometimes ‘solutions driven’ personnel may seek solace with like minded individuals and a ‘solution’ is arrived at, but arrived at in splendid isolation. This solution, rather than a well-rounded answer, is a ‘position’ and, like may positions is defended. In defending their position and far from resolving the issue at hand our ‘project engineer(s)’ embroil the Project Team in unnecessary debate because of a combination of arrogance, pride and poor communication.
Conclusion
Project Engineer Syndrome is about sitting on a problem and missing the opportunity to talk it through with other people. This prevents others from contributing to its understanding, knowing what has to be solved, and optimising how that solution may be best. I
n 1624 the Tudor poet John Donne wrote that “No man is an Island” which, although written 400 years ago exemplifies that on a project it’s a team effort rather than individualism. We should also remember Chaucer’s words that “Time and tide waits for no man.” A Project Engineer who procrastinates over sharing a problem, or a Project Manager who demands a solution rather than defining the problem may well miss their collective boat and everybody can be left high and dry.
Bio:
Malcolm Peart is an UK Chartered Engineer & Chartered Geologist with over thirty-five years’ international experience in multicultural environments on large multidisciplinary infrastructure projects including rail, metro, hydro, airports, tunnels, roads and bridges. Skills include project management, contract administration & procurement, and design & construction management skills as Client, Consultant, and Contractor.