For most capital project owners in the public and private sector, ensuring that the right policies and procedures are implemented to deter fraud on their projects is always on their top priority list. Regardless of how comprehensive those project management procedures are, each procedure should have an output form that will be used to formally communicate each transaction of each business process covered in the procedures’ manual.
The tendency to commit fraud is very much part of every business and capital construction projects are no different. Actually, there are more chances to commit fraud on a project than operational frauds where usually corporate policies and procedures are well enforced and internal or external audit is an ongoing requirement.
When it comes to delivering capital construction projects, there are many actions that could be labeled as “Project Fraud”. Examples of those include:
- Unsubstantiated project decisions
- Under-reported estimates of project cost
- Over-reported estimates of project benefits
- Unbalanced bids
- Over-reported schedule performance to hide project delays
- Wrong forecasting for the cost to complete the remaining project scope
- Unsubstantiated change orders
- Over-estimated change orders
- Over-reported quality progress
- Acceptance of lower-quality deliverables that cannot be used as originally thought
- Delayed and/or improper approvals
- Conflict of interest and kickbacks
- Negligence in protecting client’s interest
- Non-compliance with the contract’s terms and conditions
- Creating unnecessary threats by failing to comply with best practices
- Failing to report threats before they harm the project
- Failing to report opportunities that could have benefited the project
- Lost or misplaced project documents
- Appointing unqualified project team members
- Intended wrong actions or decisions
Therefore, having well-thought-of output forms that can help prevent fraudulent transactions that are associated with the business processes that have the risk of fraudulent transactions is something that all project owners should insist to have on their projects. Those well-thought-of forms need to enforce the best practices of transparency and accountability while communicating what should be communicated for each business process. The well-thought-of output form for any formally communicated transaction whether it will be wet-signed or digitally signed should have four key components.
The first component is the details of what is being transmitted or communicated which would depend on the requirements of the business process being performed. For example, the content of a change order form will differ from the form for the interim payment certificate. The second component is the checklist of all items that need to be verified and confirmed before approving or rejecting a business process transaction.
The third component would be the list of all documents that are sent with each transaction to support the content of what is being communicated. The fourth and last component is the details of the workflow tasks carried out for reviewing and approving the transaction showing the name, date, action taken, notes made by everyone who has a role in performing the business process with the option of also displaying their signature.
A Project Management Information System (PMIS) like PMWeb is designed to enable project owners to digitally enable their project management procedures. PMWeb will be used to manage all business processes and in particular those that have the risk of fraudulent transactions. Those would include as a minimum the business processes for a cost estimate, budget, submitted bids, awarded contracts, changes orders, interim payment certificates, work inspection requests (WIR), material inspection requests (MIR), non-conformance reports (NCR), requests for information (RFI), technical submittals, document transmittals, punch lists, meeting minutes, project team appraisals, value engineering proposals and punch lists. Each template needs to have all data fields required to manage its relevant business process. Some of those data fields could require selecting their values from a predefined list of values to enforce standardization. In addition, the templates should be configured to restrict who can fill the different data fields within each template. Those data fields will be the information to be communicated on the well-thought-of output form.
In addition, there should be a predefined checklist of items that need to be formally verified before a transaction can be approved or rejected. Those checklists should be comprehensive and aligned with the contract documents to cover the obligations and entitlements set in the contract agreement for each entity that has a role in delivering the project. Those predefined checklists will be available to be added to any of the PMWeb default ready-to-use business process templates. Each task in the checklist will be assigned to the project team member responsible for performing the task as well as the date of completing the task. The checklist will be part of the well-thought-of output form.
For other business processes that PMWeb custom form builder will be used to create their templates, the checklist will be one of the tables to be included in the template design. For example, for the Work Inspection Requests (WIR) template, there will be a detailed checklist to verify all items that need to be inspected. The same could have been done for Non-Compliance Reports (NCR) or any other template for a business process that has the risk of committing fraud actions.
In addition to the captured data for each business process, there is also the need to capture all documents that are associated with each transaction that supports what is being communicated. Those documents could include pictures, videos, MS Excel files among many others. PMWeb attachment tab in those templates will be used to attach all those supportive documents. It is also highly recommended to add comments to each attached document to provide a better understanding of what was the document for. The attachment tab also allows the user to link other records for business processes implemented in PMWeb as well as associate URL hyperlinks with websites or documents that are not stored in the PMWeb document management repository.
To enforce accountability in reviewing and approving each transaction of each business process, the PMWeb workflow module will be used to create a workflow to formalize the review and approval tasks of each transaction of each business process. The workflow will map the sequence of the review and approval tasks along with the role or user assigned to the task, duration allotted for the tasks, and availability for each task. In addition, the workflow will be designed to include the conditions needed to enforce the approval authority levels as defined in the Delegation of Authority (DoA) matrix in the project management procedures manual.
For every transaction of each business process, the workflow tab available on the template will capture the planned review and approve workflow tasks for each transaction as well as the actual history of those review and approval tasks. PMWeb will capture the actual action data and time, done by who, action taken, comments made, and whether team input was requested. This data will be part of the well-thought-of output form.
Sometimes reading a transaction of a business process in isolation from other interrelated business processes might not provide the needed alert that a fraudulent transaction has occurred. For example, having a report that combines the business processes of budget, budget adjustments, awarded commitments, approved and pending change orders, interim payment certificates for approved work in place, and payment made for those approved invoices might give the needed alert on that a fraud transaction or transactions could have happened on the project. Of course, there is no limit to the number of reports that can be designed and created to either query and report on the data of a single business process or the data from interrelated business processes to provide the required monitoring and evaluation of transactions to help identify if a fraudulent transaction has occurred or not.
Knowing that the cost of preventing fraud is far less costly than rectifying the damages of fraud transactions, some project owners deploy “Fraud Analysts” to review transactions of a specific business process or group of interrelated business processes across the organization’s complete projects’ portfolio including completed projects to identify measures that can prevent project fraud. Those analysts might also consider using other data sources to enrich their analysis. This is needed to build the data volume needed to learn to make their analysis of value and relevance.
The Fraud Analysts will analyze all relevant transactions to identify trends and correlations that can help them to learn what events or actions could trigger a fraud transaction. This will enable those analysts to recommend what measures to be incorporated in the policies, procedures, and business processes to prevent such fraudulent transactions as well as what are the triggers that need to be watched to predict fraud.
