It is no secret that corporate compliance with Sarbanes-Oxley (Sarbox) is a tough, death march. It has all the drama of a close Super bowl game, sudden death. If the right project management disciplines are not in place, the challenges can prove monumental.

First: What is Sarbox?

Sarbox is in response to the financial reporting excesses of corporate America that occurred throughout the 1990s and at the turn of this century. Companies like Adelphia, Arthur Anderson, Rite Aid, Enron, and Tyco are just a few of the corporations that found unwanted recognition on news Web sites and in newspapers across the globe.

In response to this circumstance, Congress passed Sarbox legislation to deal with financial abuses and legal violations. President Bush then signed the bill into law.

The Securities and Exchange Commission (SEC), responsible for overseeing this aspect of the financial sector, created the Public Company Accounting Oversight Board (PCAOB) to develop standards for independent auditors to attest on the effectiveness of internal control regarding financial reporting.

The Sarbox law consists of multiple sections. A major focus of the law, however, is complying with Section 404 so that upon filing annual reports, e.g., Form 10-K, external auditors can attest the effectiveness of those controls, and the Chief Executive Officer (CEO) and the Chief Financial Officer (CFO) can certify them.

Due to legal consequences for noncompliance and the potential impact to stock value, Sarbox is critical to key decision-makers in the corporation, especially the Board of Directors, the Audit Committee, CEO, and CFO.

Second: Why should project managers care?

It is rare, of course, that project managers concern themselves with financial compliance unless their project pertains to a Federal contract. Times have changed, however, for three reasons.

First, a project, whether dealing directly or indirectly with Sarbox, may have a significant, even material, impact to the financial statement of the company. A ?sizable? project may be determined ?material? enough to report it in documentation submitted for Section 302 quarterly certification.

Second, a material project will likely require having the necessary project management controls to demonstrate due diligence in controlling its performance. Effective controls in respect to schedule and cost are especially important as an expression of due diligence.

Third, a project may be building a financial application deemed in scope under Sarbox; the resulting application must incorporate, therefore, effective controls. A significant missing or failed control may result in a material challenge to the effectiveness of internal controls in general.

Third: Is there a Sarbox life cycle?

Yes. It is important, however, to understand first the technical approach for becoming compliant. The technical approach initially requires looking at the financial statement to determine what financial line items may be in scope based upon a definition of materiality. Then, it involves determining, for the selected items financial line items the processes that are impacted. For each process, determining the control objectives for each process becomes necessary. Finally, it involves identifying the pertinent control activities.

To apply the technical approach, a Sarbox project can execute a five-phase life cycle to achieve compliance:

Phase 1: determining the scope of work by performing a business risk assessment on the financial statement

Phase 2: identifying and documenting key controls for relevant processes

Phase 3: evaluating the control design

Phase 4: validating and testing operations and controls

Phase 5: assessing and certifying controls

Progressing through the life cycle involves many people. These people include the Board of Directors and its audit committee, CEO, and CFO. They are, however, the ?tip of the iceberg.?

It is easy to conclude, albeit incorrectly, that Sarbox involves strictly finance. Sarbox is multidisciplinary. Financial controls can cut across many functional areas of a corporation. Information technology (IT) is one of those areas because many controls require the use of applications and infrastructure, e.g., data centers. These controls must exist and be effective to pass assessment and certification requirements. Indeed, the IT role is so important that a strong argument can be made that Sarbox is as much an exercise of information system as well as financial controls.

Finance and information systems are not, however, the only people engaged in a Sarbox compliance project. Internal auditors, security specialists, external consultants performing ?field work,? and external auditors are also engaged. If processes cut across multiple functional areas, which manifests a matrix environment, then process owners must also become involved and engaged. If processes also involve multiple business units, then points of contact, or ?touch points,? must be identified for coordination.

Four: What are the unique challenges of Sarbox?

A Sarbox project can has some unique challenges.

Priority.

A Sarbox project can conflict with other projects that some executives deem just as high, if not higher, priority. A resource constraint environment can aggravate this circumstance, requiring the making of difficult decisions. Outside of the finance arena, not everyone may agree that Sarbox is the number one priority despite obvious consequences. Instead, education among the executives and management ranks may be necessary to facilitate their focus on Sarbox. That focus may entail subordinating ?pet? projects to Sarbox, e.g., upgrades to information system in the fourth quarter of the year.

Cross-functionality. 

A Sarbox compliance project is frequently cross-functional, involving processes spanning across different multiple functional areas and possibly business units. The challenge is to involve all the appropriate people and engage them. Fulfilling that requirement may entail substantial investment time and persuasiveness to convince people of the importance of Sarbox and their participation. While seemingly obvious, the reality is that matrix organizations make it very difficult to exercise command and control. This situation is especially the case when IT entities do not report to the CFO and, yet, he or she may depend on their cooperation. This tenuous relationship can turn into a power struggle, especially if the Chief Information Officer (CIO) perceives that the CFO is managing the former.

Teaming.

Teaming could prove difficult. A matrix structure is only one contributor to this challenge. The multiplicity of disciplines can also impact project performance. Each discipline?s perspective on controls is somewhat different along with its jargon. For example, ?corrective action? means something different from a project manager than to an auditor or IT professional perspective. Even the perception of the word ?deficiency? can have varying degrees of meaning and significance vis-à-vis each discipline.

Precedence. 

The unprecedented nature of a Sarbox project can prove challenging. This type of challenge can prove to be a ?double-edged sword.? The lack of precedence can provide a convenient excuse for not performing the necessary work; other times, this circumstance is valid (and, for Sarbox, is frequently the case). Many people have a tepid enthusiasm for compliance in general and financial or information systems controls in particular until auditor or security professionals arrive. On a Sarbox project, they must quickly adopt an unfamiliar perspective, creating an immense learning curve that adds to existing frustration and confusion under a tight timeframe.

Retention.

Turnover can wreck havoc on the project if key people who document controls depart for any reason. A loss of tribal knowledge and rework can impact progress. This situation can become aggravated if the project is fast tracked or crashed; turnover can impact the critical path. Then, workarounds and corrective actions, even after performing good risk assessment and contingency planning, can become frequent.

Technical performance indicators. 

Developing technical performance indicators, such as metrics on quality, can prove challenging. The unprecedented nature of Sarbox and the often vague direction from the PCAOB coupled with constant assessments and re-assessments can pose a problem. The internal project team tracks performance metrics; however, so do the external auditors. External auditors must maintain their independence and objectivity, making it very difficult for both parties to work together to develop uniform metrics. Consequently, even if the metrics are similar, they are rarely in ?sync.?

Integration. 

Integration among all the different business entities can be difficult. Some business units may provide support to other business units. At various points during the project, they must work cooperate to address issues on compliance. While simple enough, actual practice is not easy. Each business unit will likely have its own priorities concerning compliance and have a different schedule for producing deliverables. Such relationships can be immensely complex, especially when each entity is responsible for achieving its own compliance.

Time and cost estimating. 

Time and cost estimating may prove difficult and not just because of the unprecedented nature of the project and the unfamiliarity of financial compliance. Another factor that can complicate estimating is the multidisciplinary nature of the Sarbox effort. If standards are vague or ill defined until late in a project?s life cycle, estimating can become difficult to perform, resulting in SWAG (scientifically wildly assumed guess). This circumstance can further add to the difficulty of comparing estimates to actuals, making the assessment of schedule performance very difficult.

Scope.

An evolving scope can prove challenging. What is considered in and out of scope can constantly fluctuate due to changing market conditions and reversals of advice by external consultants and auditors. Line items in the financial statement could drop in and out of scope during the project, for example, thereby causing frequent starts, stops, and rework. A high frequency of occurrence is akin to shooting at a moving target. In addition, some decisions by the external auditors and consultants on the tasks may require execution, only to be reversed a short time later.

Communications.

The combination of vague terminology and semantics, as well as people subscribing to applying different paradigms complicates efforts for getting everyone ?on the same wavelength.? Even with a plethora of training sessions and meetings on tools, control techniques, and the subject of Sarbox, communications can remain difficult for reasons described earlier. Even the breadth and depth of meetings can pose challenging. The communications can often cover many unfamiliar subjects in complex detail, thereby adding to learning curves and difficulties in applying concepts.

External dependencies.

The number of external dependencies can create a complex web of entanglements that can frustrate the most patient people. External dependencies can conflict with one another, causing a standstill or rework. For example, external auditors might make a decision on an issue that contradicts the advice of internal experts. Or, the team might receive incorrect or incomplete guidance. The team might have to wait for further guidance but have no other choice than to proceed forward due to a tight timeframe while realizing that rework might occur.

Perception.

The perception of Sarbox itself may pose a challenge. A strong sentiment may exist among many people that Sarbox was the result of executives who broke the law and acted unethically which is a fact. However, this attitude adds to the prevailing negative perception of Sarbox. A Sarbox project, therefore, likens itself to B. F. Skinner?s notion of negative re-enforcement: failure to comply may result in a painful experience to avoid. Motivation under such perception can prove to be very difficult.

Mandated milestones.

Executive leadership will likely mandate major milestones. Consequently, these milestones may not be based on estimates on the effort to accomplish them. Coupled with PCAOB?s ultimate milestone for compliance the only choice is, particularly for large corporations, to fast track and crash the project. Many tasks will have to occur in parallel and require substantial overtime to complete them. Burnout can easily result despite bringing in ?relievers.? The extensive effort and the short timeframe can pose a monumental challenge that requires close tracking of resource deployment and utilization.

Maturity of tools and techniques.

The immaturity of the tools and techniques can present a challenge. Templates, techniques, and tools will likely be developed ?on the fly? because requirements may still be ill defined or non-existent. The impact of this immaturity can affect the chain of relationships. Technical experts may rely on external auditors and consultants who, in turn, rely on guidance from PCAOB. Reversals on guidance on applying tools and techniques can spring numerous surprises on the team, adding to frustration levels in an already high stress environment.

Project Management.

The technology transfer of project management tools, principles, and techniques may be very difficult despite being the means for dealing with many of the challenges described above. Project management may be too much for some people to absorb. In the midst of learning about Sarbox, project managers and their team leads will likely learn how to use status collection tools and learn to interpret data to improve cost and schedule performance. For many people on a Sarbox project, this exposure to project management may occur for the first time despite having project management responsibilities in one form or another in the past. In other words, project management, tools, techniques, and principles may be the bitter medicine that they must have to help them navigate through the Sarbox life cycle.

Part II will address these questions: 

Can project management help? Is success possible? 

Check out Part II in our next issue of PMB e-newsletter.

Ralph L. Kliem is the author of Leading High-Performance Projects, co-author of Reducing Project Risk (Gower Publishing) and The Organizational Engineering Approach to Project Management (St. Lucie Press), the author of The Project Manager's Emergency Kit (St. Lucie Press) over 200 articles. He has managed projects and can be reached at (425) 869-6677 or by visiting www.RalphKliem.com He has project managed a SOx 404 project for the business unit of a Fortune 100 firm and his insights from that experience serves as the basis for the contents of this article.


 

Joel M. Koppelman