But during both the creation and subsequent audit steps, organizations must beware of "shelfware" -- documentation that sits on the shelf, so to speak, and is never used except to prepare for audits. Of course, this applies to electronic documentation as well.
The point is that policies and procedures must be useful and accessible to the people who need them or else they will not be followed. This is one of the reasons that externally developed policies and procedures cannot be transplanted wholesale. They must be "tuned" for internal use.
From the start of a governance project, great care must be taken to create policies and procedures that actually aid the organization. What comes of these projects must add value and not just needless layers of bureaucracy.
Are standards beneficial? Definitely. By using COBIT, ISO 17799 and/or ITIL, organizations have access to a wealth of knowledge developed by thousands of people over many years. Using one or more of these standards as a framework, people developing policies and procedures can better understand what needs to be looked at and can share best practices with peers all over the globe through the Internet, books, classes, seminars, etc.
Focusing on IT
Now, let's discuss what it means to document policies and procedures in IT. For the purpose of this article, we'll assume that a risk analysis has already been performed and decisions made about the appropriate framework(s) to follow and what needs to be done in order to address identified risks.
It is a fatal mistake to bring in consultants or buy pre-written policies and procedures and expect to implement them wholesale without modifying them to work in your organization. Clearly, there are benefits to reviewing what others have done and leveraging that work to "jumpstart" your efforts. However, these policies and procedures need to be edited and refined to work in your environment.
The best people to do this are those who actually perform the work every day. Depending on your organization, you may create a project team with the appropriate stakeholders. Be sure to carefully select the team, bearing in mind communication skills, stature with peers, etc.
Have a knowledgeable council comprised of peers of the parties writing the policies and procedures review everything and have approval prior to release of the content into production. There are a variety of reasons that necessitate peer review prior to formal adoption:
1. Espoused Theories -- What one must be cautious of involves how people view their own jobs and/or the best way of accomplishing tasks. Individuals can inadvertently document what is known as an "espoused theory."
Organizational psychologist Chris Argyris observed that people have a difficult time explaining what it is that they do because they tend to document their ideal method, or the method they would use without consideration of other issues in the workplace that could constrain the use of that method. He called this an "espoused theory."
So people can document policies and procedures from an idealistic perspective that must be reviewed for applicability in the real world.
2. Lack of Totality -- Scientist and philosopher Michael Polanyi documented that people regularly do not document how they perform tasks because they literally know more than they can say. Thus, someone may attempt to document how to do something with all of the best intentions in the world, but be unable to satisfactorily do so because he/she isn't fully aware of all that he/she does. Hence it pays to review the work and ensure that it is complete.
3. Simple Mistakes -- In our technical world, it is very simple to make a mistake through errors of interpretation. For example, I may think I know how to back up a system and try to document the process. However, the reality is that I do not know everything and another person may have additional valuable input.
4. Diversity -- By involving the team, people know what is going on and can give other perspectives. Due to diverse backgrounds and perspectives, often times better ideas arise during a peer review session because people build on one another's concepts.
After creating the documentation, it needs to be published. In this age, the best means is to use the Internet and the Web. Be sure to have the material organized and searchable. Be very certain to follow appropriate document management practices such that versioning and access controls are in place.
As policies and procedures are released, it is not enough just to publish them. Appropriate training must be instituted to be sure that all of the stakeholders are aware of the new/changed policies and procedures. It is very important that people be formally trained at the start and have refresher training at least once per year.
Without a doubt, the environment of IT is constantly changing. What is documented today will not be true forever and there must exist means to audit and continuously improve the system. If the policies and procedures get out of synch with reality, then people will stop using them. Hence, there must be routine audits to ensure both that documented practices are being followed and that they are still appropriate.
Furthermore, there must be a formal change process for people to proactively review and revise the various policies and procedures. Ideally, the system would be continuously evolving as the environment changes.
The above five steps outline some of the potential phases involved. In practice, treat the implementation of policies and procedures as a project. It needs a plan with tasks, assignments, due dates, milestones, budget, communication plan and so on, just like any other project.
The standard frameworks help identify some of the detail of what needs to be done, but solid project management practices are still required to bring things to efficient fruition. Furthermore, once the policies and procedures are implemented, the work does not stop. There must be a continuous improvement process put into place that will spur additional projects in the future as the organization and environment evolve.