Skip to content

How To Successfully Handle Project Snags

We are currently doing the final tests of our new Open Item Database. This is a feature-rich, yet simple tool for EPC (Engineering, Procurement, and Construction) projects to record and manage open items, and more specifically, project snags.

 Why do you need this database?

From our experience in EPC projects, snag management can be very painful. This happens especially towards the end of the project when relevant stakeholders have gone and some severe project snags need closure, but keep in mind that it may be difficult to find the exact root cause. But wait… there is more!

A typical EPC project is complex and usually consists of a large undertaking. Most of the time all work packages and activities are planned using professional tools and the project teams carry out the activities in the work packages. However, during the project, there will be issues, comments, project snags, or even faults and defects. The question is how can these managed?  What is the best way to manage these issues? Usually the traditional first thought is to manage it in an excel-sheet where somebody updates it regularly.  As issues and snags are cleared the excel sheet will reflect this. Typically this person managing the excel sheet will be the QA/QC department or person.  The management of these items are essential and it shall not disturb the ongoing project activities. Clear categories are the key for managing these items besides a clear detailed description.

How do we differentiate open items?

  • Comment
  • Issue
  • Snag
  • Fault
  • Defect

In general for each open item, the most important part is a clear description of the topic and where it originated. The worst thing is to have an open item list at the end of the project without a clear description. That’s when it becomes really difficult to close items because assumptions may be made, people involved aren’t clear on what is needed and the client may not be willing to sign-off on the project due to all the pending issues.

In many cases, the open item is a comment which may be one or more of the following:

  • stakeholder opinion which needs to be addressed
  • a drawing or document
  • or just to say “yes sir” with an answer “noted”

If this is completed the item can then be closed.  Comments are important to record, but note that it may be just an opinion or an idea but not more. Ideally, comments should be dealt with in the regular meetings and in meeting minutes. It can also help to include comments in the database for active management and closure of the comment.

If it is a major issue that requires more than a simple “noted” from a stakeholder, then it is more serious and has to be resolved. An issue on the table has to be analysed carefully to understand the the root cause. An action plan needs to be initiated and executed to close the issue. Issues are typically internal open items, which need follow-up. Again, active management and issue closure is vital so that the remainder of the project is not effected.

How and when do you spot snags?

A snag is typically raised during an inspection either from installation inspections, FATs, SATs or other Client inspections.  In EPC projects, the collection of snags it is called a snag list or punch list. With this database system for open item management, these so-called snags will be analysed when entered into the database and given the right category. Is it really a snag or is it just a comment? This may simplify the follow-up and sign-off on the open item. It looks better in the statistics if you have 7 comments and 3 snags out of 10, instead of 10 snags in your report.

 What is the difference between “fault” and “snag?”

The definition of fault is similar to snag, but a fault carries more weight and it clearly indicates a mistake, either as a single incident or a more complex system fault. A fault has to be fixed. Faults typically arise during system integration:

  • if interfaces do not work together,
  • software faults are linked,
  • a cable fault needs to be managed to make the system work again.

For instance a cable fault can have a severe impact if it is a long and substantial cable and due to contractual requirements it is not permitted to join cables. Hence the whole cable needs to change. It requires a clear follow-up and fault management with the database.

 What is a defect?

A defect can occur before project completion, but it can be an effect of an issue, a snag or a fault that causes a defect. During the defect liability period, (DLP), a defect needs immediate follow-up by the contractor. Under normal circumstances, the defect is to be fixed by the contractor free of charge during DLP. If the contractor can prove that the defect is caused by wrong operation or other influences not within the contractors control, the contractor can still fix it, but it can be charged back to the Employer.

All the above incidents and open items need proper documentation and follow-up. The better it is managed, the faster things can be closed and the cost reduced. For a large-scale EPC project the amount of open items easily exceeds the 4 digit numbers. Therefore, to manage it in a database with clear references, evidence based on pictures, videos and other records will be of tremendous value.

If you are a new Project Manager, it would be great to start making this process a habit to better set yourself and your team up for success!