 |
Arbitrarily, process leads can be categorized into three different sub-categories or levels. Level one process leads are those who directly interact with the client to achieve the results required of the project, and are therefore accountable for any and all mishaps. Additionally, these leads supervise other lead process engineers who in turn supervise a team of their own.
In the second level, process leads only supervise a group of lead process engineers in charge of their own teams but they don’t communicate with the client directly. At the lowest level, process leads are in charge of a group of non-lead process engineers. Each of the process engineers in levels two or three can be named as sub-leads.
In this article, we are mainly focused on groups two and three and will not discuss the relationship between the process lead and the client.
Every lead must satisfy project needs, team needs and the individual needs of his or her team members. The focus of this article is on project needs.
Project needs
Each project has three main aspects: quality, cost and schedule. A project should be done with the quality required by client (which is not necessarily the “highest” quality) in the specified time and for the cost anticipated. Violation from any of these aspects will decrease the success of the project. A process lead addresses these requirements by doing three things: Planning, budgeting, and scheduling.
Planning means assigning the right person to the right task. This can be done by realizing each person’s skills (and desires) and having a clear understanding about the nature of each task.
Scheduling tasks means preauthorizing each task to meet the project deadlines.
Budgeting can be money budgeting or man-hour budgeting. In man-hour budgeting, a process lead should be able to estimate the required time needed to finish each task.
Planning: Person for the task
Process engineer’s skills. Engineers are commonly categorized into three levels: senior, intermediate and junior. A balance must be created in the mix of each of these categories within the team.
At the same time, however, it may be more beneficial for the lead to categorize his or her team within four other categories, as follows:
1. Group one consists of individuals with the ability to both determine the methodology in which results can be achieved as well as the skills required to do so.
2. Group two consists of individuals with the skills required to achieve results once they have been given the methodology in which it can be done.
3. Group three consists of engineers who require both the method, and the means to do so, perhaps through an example or demonstration.
4. Lastly, group four consists of engineers who require the method, the means, an example or demonstration, and step-by-step supervision to ensure the accuracy of their results.
Another way to categorize process engineers is based on either their capability to work in front-end engineering design (FEED) and Pre-FEED stages of a project, or their ability to work in the detailed engineering stage of projects. Generally, process engineers who work in FEED/Pre-FEED stages are more senior-level engineers. They are the engineers who have the high level of skills in doing studies, cost estimations, calculations and so on. Usually they are engineers with expertise in one area of the chemical process industries (CPI). For example we can have a process engineer for FEED stage of a petroleum-refining, water-treatment or ink-making project. It not popular to have a process engineer in FEED stage to be able to work in two totally separate process industries.
On the other hand, process engineers in the detailed engineering stage are more “general” process engineers with less experience or seniority. Generally they are good in piping and instrumentation diagram (P&ID) development and calculations. To be a good process engineer, it is good to have a mix of two areas of process engineering. For an engineer working exclusively in FEED/Pre-FEED stage of project, it is difficult to design a plant with good operability.
Specialists versus generalists. When considering specific task assignments, the lead must determine whether his or her team members are specialists with experience in only certain topics or generalists with a less thorough knowledge of all general topics. It is most efficient to encourage semi-specialists who possess a general understanding of all topics as well as thorough understanding of one or two limited topics. In this way, we are “building” a person who can give specialist ideas in some topics, while at the same time preventing a major loss for the group after he or she might leave the group. One way of “building” such persons is by assigning 60% of the tasks to a person in one topic.
Information routes in a team. There is an inherent executive hierarchy in the workplace where the individual at the top (hereafter known as level A) oversees the few immediately below him or her in the pyramid (level B), and each of those individuals supervise those immediately below them (on level C). As a result, it is more efficient for each person on level C to abide by a “filtering rule” that requires only the result of their work to be reported to individuals in level B, whose knowledge of the level-C individual’s process may be unnecessary and unnecessarily time-consuming. Subsequently, the persons on level B will only report their results to level A, foregoing the disclosure of any unnecessary details.
Conversely, when assigning tasks the person on level A will present the supervisors on level B with a vague idea of what he or she requires of them and trust the supervisors with creating the details and determining the approximate deadlines that accompany it. As a direct result, what may be considered a detailed version of person A’s idea on level B, will still be added upon in the work of those working on level C.
All these guidelines can help each level of the workplace hierarchy run smoothly and efficiently to create an ideal result.
In summary it can be said that ideally, ideas travelling from the peak of the pyramid down grow less ambiguous and more clear, while results achieved at the bottom of the pyramid and travelling upward undergo a decrease in unnecessary and excessive details (Figure 1).
Delegating tasks to the team. Following every project meeting, the lead must update and delegate the responsibilities assigned to his team by the project managers, and to assign internal deadlines while keeping in mind potential time-consuming back-and-forth communication that may arise. Therefore, the internal deadlines might exist before the actual deadlines to account for any such problems.
Project information and requirements that the lead’s team must be made aware of, should be filtered and their target audience must be identified. One way of doing this is transferring the “required” information for the project schedule to a simple Gant chart (for example, in Excel), which can be distributed to process engineers in an internal process meeting.
When no deadline is specified, it is in everyone’s best interest for the lead to determine an arbitrary deadline for the task assigner’s approval in order to prevent future conflicts.
For every task, a lead should communicate clearly with his (or her) process engineers about his expectations to hold them accountable. He needs to tell them about the quality of work. The level of details, the deadline and the approximate hours needed should be defined.
Deliverables features
Three main aspects of a project (quality, cost and schedule) can be applied to each task/deliverable in the project. Each deliverable should meet the required quality within the specified manhours and in the required time frame. Furthermore, the quality of a deliverable can be translated to accuracy and completeness of the document.
Accuracy and completeness. The accuracy and the level of completeness of documents presented to the client are not quantifiable qualities, but rather subjective ones. It is therefore the process lead’s responsibility to sense the importance of the level of accuracy conveyed in a document. In this case, document accuracy is dependent on two parameters, the first being the time-criticality of the document and the second being the scope of the document.
Time-criticality. It is sensible to place the accuracy of a document required at the beginning of a project low on the engineer’s list of priorities, because throughout the course of the project, a document created at the preliminary stages will undoubtedly undergo many revisions. Therefore, a large quantity of time spent on such a document will be inefficient and unnecessary.
As an example, the first draft of a document marked IFR (Issue For Review) is not in need of such painstaking accuracy as the revision marked IFC (Issue For Construction), due to their placements within the project timeline.
An alternate aspect of this parameter for criticality is the occasional need for the creation of a document before other tasks can begin. The lead needs to understand that the importance of the accuracy of the starting document is understandably not crucial in phase one of a project where it may be simply a hypothetical placeholder. However, in the final phases, such a document would require a higher grade of accuracy simply due to its proximity to the end of the project. Inaccurate data in the final stages of a project can prove to be disastrous for both the firm and the client.
Document scope. The second parameter is the target of any given document: equipment, instruments or software adjustments. If a document is relevant to the design of equipment — which are expensive and in certain cases may be long lead items — then it is of the highest grade criticality. For instruments, which a process group usually specifies, a “range” rather than a single design number is given. Instruments are therefore of lower criticality and in less need of accuracy. Meanwhile, software adjustments, which hold little to no financial burden, are of the lowest criticality.
As an example, in tank design a process engineer needs to provide the exact physical dimensions, but only a range of measurements in regards to level-meter, and simply a set point for the high-level tank alarm, which could easily be adjusted at a later point in the project with minimum cost impact.
Instructions for preparing documents. In creating documents and completing tasks, the engineer must abide by several sets of guidelines and standards of procedures dictated by various sources, within a hierarchy of importance. The guidelines presented may only be followed in the case that they do not interfere with or contradict the sets of guidelines superior to themselves.
At the first and most supreme level there may be governmental rules and regulations that must be obeyed, followed by the instructions from the clients, then any project-specific standards that must be met, the engineering firm’s own set of rules, and lastly the industrial common practices that may not have been addressed by any of the above guidelines.
These industrial common practices may be verified through the checking of credible and up-to-date published material, such as scientific peer-reviewed journals, or industrial magazines and articles presented in scientific conferences. It should be noted that information retrieved from the internet lack credibility and should only be relied on when obtained from credible online scientific journals. However, it is important to remain cautious when interpreting information retrieved from published material, as it may prove to be detrimental to make assumptions or to extrapolate — and in certain cases, even interpolate — from the information provided. At the same time, any theories formed must undergo laboratory, pilot, and industrial-scale testing in order to ensure credibility and to be qualified for use in design. The absence of any of these tests jeopardizes the credibility of the information.
On a different note, it is important to understand that even at the governmental level, ambiguity may be present within the rules and regulations dictated. In such cases, a case-specific interpretation may be required through discussion — be it oral or written — that must be recorded with the results of the discussion for future reference and the advisement of new employees. These records may be presented to the client as job specification upon the completion of the project.
Preparing deliverables. In the field of engineering, it can be said that all critical documents undergo three different steps before being considered approved or completed. First, they must be originated by a process engineer, then they must be checked by another individual with experience in the topic covered by the document, and lastly they must be officially approved by a third process engineer who may or may not be the process lead.
It is imperative to remember, however, that it is not the responsibility of the checker to scrutinize every aspect of the document. As a general rule of thumb, the checker should only spend a tenth of the time spent creating the document to check it; if more time is required, the document might be in need of a complete revision by the originator and may even be reassigned to another individual completely. The checker will check for faulty assumptions and inaccurate methodology utilized in the document before passing it along to be officially approved. Though at the highest level, the approver will spend even less time on the document, sparing only the briefest of glances to ensure the result “appears” logical before signing off on the document. Therefore, it is advisable for the originator to double, and even triple-check his or her work before passing it along to the checker.
Scheduling: Task deadlines
In determining achievable deadlines, it is important to know the total required man hours to finish a task, which comprise three elements. Firstly, time must be allotted for the technical content of the task to be created. Secondly, the time required for the determination and transferring to the appropriate format and lastly, time must be allotted for gaining the required approvals and signatures and official issuing.
Accelerating a task. In some cases, tasks may be in need of acceleration in order to meet the deadline. To accelerate a task there are two alternatives available: boosting human resources and simplifying the task.
Boosting human resources may include the short-term external/internal hiring of additional personnel, encouraging employees to work over-time, or reassigning tasks to the semi-specialists.
For the other alternative, it may be appropriate to develop calculation templates, algorithms, decision-making matrices, or bulleted-type instructions to simplify the task.
Unscheduled tasks. A reality of working as a process lead is the presence of unscheduled tasks that may be requested by various outside players. In such cases, overly flexible process leads will always accept these tasks while overly “tough” leads will always decline them. However there are various available paths a lead can take in such a case.
Firstly, the request and the suggested deadline can be accepted if it will not negatively impact the team nor hinder the completion of the scheduled task.
Secondly, the request and the deadline may both be accepted, but at the cost of quality and accuracy, should the other party accept these terms. In this case, a less accurate or incomplete form of the deliverable will be passed to the “internal customer” if it is discussed and agreed beforehand.
Thirdly, the request may be accepted with an adjusted deadline that will neither impact the team nor the completion of the scheduled tasks.
And lastly, the request can be respectfully denied for various reasons that include — but are not limited to — the discussed task not being part of the team’s scope of responsibility or it jeopardizing the completion and quality of the scheduled tasks. In this case, the lead should remain loyal to the scheduled tasks, even though this denial may go against the lead’s personal character and generosity.
Budgeting: Manhours
Regarding manhour estimates, it is important for the lead to realize that the numbers resulting from such a calculation often refer to the estimated amount of time intermediate engineers will require to complete the task. Should a team be comprised mainly of junior or senior engineers, the man-hour estimations will need to undergo an adjustment befitting the efficiency of the team.
At the same time, it is important to understand that given 100 estimated man-hours within a period of ten days for a specific task, an engineer will not necessarily be able to fulfill a flat number of ten hours per day for each of the ten days. Rather, it is more realistic to presume that in the first few days only a handful of manhours will be put forward for the task, whereas in the next several days the engineer might be capable of completing more than the ten estimated hours per day. This number will decrease once more in the final days, until the task is completed. In this way, it is wiser to visualize that a graph depicting the rate of manhour usage is not a straight line — or a constant rate — but rather a bell curve (Figure 2).
As a result, it may be wise to consider alternate tasks for the engineer during the off-peak stages of the task. During this time, the engineer may be capable of assisting other tasks or even other projects at the peak of their own respective bell curves. Organization for the purpose of simplifying future projects may also be beneficial, as may be training sessions and team-building activities and so on.
Consequently, when at the peak of a task’s bell curve, a lead may utilize others during their off-peak stages, ask his or her own team to work overtime or attempt a higher level of efficiency, or request a short-time hire. The last should be viewed as a last resort due to its tarnishing of a company’s reputation in hiring and letting go an individual within a short period of time.
Interdisciplinary communication
In communicating with others, it is important for the lead to ensure his or her team members can make distinctions between various modes; for example, at the most informal level of communication, a verbal interaction is sufficient. In regards to more formal interactions, Emails may be more appropriate and at the most formal level, the most effective solution would be to interact through Email with the supervisor copied to (as a CC recipient of) the exchange. In doing so, the lead can ensure that each mode of communication is appropriate to the interaction so that, hypothetically, the supervisor would not be unnecessarily informed of minute details. Additionally, overly formal Emails in regard to what is in essence a casual interaction may cause alienation and result in friction between team members.
When communicating with people across different disciplines, such as materials or piping, it is important to keep in mind that the same word when used by various persons can mean different things. For example, one can use the term trim to refer to a internal part of a valve, while another individual will use the same term to refer to tank attachments.
At the same time, it is important for members of each discipline to keep in mind the needs, standards and scope of interest of others.
For example, when a person from a materials group asks for velocity of liquid in pipes, he or she is looking for a rough range of velocities and if a process engineer prepares an accurate list of velocities with decimal points, it will be waste of time.
As an extension of this, it is important to remember that when discussing a hypothetical pump, a mechanically oriented person will refer to it as the “centrifugal pump” while a process engineer will use “crude oil pump” and an individual from the piping discipline will allude to “the pump in building A”.
Therefore it is imperative to clarify the specifics when interacting with other disciplines, and to keep in mind the terminology and “language” utilized by each discipline.
Author
Mohammad Toghraei, MSc. P.Eng. is currently a senior process engineer with Vista Projects (330-4000 4th St. SE Calgary, Alberta, Canada T2G 2W3; Phone: 403-255-3455; Fax: 403-258-2192; email: [email protected]) and is the instructor of several process engineering courses with progress seminars. Toghraei has over 20 years experience in the field of industrial water treatment. His main expertise is in the treatment of wastewater from oil and petrochemical complexes. For the past seven years he has taken on different technical and leadership roles in water treatment areas of SAGD (steam-assisted gravity drainage) projects. Toghraei has received a B.Sc. in chemical engineering from Isfahan University of Technology and an M.Sc. in environmental engineering from the University of Tehran, and is a member of APEGGA.