The importance of verifying designs

Image source itpro.co.uk

Introduction

Imagine yourself in this situation. You are a discipline lead on a multi-million dollar project. You have a
package of work due Friday which is the detailed design drawings for a concrete structure. You know
that for verification to be complete the model, drawings and calculations need to be verified. The thing
is, you dont think you can get the verification complete in time and there is pressure to get the
deliverable out the door. Your team has done this design before, surely there wont be any errors?
Right?! What do you do?

We have all been put in this situation at some point during our career. How you answer this question
really says a lot about your quality ethos as a person.

Why verify?

Verification can be defined as the process of establishing the truth, accuracy or validity of something.
ISO9001 requires that verification be performed in accordance with planned arrangements to ensure
that the design outputs have met requirements (paraphrased). Clearly verification is seen as important,
otherwise the ISO standard would not have included it.

What happens if we dont verify? is probably a good question. Well, its a risk issue. You could end up
with design errors making their way into construction. All designers, no matter how good they are, are
human and may make mistakes. A product that doesnt meet its requirements could be the end result
of a design error or omission. This could be a safety, technical performance, durability or maintenance
type issue. Rectification of this could cost a lot of money. Not to mention the fact the company
responsible for design could end up with a contractual/PI/PL claim and damaged reputation.

Image source Image source the chive.com Image source the chive.com
funniestarea.blogspot.com

Figure 1: Bad design were these verified?

1
Companies want reputations as reliable and trustworthy and capable of consistently producing a good
product. To recognise this, it is not uncommon for design consultancies to have quality management
systems with procedures/clauses that state verification is mandatory on all outputs and must be
undertaken from someone independent of the team. So process is often not the issue. Verification not
being undertaken tends to be behavioural.

Verification takes discipline

Lets be brutally honest.

Unless you have a disciplined
and organised team, there is a
high chance verification may
end up rushed or wont be
thorough enough. At the
outset of a project it is critical
to ensure a culture is instilled
where verification is non-
negotiable and deliverables
dont go out the door without it
having taken place and being
undertaken properly. Take
pride in your work!

Image source liveanacelife.com

To help the team build a good verification culture, some critical things need to happen, which are:

Determine deliverables.

Define project requirements.

Determine verification methods, timing and budget.

Agree a process.

Find experienced verifiers.

Assign someone to lead or manage the verification process

Firstly a verification plan needs to be developed. Ideally this means going through the list of
deliverables, grouping them into packages and then determining dates and durations for the verification
activities of these packages This can then be built into a verification planning document (perhaps a list
in excel) and also ideally built into the project schedule as package sub tasks. In order to determine
package verification durations there needs to be an appreciation of how the verification will be
undertaken and by what method and at what time. This is where our assessment of risk comes in.
Have we undertaken design like this before? Is the design complex and unique or repeatable? How
experienced is the team member producing the calculations? Questions like this will tease out whether,
for example, fully independent modelling may be required, or whether spot calculations may be suitable.

As a default, time should be allowed for independent modelling, calculations and analysis to be
performed as well as a verification of document details. Time for the verifier to check the design against
technical requirements and client standards needs to be allowed as well. The experience and
knowledge of the verifier will have an influence on duration too. The norm for verification turn around
for a package of reasonable size tends to be 2 weeks. That may not be full time. Short reports or simple
deliverables may be 1 week. So you can put these times into the schedule by default and then tweak
after discussions with the discipline leads and lead verifiers. In terms of a budget, the best way to work

2
up a budget is by assigning verification hours to work packages. This is done in consultation with the
key discipline leads.

Ok. So now lets assume you have your budget and durations. There could be a critical thing you
have missed. Did you read the contract and scope of works? Did you double check all the
deliverables the client is asking for? Are
you certain the team know the standards to
be adopted on this project? Do they have
physical copies (or pdfs) of those
standards? Have they read them? Do the
team know about any particular project
requirements in technical criteria? To
address the uncertainty of the answer to
these questions being no, you can request
each discipline lead to produce a design
brief for their discipline at project inception.
This is often called a Design Criteria Report
(DCR) and may be an actual report or
possibly in a memo format.
Image source wisegeek.com

This DCR can include a list of packages and deliverables, reference to applicable client standards to
be adopted, details of software to be used for analysis, assumptions to be made as well as details of
how design packages will be developed, reviewed and verified. Most often this is an expansion of
what was included to the client at tender stage but with more detail applied. Writing the DCR at
project inception and getting it signed off by a verifier and then the client can be very helpful. These
DCRs inform the team and the verifier and create a baseline for design and verification that everyone
has agreed to. The last thing you want is arguments between a designer and verifier about what
standard is applicable during verification at the 11th hour or whether particular software is acceptable
or not. DCRs are common for the geotechnical discipline where parameters and interpretations are
critical. But they can be just as useful and thought provoking for the design team when applied to
other disciplines. The process of producing such a DCR gets the designer to stop and think about
things.

Next, lets discuss process. If you are lucky, you will

have a Project Leader or Director who put a lot of
thought into developing or adopting a digital work
solution for your project with workflows. The not so
fortunate will have to manage with a standard
Document Management System and simply sending
the verifier a word and pdf copy of the Verification
Form with the deliverables to be verified. If you do
resort to email, at least be organised with your
project folder structure to file verification packages,
forms and close outs with a structure that reflects the
WBS and verification process. Image source pipefy.com

As a guide for each package you can have a folder for Verification Brief, another for comments
received and another for close. These can be part A, B and C on a form. Always ensure that as part
of the verification process verification comments are categorised with some sort of importance level
(low, medium, critical) and distinctions are made between non-compliance to DCR and nice to haves
(i.e. recommendations). Its also helpful to stipulate in the process that if critical issues are found a
meeting will be convened to discuss the issue urgently prior to formal comments. At least this gives
the design team a heads up and a chance to start rectifying the problem while verification continues.

3
Some people organise a verification meeting or have a phone call mid-way through the process with
the verifier just to check in as par for the course on all packages.

Lets talk about Verification Databases. Some clients pull the standards and project functional
requirements into a database and then attach WBS type attributes to each item so filters can be applied
and a verification undertaken that all requirements have been met for each package. If you or the client
do decide to use such a package then think carefully about the additional time that may be needed to
develop and maintain such a database, as well as who will have access and what reports you might
want it to perform. You need to determine if the benefit of its robustness is worth the cost to develop
and maintain it.

Lastly lets discuss people. Experienced verifiers are worth their weight in gold. Most discipline leads
have a go to verifier they have used for years who they can trust. They may delegate some of the
number crunching but they take accountability for the verification all the same and are respected as an
expert in their field. Something to bear in mind is that experienced personnel can be very good at
highlighting issues. So you will need some processes in place to handle design dispensations (where
a relaxation is being sought) and also a process for handling a situation where a designer and verifier
cant agree on an issue. A go to list of alternative subject matter experts for dispute resolution can be
helpful but sometimes the Project Director will just have to make difficult decisions.

Conclusions

Taking all the above into account you can now see why on larger projects it is not uncommon to
assign a team member with responsibility for verification. This person plans and coordinates the
verification, ensures verifiers have copies of standards, handles a budget for the tasks, assigns
personnel to lead the verification process, ensures packages are verified in a timely and robust way
and manages and reports on the progress as well as handling issues and communications. On
smaller projects the Project Leader can do this, but when you start to have over 25 packages it can
get so that a part time coordinator of verification is a good idea. When the design fee hits $20m+ you
can start to create a full time review/verify manager role. It all starts with careful planning at project
plan stage.

Determine deliverables.

Define project requirements.

Determine verification methods, timing and budget.

Agree a process.

Find experienced verifiers.

Assign someone to lead or manage the verification process.

If this is done well, then delivery and verification will go well. Thats providing your team produce good
designs! And thats probably a subject for another article.

About Christian Mapes

Christian is a quality and systems specialists with over 20 years industry experience, mainly in the
transportation sector on major projects. He works for Aurecon as Systems and Procedures Lead and
his role involves quality management assistance on projects as well as internal business improvement
initiatives.