Recent scandals in the corporate world have created a refreshed awareness of the audit function. A direct by-product of these scandals is the Sarbanes-Oxley Act of 2002 (SOX), which gives legal and financial muscle to the assurance of the integrity, reliability, and accuracy of financial reporting and corporate disclosures. In fact, based on a recent survey of CFO's and IT executives, 71 percent of the respondents believe that Section 404 of the Act, which requires business process audits and documentation to support internal controls certification, is the most critical part of SOX. While some may argue that the Act does not go far enough, it is surely a positive, aggressive start.
While this reemphasis may be good news for current and ongoing systems, the process of developing an audit awareness and the need for substantial controls can and should be established as software is being implemented. If you are the project manager or the project sponsor, possibly the company's CEO or CFO, it is in your best interest to create a financially healthy environment from the start of the implementation project. The expectation is that this good inbreeding will continue with the software into production and throughout its entire lifecycle. Considering the extensive scope of enterprise software such as enterprise resource planning (ERP), supply chain management (SCM), and warehouse management systems (WMS) software, the need for adequate and substantial controls is even more apparent.
This two-part article looks at four key segments of an enterprise software implementation, with timely emphasis on SOX, and suggests audit procedures, controls, and processes that should be typified, observed, tested, and reported upon. These segments include:
* Project Planning and Management
* Documentation and Reporting
* Software Piloting
* Data Conversion
Clearly, there may be others and, hopefully, this discussion can encourage or scare you into identifying these other areas that may be pertinent and cost-effective to your organization.
Before the full impact of SOX can be absorbed into an organization as a basic component or guiding principle of a project's life cycle, considerable prep work is needed. Getting everyone acquainted with the requirements of the Act and making sure that projects are in compliance is no simple task. Be advised, it will not happen overnight. Consequently, an education and training process must be completed so that everyone is in agreement and on the same sheet of music. This mission should be undertaken as you would for any project but with special emphasis placed on securing a high profile executive to serve as the sponsor. Given the fact that they are most affected by SOX, a CEO or CFO are natural choices and should be easy to convince to participate.
The key elements of project planning and management that come under intense scrutiny include:
* Project charter and overall workplan
* Project plan
* Regular and documented status reporting format
* Issue resolution protocol
* Deliverable monitoring against plan
* Continual communications plan
You are probably saying this is not new stuff; we're doing it today. While the sections of SOX are still in a state of flux, particularly Section 404, the specifications for these elements will not be open to discussion but rather will be rigidly dictated and compliance strictly enforced. Consequently, more than casual attention must be given to these matters and must be available for future review.
Projects will be evaluated based on their impact on a company's bottom line. Specifically, large projects, particularly those associated with enterprise-wide systems, are responsible for consuming materially significant funds that can affect financial statements. Accordingly, the internal and external costs associated with a project can represent a significant expenditure and corresponding expense. The level of expenditure can determine whether software acquisition and implementation projects are capitalized between the balance sheet and income statement. Furthermore, the allocation method must be defensible. Typically, a company will rely on the project manager and the corresponding procedures and controls to support the position taken.
With the arrival of SOX, as project manager, you should be taking certain actions in preparation. Become familiar with the Act itself and see if your industry has additional requirements. An education process for the organization has been addressed above. The AICPA provides a nice and concise overview of the Act. Start looking at Sarbanes-Oxley tool sets. Typically, these are not intended to replace project management tools but rather act as repositories, providing a means to capture required data. Typically, your external auditors can help in this regard. As will be discussed below, start involving the audit function in the project management process as a way to install a control discipline and mindset at the start of a system's life cycle.
Probably those of you working in an overseas company and not subject to the Act may heave a sigh of relief. Good control practices, however, are not restricted by national boundaries or languages. These practices just make good sense and do not need legislation or the attachment of criminal penalties to be implemented. Steal the concepts from the SOX and start your own program to improve internal control practices.
As a project manager, you should encourage the involvement of the audit function from the outset. While specific and typical areas of involvement will be addressed in Part II of this article, as part of the planning and management process, coordination with the audit function can ensure that control objectives and guidelines are understood. In this way, team members will be able to assist in the identification of control weaknesses or gaps. Bear in mind, however, that the ultimate decision as to the materiality of a control weakness rests on the shoulders of the audit function.
Finally, a key aspect of project management is keeping management informed. Ensure that the steering committee, including the executive sponsor, is aware of the project's progress against plan, decision points, and significant changes in scope. Their approval will help keep you in SOX compliance. This is also an opportune time to discuss control objectives and their positive affect on and through the enterprise software. Companies are also starting to look more closely at the project management office (PMO) in an effort to provide more efficiencies but, more importantly, tighter control and monitoring of IT projects. But don't expect a quick fix, easy metrics, or an immediate payback.
The documentation required for compliance with SOX is rigorous. Consequently, a critical aspect of SOX compliance and an internal controls framework is developing a repository of documented controls. As indicated above, there are tool sets available to facilitate this activity. However, the implementation team, with the software's functionality fresh in mind, can start the compilation process and fill the repository. As the project team becomes familiar with the software, control aspects will come to light. For this reason, it is important the audit function defines internal controls, both hard and soft, so that the team knows what to be on the watch for. Confirmation of the controls can be completed in the testing and piloting phases.
Samples of documentation that could be used to satisfy the SOX requirements and, more importantly, can be accumulated during the acquisition and implementation of software are:
* Policy and procedure manual
* Job descriptions and desk procedures
* Systems documentation and workflows
* Report layouts and samples
* Edit criteria and error resolution procedures
* Ongoing reconciliation procedures
Many of these samples can be easily obtained from the vendor or vendor special interest groups where other companies may have already paved the way.
Some might argue that compliance with SOX will only add to the length of the overall project. First, to counter that argument, companies bound by SOX may have little choice. Secondly, it is easier to gather the information gradually as a work-in-progress rather than afterwards when interests have been transferred to other projects. Finally, below is the tradition timeline of an implementation project with the interjection of an audit presence. It would not appear that the extension of the overall project length is minor and could be considerably offset if the audit function serves an active member of the team.
While this reemphasis may be good news for current and ongoing systems, the process of developing an audit awareness and the need for substantial controls can and should be established as software is being implemented. If you are the project manager or the project sponsor, possibly the company's CEO or CFO, it is in your best interest to create a financially healthy environment from the start of the implementation project. The expectation is that this good inbreeding will continue with the software into production and throughout its entire lifecycle. Considering the extensive scope of enterprise software such as enterprise resource planning (ERP), supply chain management (SCM), and warehouse management systems (WMS) software, the need for adequate and substantial controls is even more apparent.
This two-part article looks at four key segments of an enterprise software implementation, with timely emphasis on SOX, and suggests audit procedures, controls, and processes that should be typified, observed, tested, and reported upon. These segments include:
* Project Planning and Management
* Documentation and Reporting
* Software Piloting
* Data Conversion
Clearly, there may be others and, hopefully, this discussion can encourage or scare you into identifying these other areas that may be pertinent and cost-effective to your organization.
Before the full impact of SOX can be absorbed into an organization as a basic component or guiding principle of a project's life cycle, considerable prep work is needed. Getting everyone acquainted with the requirements of the Act and making sure that projects are in compliance is no simple task. Be advised, it will not happen overnight. Consequently, an education and training process must be completed so that everyone is in agreement and on the same sheet of music. This mission should be undertaken as you would for any project but with special emphasis placed on securing a high profile executive to serve as the sponsor. Given the fact that they are most affected by SOX, a CEO or CFO are natural choices and should be easy to convince to participate.
The key elements of project planning and management that come under intense scrutiny include:
* Project charter and overall workplan
* Project plan
* Regular and documented status reporting format
* Issue resolution protocol
* Deliverable monitoring against plan
* Continual communications plan
You are probably saying this is not new stuff; we're doing it today. While the sections of SOX are still in a state of flux, particularly Section 404, the specifications for these elements will not be open to discussion but rather will be rigidly dictated and compliance strictly enforced. Consequently, more than casual attention must be given to these matters and must be available for future review.
Projects will be evaluated based on their impact on a company's bottom line. Specifically, large projects, particularly those associated with enterprise-wide systems, are responsible for consuming materially significant funds that can affect financial statements. Accordingly, the internal and external costs associated with a project can represent a significant expenditure and corresponding expense. The level of expenditure can determine whether software acquisition and implementation projects are capitalized between the balance sheet and income statement. Furthermore, the allocation method must be defensible. Typically, a company will rely on the project manager and the corresponding procedures and controls to support the position taken.
With the arrival of SOX, as project manager, you should be taking certain actions in preparation. Become familiar with the Act itself and see if your industry has additional requirements. An education process for the organization has been addressed above. The AICPA provides a nice and concise overview of the Act. Start looking at Sarbanes-Oxley tool sets. Typically, these are not intended to replace project management tools but rather act as repositories, providing a means to capture required data. Typically, your external auditors can help in this regard. As will be discussed below, start involving the audit function in the project management process as a way to install a control discipline and mindset at the start of a system's life cycle.
Probably those of you working in an overseas company and not subject to the Act may heave a sigh of relief. Good control practices, however, are not restricted by national boundaries or languages. These practices just make good sense and do not need legislation or the attachment of criminal penalties to be implemented. Steal the concepts from the SOX and start your own program to improve internal control practices.
As a project manager, you should encourage the involvement of the audit function from the outset. While specific and typical areas of involvement will be addressed in Part II of this article, as part of the planning and management process, coordination with the audit function can ensure that control objectives and guidelines are understood. In this way, team members will be able to assist in the identification of control weaknesses or gaps. Bear in mind, however, that the ultimate decision as to the materiality of a control weakness rests on the shoulders of the audit function.
Finally, a key aspect of project management is keeping management informed. Ensure that the steering committee, including the executive sponsor, is aware of the project's progress against plan, decision points, and significant changes in scope. Their approval will help keep you in SOX compliance. This is also an opportune time to discuss control objectives and their positive affect on and through the enterprise software. Companies are also starting to look more closely at the project management office (PMO) in an effort to provide more efficiencies but, more importantly, tighter control and monitoring of IT projects. But don't expect a quick fix, easy metrics, or an immediate payback.
The documentation required for compliance with SOX is rigorous. Consequently, a critical aspect of SOX compliance and an internal controls framework is developing a repository of documented controls. As indicated above, there are tool sets available to facilitate this activity. However, the implementation team, with the software's functionality fresh in mind, can start the compilation process and fill the repository. As the project team becomes familiar with the software, control aspects will come to light. For this reason, it is important the audit function defines internal controls, both hard and soft, so that the team knows what to be on the watch for. Confirmation of the controls can be completed in the testing and piloting phases.
Samples of documentation that could be used to satisfy the SOX requirements and, more importantly, can be accumulated during the acquisition and implementation of software are:
* Policy and procedure manual
* Job descriptions and desk procedures
* Systems documentation and workflows
* Report layouts and samples
* Edit criteria and error resolution procedures
* Ongoing reconciliation procedures
Many of these samples can be easily obtained from the vendor or vendor special interest groups where other companies may have already paved the way.
Some might argue that compliance with SOX will only add to the length of the overall project. First, to counter that argument, companies bound by SOX may have little choice. Secondly, it is easier to gather the information gradually as a work-in-progress rather than afterwards when interests have been transferred to other projects. Finally, below is the tradition timeline of an implementation project with the interjection of an audit presence. It would not appear that the extension of the overall project length is minor and could be considerably offset if the audit function serves an active member of the team.
No comments:
Post a Comment