Is the Juice Worth the Squeeze

Is the Juice Worth the Squeeze?

Assessing the cost of AWP software
Is The Juice Worth the Squeeze? – Assessing The Cost of AWP Software 

By Andrew Foy, O3 Solutions VP of AWP & Construction 

Using Advanced Work Packaging (AWP) software on your project is not the same as getting a license of Microsoft for your home computer. AWP software is infinitely more complex and specialized. Unfortunately, that is also reflected in the price. At O3, we often get asked whether “the juice is worth the squeeze” in implementing AWP software on a project. This should address that question.  

Why do you need AWP software?  

Let’s start with the basics. The first question in any situation like this should always be “why?”. The answer to this is to be found in the complexity of modern capital projects.  

Typical projects will include information from dozens of sources, data from a multitude of stakeholders, and constant updates and changes across the whole project lifecycle. Corralling all this information and making it available to Workface Planners (the people who build the Installation Work Packages) is a mammoth task.  

Technically, work packaging with paper and pen or with standard MS office tools is possible, but it is very labor intensive and incredibly prone to error. It also means that you aren’t maximizing the value of the project information at your disposal. If you don’t have a data-driven system that can tie together the various data sources, it becomes a manual process that must be done by your Planners.  

 Ok, I need software to manage AWP on my project. Can I just build it myself?  

Some people have tried. The vast majority of them will fail. In fact, in the time that I have been involved with AWP, I can think of only one company that has successfully created AWP software internally and used it on projects. And they had a small army of programmers and data experts working on it for years. Everyone else, even if they start down that path, quickly finds that it is not the right approach.  

As part of our vlog series, we addressed this exact issue and listed some of the reasons why it is never as successful as you might think. It is also a false economy, costing more to develop and maintain internally than to get purpose-built software available from a commercial provider like O3.  

The link to that vlog and the associated blog is here 

Isn’t paying for software is just going to INCREASE my costs?  

This is a common question about AWP as a whole, and the software cost element has much the same answer. It is critical to consider not only the costs but also the benefits. The best way to look at this is by assessing the Return on Investment (ROI).  

Yes, doing AWP will cost money, and using a top-grade software will too. But the potential savings will outweigh the costs, typically many times over. By calculating this ROI, you can demonstrate to your management team that you are being a good steward of their money.  

O3 developed the first ever AWP ROI tool, to allow our clients to calculate the investment and savings and show the overall value proposition. Critically, this ROI tool shows not only the benefits of doing AWP, but how those benefits will change depending on whether or not you choose to use AWP software.  

The main headline from any such ROI assessment of AWP with and without software is that the software costs are always dwarfed by the additional savings, both in terms of cost avoidance (lowering the cost of Planners) and additional effectiveness of AWP itself. Typically, the reduction in Planner costs alone is enough to easily cover the software costs, so the savings in craft labor can be placed entirely in the “win” column.  

 How can it take that much longer to build a package manually?  

Firstly, it’s not just a question of building the package. That’s only part of the package management process. The Planner’s role should also cover every aspect of the package lifecycle, including approval, constraint management, change management, progress, close-out, and feedback.  

If all you are asking the Planners to do is create the packages and throw them over the fence to the construction crews, you won’t be getting the efficiency improvements from AWP and Workface Planning that you could be.  

Let’s take a look at the various steps, and figure out the differences between packaging with and without software.  

Scoping the package:  

Each Construction Work Package (CWP) should be broken down into a series of Installation Work Packages (IWPs). One of the first things that the Planner needs to do is meet with the Superintendent or General Foreman for that discipline and discuss logical breakpoints for the work, as well as the preferred installation sequence.  

With a manual approach, that discussion will involve poring over hundreds of drawings, trying to piece together an understanding of the scope from two-dimensional images and written engineering documentation. Experienced field supervisors will have a good understanding of how to read all this information, but it still takes significant time to unravel, even something as simple as laying out all of the ISO continuations from one sheet to the next.  

With software, the whole process is much simpler. Take a copy of the model, isolate a single CWP on the screen, and in one moment you can visualize the work that has to be done and start working on the best installation sequence.  

Even better, you can use status visualization (coloring the model to represent certain information) to graphically display various data like material availability and drawing availability so the Superintendent and Planner can focus on packaging the work that is supported by the available deliverables.  

Estimating the package:  

Each IWP needs to have an estimated number of hours for field execution. These typically come from standard unit rates or rates of placement that are established at the start of the project. Applying these rates to the quantities in each IWP will provide the hours total.  

With the manual approach, the Planner is required to perform a manual quantity take-off on the package. Each drawing has to be checked, and each different size, thickness, material type, or designation has to be accounted for and tabulated. Then, once all the quantities have been laid out in a spreadsheet, the Planner can look up the relevant unit rate for that item and calculate the hours for each row.  

This process is both lengthy and prone to error. It also creates a very annoying feedback loop for the Planner when they are trying to scope a package. If you are looking to keep your packages to a reasonable number of hours, the Planner must include a certain amount of scope, then estimate the hours and, depending on the result, either increase or reduce the scope to meet the target.  

It also means that, if the Superintendent changes their mind about the scope boundaries, the Planner has a very laborious task of re-estimate the scope.  

With O3, the rates are built into the software during implementation. This means that, whenever a Planner starts adding components to a new IWP, the hours associated with the work are calculated automatically. The Planner can add or remove components and get an instantaneous update on total hours.  

 No manual take-offs. No Excel spreadsheets. No calculation errors. Just immediate, efficient, and exacting results.  

Adding drawings to the package:  

Once the Planner has scoped the package and estimated the hours, the next step is to ensure that the required drawings are included.  

With the manual approach, the Planner will have to flip through a stack of printed drawings or access a document control folder and click on each drawing until they find the ones they need. The Planner will then have to manually compile a list of the drawings using Word or Excel, noting down the drawing number and revision. This is another tedious process that is prone to error.  

O3 can greatly reduce the time and effort of compiling the drawings by setting up relationships between the construction components in the model and the associated drawings. This allows the software to automatically assign many drawings to the IWPs when the relevant components are added to a package.  

The Planner still has the option to add other drawings to an IWP, for additional detail and information the crew might need for the work. But the automation process will vastly improve the time it takes to compile a full drawing list and will remove the need to transcribe the drawing details onto a list in the IWP.  

Adding materials to the package:  

Much like the drawings, the process of adding materials to the IWP is very slow and laborious when done using a manual approach. It will require the Planner to go through each drawing and write down all the required materials, transferring this information line by line into a Word or Excel file.  

As with the other manual processes, this is time-consuming and very likely to result in frequent errors. It is further complicated by the fabrication process which will require the Planner to understand which pipe and steel components have been pre-assembled off-site, and which listed materials have been consumed in that process.  

Again, O3 can simplify the process. The material information can be pulled directly from the construction components that have been added to the IWP, creating an automatic material list. Further, the system can use the fabrication data from spool files and steel detailing files to automatically understand the pre-fabrication status, and therefore only add the relevant information to the IWP in the format that it will be received on-site.  

No wasted effort. No hand-written notes. No confusion over material grades or shop welds.  

Just a streamlined process for generating a field material list that can be automatically added to the IWP and used as the basis for material availability assessment and pick tickets.  


Once the IWP has been created, it should be reviewed and approved by various stakeholders. Typically, at minimum, this would be the Superintendent, Safety, and Quality.  

With a manual process, your Planners must go through the sluggish task of physically printing out each IWP and walking it around to the various people who need to sign it. Often that involves leaving it on someone’s desk and hoping that they look at it. They will often spend hours chasing pieces of paper from one office to the next, trying to find out who is delaying the IWP approval because it is stuck at the bottom of a stack of files and being ignored.  

O3 allows the approvers directly into the system, so they can review and approve the file electronically. And, critically, you can track the approvals to see if there is a consistent culprit for delays. This takes away the guessing and (quite literal) legwork from approvals and status updates.  

Managing Constraints:  

The last major aspect of IWP management prior to release is also the most critical. The Planners need to make sure that every impediment that could impact the seamless completion of a package is identified and removed before it is handed to a field crew.  

With a manual process this can happen in two ways:  

In the first scenario, the constraints become a manual list on the front of an IWP the Planner has to chase around from stakeholder to stakeholder to get “wet signatures” as confirmation the constraints have been cleared. This is a huge amount of effort for the Planner. (Picture it like getting three approval signatures but multiplied by a factor of four). Often this huge effort is what leads to the second scenario, where the Planner just ‘pencil whips’ the list with a cursory review, hoping that everyone else in the process will do their job.  

The first scenario means a significant workload on the Planners, and the second scenario ends up just pushing the problem downhill onto the field crew, meaning that a lot of the benefit of workface planning is lost.  

AWP software, on the other hand, allows for the automatic creation and identification of many constraints, as well as the manual creation of others to supplement the system-generated list. From there, each constraint can be assigned to a particular person, along with a completion date. The process is driven to action, and the system will notify (and, if necessary, harass) the action owner until the constraint has been satisfied and removed.  

O3’s dashboards give the Planners immediate insight into the current status of all constraints and which ones will start impacting upcoming IWPs if they aren’t cleared.  

Other aspects of package management:  

The work of the Planner is not complete when the IWP is issued. Other elements still need to be managed, all of which are simpler and more efficient with a robust software solution:  

  • Change management – handling modifications to package contents, particularly drawings.  
  • Progress – reporting accurate updates from the field based on actual work completed, tied to the package components and the agreed rules of credit. Using status visualization to display package and overall progress using a colorized version of the model.  
  • Performance – assessing the effectiveness of the field crews by tying earned hours to actual expended hours, resulting in a Performance Factor (PF).  

How can it take that much longer to build a package manually?  

I think we can see now that there is a massive difference in Planner effort between building a package manually and building one using O3.  

For comparison, we historically see an average of ten hours or more to create and manage an IWP through its full lifecycle when done manually. That number drops to about four hours when using O3, which equates to a sixty percent savings on Planner costs.  
To reiterate – the savings in Planner costs alone typically cover the software costs easily.  

 The AWP software will pay for itself many times over, but does that mean I have to replace all the tools in my Project Management suite?  

AWP is a process that should sit in the middle of everything you do on a project because it ties into the work of almost every department and team executing the work. AWP cannot exist in a siloed environment and cannot thrive when people are refusing to look beyond the confines of their own scope.  

AWP software should be seen in the same light. It should be a place for collaboration, where all stakeholders can exchange information and maintain the much talked about (but rarely seen) “single source of truth”.  

But that doesn’t mean that the AWP software takes over and replaces everything else you are using. For O3 to be truly effective, it should interface with the other tools at your disposal. This allows our clients to maintain a “best in class” approach to their software needs, as well as minimizing the change management impact of using AWP software.  

Standard project software interfaces include:  

  • 3D model (O3 can support 70+ different model formats) 
  • Document Management System  
  • Materials Management System 
  • Pipe spool fabrication files (PCF/IDF) 
  • Structural steel fabrication files (Tekla IFC) 
  • Completions software 
  • Schedule  

Other information can be imported into O3 from standard project flat file data, such as:  

  • Line list 
  • Valve list 
  • Cable schedule 
  • Instrument index 
  • Equipment list 

All of this allows the project to maximize the use of its existing data, without having to needlessly create additional information just to support AWP. And at the same time, you can use all your standard tools for the other project applications, so your teams can operate with minimal disruption to their standard processes.  

This “best in class” approach provides the greatest value to the project, but also highlights three key areas of risk when considering other tools: 

  • Be very wary of anyone who tells you that their AWP software can do it all, and you can scrap all your other tools. This supposedly ‘integrated’ approach can look and sound very slick in a pre-canned demo, but I have never seen a system that can live up to this promise. And you will typically only discover the gravity of the error when you have gone a long way down a very painful path.  
  • Replacing all your existing tools with a single solution suite puts your project execution capabilities at significant risk, especially when the promises being made for the single solution are not based on existing capabilities. Make sure you understand what the proposed tools can actually do TODAY before you agree to give up your other tools.   
  • AWP will require integration across multiple systems, but also across multiple stakeholders. So, it is equally important to understand how your AWP software will be able to support this data integration with the other organizations involved in the project. It is no use having a system that works for you, but can’t share data back and forth with the Owner, Engineer, Construction Contractor, Vendors, etc.  

 Can I just buy the software, and use it whenever I like?  

O3 markets itself as SaaS – software as a service. What this means is that you get access to the software for a particular project or group of projects. There are a few different ways this can be done:  


You use the software on a single project, and when the project is done, your access to the software ends. In this instance, the cost of the software is scaled based on the size of the project, to provide scalable pricing tied to the value proposition of the project. Essentially, what that means is that you aren’t paying the same for a small project as you are for a large one, where the savings available for doing AWP will be higher.  

In this instance, you can use different modules of O3 software for the various phases of the project:  

  • ONPlan provides the foundation for AWP in the early FEL stages (Select & Define) 
  • ONDesign gives you complete AWP management of the detailed design stage of the project.  
  • ONBuild is the workface planning tool, for managing the construction stage activities and packages.  
  • ONStart takes AWP to its natural conclusion by work packaging all the way to commissioning and completions.  


A single facility may have several different projects all running concurrently, typically of differing sizes and in different stages. Using this model, O3 can provide portfolio pricing that will give all of the projects access to the full software suite at all times throughout their lifecycle. This model is scaled using the annual budget for capital projects, so as your portfolio grows or shrinks, so does your software cost.  

This approach will provide excellent benefits and savings over the project model when a single facility is running at least five concurrent projects, and the savings increase with portfolio size.  


The last option is for the whole company, where any projects within your execution portfolio, regardless of size and location, can be managed using O3. As with the Portfolio model, this gives you access to all of the O3 modules for all of your projects at any time and is scaled using the annual budget for capital projects. This means that all the projects on which you have chosen to implement AWP can enjoy the benefit of the O3 software, and we can grow with you as your maturity and scale develop.  

 Why don’t I get to keep the software?  

The SaaS model is a way of providing you access to the software, without you ever fully “owning” it. That’s why it is marketed as a service model. You still get the full use of the tool and continue to enjoy all the benefits of its development – and we roll out a new release every two weeks – but you pay for it like a service, with the duration governed by the length of the project or using an annual renewal for Portfolio or Enterprise. By paying for the software like you would a service, you only pay for what you need. The data contained within the platform is still yours and can be exported as needed, but once the need for the tool has ended, you shouldn’t have to pay for it. 

 Who needs access to AWP software?  

AWP is intended to be a collaborative process, and the software used to support it should be no different. If you are discussing licenses or ‘seats’, it is very likely that you will not see the full benefit of AWP because you are balancing cost against access. Having to determine who to allow access to, or how much extra to spend to give access to the right people, will just drive bad decision-making.  

O3 uses an unlimited license model, so you can have as many people in the software as you like. All that is needed is a username and password. This allows you to provide direct access to all the project stakeholders, including the engineering contractor, vendors, suppliers, fabricators, construction contractors, and the owner.

Everyone can be set up with the necessary roles and permissions to grant them relevant access, and you can say who gets to see what. This means that nobody can trawl through sensitive data that they shouldn’t have, and it has the added benefit of simplifying their user interface by only showing them the menu items that they need.  

What do I get for my money?  

The software pricing has two elements – implementation services and monthly subscription.  

Implementation services is a lump sum price for the O3 team to work with your team to set up the software. This includes configuration, training, and integration with your other tools. The key difference with O3 is that we don’t push services, meaning we don’t want to sell you, people. Our goal for all implementations is to get you set up and self-sufficient as quickly as possible. We teach you how to use and manage the tool, so we can step away and you don’t have to keep paying for man-hours.  

All that leaves is the other element of the cost, which is the monthly subscription. This will vary with the phase of the project and the O3 module being used, but essentially you pay a fee each month for the use of the software. This gives you full access to market-leading software and allows you to take your AWP approach to the next level.  

 Total cost of ownership 

Another very important thing to consider when selecting AWP software is the total cost of ownership. Typically, the price of the software is not all you will pay. Make sure you understand all aspects of the cost, including:  

Services – This is the big one. How many hours of support will you need to make the software work? Many software providers use complex processes for data manipulation that must be repeated every time you have new data. Others offer customization that needs ongoing support and maintenance. This leads to you having to pay for their services to continue throughout the project.  

Hardware – Old-fashioned providers can still offer ‘on-premise’ solutions where software is physically installed on local machines or servers, resulting in costs for hardware assets.  

Licenses – Selling access or ‘seats’ can make the initial software cost look low but can then add up significantly as you ramp up your use of the software. It can also lead you to have to choose who should be able to access the tool.  

Development – Maybe the software doesn’t do exactly what you need right now, but for a small fee it can be made to meet your exact requirements. This is a very slippery slope, and it means every time you want a new feature, you have to sign a change order.  

Make sure you understand all aspects of the cost before signing on the dotted line.  

 What do I need from AWP software?  

A lot of companies are discovering they need AWP software but aren’t sure what they should be looking for in a product. Going into discussions with software providers without knowing what you want is a lot like walking onto a car lot and saying you want “a car”.  

To make it easier, O3 has produced a guide to technology selection and a document listing the various software requirements needed to support AWP. These documents, produced as deliverable number six in our AWP Implementation Toolkit, can be used as the basis for describing your needs and assessing the offerings of the various providers. They are available in native format, so you can modify them to suit your exact requirements.  

 Who is responsible for purchasing the software?  

This is a common question for AWP technology, and the answers can often be varied. Historically, the Owner has been the first to adopt AWP technology because they are usually the primary drivers behind AWP on a project and have the greatest influence over the whole project lifecycle.  

This can, however, cause some difficulties with Owners who try to push their technology selection onto a Contractor (Engineering, Procurement or Construction) who already has an established process for managing AWP. In these cases, the best option for the Owner is to stipulate the requirements for AWP standards on their project and invite the Contractors to demonstrate how they will meet those needs. If the Contractor has a sophisticated tool, let them use it. If, however, they are trying to manage AWP with Excel or other semi-automated processes, the Owner can offer access to their AWP software for use on the project.  

Ultimately, anyone on the project can hold the AWP software, whether they are the Owner, EP, EPC, Construction Management Contractor or Construction Contractor. The two main considerations for who purchases it are:  

  1. Is the holder of the AWP technology being deployed to the project early enough? (This is a problem if the Construction Contractor buys the software, and isn’t being brought on until the Execute phase).  
  1. Willingness to provide access to the software. AWP is meant to be a collaborative environment, which only works efficiently when all project stakeholders have access to the information, both in terms of reading it and providing it.  

 If you would like any information about anything included here, or further details about O3’s market-leading AWP software, please reach out to us and one of our team will be happy to discuss your needs.  

We are using cookies to give you the best experience. You can find out more about which cookies we are using or switch them off in privacy settings.
AcceptPrivacy Settings