Article 1 - Tracking Deliverables

The Technical Meeting

PHC Technical meetings happen frequently, not for their own sake, but in the interests of the project and efficiency. Meetings are always short and effective!

Daily Meeting FormatPHC Technical meetings occur everyday throughout all project locations. Usually the meetings are chaired by a PHC consultant, but depending on the geographic spead of the project it is sometimes necessary to nominate a PHC champion to update the systems, or for a PHC consultant to chair a meeting remotely. Whichever way, the PHC technical meetings always follow a specific order and never run for more than 30 minutes. Each meeting is a “toolbox talk” that brings out daily problems and updates that are made in full view of the project.

Deliverables ListWherever the Technical Meeting is held and with whatever participants, an appropriate list is generated that is relevant to all parties present. The illustration shows an example of the list, which is a standard output of PHC and is used as a common status indicator throughout the project. It has areas that show the Deliverables' ID fields, Status fields and a panel that acts as a look ahead for planned state changes. It also has a status matrix that shows where the selection fits within the overall status of the project's deliverables. In practice this list is rarely printed and meetings take place with the list contents displayed on a projector screen.

Although we talk about the PHC Technical Meeting as though it were a PHC 'exclusive' meeting, in fact it is no such thing. In every project and in every company there are technical meetings, 'toolbox talks' and 'reviews', some formal some informal. With PHC we insist on a meeting regime, but integrate into the meetings that already occur. The difference PHC makes to the meetings is that an order and sense of urgency is imposed as everything is recorded and assigned by our PHC consultants making the forward plan and accountability crystal clear.

The first meeting using the PHC approach is quite refreshing to the engineers who welcome the chance to speak freely about their deliverables and realise that what they say, request, inform and query, will be acted on immediately. Engineers leave the meeting knowing the meeting participants will get the 'e-minutes' by email to their PDA while on the way back to their desk!

According to the size and spread of the project, deliverables lists can be very large. To cover a 30 minute meeting on the Documents deliverables list of maybe 750 items, we frame the meeting by formulating discussion around the few items that are flagged as having time or operational sensitivity. If there are more than can be discussed in the allocated 30 minutes then we either spread the discussion over two meetings or hold separate meetings with 'discipline' leads.
Back to Top

Our Approach to Deliverables Tracking
We answer on a continual basis the question 'What is Where, How is it and How do we Know?' which is in fact the PHC™ project mantra. It is how we go about answering that question using software tooling that is unique to PHC™ that gives us the confidence that we can make a tremendous impact on the Project.

The very first consideration in Deliverables tracking is to consider whether the Deliverable even 'exists' in the first place. We are used to the standard response that 'the deliverables list is in; appendix C of the contract, the Master Document Register, the Department Spreadsheet, the online database, the Vault, the Primavera Plan. Well the truth is that the Deliverables list is in ALL of these places. And we virtually guarantee that on first review, we will find duplications, ommissions, misspellings, new introductions, deletions, and it is these differences between lists that causes the most confusion in a project.

But it is 'quiet' confusion, as no one feels it his responsibility to go ahead and check, let alone carry out stringent regular cross checks that we do as a matter of policy in PHC. This quiet confusion because of its low impact on the wider 'project' persists as a background annoyance that becomes apparent occasionally at first when trying to 'find' for instance a non-existent document. But as the project progresses it is felt more and more as time is wasted on 'chasing project ghosts'. A PHC project simply doesn't suffer from this. As our efforts on cross-checking sources allows us to help the source owners fix their records.

Units Existence CheckFor an example of the power of our approach in action, we can look at some data from the Petrovietnam Dung Quat Refinery (DQR)project. There were 5 centres of design on this project, each in a different country. Each feeding a master database (Wonderware 'InTouch' system) administered on site in Vietnam. We formed a Tag status Deliverables Tracker for each of the Tags in the system and reported the Tag's in Plant System categories.

When you check for 'existence' of deliverables using a PHC approach, outputs allow patterns to be seen in the data. These are 'questioned' and at the documentation stage they are corrected. The example here relates to the 4 Tags shown against Plant Unit '011 - CDU' that are shown as handled by the Milan team [Column M] while the other 4,979 tags for that plant system are shown as handled by the Kuala Lumpur team [Column KL]. This related to a simple error one of the [KL] P&ID documents . Easy (and inexpensive) to fix at the documentation stage. This would have caused the loss of tens(or even hundreds) of man hours if the errors had persisted in the documentation until commissioning time.

Systems Existence Check'Plant Units' was one of the Deliverables Trackers on DQR. We also tracked 'Plant Systems' in much the same way and the same considerations applied as regards 'existence' checking. Identifying the data sources and comparing content reveals patterns that allow documentation to be fixed and information to be distributed effectively. For the Plant Systems, to take for example (from the many inconsistencies on this report), Plant Systems 19-P-80 and 20-P-80 raise a question, as neither of these had a name but had tags assigned to them from the Tokyo team [Column T]. Both of these resolved to P&ID errors and we were able to communicate these to the Tokyo Team and have them corrected.

While 'existence checking' it is a natural to keep the deliverables' status up to date and appropriately in focus. This is one of the cyclic process that the PHC function carries out continuously throughout the project.

Back to Top