Fast growth of the information volume and resources, we witness today, has made analysis of the information credibility (IC) a crucial task for business success. It tries to answer the question - Can we trust the information and to which degree?

In project management IC deals with three kinds of information: the contractor technical expertise, its management skills, and the input data needed for the project execution. This article focuses on the last category and the easiest one. The first two categories require application of expert systems transforming credibility as a quality perceived by individuals into some score. These systems are not part of modern project management

Input data cover different aspects of the project from technical to environmental, to legal. For instance, technical data is represented by attributes and parameters describing equipment pieces (They may be found in the equipment datasheets). The total amount of parameters and attributes for the average mega-project is well above 20000 (twenty thousand).

These parameters and attributes come from disparate information sources with different levels of credibility ranging from educated guesses to certified data. The project may be staffed with top-notch experts, but if the data input (or part of it) is garbage, the output will be garbage as well.

To mitigate GIGO (garbage in, garbage out) phenomenon, conventional project management (PM) introduces four levels of information credibility – pending (decision), for information, for construction, and as built. They are self-explanatory. In any system, the item with the lowest level of information credibility (ICL) defines the system's ICL.

As different parts of the project have different tolerance to the information inaccuracy, the team may start working on the project even if not all 20000 inputs are tagged "for construction".

Such work – called concurrent engineering - shall be synchronized with the timely ICL update.

For example, general assembly drawings obtained with quotations (having the "for information" level) are sufficient for starting mechanical design, but not enough for completing it – the "for construction" level is required.

Today inadvertent mixing of both levels is a norm. It leads to massive re-work and boosts engineering work hours by a factor of 3 – 4. This is accompanied by errors in purchase orders increasing capital expenditures by 2 - 3 % .

How has Crenger solved the ICL monitoring, update, and synchronization challenges? From the very beginning, ICL was the core part of the Crenger development philosophy extending to the information review and approval process. ICL is present at any point of its software hierarchy. It may be easily retrieved for the P&ID item parameter or attribute, for the item, P&ID, group of items, the purchase package, or any item of the plant wiring. Crenger introduces a global update of ICL for P&ID or some area of the plant. The ICL change may be annotated, the change notifications may be sent to subscribers.

The same approach is extended for file management. Files are the second big source of input data: general assembly drawings and specifications of procured equipment, engineering reports, guidelines, and sketches. For instance, the required documentation pack for the large-capacity pumps of over 600kW includes 36 files.

Finally Crenger links ICL to the main phases of the project – engineering, detailed design, etc. Any transition to the next phase triggers auditing of the information; data inconsistency, pending or outstanding issues, and unfinished tasks block the progress.