TEAM Zarate Tarrani Notes From the Field

Process - Part 3: Policies. In my 21 March entry I gave an example process, using IT change control and the ETVX model to illustrate how a process works. I concluded the entry by stating that the process did not contain policies and left that for this discussion.

What is a Policy? A policy is a directive that has the following attributes:

• scope and applicability (what and whom does the policy govern?)
• comes from a source of authority that exercises control over all individuals who have roles and responsibilities in carrying out, enforcing or complying with the policy
• governs the scope of a processes and procedures that enable or support meeting the policy's objectives
• traceable to business imperatives (if you've been following my discussion of the Tarrani-Zarate Model in Postcards from the Revolution you'll have a basic understanding of business imperatives)
• enforceable

Mechanics. These imply that there is a system of authority, responsibility and accountability. The authority behind the policy is directly responsible for the implementation, execution and enforcement of the policy. Even if responsibility is delegated, the direct responsibility should be placed on the authority who created the policy.

Responsibility entails accountability for how well or poorly the responsibility has been discharged. This chain of authority-responsibility-accountability is a basic precept of leadership and the foundation of any organization.

Why Policy? Without policies there would be no control mechanism for processes. In the real world there are processes that are operating without governing policies, but such processes are often ad hoc and too often are a duplication of effort or are inefficient at best and wasteful at worst.

Relationships and Connections. Here is how it's supposed to work and why: business imperatives spawn policies. These imperatives come from many sources, including law, competitive pressures, the fiduciary responsibility of the board and executive management to safeguard shareholder value, etc. The execution of the policy is within the scope of processes, which are decomposed into procedures (see the ETVX model in my 21 March entry).

A few rules of thumb:

• Policies are executed via processes, and processes are comprised of procedures and validation points.
• Processes without governing policies have no controls, and if they cross organizational boundaries, depend on personalities instead of positional authority.
• Policies without processes have no repeatable means of being executed and are probably unenforceable.
• An unenforced or unenforceable policy erodes authority and can result in morale problems, inefficiencies and worse.
• A policy needs a source of authority who has control over all stakeholders.

Example Policy. The following policy is linked to the change control process presented in my 21 March entry. You'll see direct links between the policy, roles and responsibilities and the process itself.

It is the policy of (Enterprise) to manage the life cycle of all information systems supporting its business and technical objectives. As such, the processes and procedures for change control set forth in this policy document governs change, and release management. The scope of this policy is the management of changes to the production environment. Specifically: before any change to a system or a baseline, the proposed change will be evaluated and approved by the (Enterprise) Change Control Board.

No approved change will be implemented without:

1. Entry criteria needed to initiate the change control process.
2. An approved plan of action with milestones for implementation, that provides a sequence of events or steps for implementing and releasing the change into the production environment, a roll-back plan, assigned roles and responsibilities and post implementation validation (PIV) test plan.
3. A completed test plan showing the results of testing the change in a pre-production or staging environment.
4. Approval from the application owner(s) affected by the change and the business systems managerresponsible for the application or system being changed.
5. A formal review by the Change Control Board to ensure that all entry criteria for the change have been met.

Any system or application failure or defect traced to a change made to a system or application that was not made in accordance with this policy, process and procedures will result in disciplinary action. Specifically:

1. The error will be communicated to all stakeholders of the affected system and/or application.
2. Individual(s) making the unauthorized change will be required to develop an action plan specifying which measures will be taken to avoid a future occurrence of the failure or defect.
3. The action plan will be reviewed and approved by the individual's management chain and posted in a public place for review.

Closely examine the policy statement above, then compare it to my definition and discussion. Also analyze the process that was described in my 21 March entry and see if there are any gaps in the integrity of the policy or the process.

Here's a key question: from which level in the organization should come the source of authority for the policy and process we've been discussing? Hint: it's not IT.

Next Up. My next entry on processes will discuss goals, critical success factors and key performance indicators.