Mitigating risk in IT controls.

• Author: Melbye, David

[ILLUSTRATION OMITTED]

Technology projects, like most other initiatives, carry a certain degree of risk. For large, enterprise-wide projects such as an enterprise resource planning system, that risk can be quite large, with millions of dollars committed to an effort that will last for two years or more. Smaller projects might not have quite the same exposure, but the risks are similar:

* The project could be underestimated and therefore might not be completed on time, on budget, or within the established scope.

* Organizational priorities could change in the middle of the project, rendering some objectives moot and elevating previously discarded concerns.

* Staff resources might be reallocated to other initiatives.

* Third-party vendors and contractors might not perform as advertised, and deliverables (previously identified portions of the project that are to be completed at a specified time) could be late or of substandard quality.

* Funding could be reduced or eliminated.

* Computer hardware or other equipment might not be sized properly to support the goals of the project.

These are just a few of the concerns that finance officers face when assessing risk and identifying ways to mitigate that risk.

MILESTONE SCHEDULES

As a best practice, the GFOA advocates deliverable-based milestone schedules as the best way to protect the organization against implementation risk. In this model, payments are made according to a predefined milestone schedule, with payment contingent on receipt and acceptance of deliverables that were defined before the contract was signed. The contract itself, or statement of work that accompanies the contract, can specify the deliverables. It should include the following:

* A narrative description of the deliverable and a sample format.

* The timing of when the government should expect the deliverable.

* The level of detail for the deliverable.

* Clearly defined roles and responsibilities for developing the deliverable.

* Defined dependencies, or other tasks or deliverables that have an impact on content and timing (that is, one deliverable depends on completion and acceptance of another).

Because of the volume of information that can be attached to each deliverable, some governments and vendors choose to create deliverable expectation documents outside the contract, to keep the contract itself more readable. See Exhibit 1 for an example of the resulting schedule.

Along with a deliverable schedule, there should also be an agreement on acceptance criteria and a review process. Vendors will not likely agree to such a payment schedule without knowing the timeframe for the review and acceptance process, and in any event, governments should conduct those reviews quickly to keep the project moving forward. Typically, governments need five to ten days to review a deliverable, and each deliverable usually has an...