When it comes to managing the delivery of capital projects, usually there are hundreds of processes that need to be implemented by the entities who are part of the project delivery. Those include processes at the project initiation, initial planning, tender for the design, design development, tender for construction, construction, testing and commissioning, and turnover and closeout phases. For each process, the project management team defines the form for the different entities to use to perform and communicate the process by a pre-defined workflow that identifies the entities responsible for initiating the process, reviewing, approving, and keeping others informed.
To understand the criticality and importance of timely and correct execution of those project management processes, organizations involved in capital projects’ delivery started using collaboration applications like Aconex to electronically communicate those processes. The Aconex mail module is used to communicate those project management processes where an HTML template of the process form will be displayed in the message part of the mail form to allow the project team to fill in the information needed for the process. Nevertheless, this is information is not captured as data as captured data is limited to the Aconex default fields like mail type, to, form, response required, subject and attributes. In other words, all this added information gets wasted.
Of course, the Aconex Mail module allows attaching the relevant documents for each transaction that was uploaded into the Aconex document management repository. In addition, it allows linking other mail messages to the created mail. Further, the initiator of the mail communication can also select to whom the mail needs to be sent so they can be notified of the needed action. The list of recipients who could receive those mail notifications will be predefined in Aconex with the option to add other recipients at the time of sending the mail if those were not already predefined.
The Aconex Mail approach is similar to the PMWeb Project Management Information System (PMIS) correspondence module approach which also allows inserting an HTML template in the detail part of the correspondence form. Of course, with PMWeb the number of database fields that are part of the correspondence module is unlimited and they include default fields such as WBS level and project schedule activity (which will be imported from the project schedule) among many others. Supportive documents that are uploaded into the PMWeb document management repository can also be attached to the correspondence module as well as links to other PMWeb records and imported MS Outlook emails.
In PMWeb, the distribution of the created mail, which represents a project management process, is more than just selecting who to notify of the message. Unlike the Aconex mail module which does not have the workflow option and simply assumes that each project management communication has a single communication channel “From-To”, PMWeb allows having a unique workflow for each project management process type. This allows involving all those project team members who should be part of each project management process, which usually differ depending on what is being communicated in the mail. In addition, a predefined process identifies the workflow steps that need to be followed in the review and approval process, the duration of each step, and what happens if there is a requirement to return or resubmit the mail message. PMWeb also allows adding conditions to the workflow to adhere to the project’s approval authority levels.
Nevertheless, this is not the way a Project Management Information System like PMWeb is designed to perform. A PMIS is not just another mail and document management system. Instead, for each project management process, a PMIS like PMWeb has unique input forms to capture the data and all relevant information for the process. PMWeb comes ready with most of the input and output forms as well as reports that are considered a must requirement for capital project delivery. These include, for example, the processes for the request for information, submittal, meeting minutes, safety incident, punch lists, budget, budget adjustment, commitment, change orders, progress invoices, potential change orders, daily reports, funding requests, and risk register.
In addition, PMWeb visual custom form builder allows creating all other needed forms to execute the project management processes that are not available by default in PMWeb. For example, assume that for a certain project, there is a need for a “Site Inspection Notice” form, a form that PMWeb does not have by default. PMWeb accepts the HTML file format of a MS Excel template already created for the form.
PMWeb custom form builder allows importing the HTML file template to create the new form and as preferred by most PMWeb users, uses the custom form tables to create the form to match and optimize the desired form template layout. PMWeb custom form builder allows merging table cells horizontally and vertically, having different colors for cells, having different font types and sizes, having fonts to be bold, underlined, or italic, and adding logos, add hyperlinks, among others.
The new form data fields created in PMWeb needed to capture the needed information maps into the created visual form. The created data field formats could be text, numeric, currency, date, Boolean, and data lists. The data list field, which is similar to attributes, is very important as the organization can predefine all data dictionaries with all possible values to select from. For some projects where there is a need for dual language displays like English and Arabic or English and Spanish, those lists could have predefined values in both languages. The size of those fields can be controlled by the user who is creating the form. For the currency field types, PMWeb also added formulas to calculate other currency field values.
Knowing that for each form there could have different team members involved in completing different parts of the form, the PMWeb custom form builder allows assigning permissions for the created fields for the different defined project roles and users. Those permissions set the rights to view or edit the values of the defined form fields. In addition, it sets the permissions for creating, deleting, editing, and viewing the created custom form. This is a must requirement when the form is shared in a workflow where different project team members could have different permissions to complete certain sections or fields within the form itself.
The completed visual custom form is now ready to be accessed using any web browser on any device whether it is a desktop or a mobile device. The form has the fields to be completed in their relevant field type. All supportive documents can be attached to the form and other relevant PMWeb records and imported MS Outlook emails can be linked to the form. The pre-assigned workflow ensures that the form is channeled to its intended recipients with access restricted to their only permitted form fields. This is critical and a must requirement for ensuring transparency and accountability. What is also more important is that the captured data in the form becomes automatically available to be reported on in any desired form and format without the need to reinput this data into MS Excel spreadsheets.
Another very important feature of the PMWeb custom form builder is the option to create multiple tables to capture data in a quick and structured format. For each table, multiple fields will be created to capture the needed data. For example, for the Site Inspection Request form above, the site observations and actions could have been added as a table. This would allow increasing or decreasing the reported observations without the need to modify the form.
The fields in each table could be text, numeric, currency, date, Boolean, and a list of predefined values. Some of those fields could be locked to enable showing the fixed predefined values created for them. This is a very important feature for creating checklists where tables are used to inspect the work against a predefined lists of items to be inspected. Again, access rights can be restricted for roles and users on which tables they edit or view.
The Environmental Inspection Checklist form shown below details how the custom form has included multiples to capture data on Air Emissions, Nuisance Control, Resource/Energy Conservation, Waste Management, and others. For each table, predefined values for items to be inspected were added. When this form is used for the environmental inspection, for each inspected item, the inspector needs to provide the inspection compliance score of “10” for Full Compliance, “5” for Partial Compliance, “0” for No Compliance, and “NA” for Non-Applicable items. In addition, details of the required actions will be added as well as the risk rating of the taken actions which could be Extreme, Maximum, Medium and Low. Again, the action risk rating values will be predefined in a list to select from.
