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, 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 request 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 if 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 consultants, 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 gets inherited to the levels below, or projects, and there will be no need to create them again, however if the user needs to be a 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 for 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 have 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 a 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 needs to approve or any of the roles can approve. In addition, PMWeb workflow gives the option on 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 allows 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 buillding 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 guess work 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 PMWeb transmittal module where it allows linking selected PMWeb records to the transmittal form. An automated condition can be assigned to the transmittal form, similar to 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 summarizes workflow tasks by 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 to 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.
About the Author
Bassam Samman, PMP, PSP, EVP, GPM is a Senior Project Management Consultant with 40-year service record providing project management, project controls services and project management information system to over than 400 projects with a total value in excess of US$ 400 Billion. Those projects included Commercial, Residential, Education and Healthcare Buildings and Infrastructure, Entertainment, Hospitality and Shopping Malls, Oil and Gas Plants and Refineries, Telecommunication and Information Technology projects. He is thoroughly experienced in complete project management including project management control systems, computerized project control software, claims analysis/prevention, risk analysis/management (contingency planning), design, supervision, training and business development.
Bassam is a frequent speaker in topics relating to Project Management, Strategic Project Management and Project Management Personal Skills. Over the past 40 years he has lectured at more than 400 events and courses at different locations in the Middle East, North Africa, Europe and South America. He has written more than 400 articles on project management and project management information systems that were featured in international and regional magazines and newspapers. He was a co-founder of the Project Management Institute- Arabian Gulf Chapter (PMI-AGC) and has served on its board of directors for more than 6 years. He is a certified Project Management Professional (PMP) from the Project Management Institute (PMI), a certified Planning and Scheduling Professional (PSP) and Earned Value Professional (EVP) from the American Association of Cost Engineers (AACE) and Green Project Management (GPM).
Bassam holds a Masters in Engineering Administration (Construction Management) with Faculty Commendation, George Washington University, Washington, D.C., USA, Bachelor in Civil Engineering – Kuwait University, Kuwait and has attended many executive management programs at Harvard Business School, Boston, USA and London Business School, London, UK.