Creating the optimal asset

Overview

I have spent my career procuring assets, delivering projects, and collaborating on the long-game of operations and asset management after project delivery. Through these experiences, what has become apparent to me is that optimal project potential is reached when a few simple steps (what I refer to as Golden Rules) are incorporated not only in the very early stages of the project’s foundation, but, more importantly, when they are actively engaged throughout project execution. The following series will explore how we can maximize the benefits of these Golden Rules.

The rules, in and of themselves, do not constitute a new approach to doing work. Many of them are commonplace in today’s projects. However, I believe their value is often underestimated or miscalculated. In this six-part series, we will identify specific elements of the rules that possess the most potential to have a long-term, positive impact on project delivery and outcomes, thereby optimizing future operations. 

The Golden Rules

As Asset can be defined as “Anything tangible or intangible that can be owned or controlled to produce value and that is held by a company to produce positive economic value is an asset”, but the actions at the onset in the delivery of projects are not always undertaken by considering “produce positive economic value”. In many occasions, far from it.

An engineer is not only trained to be a great lateral thinker and be innovative, but he or she is also trained in the realities of practicality and what is necessary to successfully “engineer” an asset. Such practicalities include the typical examples of theory, limits, interfaces, rules and regulations, etc. but must also have a strong consideration of economics.

The “Golden Rules” are therefore aligned to support the creation of Pre Operational Optimization and if incorporated adequately in the very early stages of project preparation, there will be a greater ability to extract greater value during the operation of the asset through minimizing the risk of introducing assets that will cause significant frustrations for the Owner/Operator in the 20+ years ahead that they will have to use them:

Rule #1 – Operational basis for the Assets MUST be considered right at the very beginning. Here we look at not only how we should establish the design specification intent, but why we should provide a greater emphasis on what challenges the “Operations Manager” may face.

Rule #2 – Understand the balance between “Innovative Benefits” vs. “Innovative Risk.”If the technology is new and not well proven, then you are an Innovation Leader and can unwittingly (or wittingly) be introducing Innovative Risk. If the technology is established and proven through the initial stages of its lifecycle, then you are at the other end of the scale as an Innovation Laggard, providing Innovative Benefits and minimizing Innovative Risk. So which path should you take?

Rule #3 – Evaluate the solutions on a ‘Whole of Life Value’ basis. In this rule, considerations of asset cost in the preliminary stages of project definition must go beyond just comparison of the capital outlay.

Rule #4 – Determine if you will use a “Performance-based” or “Prescriptive-based” Specification. Most projects are typically delivered using a “Prescriptive-based Specification,” but this means that the Project Owner subsumes all the risk over the extended life of the asset. Performance-based specifications (or a combination of the two) can provide reduced ‘Whole of Life Cost’ risks by transferring risk to the developer, ensuring that the Operational requirements (as per rule 1) are provided.

Rule #5 – Utilize the metric of Overall Equipment Efficiency (OEE). Indicators of maintenance, such as OEE, provide a structured, reliable, and cost-effective method to facilitate work and maintenance of decision-making processes. From both short- and long-term perspectives of asset management, it can be extremely beneficial. If considered in the Design process evaluation, it can reduce capital outlay and establish a strong basis for performance management from the start of operations.

Rule #6 – Remember that Value Engineering WILL add value. The value of a product or service can provide an increase of its function or a reduction of its cost. Therefore, value engineering seeks to analyse the function by examining the how-why equation to identify relationships that increase value.

Short-term focus makes for long-term problems

All too often, the project team takes a myopic view of the project. The golden rules are extensively downplayed in the feasibility study stages of the project. Instead, asset design and capital costs inform the majority of project design efforts, and are elevated ahead of Operational Considerations, which don’t seem to reappear until the team begins to consider Operational Readiness. Why is this? Most project teams are motivated only by their performance measurement – project delivery. They are less concerned about long-term operational performance, which is considered someone else’s problem. By that point, the team will have been long finished with the project, and likely long gone.

As we take a deeper dive into these golden rules, we should stop to consider that maybe, just maybe, we can provide improved, positive outcomes for our clients, for the asset owners, and for the operators who must manage the consequences of our designs. Are we really optimizing assets from the start? How can we do better?

Golden Rule #1: Operational basis for the Assets MUST be taken into consideration right at the start.

Defining what you want your asset to do sounds simple enough, right? But, this is exactly where everything can go very wrong. It’s the start of the pointy edge. Everything in the asset feasibility design stages or procurement process begins here, and if you get it wrong (from an operational perspective) – you’ll never live it down.

The Basis of Design (BoD) is a critical document that serves as a project’s foundation. It delineates what will be delivered to the owner, including standards to be used, climate conditions, performance outcomes (speed, weight, volume, tare weight, gross weight, geometry, life of asset, etc.).

It is vital that the project team takes into consideration that the needs of the Owner are what determines the BoD, not the manufacturer or construction company.

Typically, it is developed on the back of the Owners Project Requirements (OPR). However, many times this does not consider the entire key performance requirement that will have an impact throughout the asset life cycle – the limits to what is acceptable for the operation to perform to expectation. This would then take into consideration quality requirements, acceptable failure rates and maintenance considerations.

The BoD is an iterative document that provides a record of decisions, assumptions and process that are intended to meet the Owners project needs. So, similar to the OPR, as the project evolves the BoD should require continuous reassessment as the owner (and his Operations team if hopefully employed at this time) and design teams make decisions. The owner and project team should not be afraid to then have to reassess the budget and time constraints and amend these documents as changes occur. It is vital that it takes into consideration that the needs of the Owner are what determines the BoD, not the manufacturer or construction company.

User Requirements Specification

User Requirements Specification (URS) (also sometimes referred to as the Owners Project Requirements) is generally a planning document, created when a business is planning a development and is trying to determine specific needs and details the functional requirements of a project and the expectations of how it will be used and operated

Consultation is imperative. The operating team will live with the assets well after you have finished managing the design, manufacturing/construction and commissioning and this team is really important to you at this time – most would like to avoid them, but you need to learn to engage and embrace them.

Like a Design Brief that a new home owner might give to his or her Architect, it is intended to refine the desired end state – the purpose, the function, the value drivers and the expected operating results.

The URS should cover the criteria of Function, Form, Economy and Time.

Considerations in the URS include (but not limited to):

• Executive Summary
• Project Introduction
• Stakeholder Requirements: Stakeholders listing, organisation structure and interfaces
• Output Requirements
• Location Information
• Required Operational Considerations/Practices
• Integration and Interface needs with surrounding Infrastructure
• Boundaries of project
• Environmental, Social Impact and Sustainability Goals
• Quality requirements
• Project Specific Requirements
• Risk and Safety Requirements
• Design Criteria
• Energy efficiency goals
• Components of Project
• Project Delivery Method/Approach
• Early Operational Readiness Considerations
• Project Documentation requirements
• Project Budget and Time delivery requirements
• Measurement and Verification

Basis of Design

If the URS is the functional and operating brief of what is the desired outcome of the project, then the BoD provides the foundation to which is the approach which must be taken for the project.

The BoD will build significantly on the URS, and eventually may over-ride it, given it will become the most fundamental and contractually sensitive document in the project. This becomes the most detailed account of what is to be built and, as such, is an extremely critical document that will be the entire projects foundation.

Unfortunately, the BoD document is often forgotten until after the design process where it is then hastily thrown together and is effectively of no use to anyone.

All of the Golden Rules are linked to the BoD, which, when done correctly, demonstrates not only the team’s clear understanding of the project’s purpose, but its deliberate intent to preserve the owner’s requirements from inception to operation. 

Each of the elements in the URS are expanded on in detail in the BoD, and references to this document in all other documents and drawings will eventuate. The BoD is a document that records the major thought processes and assumptions behind design decisions made to meet the URS and the design team should use the BoD document to show “how” their), a general planning document that determines the requirements, expectations, and operational functionality of a project, including those specified in the Request for Procurement (RfP). Ideally, the BoD should show “how” the team’s assumptions and specifications will enable the completed project to satisfy the requirements listed in the URS. Consultation and collaboration in creating both these documents are imperative, and, ultimately, in everyone’s best interests.

To ensure the BoD meets all of the owner’s needs and desires, it should address in detail the design elements identified in both the Request for Procurement (RfP) and the OPR. Hopefully, the URS captured all of the owner require­ments in the RfP, but it’s a good idea to review the URS against the RfP.

The URS must serve as the source document for the BoD. So, it is important that the first major section of the BoD provide a restatement of the URS’s project description—an overview of the purpose and essential functions.

Each requires continuous reassessment as the owner, the operations team, and the design teams make decisions. All must be unafraid to reassess the budget and time constraints, and amend these documents, as needed.

If a URS has not been provided by the Project Owner, then the development of the BoD becomes even more critical, and collaboration even more important. It may be required that the BoD in this circumstance needs to be developed with more detail and background information so that it can cover off the expected detail that would have been covered in the two separate documents.

Avoiding the “decision-making hiatus”

Some engineers may view all this front-end collaboration as opening the door to risk: potentially introducing design delay and over expenditure in the asset procurement. It is rare that a manager will consider the impact of capital payback if you get it wrong at this stage.  This is because the manager’s or engineer’s performance bonus may be calculated on conventional industry metrics such as meeting schedules and budgets, no matter what. It is this maddening approach that needs to be countered in the preliminary stages of the project, to ensure that the “decision-making hiatus” is averted.

Schedule is hard to negotiate because business pressures almost always require a project to start on time, since cash flows are necessary to pay off the investment expediently to meet business and market expectations. But let me put this out there – is blowing the budget by a small percentage worth it, if it will significantly reduce the risk of asset failures or inefficiencies as the operation begins? A cost benefit analysis of the impact, in many cases, will prove that a slight overrun in budget can be paid off in just months. This is, again, why the BoD is the most fundamental and contractually sensitive document, establishing the project’s purpose, approach, function, value drivers and expected operating results from the get-go.

All of the Golden Rules are linked to the BoD, which, when done correctly, demonstrates not only the team’s clear understanding of the project’s purpose, but its deliberate intent to preserve the owner’s requirements from inception to operation. 

In part two, we'll discuss how to understand the balance between “Innovative Benefits” vs. “Innovative Risk.” 

Explore all six parts of the 'Creating the Optimal Asset Series'.