In the mega project management world, RFI typically refers to the process whereby project contractors or vendors formally make a request for information regarding a specific scope of work. There may or may not be intersecting work, i.e., other contractors involved in the delivery of the work scope. RFIs are part of a formalized, managed communication process where information transactions are frequently tracked using Excel spreadsheets. There are two challenges with this approach:
- The Excel-based process does not scale well to mega project size. RFIs can quickly turn stale and no longer be relevant, and supporting documentation for the RFI has no where to go and needs to be manually managed.
- There is a single point of failure, e.g., usually only one recent copy. Copy confusion is common. Who/where is the keeper of the RFI spreadsheet?
Is an RFI considered a formal information management deliverable or is it a uniquely engineering management deliverable? In other words, will the Owner eventually want the information from the RFI or is the RFI just used for the life of the project?
I think an RFI is an engineering management deliverable that, as the project matures, becomes relevant to the Owner of the project and, therefore, mutates to an information management deliverable. As such, RFIs should be sufficiently indexed and, at a minimum, be searchable and easily retrievable using a variety of criteria. Excel lists of RFI metadata that may have been adequate for a project will fall woefully short of being useful once the project is handed over.
If we attribute a project lifecycle (including handover) to an RFI in a mega-project, and apply this same logic to the practice of interface management, a clear business case emerges for the use of a tool to manage the information that supports the interface. Unlike RFI management, however, IM programs require – at the very least – early planning, contractor/buy-in, a collaborative space with role-specific access and a reporting component. RFIs could possibly be contained and managed semi-manually, but the longevity or life span of this information would relate to the project only.
Practically speaking, the number of transactions generated from managing interfaces has too many related information assets to manage manually. A mega project’s information and supporting documentation, even during concept screening and FEED stages, will quickly bury a manual interface management process in confusion and frustration. There will be precious little interface information to hand over to the Owner. Interface decisions and related information history are just too valuable to lose to confusion.