The construction industry is one of the industries that continue to suffer from the high cost of fraud. By definition, fraud is an intentionally deceptive action designed to provide the perpetrator with an unlawful gain or to deny a right to a victim. Types of fraud in the construction industry include billing fraud, bid-rigging, bribery, fictitious vendors, change order manipulation, the substitution of materials, false representation, and money laundering.
Although some might assume that automating the review and approval of procurement and commercial management processes might be enough to deter fraud on projects, nevertheless this tends to be untrue. There are many other project management processes like requests for information, submittals, non-compliance reports, verbal site instructions, work inspection requests among many processes that could be used to support or could lead to fraud actions. Having very tight workflows, approval chains, approval authority rules and transactions audit trails for processes will provide the control measures to immediately catch fraud issues as well as enforce transparency and accountability in executing the project management processes.
Unlike accounting and financial software applications, a Project Management Information System (PMIS) like PMWeb provides a single 100% web-enabled platform to manages all types of processes required for capital construction projects delivery on a single integrated solution. Whether those processes were procurement, commercial, site management, quality, HSE among others, PMWeb will be used to automate all related processes.
In general, each project management process should have its own unique workflow tasks although occasionally some processes might share similar workflows. For processes that share similar workflow steps, they might have different roles or individuals to perform the workflow tasks. Nevertheless, regardless of the workflow was unique for a process or not, all workflow tasks will be performed for each transaction of each project management process.
When it comes to creating workflows for project management processes, one first needs to determine what will be the roles that will exist on a project. Those will address the roles performed by the different entities involved in delivering a capital construction project. For example, entities could include the project owner, project management consultant, design consultant, supervision consultant, contractors among others. Examples of project roles include Project Manager, Cost Manager, Commercial Manager, Quality Manager, Quality Engineer, Inspector, HSE manager, HSE Supervisor, CEO, CFO, CPO, Architect, Civil Engineer, Electrical Engineer, Mechanical Engineer, Structural Engineer, Contractor, Consultant, Contracts and Purchase, PMO Lead among many others.
Each PMWeb user will be assigned a role for those defined roles. A PMWeb user, who is also a project team member, could also play different roles on different projects. Therefore, roles assignment to PMWeb users or project team members could be specific to a project or for all projects. The advantage of doing it at the System level, or all projects level, is that the same roles get inherited to the levels below or projects, and there will be no need to create them again, however, if the user needs to be an assigned to the role that is different than what was assigned at the System level then the same needs to be changed at the Program or Project level.
PMWeb allows defining if a PMWeb user can have multiple roles as detailed above and if the same role can be used more than once in the same workflow process. In addition, PMWeb allows defining who will be the document manager who will receive notifications for all types of workflow tasks or selected ones such as approvals, returns, and rejects. In addition, PMWeb allows defining if the assigned document controller can edit records, workflows, and/or notes.
In addition, the PMWeb system administrator has the option to delegate or replace workflow tasks assigned to a specific user to other users when this is needed. This delegation or replacement could be limited for all projects that the PMWeb user has a role on or limited for a specific project or projects. In addition, delegation or replacement could be for all roles performed by the project team or for all roles. The delegation or replacement could be limited to future workflow tasks, past workflow tasks, or both. Finally, the delegation or replacement could be for a limited time period or permanent. Of course, the delegation or replacement can be activated or deactivated as needed.
The next step is to create the workflow process by dragging and dropping the defined project roles in the required sequence to perform the workflow tasks. Of course, the sequence can be altered by dragging and dropping the workflow task to the new desired sequence. The workflow could also include branches which can be associated with conditions for approval authority levels or the category or type values that are specific for each project management process. For each workflow process, PMWeb allows assigning what is known as Business Process Managers (BPM) who will be the PMWeb users who have the authority to change the workflow tasks after the workflow starts. In addition, it allows defining if there a need to add an alert to the process when a task is overdue. The alert requires defining the number of days before an alert is activated, who should be alerted, and whether this alert to be done via email, online notification, or both.
The created workflow can be also viewed in a visual format if required. The Project defined roles need to be dragged and dropped to the canvas to create the workflow tasks and the sequence for executing those tasks. When adding the workflow tasks, those tasks can be selected to be visualized as submit, step, branch, or finish tasks.
A review duration, in calendar days, needs to be added for each workflow task. In addition, PMWeb allows defining what other PMWeb users or non-PMWeb users should be notified or carbon copied (CC) on each workflow task. Notifications can be either sent via email, online notifications, or both. PMWeb also allows defining to which workflow step the process needs to restart when the process is returned or required to be resubmitted. This is important to capture the workflow revisions for each process transaction.
In addition, PMWeb allows defining the workflow task type as per RACI (Review, Approve, Consult, and Inform) or any other responsibility assignment matrix role abbreviations. Further, instructions can be added for the workflow task if needed. For workflow processes that might have multiple reviewers, PMWeb allows assigning the condition if all need to approve or any of the roles can approve. In addition, PMWeb workflow gives the option of who needs to be notified when the workflow task is performed. Finally, PMWeb allows defining the available review actions for the workflow review step.
One of the important requirements for creating a workflow for a process is the ability to add branches to enforce approval authority levels. For example, for the process of change order review and approval, there might be the condition that for all change orders that has a value that exceeds US$ 50,000 and for out-of-scope work, the commercial manager needs to be notified as he/she will be the one to approve or reject. PMWeb automated rules allow defining the needed rules for each project management process by selecting the exemptions that will launch a new workflow from the current workflow assigned to the process.
The use of automated workflow conditions is not limited to approval authority levels but it can be also used to direct a process submission to the intended review and approval team based on the content of the process. For example, for the RFI form, the category field could be pre-populated with the building systems such as architectural, structural, plumbing, electrical, HVAC, conveying systems among others. In this case, the automated conditions rules will be used to direct the submitted RFI to the workflow that is specific for each RFI category which could be architectural, structural, plumbing, electrical, HVAC, conveying systems among others. This eliminates the guesswork from deciding on who should be included in the review and approval process.
The created workflows can then be assigned to their relevant project management process. Of course, there is also the option of having project management processes without workflow. For those processes, the project team might elect to submit those processes for review and approval using the PMWeb transmittal module where it allows linking selected PMWeb records to the transmittal form. An automated condition can be assigned to the transmittal form, like what was done for the RFI form, to direct the transmittal to the project team members assigned to review and approve the type of record being transmitted.
When a user login into PMWeb, all due workflow tasks for this particular user will be automatically displayed on the control screen. The project team member can select the workflow task to be actioned from the listed workflow tasks.
In addition, email notifications can be also sent to PMWeb users to notify them of needed workflow actions. The email notification template can be designed in the required format as well as different email notifications can be configured for each type of workflow action such as submit, approve, reject, resubmit, return among others. The email template could be also designed to have approve or reject on the fly option by adding green and red buttons to approve or reject respectively. In addition to the hyperlink to the PMWeb process transaction, which is part of each workflow email notification template, PMWeb allows defining what attachment to be sent along with the email notification. Those could include the form output, reports among others. Email notification templates could be locked to restrict editing or modifying those templates.
PMWeb also allows creating reports and dashboards to report on the workflow tasks. Those reports can be grouped by project, process, user, status among others. In addition, delayed workflow tasks can be coded in Red while due workflow tasks in Yellow and those yet to become due in Green. The report can be designed to include visuals that summarize workflow tasks by the process, status, and user.
In addition, PMWeb output forms for each project management process can be designed to display the workflow tasks performed on each transaction. This will immediately provide the history of each transaction showing the responsibility for delays, if any, as well as all actions and notes made in reviewing and approving or rejecting the transaction. The workflow actions can be also used to fill specific fields in the output form like those for approval name, date, and signature.
