Intelligent and motivated consulting engineers have produced countless examples of outstanding, successful projects and yet there are still too many stories of projects where clients don’t achieve complete satisfaction at final delivery.
“We just had a brand-new pumping station built, but we still get overflows in the pond!”
“Shafts are still breaking all the time, even after I had the engineer put in variable frequency drives on all the conveyors.”
“The facility was just built last year, but I have to call for service nearly every day!”
We are all saddened when we hear statements like this, and I have learned that it is often a long road in the project history that leads to a disappointing outcome. Professional engineers need to do their part in understanding and delivering solutions for clients, and there are many excellent consultants out there who do just that. Also, every engineering project has a client who initiates the project; and just like in a marriage, the communication by both parties is integral to the overall success of the initiative. In some cases, the client and engineer may be internal to a common organization, and while this changes a few dynamics, it does not alter the need for proper engagement.
The tips in this article increase your chances of achieving a successful project when using a consulting engineer.
Don’t Rely Only on the Scope of Work
How do you communicate the requirements of the project to your consulting engineer?
One conventional method is to prepare a scope of work paragraph, section, or document. The scope of work may include statements such as:
Upgrade the dewatering pumping system with 500 hp submersible pumps driven by variable speed pumps;
Review the existing structure and upgrade as required;
Provide mechanical drawings including layouts and piping diagrams;
Prepare an electrical drawing set with single line diagrams and motor starter schematics; and
Utilize an Allen Bradley ControlLogix PLC with a 5570 controller to control the new equipment.
In the brief scope of work above, the client is trying to define what they want. These statements are not necessarily wrong, as the client has specific business knowledge and is trying to establish the criteria to achieve a successful project. However, are these types of prescriptive statements, or a list of 10, 100 or 1000 of these statements, going to provide the client with what they need for project success?
Let’s say the engineer designs the pumping system with the 500 hp submersible pumps, VFD drives, and the ControlLogix PLCs. Will the client be satisfied with the completed works? Maybe.
Why is the answer maybe? When it comes down to it, there are higher level requirements that that will determine a project win. What the client may actually need is to:
Eliminate flooding caused by inadequate dewatering pumping capacity; or
Reduce overtime hours due to excessive dewatering system breakdowns.
These higher level requirements are not prescriptive and do not constrain the engineer on design content. However, they do provide clear guidance as to what success looks like. They also offer flexibility on the means to achieve the objectives.
Prepare Performance-Based Requirements
Many of us technical folk communicate in terms of specifics rather than broad intent. While detailed requirements are absolutely appropriate and necessary at certain points; in exclusivity, they may obscure the overall project objectives.
Before engaging a consulting engineer, prepare a concise set of overarching objectives for the project. Consider the benefits that will be provided to you or your organization by the initiative. In the example above, the benefit to the client is not the new dewatering pumping station, but instead fixing the flooding problem. You may even bring the objective to an even higher level by indicating that the goal of the project is to improve annual production capacity by stopping the intermittent flooding caused by inadequate dewatering pumping capacity. These grand objectives provides everyone working on the project, including the engineer, a clear vision of what the project is trying to achieve as well as a measure for success.
In another case, you might think you need a new ultraviolet disinfection facility because the regulator indicated you are non-compliant with respect to specific pathogens. However, the ultimate goal is to provide safe drinking water that continuously meets all regulatory requirements.
The performance-based requirement, if expressed appropriately, provides a clear measure of project success and rarely is solely based upon the installation or construction of an asset. For example, a project could provide a new electrical harmonic filter; however, this alone does not meet any business requirements. The harmonic filter could be turned off and still meet the “provide” requirement! The benefit is not the installation of a shiny new harmonic filter, but rather reduced equipment failures due to improved electrical power quality.
Thus, ensure that your engineer is fully aware of specific and measurable performance-based requirements.
Don’t Exclude Prescriptive or Detailed Requirements
Please don’t eliminate all technical details from your requirements though! While you can’t climb a mountain with binoculars glued to your eyes, they can be invaluable in scouting out the details and planning the path of ascension towards the peak. That planned course will change as you climb, but focussing solely on the summit is just as dangerous as keeping the binoculars affixed to your face!
Include prescriptive requirements where they are helpful. If your organization has had great experience with a specific vendor’s PLCs and your staff have a high level of competence servicing them, then, by all means, include this as a requirement.
If your team finds detailed P&ID drawings useful from an operations and maintenance perspective, then include that in your requirements. In addition, where your organization has specific drafting standards, then add that in your requirements as well.
However, you must realize, that for every prescriptive requirement that you place on the engineer, you as the client are taking some responsibility for the success of that component.
Thus, be careful when including technical requirements that may limit the consulting engineers’ ability to provide an effective, and possibly the best, solution that meets your core goals. For example, if you specify that all flowmeters need to be magmeters, you may get what you state only to find that a magnetic flowmeter does not work well in that application.
I am not endorsing that consulting engineers can neglect their responsibility to provide a safe and effective solution. An engineer who becomes aware of a particular client requirement impeding the delivery of the overarching project goals is obligated to notify the client. The engineer and client can then have a constructive discussion working towards project success. However, clients also need to provide the engineer with a clear picture of the needs and objectives through appropriate requirements definition.
An engineer who is aware of the measures for success is more likely to deliver a solution that the client views as a win.
Requirements Analysis
What if the client does not know what they need?
In some cases, the client may be aware of a problem that needs to be solved but has no definite plan on how to address the issue or measure success. One approach that has been used is for the client to tack on a conceptual design phase to the front end of the engineering assignment. While this is not necessarily a wrong approach, it may not clarify the requirements for the project. This path could lead to a design that solves a problem, but not necessarily the one that provides the most benefit to the client.
Collect Requirements is a specific process that is recommended in the Project Management Body of Knowledge (PMBOK ®) 6th edition and suggests eight tools and techniques to gather these requirements. One of the proposed tools is Expert Judgement, and an experienced professional engineer can help identify the requirements. The engineer may suggest tools, such as facilitation of key stakeholder sessions with and multi-criteria decision analysis to identify and analyze requirements.
It is best practice to complete the requirements analysis process before engaging the engineering team to initiate design. If your company policy requires competitive procurement of engineering, this means that an early phase will be needed. The requirements analysis could be performed internally, or you will need a separate smaller engineering assignment to define the project requirements.
The additional time taken to analyze and define the requirements clearly will be paid off in reduced project risk and a higher likelihood of achieving the desired benefits.
Alternately Develop Long-Term Relationships
I have seen and been part of highly successful projects that delivered client benefits with minimal requirements specification. In some of these cases, the requirements are very coarsely laid out, and may not be much more than:
“We have problem X, can you help us fix it?”
However, in most cases, these wins are part of a continuing relationship between the client and a specific group of engineers. As part of this relationship, the engineers have detailed knowledge of the client, the client’s systems and assets. While not necessarily ideal, a lack of effective communication by clients can somewhat be compensated by developing long-term relationships with a specific consulting engineer who clearly understands the client’s requirements.
However, in current environments of accountability and demonstrated cost-effectiveness, many firms have competitive procurement purchasing policies. This reality is not a negative factor but does necessitate that clients communicate effectively in terms of requirements definition. Alternatively, determine how to procure long-term relationships with engineers who understand the intricacies of your organization and are motivated to help you define the requirements.
Summing it Up
You can significantly improve your chances of project success and reduce project risk if you clearly communicate your requirements to the professional engineer. If using competitive procurement, explicitly state these requirements in the Request For Proposal. Creating these requirements may take time and effort through a requirements analysis process. However, this effort will pay off when your consulting engineer works tirelessly to achieve your core objectives.
Your project should deliver a benefit, and not merely a set of deliverables.
Photo credits:
Photo by rawpixel.com from Pexels.
Photo by Malachi Witt from Pixabay.
Photo by Gerd Altmann from Pixabay.
Photo by Martinelle from Pixabay
Photo by Christina Morillo from Pexels.
Comments