The Importance of Engineering Management

The Importance of Engineering Management

By Freek Van Heerden

Introduction

The role of the engineering manager in projects was previously described using the ten knowledge areas of the Project Management Body of Knowledge (PMBOK) as a reference (van Heerden, 2018). In that article the responsibility of the engineering manager in each knowledge area was discussed without any attempt to specifically differentiate or highlight the areas where the engineering manager is the lead contributor in comparison to the project manager.

In this article we address the areas where the engineering manager must take the lead for a project to be a business success. We consider key work processes and capabilities that will provide for successful engineering management.

A successful project

In order to understand the importance of an engineering manager on a project, it is necessary to firstly elaborate on what constitutes a successful project. In the literature, a successful project is typically described as a project that meets cost, schedule and production objectives within a specific margin of, say, +-5%. While meeting these objectives would imply that a project has been successfully implemented, it does not guarantee that the resulting venture would be an economic success. Developing a project that achieves sustainable business success is what a project is about, not just executing an agreed scope.

While these metrics (cost, schedule and production objectives) are surely a good measure against which to compare the project implementation outcome, there may be other results that contribute towards a successful project, specifically as far as the business owner is concerned.

During project framing discussions, we often use the project management triangle of cost, schedule and quality to agree the primary drivers of a project. Want it fast and cheap? No problem, but the final product won’t be very good. Want it good and fast? All right, but it won’t be cheap. During these discussions, the problem has always been that the business owner wants the project as fast as possible, as cheap as possible and with the best quality, while the project manager tries to clarify in his mind whether cost, schedule or quality was the primary driver.

Ward (2014) argues that this “pick any two” idea is not true. He states that: “Upon closer examination, we discover that what little data there is to support this position is largely of the nature of a self-fulfilling prophecy. We sacrifice one leg of the triangle because we believe we must, then look on our results as proof that the outcome was unavoidable. It does not have to be this way. There’s no need to pick only two.”

Ward (2014) argues that a successful project should be: Fast, Inexpensive, Restrained and Elegant, abbreviated to FIRE. These terms are further explained below.

  • Fast: Fast focuses on the schedule and expresses that it’s important and beneficial to have a short project schedule. The precise definition of what is a short timeline will naturally vary from project to project, but Fast is about defining project objectives that can be satisfied on a short timeline, not one we know will require forever to accomplish. Fast is about disciplined project execution and not about rushing ahead;
  • Inexpensive: Being Inexpensive means designing processes, plants and organisations with cost in mind. It involves “solving problems with intellectual capital instead of financial capital” (Ward, 2014). It is not about doing a project cheaply, but rather about getting real value for money;
  • Restrained: Restrained implies a preference for self-control in considering the absolute minimum technical solution for a project. It implies tight budgets, small bur efficient project teams, short meetings, and short documents. No non-essential luxury items or infrastructure will be tolerated;
  • Elegant: An Elegant design should be “pleasingly ingenious and simple” (Ward, 2014). Start by stating project goals clearly and then incorporate mature, proven technologies into the design. Truly elegant solutions to project challenges are often surprisingly simple. We may not be able to avoid complexity entirely, but we can take steps to minimise it.

Returning to the metrics of project success, we see that there are more than just schedule, cost and production objectives (i.e. product quality and plant throughput).  This is reflected in Figure 1, where we indicate the use of the ‘standard’ metrics, as well as the FIRE metrics for determining project success.  There is obviously some overlap between measures like Cost (a ‘standard’ metric) and Inexpensive (a FIRE metric).

If one then considers the above ideas on what constitutes a good project, one can start to visualise the importance of the role that the engineering manager plays in pulling together the engineering effort to deliver a successful project.

Figure 1:  Metrics of project success

The engineering manager

Opening remarks

It is the engineers on a project that define the project scope and other requirements, design the equipment and ensure that the required quality is met. They determine the level of complexity, the ease of project execution and the cost associated with the scope and quality/standards required.  Thus, engineers play a crucial role towards the eventual business success of the project.

In developing a project, the effort of the engineers should be directed, co-ordinated and focused toward achieving the business objectives and delivering a successful project. It is the engineering manager, as the leader of the engineering team, that bears the brunt of this effort. We deliberately use the term ‘leader’, rather than ‘manager’. The engineering manager on a project is normally not a direct functional line manager, but rather the conductor/co-ordinator of the engineers assigned to the project. The engineering manager needs to lead, inspire, negotiate, cajole and convince the different engineering disciplines, and sometimes their line managers, during the project life cycle, to maintain focus on the business and project objectives.

In executing his/her work, the engineering manager must focus on:

  • Team alignment: Visualise the business intent and contextualise the business requirements so that the team understands it fully;
  • Scope of facility: Synthesise the integrated facility scope within the boundaries of cost and schedule;
  • Engineering execution plan: Develop and implement an engineering execution plan as part of the overall project execution plan;
  • Technical risk management: Identify, assess, rank, and manage technical risks holistically; and
  • Philosophies, standards and specifications: Contract and ensure appropriate design philosophies, standards and specifications are set, and met.

The role of the engineering manager is illustrated in Figure 2.

Figure 2: Role of the engineering manager

Each of these roles is discussed in more detail below.

Team alignment

The engineering manager is typically the person that interfaces with the business owner. He/she must understand what the business owner wants to achieve and then translate that understanding into “engineering talk”. Very often a business owner has a rough idea or concept in his mind, but that does not translate into a defined and executable project. The engineering manager plays a pivotal role as the interface between “the business” and “the project”, translating and communicating between the two parties and managing the relationship.

In order to do this translation, the engineering manager must have a good understanding of what the drivers of the economic and operating models of the facility are. In this way, he/she is the person that ensures alignment of people’s thinking and the total engineering effort through all the project stages.

The engineering manager must ensure that his entire team of engineers understand the business objectives and project objectives, and establish alignment.

Scope of facility

A scope of facility must be developed that will meet the business needs. In FIRE terms, it needs to be Restrained, Inexpensive and Elegant and it needs to be done Fast. The proposed solution must delight the business owner. Only once a scope is in place can the project manager determine the cost and schedule. The engineering manager must understand the boundaries of cost and schedule that will make business sense and guide the engineering teams toward developing a concept within the boundaries of cost, schedule, quality, reliability.

The description of the facility must be broken down into a facility breakdown structure, supported by individual work packages with appropriate details. Operating safety and environmental requirements must be properly translated into the engineering scope. Each work package needs to be written up in detail, reviewed and approved by at least the engineering manager, the project manager and the business owner. This scope definition package forms the basis for the total project cost.

Achieving approval is crucial as it aligns everybody on what the project will actually deliver (and not deliver) and is a crucial document through which changes are managed and scope creep (and thus cost and schedule overruns) prevented. A proper definition of how engineering scope changes will be managed and controlled is an essential element for a successful outcome.

Managing the development of the scope of the facility towards an optimised solution requires consideration of the complete business value chain during front-end loading of the project. Various techniques to support this effort have been described in previous insight articles (Render, 2016; Steyn & Buys, 2017; van Heerden, 2017; van Heerden & Steyn, 2015). The engineering manager should continually be on the lookout for an Elegant solution, keeping it “pleasingly ingenious and simple”.

Engineering execution plan

The engineering execution plan lays out all the methods, procedures, milestones, decision points and decision makers, as well as the resources required to complete the engineering work. A well-developed plan is essential in completing the work Fast. Exercising Restraint during the development of the execution plan means ensuring resource requirements, tools and decision-making processes that would adequately support the overall intent of achieving a successful project and business venture.

All too often the front-end development is marred by indecision and recycling of concepts, under the guise of reaching a proposal that is both technically and economically feasible. This often adds many months to the front-end development that can be mitigated through a focused drive by the engineering manager, always keeping the business objectives and boundaries in mind.

Technical risk management

We’ve published several articles on how to identify, assess and manage technical risks holistically (Steyn, 2018a, 2018b & 2018c).

In the article Planning for project risk management, Steyn (2018a) states that. “[l]ife is uncertain, and projects are unique, complex in nature, based on assumptions and done by people. Projects are therefore subject to a plethora of uncertainties, i.e. risks and opportunities, that can affect the project and business objectives. Although the activity is normally referred to as project risk management, it covers both risk and opportunity management. Potential positive and negative outcomes deserve equal attention.”

If production is delayed through technical problems, either during construction or start-up, the slower ramp-up of the revenue can have a devastating impact on the project finances and even on the owner company itself. Proactive identification and mitigation of risks can go a long way towards securing the expected outcomes. Engineering managers use various techniques like potential deviation analysis, innovation assessments and decision analysis techniques to identify potential risks associated with for example planning, technology maturity and technology selection processes.

Philosophies, standards and specifications

Van Heerden, Kriel and van der Walt (2016) maintain that “quality should always be the point of departure for any work and that, if a quality product is delivered, it will support meeting the business objectives in terms of cost and schedule.”

In the article Fit-for-purpose specifications for project development and implementation, Thirion (2017) maintains that “[e]very project has unique objectives that must be met by the project manager, who achieves this by managing deliverables such as cost, schedule and technical integrity of the project. After project completion, the business operates, maintains, and finally decommissions the plant. Specifications should contribute during project execution to minimise cost and schedule, and deliver technical integrity, and during plant operations to meet operations requirements such as maintainability, reliability, operability, throughput, product quality and safety.”

Standards and specifications are often blamed for cost overruns in that projects appear to be gold-plated. Considering the business objectives in terms of the facility life, reliability, maintainability and operability the engineering manager needs to guide the engineering fraternity towards the development of fit-for-purpose specifications. In this exercise it is necessary to not just consider the initial capital investment, but also the impact on the total life cycle cost of the facility. An Elegant solution would be one where the correct balance has been struck that provides for an affordable initial capital cost as well as an overall life cycle cost that will support a sustainable business solution.

Once the project requirements are set and detailed design, manufacturing and construction commences, an engineering quality plan is required to ensure that the deliverable does in fact meet the agreed quality. A proactive and thorough quality assurance plan will enable non-conformities to be identified early on with enough time to correct the defects. If critical defects are only discovered late during construction, it inevitably leads to long delays in start-up and will have a serious impact on the viability of the business.

Concluding remarks

In this article, we’ve highlighted five key aspects where we believe engineering management should play the leading role during a project, namely:

  • An aligned and directed engineering team, focusing on delivering a facility that will meet the business intent;
  • A facility scoped such that it will deliver the required project at an affordable cost, reliably and at the right quality;
  • An effective engineering execution plan to complete the work in an efficient way with the correct resources and competencies;
  • A risk management process that will prevent sudden and unexpected surprises and predetermined contingency actions should something go wrong; and
  • A facility designed and constructed using fit for purpose specifications.

Engineering managers who focus on these aspects will, during the development and implementation of projects, prove their value and contribution towards successful projects.

References

Render, C.L. (2016) Technology selection. Available from https://www.ownerteamconsult.com/technology-selection/. Accessed 20 January 2020.

Steyn, J.W. (2018a) Introduction to Project Risk Management, Part 1: Planning for project risk management. Available from https://www.ownerteamconsult.com/introduction-to-project-risk-management-part-1-planning/.Accessed 20 January 2020.

Steyn, J.W. (2018b) Introduction to Project Risk Management, Part 2: Identify, analyse, action and monitor project risks. Available from https://www.ownerteamconsult.com/intro-to-project-risk-management-part-2-identify-action-and-monitor-project-risks/. Accessed 20 January 2020.

Steyn, J.W. (2018c) Quantitative risk analysis for projects. Available from https://www.ownerteamconsult.com/quantitative-risk-analysis-for-projects/. Accessed 20 January 2020.

Steyn, J.W. & Buys, C.P. (2017) Project optimisation techniques: Site Selection for Process Plants. Available from https://www.ownerteamconsult.com/site-selection-for-process-plants/. Accessed 20 January 2020.

Thirion, C. (2017) Fit-for-purpose specifications for project development and implementation. Available from https://www.ownerteamconsult.com/fit-for-purpose-specifications-for-project-development-and-implementation/.Accessed 20 January 2020.

Van Heerden, F.J. (2017) Value chain optimisation. Available from https://www.ownerteamconsult.com/value-chain-optimisation/. Accessed 20 January 2020.

Van Heerden, F.J. (2018) Introduction to Engineering Management. Available from https://www.ownerteamconsult.com/introduction-to-engineering-management/. Accessed 20 January 2020.

Van Heerden, F.J. & Steyn, J.W. (2015) Select topics in value engineering: Standardisation in the process industry. Available from https://www.ownerteamconsult.com/select-topics-in-value-engineering-standardisation-in-the-process-industry/. Accessed 20 January 2020.

Van Heerden, F.J., Kriel, D. & van der Walt, D. (2016)  The project management triangle conundrum: selecting between quality, cost, time.  Available from https://www.ownerteamconsult.com/the-project-management-triangle-conundrum/. Accessed 20 January 2020.

Ward, D. (2014) F.I.R.E. – How Fast, Inexpensive, Restrained and Elegant methods ignite innovation. HarperBusiness Publishers, New York.

You may also be interested in

The Importance of Engineering Management

The Importance of Engineering Management

In this article we address the areas where the engineering manager must take the lead for a project to be a business success. We consider key work processes and capabilities that will provide for successful engineering management.

Introduction to Engineering Management

Introduction to Engineering Management

By Freek van Heerden

Introduction

There is sometimes confusion regarding the role of, and need for, an engineering manager on a project. It is often stated that the project manager is the responsible person, and the use of an engineering manager is therefore superfluous. In this article the roles and responsibilities of an engineering manager and the interaction between the engineering manager and the project manager is explored.

OTC prescribes to the concept of an integrated project management team, as illustrated in Figure 1. In such a team all the required competencies are represented within the team to support successful completion of the project. As such, we believe that the project leadership team should be made up in such a way that these leaders have the right background and can guide the team effectively.

Fig 1 Owner Project Team

Figure 1:  The owner project management team

In the case of industrial projects, the project manager should ideally be supported by a business manager, an operations manager and an engineering manager.

Roles and responsibilities of the Owner PMT

In the arrangement as reflected in Figure 1, the responsibilities within the overall team can be summarised as follows:

  • Project Manager: The project manager is overall accountable for the project outcomes and is specifically responsible for meeting the schedule and cost objectives. Within these overall objectives he need to focus on the overall project execution strategy and plan, the contracting strategy, project commercial and legal issues as well as schedule, cost and change management. Safety, environmental and quality issues during the project execution is also of extreme importance.
  • Business Manager: The business manager is responsible for business activities that includes for example overall business plans, business viability and economics, marketing, sales and all other support functions including legal, financial and business commercial issues. An issue that is also gaining prominence is product stewardship over the total logistics chain from raw material supply to final product delivery to customers.
  • Operations Manager: The Operations manager is responsible for operations activities. This includes both operating and maintenance aspects. Operations personnel requirements, recruitment and training, variable and fixed operating costs, commissioning, operability and maintainability, operational safety and environmental compliance of the final facility are some examples within his area of responsibility.
  • Engineering Manager: The engineering manager is responsible for the overall technical integrity of the project. As such this would include a facility scope that meets the business needs. An overall integrated technical solution requiring management of interfaces as well as management of technical/engineering quality of deliverables be it design deliverables or actual hardware like vessel, pipes or even control and IT systems. The execution of the engineering work in support of the overall project execution plan is also important.

If one considers the PMI Global Standard for project management, namely the PMBOK Guide, 6th edition (PMI, 2017) one will see that project management includes processes like integration management, scope management and quality management. Surely then, all issues listed as the responsibility of the engineering manager belongs with the project manager.  Why would an engineering manager then be required?

In the following sections, I’ll elaborate on the differences between the engineering and project management roles.

The relationship between project manager and engineering manager

It is important that the entire project team can translate the business objectives of a project into a properly defined scope, which meets both the schedule and cost objectives of the project.  It is the primary responsibility of the project and engineering managers to have a full understanding of these objectives and to ensure they are met.

The project manager is required to be a project management professional. He understands all the work processes as per the PMBOK guide. The project manager is accountable for the overall project outcome. To achieve this, he uses professionals in various disciplines to achieve his goals. For example, a project controls professional responsible for cost and schedule issues, a legal professional to handle commercial and contractual issues, a risk management professional to handle risk management.

In the same way, the project manager requires a professional who understands all the technical and engineering requirements of the business within which the project is being executed. Only on small projects may the project manager have the knowledge and time to address both project and technical management. Even in such cases, if the project manager is a technical person, it often happens that he then starts to concentrate on the technical issues and project management suffers, or vice versa.

The engineering manager therefore needs to support the project manager in focusing on the project management work processes of a technical nature. The engineering manager needs to firstly be a technical/engineering professional who understands the business objectives and technical/engineering aspects of the business, such that a project can be developed that will meet the business needs. Secondly, he needs to have a sound understanding of project management processes so that the work is carried out within the project management framework.

One can probably call the engineering manager the “project manager for the technical work”. The engineering manager is no longer an engineer doing the design work, but the person managing the various engineering functions in getting the work done. He is also the person that must ensure that all the work done by the different functions is integrated into a whole that will deliver a functional end product. Very often a very good and capable engineer is appointed as an engineering manager, but he fails miserably at the job or leaves the job after a few days. This happens because he now becomes a high-level manager and an integrator having to align, support, coach, defend, justify and communicate with stakeholders rather than do engineering. Dedicated engineers often find this position very frustrating.

Who then makes a good project engineering manager?  A person who has a good technical basis, that has a good grasp of all the different engineering disciplines and technical complexities of the business. He also needs to understand business development methodologies and the objectives of the business such that project will meet the business needs. A person who has been a project manager but would rather focus on the technical management than the detailed project management aspects is also a good candidate.  Additional thoughts are shown in Figure 2, courtesy of my colleagues.

Characteristics of an engineering manager

Figure 2:  Characteristics of a good engineering manager

Specific responsibilities of the engineering manager

The project and engineer manager need to work together in a close relationship to ensure all the PMBOK knowledge areas are fully covered on a project. In some areas the project manager needs to take the lead, while in other areas the engineering manager could take the lead.

If one considers the 10 PMBOK knowledge areas, one could possibly better define the role of an engineering manager as follows:

  • Integration management: According to PMBOK, integration management is all about project integration like the project charter, project management plan and such. A very important activity for an engineering manager is technical integration management, including definition of battery limits for each package; definition of battery limit conditions like composition, pressure temperature; tracking these definitions and ensuring consistency between packages; and ensuring the technical integration of the new facility with peripheral facilities out of scope of the project;
  • Scope management: The development and management of the scope of the final product to be handed over to the client in such a way that the completed project will meet the original business intent is primarily the responsibility of the engineering manager.  In addition to the product scope, the engineering manager must also develop the scope of technical services to be performed by his team or the scope that will be contracted out;
  • Schedule management: The engineering manager needs to develop the schedule of technical/engineering activities and ensure that these are correctly integrated into the overall project plan;
  • Cost management: The capital cost of a project is an outcome of the product scope. As such, the engineering manager is a main contributor to the final cost of the project. One of the tasks is to ensure that the product scope will be able to meet the quantity and quality requirements. In addition, the project must be economically viable. This often requires trade-offs to be made or alternative technical solution to be sought to generate a product scope that will result in an economically viable and sustainable project.  The engineering manager must ensure that the right questions with regards to these alternatives are asked early on, to guide the engineering team in achieving the best cost-effective solutions;
  • Quality management: It is of paramount importance that the engineering manager understands the quality drivers of a project early in the project.  One of his key functions is achieving the required quality of the final deliverables. Whether it is the hardware and software being developed, the construction of the facility, or the quality of the final products that will be delivered once the project has been completed. Ensuring the quality of these rests squarely in the lap of the engineering manager;
  • Communication management: Communication and ensuring alignment with stakeholders is a joint responsibility of the overall project leadership team.  The engineering manager will concentrate on communicating with the engineering disciplines;
  • Resource management: The engineering manager is responsible for determining the engineering resource competencies, numbers and the sourcing of these resources;
  • Risk management: Although the project manager is overall accountable for project risks, each member of the leadership team is responsible for the management of risks in their specific areas. As such, all technical and engineering risks reside with the engineering manager;
  • Procurement management: During the procurement activities, the engineers are required to do regular inspections to ensure that the quality requirements, as specified by them during the project development phase, are adhered to. This often results in a conflict between schedule and quality.  It lies within the ambit of both the project and engineering managers to resolve this to the benefit of the project objectives; and
  • Stakeholder management: Stakeholder management is a crucial activity to be performed by all members of the project team, but also, very importantly, by the project sponsor as the accountable person.

The engineering manager thus plays a crucial role in many of the PMBOK knowledge areas and his support to the project manager is extremely important. A good project manager will work together with his engineering manager on an equal basis and between the two of them they will ensure that all areas of project management are adequately covered.  They can be considered as the two sides of the coin of project management on a project. If the one fails, the other will fail as well. The engineering manager can also be considered the assistant project manager and both he and the project manager should always be fully aware of all aspects of the project. The one should be able to stand in for the other at short notice and without adverse consequences to the project.

It is more than likely that there will be conflict between the roles of project manager and engineering manager, but it is crucial for these two role players to ensure that a healthy work relationship between them is fostered, to continually serve the project objectives.

Closing remarks

The ultimate objective of using an engineering manager is to enable the project manager to focus on the overall project management aspects, as per the PMBOK knowledge areas of the project and for him to use the engineering manager to ensure successful completion of the technical and engineering work.

We trust that this article has been ‘insightful’ (pun intended).  More detailed articles on the key capabilities, work processes and competencies in engineering management are in planning.

References

PMI (Project Management Institute, Inc.), 2017, A guide to the project management body of knowledge (PMBOK Guide), 6th ed. PMI Book Service Center, Atlanta.

Value Chain Optimisation

Value Chain Optimisation

By Freek van Heerden

 

Introduction

A key objective during front-end loading is to develop a project concept that is optimised to meet the business needs.  All too often, projects are recycled at the end of a gate for “value engineering” because the required hurdle rate cannot be met.  During the value engineering exercise, improvements are proposed, the savings banked and the project is approved to proceed to the next stage of the project cycle. These claimed savings often do not realise, because they were either ill-conceived, or they were/could not be implemented during the next stage of development.  The result is that the project cost escalates again to the previous levels, or even higher.

The methodology followed during Value Chain Optimisation (VCO) is a rigorous and pro-active approach, across the full project value chain, during each development and design stage of a project. It ensures that only the required functionalities are incorporated into the project and that each proposal is fully tested and incorporated into the design before the project proceeds to the next stage.

By following this methodology, improvements in NPV (net present value), or IRR (internal rates of return), of typically 20 to 30% against the original project baseline are achieved on many projects.

The project value chain

We firstly need to define exactly what is meant by the project value chain. A generic value chain is shown in Figure 1.

A value chain comprises all the steps in the process from obtaining the feedstock, processing this feedstock through the various steps up to final placement of the product in the market and delivery to the customer.  Also included in the value chain are all services, utilities and infrastructure required, as well as any environmental protection steps to be taken.

Considering the full value chain, ensures all aspects are reviewed during the VCO process.   It also ensures that any interrelationships, or cross impacts, are understood.

VCO Fig 1

Figure 1:  The project value chain

The Value Chain Optimisation methodology

VCO is a rigorous methodology that is carried out throughout the project life-cycle in increasing detail.  The VCO methodology entails the following steps:

  • Identify “must” requirements and “nice to have’ requirements
  • Generate the minimum technical solution from “must requirements;
  • Determine the cost and NPV for the minimum technical solution;
  • For each “nice to have” option, calculate incremental capital and differential operating cost and NPV;
  • Select only “nice to have” options that meet a predetermined hurdle rate; and
  • Include these selected options in the optimised design; and
  • Obtain sign-off on the optimised design.

Specifications and requirements are categorised in musts, and nice to haves, and only the absolute must requirements are included into the minimum technical solution for the project minimum cost definition.  This approach ensures that the absolute minimum capital cost solution that will meet the business need is defined.

For example, if water is required is required for the project and water storage is provided in the process design, the first question is if storage is a must or a nice to have. If it is a must, then it is included in the minimum cost, a nice to have is excluded. If, for argument sake, water storage is a must then the next question is whether a steel water tank is required or if a lined pond would suffice. During these discussions, the workshop leader needs to ensure that the absolute minimum capital cost solution is derived and not someone’s preferred solution.

Once the minimum cost and associated NPV for the minimum cost solution is defined, options (for each “nice to have” feature) are generated to improve from this point. For each option, the incremental capital and differential operating cost and NPV is calculated.  Only options that meet a predetermined hurdle rate (e.g. positive NPV at cost of capital) is considered for inclusion in the optimised design.  From these calculations, the graphs as shown in Figure 2 and Figure 3 are generated.

VCO Fig 2

Figure 2:  Capital cost evaluation for each option

VCO Fig 3

Figure 3:  NPV evaluation for each option

To obtain sign-off for the options to be included, the design is updated and verified to ensure that each solution is workable and safe.

Key to the success of this methodology is ensuring that the minimum cost solution is exactly that, and not some higher cost point that is the preconceived optimum solution as perceived by the team.  Achieving the minimum technical solution requires an experienced facilitator that will keep on pushing the team until he/she is convinced that this point has been reached. There is normally a fair amount of resistance by the team as they typically perceive the minimum cost solution as an “unbearable” point and will not buy into it.  This is understandable, but it must also be realised that the intent is not to actually build this minimum cost solution.  The objective is to create an as-low-as-possible starting point from which to evaluate each and every improvement opportunity, as well as be able to justify its inclusion or not.

Value Chain Optimisation levels of detail

The VCO methodology, described above, is repeated 4 times during the project life-cycle. Each repeat considers the next level of detail in a similar fashion as the prefeasibility stage is followed by the more detailed feasibility stage, and so forth. The guidelines for the different levels are described below:

VCO Level 1

During the VCO Level 1 exercise, focus is on the feedstocks and products (quality, quantity, alternatives), production capacities, overall reliability, environmental as well as services, utilities and infrastructure inputs/interfaces, as examples.  All streams entering and exiting the value chain are considered as well as the impact of these upon the design and cost of the facilities.  This is illustrated by the red square around the production facility in Figure 4.

VCO Fig 4

Figure 4:  VCO Level 1

VCO Level 1 helps to cement the business plan and ensure that the overall requirements are optimised.  The VCO Level 1 is often the point at which more than 50% of the improvements are realised.

The VCO Level 1 workshop is normally held at a point where the prefeasibility stage is around 50 to 75% completed.  One would need, at a block flow level, a project concept, capital and operating costs, market data, revenues, as well as a working financial model.

VCO Level 2

As soon as the facility can be subdivided into logical sub-areas, each with its costs, the VCO Level 2 exercise should be performed. This is normally during the early feasibility stage development. Each area is now individually analysed to determine the minimum cost and optimised solutions.

At this stage alternative technologies can be considered, as well as specification changes that could affect the overall sub-unit, buffer storages vs. reliability, layout alternatives, etc. One can clearly see that the amount of work to complete each level of analysis increases asymptotically and it is essential to ensure that the previous VCO level analysis has been done thoroughly, and has been duly signed off to prevent costly rework and time delays.

VCO Level 2 focus areas are illustrated in Figure 5 by the red squares around the individual process areas of the production facility.

VCO Fig 5

Figure 5:  VCO Level 2

VCO Level 3

During VCO Level 3, at least each major equipment piece is analysed to ensure optimum specification and selection. Types of compressors (reciprocating, screw, centrifugal), designs of pressure vessels (pressure, temperature, material of construction, no. of nozzles, etc.) is analysed. This exercise is normally carried out toward the end of front-end engineering and design, or early in detailed engineering.

VCO Level 4

The objective for VCO Level 4 is to decide on the optimum procurement practices. Different suppliers for the equipment are considered, procurement strategies are developed, spares holding requirements and maintenance practices are reviewed. This exercise is carried out at the start of the procurement cycle.

Some practicalities

VCO Reviews

Before finalising the work for a specific level, it is required to review the specifications and conclusions of the higher-level work to ensure no changes will contravene the boundaries set at the previous level. If required, some modifications must be made to ensure the overall design is still sound and the changes have been fully evaluated and incorporated.

VCO workshop attendance

The VCO workshops should be attended by the project and business teams responsible for the development, as well as external subject matter experts that can provide alternative views.  Normally VCO Level 1, Level 2, and, to a certain extent, Level 3 (depending on the practicality) are facilitated by VCO experts.

During the VCO Level 1 and Level 2 sessions, the project teams are trained to apply the VCO principles within their work groups.  From VCO Level 3 workshops onward, the workshops are run by the teams themselves, utilising external experts as required.

Closing remarks

Value chain optimisation is a very rigorous process that has been proven to improve the business value of a project across the complete value chain by a large margin. It is advised to use experienced facilitators to introduce the concept and to train the teams to be able to carry out the more detailed exercises themselves.  Attention to detail and a dedicated team with the necessary management support is essential to ensure success.

Contact OTC for more information, and assistance, to improve the likelihood of project success.

The project management triangle conundrum

The project management triangle conundrum

Selecting between Quality, Cost and Time

By Freek van Heerden, Deon Kriel & Davida van der Walt

Introduction

When a new project is framed, the project manager usually asks the question as to which drivers are important to the project.  The project management triangle is often used to facilitate this discussion (Wikipedia, 2016).  Multiple variations of this triangle are available in the literature, but in essence they all require positioning the project relative to three issues, namely good, fast or cheap (See Figure 1).  In this representation good can be considered as equivalent to quality.

The Project Management Triangle

Figure 1:  Project Management triangle

Trying to plot a project on this triangle does not give the project management team any real tangible means of guiding the project and making trade-off decisions when required.  It just remains a “nice picture”.

It is often said that good and fast projects are expensive, good and cheap projects are slow, and cheap and fast projects are of poor quality.  It is our opinion that this dogma leads to a totally inadequate setting of the project framework and does not provide the project team with the correct guidance.

We believe that quality should always be the point of departure for any work and that, if a quality product is delivered, it will lead to meeting the business objectives in terms of cost and schedule.  In contrast, if quality work is not delivered the probability of meeting the cost and schedule objectives is very slim.  According to Mazohl (2013), quality is not a part of the project management triangle, but it is the ultimate objective of every delivery.

Once the quality objectives are clearly understood, the project team must understand the trade-off between cost and schedule as it applies to the project that they are executing.  A schedule driven project will undoubtedly be more expensive than a cost driven projects but if that is what is required to be a business success e.g. meeting a specific market window) then it is the right approach to follow.

A basic fundamental issue is that quality is not defined, or understood, in its totality and this contributes to the confusion.

Defining Quality

Most often quality is stated as conformance to predefined standards.  While this is true, it is totally inadequate to describe quality in its entirety.

We prefer to define quality in terms of the following five points:

  • Accurate:  Information / deliverables should be fair and free from bias.  It should not have any technical, arithmetical and grammatical errors.
  • Complete:  Accuracy of information and deliverables is not enough.  It should also be complete which means facts and figures should not be missing or concealed.  Telling the truth, but not the whole truth is of no use.  All relevant aspects should be addressed.  Key aspects that are relevant to the nature of the project should not be overseen.
  • Reliable:  Reliability speaks to consistent performance in quality; information, deliverables and performance on the project should be such that it can be trusted.
  • Timely:  Plan the work (schedule with milestones and holding points) and work the plan to in order to deliver the quality product.  It should be available when required (information, deliverables, resources).  Deliverables should not be over or under developed in relation to what is needed in a given stage during the project life cycle
  • Conformance:  Quality also implies meeting predefined standards and specifications.  Durability should be based on business requirements throughout all project stages and disciplines.

Looking at the above definition, one gains a better perspective as to quality.  No matter what product is being developed, the work must be accurate, complete, reliable, timely and must conform to requirements.  If this is not the case, it results in rework, higher operational costs, missed deadlines and budgets and even poor morale of the team. The final product will not meet the business strategy and result in poor client satisfaction.

Of the five points mentioned above, the first four points can be considered binary in that the work is either accurate, complete, reliable or timely or not. It cannot half meet these terms.  For example, a design calculation is either accurate or not.  If it is not correct, the hardware will most probably fail to meet the required performance.

Conformance to standards and especially specifications is often quoted as the key quality parameter.  In terms of meeting a specific business objective the required specifications can vary greatly.  For example, in fast moving industries it may be required to design hardware with a limited life expectancy (IT, pharmaceuticals) of say 5 years, while in the commodities business (refineries, mines), life expectancies of 30 years, or more, is considered normal.  It is thus required that each project is based on a solid understanding of the business needs, such that the correct specification can be set.
Quality can thus be seen as the basis upon which the ability of meeting the business objectives depends.  It is the pivot point upon which all other project decisions and trade-offs rest, as illustrated in Figure 2.

Quality is the pivot point

Figure 2:  Quality is the pivot point

Having now clarified that quality is the basis, the balance between schedule and cost can be elaborated on.  A project can now be defined as either schedule or cost driven or managed by earned value management Neither of these elements can, however, be pursued without taking cognisance of the other and form part of contractual obligations.  A schedule driven project timeline can, for example, not be shortened to such an extent that the cost becomes prohibitive.  Therefore, the project team should be given some boundaries around schedule and cost and the value/cost vs time relationship.  It must also be taken into account that this relationship may change as the project development proceeds.  For example, during early front-end loading cost may be more important than schedule, but during final commissioning schedule may become critical and important to evaluate what’s earned to ensure the project is completed before the funds evaporate

Focus on Quality

On projects, the focus between quality, cost and schedule is likely to be unbalanced in favour of schedule and costs – and often unwittingly at the expense of quality.  Figure 3 illustrates the pressure on schedule and cost because of a poor focus on quality.

Bias towards cost and schedule

Figure 3:  Bias towards cost and schedule results in poor quality and increased costs

This imbalance exists, and will continue to exist because the real cost of quality remains hidden among total costs. Quality Management Systems (QMS) have recently been introduced that, over and above the traditional quality practices, can also track the cost of poor quality on a project in monetary terms, capture the lessons learnt and enable the organisation to improve the overall performance of projects. Implementing such an advanced system requires substantially more investment in prevention techniques rather than in appraisal of quality but results in significant reduction appraisal and non-conformance costs. Using such a system has already proven in real cases the advantages that can be gained.  This is illustrated graphically in Figure 4.

Prevention rather than appraisal

Figure 4:  Prevention rather than appraisal leads to increased profits

Ensuring Quality

Quality can, first and foremost, not be achieved without an integrated project team representing all the core competencies required to execute the specific project.  Ensuring that you have the right people on the job is a key starting point to ensure quality deliverables.  Figure 5 shows a typical integrated project team consisting of a sponsor providing the overall leadership, a core project management team consisting of members from project management, technical, business and operations. The core competencies in each of the aforementioned areas are also shown in the diagram.

The integrated project team

Figure 5:  The integrated project team

When the project team lacks skills in certain of the areas, a balanced and complete view of the requirements cannot be set and neither can a complete quality focus be achieved.

Although having an integrated project team on board is a good starting point, it does not, on its own, guarantee quality.  The project leadership still needs to nurture a quality mind-set that is supported by adequate processes and tools, assisted by Human Resources to strengthen the discipline, including the integration thereof.  This is where weaknesses are identified and training is required for enhancement.  Using an advanced quality management system, as discussed previously, can help to focus the team by tracking and reporting on the real cost of quality as the project proceeds.

Concluding remarks

A quality approach means that all deliverables across the total project life-cycle must be of quality.  This not only implies quality assurance of the product (hardware) being delivered, but also the project charter, the business plan, the design work in all study phases and the project execution plan as examples.

A quality approach leads to improved efficiency, safety and profitability.

References

Mazohl, P., 2013, Project management.  Available from http://www.further-training.net/pm/keep-an-eye-on-quality/  Accessed 0n 26 August 2016.

Wikipedia, 2016, Project management triangle.  Available from https://en.wikipedia.org/wiki/Project_management_triangle  Accessed on 26 August 2016.

 

You can download this and other Insight articles from our website at https://www.ownerteamconsult.com/download-insight-articles/