7 replies
by malosa
by oldefar
A couple of recommendations on policy.
First, fewer is better.
Next, policy should have a stated objective or justification and be based on applicable laws or regulations, common sense, and business objectives.
Policy needs to be issued by the senior management after review by legal and the business and support leadership team. Better to fix a poor policy before it is issued than to argue about it ever after.
Any departmental policy must reference the corporate policy it supports.Departmental policy cannot cross departmental lines - IT department policy cannot be a factor in how a business unit functions for example.
Policy becomes a business requirement for future projects and initiatives - it will set one of the parameters for technical objectives.
Good policy will rarely need to change. Accomplish this by keeping policy at a high level and linked to business objectives.
by malosa
Before getting involved with legal and senior management, you must first review the type of policy. We write policies for our staff to follow, but are not neccessarily legal or protecting requirements. While they could be considered procedure-like, they are still rules that we want our employees to abide by. For example, or system maintenance communication policy. Our legal advisors probably have not reason to look at this. However, we had a problem with maintenance not being communicated so we wrote the policy for the technicians to follow.
If you're writing an electronics communication, that's probably a good idea to have legal review it (although this type of policy I found was not required by law). Just be careful on what you submit to legal if you're don't have an inhouse deptartment. You may accrue unnecessary costs.
by oldefar
We are disagreeing on semantics - I would consider a system maintenave communications a procedure rather than a policy. It is a set of steps to be completed.
Whether a policy is done in paper or digital format, I still recommend a legal review.This is especially true for policy regarding HR, but should be done with all. Since I also state that with policy, less is more (few as possible), the associated legal review cost is reduced.
Example - corporate policy says failure to comply with policy is grounds for immediate termination. Your department has established a "policy" on notification of system maintenance. At 3 AM on a holiday, a tech recognizes an imminent severe conidition that will be catastrophic if not resolved ASAP. The tech fixes the condition, but fails to follow the system maintenance communication "policy". A disgruntled peer notifies HR that management has failed to enforce corporate policy. The tech should have had his employment terminated, and now his manager as well.
Another example - Operations, which pulls 12 hour shifts, establishes a "policy" that dozing while on duty is grounds for immediate termination. The top performer comes in for her shift while fighting a cold instead of taking a sick day. During a particulary slow stretch early in the morning, after having completed all maintenance routines and with the network and systems at 100%, the tech nods out. Policy states you terminate your top performer.
by oldefar
Procedures are steps to accomplish tasks. An excellent source for how to write procedures can be found with ISO, in particular the 9000 series.
Most procedures will be limited to a specific work group - a team, a set of managers reporting to onepoint, etc.
Procedures should have a formal method for review and modification to keep them current and appropriate.
by dcal
In reading all responses, I had a vibe that there is a common mis-use of terminology centered around 'policy'. This is exactly my dilema. All of our 'policies' are written, however, there are business units that are creating what they are calling 'policy' and are clearly not the case. I would not consider the length of time and time of day that one takes a lunch break, a policy. It has no consequence relevant to the department or overall organization.
We are trying to identify a 'standard' for all business units to follow including a process to approve what is and is not policy.
by dcal
We have come up with a matrix to propose to Sr. Management. Policy = high level rules of the org. Standards = general rules of the org. Principles = high level guidelines of the org. Best Practices = general guidelines of the org. With Procedures being those steps or sequence of events that achieve company goals. Surrounding this entire matrix are the Business Rules that define the overall business goals.
We are still struggling with the terminology and trying to decide when to use Policy vs Principle, Standard vs Best Practice, Rule vs Business rule, Procedure vs Process. You wouldn't think that the terminology would be the hard part, but until everyone is using the same set of terms and in the proper way, then nothing will really be 'standardized' making it harder to support the organization in legal situations.
Comments and feedback welcome.
This discussion is closed to new replies.
Trending IT Employment posts
Sort by Trending