Using BS1192 : 2007 with Viewpoint For Projects [VFP] : Case Study

All

I am writing a case study currently that includes the incorporation of BS1192 2007 into several Electronic Document Management Systems like VFP [Viewpoint For Projects], Asite, Conject & BC. There are reasons why I havent adopted Addendum 2 of BS1192 2016... and il explain in the paper upon publication.

The image attached here is the one for VFP which we have tested, "Leaned out" and incorporated into a pilot project using the EDMS autonomous workflow feature.

The process above is how the use of "Suitability codes" can trigger automatic workflow processes leaning out the management process. This is why I am a huge fan of Suitability codes and their correct allocation and adoption because it makes our lives far easier.

What are Suitability Codes?

For your information, a suitability code is a code allocated by the author of a file/document to tell the receiver exactly what they can use that information for. Upon giving this suitability code, the information has a form of status that must be followed.

This removes ambiguity around why its been issued and protects the author from mistakes being had because the receiver used it for something more than he should. Suitability codes really only apply to design and production/construction information. Its not really to cover a basic correspondence letter thats informing you of an overdue invoice from your local fast food place, which you have uploaded onto your EDMS and tried to allocate status S2..... this is a different kettle of fish entirely and isnt what this article covers.

For example, a document uploaded for "information S2" has far less steps to take in the BS1192 process than a document issued at S4. Examples include that when information is shared "For Information" the author is signalling the project team that they are not requesting any action to be taken like commenting, marking up, approval or to build from...its there to use for information only!  (It might be advisable within your project Plan/BEP to define "information Only - S2" and the other status codes if you have to) But something uploaded at S4 is requesting further steps to taken.

• Its requesting that the comments received back from the previous revision issued at S3 have been incorporated to a satisfactory degree.
• Its requesting for permission that your happy with all the content to go to status A
• It could be asking for you to obtain client sanction before reissuing at status A, if thats how you want to proceed (I have set-up a status code specific to this so we can produce reports easily on what information specifically requires client sanction and to pass the responsibility to the designers to tell us which requires this, which in turn feeds back into our MIDP database)
• Any maybe other steps if you believe information at this stage requires other actions to be taken to adhere to your corporate governance processes. 

----------------------------------------------------------------------------------------------

The above diagram has a number of gates. These gates are compliant with the ones defined in PAS 1192 -2 clause 9.2. The process is pretty much identical to that defined in BS/PAS1192 but obviously has different control points and dimension because the technology we are using allows us to manage it in a variety of ways.

WIP can be managed very well on VFP outside of usual understandings of the term. Many believe the WIP should be a folder, thats restricted to only the task team where they can share files in and out. But the autonomous workflow feature within VFP allows for some nifty steps to take place.

• It can allow a task team to upload information like models or documents onto VFP and only allow the uploading task team to see the information....no one else can see it at this stage (further actions required before anyone else can)
• The Task team author can and should upload at rev P01.1 until they sign it off and the TTM places at P01;
• It allows for the task team manager TTM to review his underlings work to do some internal commenting. He can reject if he wishes or download the file and re-upload a corrected version and rev it P01.2. he can then do a final check with his underlings to ensure everyone is happy, re-upload again at P01 whilst keeping all of that audit trail history intact. He can then approve that P01 revision on behalf of his task team which then essentially complies with Gate 1 of PAS 1192 clause 9.1.

This is quite extraordinary because it allows the project team to do WIP on the same platform as all other files and allows intelligent workflow mechanisms to determine if anyone can see them and allows for constant revision (using decimal places) to their hearts content, so long as the final version is changed to the correct revision type signifying a formal publication of the information. The receiver of that information cant see that toing & froing at the WIP stage because the workflow mechanics hide it, nor does he want to as hes only interested in the final product. Only the task team can see all that and they have now kept a full audit history of the minor back-house changes they made before the final version.

-------------------------------------------------------------------------------------------------

Why have incremental revisions using decimal place?

For your information, if you struggle to understand why the P01.1 > P01.2 > P01 is required then let me explain. Lets say your WIP area is on your computer within a work folder. Lets say its an excel file that your about to issue to your boss. Whenever you open and modify the excel file it doesnt keep the previous version soon as you hit save (bar some  modern applications that now do of course) So if you have modified it 10 times, you cant recover the 8th version if you have realised you have deleted vital data. So to get around this you can laboriously save separate files each time before you hit "Save". But your boss wont want to see a file sent to him saying "Version 10"....to him its only version 1. And if he modifies it and it becomes version 11, returns it back to you and you return again at version 27 hes going to be confused. So you only send him a finalised version. The best way to do this is using incremental revisions like decimals. For example, the first version is version 1, but you are amending it several times so it becomes version 1.1, 1.2, 1.3 etc. But when you finish and send to your boss, its still version 1 to him your sending so you just send him version 1.0. You have all the 1.1,1.2 on your computer FYI.

---------------------------------------------------------------------------------------------

This workflow may not work for all. I have been doing some work with a contractor who doesnt want to follow the process of "Suitability A" for example. The part they wanted to change was G4 (Gate 4 in above diagram) for all future revisions of a "Suitability A". He didnt want to have to sign off a Suitability A after Rev C01. This meant that when the drawing was revised to C02, it would automatically go into the published area. I disagreed with this as the designer could have slipped in a crystal balustrade over the cheaper plastic one originally signed off thus auto accepting his amendment without argument. 

I hope the above guide helps. I very rarely see a good implemented BS1192 process that can easily be dissected if the need arises and that makes our lives easier around the control of information rather than harder.

I will be publishing my paper through Salford University when complete.