Piloting Policy and Process
In my job, I deal with re-architecting the
enterprise computing environment. We end up reshaping both the technological
landscape - working on issues of interoperability between systems, integration,
identification of users, authentication and authorization - and on the policy
and process landscape - working on issues like "who should be involved", "how
does the decision get made" and "what are the roles of the various people and
teams in the project".
We often run technology pilots. The concept of
pilot is very ingrained in technology development. As a Medical Products
Engineer - we always built prototypes to try out. The same thing applies in
information technology - we try out changes to applications or infrastructure in
small pieces. We understand when we start a pilot that their will be iterations
- that we will not get the solution 100% correct on the first try... or the
second or even the third.
We can put forth a technology as a "pilot" and everyone understands that we will continue to tweak the technology until we get it right (or at least right-enough for now). When we put for a process or policy, people take it as if it is absolute. They quit teams and walk out on the process. Why don't we have the same view regarding changing the policy and process landscape that we have regarding the technology landscape?
One reason is that we do not expect technology to work as planned or designed. You do not buy a new computer and turn it and expect everything to work perfectly and all of the functionality you want to be present. You know you will have to install more software, then patch some things, maybe add more RAM or other hardware, fix some preferences, find lost registration numbers for applications that you are migrating. There is no expectation that technology will work without tweaking and adjustments.
Policy and Process are abstract logical things. It seems that you should be able to perfect them in your mind before you release them to the world. But the reality is that you have to "pilot and debug" policy and process in the same what you pilot and debug technology. You need to a pass through the new process and see what issues arise that you didn't imagine. Common issues that I've seen come up are: (1) are the correct people involved, (2) did the teams have the right scope of work, (3) is there a feed-back mechanism that works and is appropriate, and (4) is there a channel for additional work to be created.
"Are The Correct People Involved"
UW-Madison is a large institution with distributed IT functions. The central IT group (DoIT) has just over 450 IT workers. Each of the colleges and departments have some level of IT staff and interest. These vary from large groups in Engineering and Biosciences to smaller groups in Arts. There are IT groups for centers of excellence, post study accreditation (the College of Education has to provide education to all teachers in Wisconsin) and continuing education (MBA program). There are IT groups that serve both UW-Madison and the State of Wisconsin (Fleet Reservations and Parking). There are IT groups that serve other campuses and the UW-System. When ever you form a team to look at policy and process, it is impossible to guess who might be interested or impacted. The formation of these teams is often taken as an absolute and not including someone is seen as a slight or insult or arrogance.
Everyone needs to understand that this a growing, changing process. That the first attempt at setting up a team is a pilot to see how it works and who is missing from the conversation.
"Did the Teams Have the Right Scope of Work"
Just as team membership is complex and difficult to work out up front, scope of work is also complex. Often, new issues and topics are discovered as you begin to develop policy and process around one area. A simple policy question can demand definitions across a whole area of technology. One example is the creation of temporary login names and passwords for visitors. There is a desire to have temporary login names and passwords so that visiting professors and presenters can get access to the network. This simple question raised a suite of other issues: who can hand them out, what services can the be used for, who is responsible for maintaining records, what do we mean by temporary? What seems like a simple request can expand into a much larger investigation. This can lead to the team asking, "is this within our scope, how do we send these issues on, to whom do we send these issues?"
"Is There a Feedback Mechanism that Works"
Feedback mechanisms are critical to change management. Feedback is the way that systems correct themselves. When you drive your car, you are running a continuous feedback mechanism. Feedback is what allows you to drive down the middle of lane or turn a corner or stop before you hit something. Feedback is also important in technology (reporting of bugs, missing functionality) and process (where the correct people involved, did the team understand the project) and policy (is the system being used correctly, is there a way to allow for new uses). Getting the feedback mechanism fine-tuned is difficult in any new process. Think of learning to drive. We are trying to learn to drive a new technology.
"Is There a Channel for Additional Work to Be Created"
Often in a technology project, new work comes up that is out of scope for the current team. The new work may impact a related system or may be under the jurisdiction of another group. In the process, there needs to be a channel for trapping these issues and routing to the correct group(s).
All of these process issues take iterations to work out. We need to pilot the policy and process portions of the project in the same way we pilot the technology. The Process Pilot needs to be included as part of the project plan. Communication and eduction are needed to explain that this is pilot and that there will be bugs and issues. With iterations and feedback, the process and the policy can develop into as robust system just like the technology.
- JJP
We can put forth a technology as a "pilot" and everyone understands that we will continue to tweak the technology until we get it right (or at least right-enough for now). When we put for a process or policy, people take it as if it is absolute. They quit teams and walk out on the process. Why don't we have the same view regarding changing the policy and process landscape that we have regarding the technology landscape?
One reason is that we do not expect technology to work as planned or designed. You do not buy a new computer and turn it and expect everything to work perfectly and all of the functionality you want to be present. You know you will have to install more software, then patch some things, maybe add more RAM or other hardware, fix some preferences, find lost registration numbers for applications that you are migrating. There is no expectation that technology will work without tweaking and adjustments.
Policy and Process are abstract logical things. It seems that you should be able to perfect them in your mind before you release them to the world. But the reality is that you have to "pilot and debug" policy and process in the same what you pilot and debug technology. You need to a pass through the new process and see what issues arise that you didn't imagine. Common issues that I've seen come up are: (1) are the correct people involved, (2) did the teams have the right scope of work, (3) is there a feed-back mechanism that works and is appropriate, and (4) is there a channel for additional work to be created.
"Are The Correct People Involved"
UW-Madison is a large institution with distributed IT functions. The central IT group (DoIT) has just over 450 IT workers. Each of the colleges and departments have some level of IT staff and interest. These vary from large groups in Engineering and Biosciences to smaller groups in Arts. There are IT groups for centers of excellence, post study accreditation (the College of Education has to provide education to all teachers in Wisconsin) and continuing education (MBA program). There are IT groups that serve both UW-Madison and the State of Wisconsin (Fleet Reservations and Parking). There are IT groups that serve other campuses and the UW-System. When ever you form a team to look at policy and process, it is impossible to guess who might be interested or impacted. The formation of these teams is often taken as an absolute and not including someone is seen as a slight or insult or arrogance.
Everyone needs to understand that this a growing, changing process. That the first attempt at setting up a team is a pilot to see how it works and who is missing from the conversation.
"Did the Teams Have the Right Scope of Work"
Just as team membership is complex and difficult to work out up front, scope of work is also complex. Often, new issues and topics are discovered as you begin to develop policy and process around one area. A simple policy question can demand definitions across a whole area of technology. One example is the creation of temporary login names and passwords for visitors. There is a desire to have temporary login names and passwords so that visiting professors and presenters can get access to the network. This simple question raised a suite of other issues: who can hand them out, what services can the be used for, who is responsible for maintaining records, what do we mean by temporary? What seems like a simple request can expand into a much larger investigation. This can lead to the team asking, "is this within our scope, how do we send these issues on, to whom do we send these issues?"
"Is There a Feedback Mechanism that Works"
Feedback mechanisms are critical to change management. Feedback is the way that systems correct themselves. When you drive your car, you are running a continuous feedback mechanism. Feedback is what allows you to drive down the middle of lane or turn a corner or stop before you hit something. Feedback is also important in technology (reporting of bugs, missing functionality) and process (where the correct people involved, did the team understand the project) and policy (is the system being used correctly, is there a way to allow for new uses). Getting the feedback mechanism fine-tuned is difficult in any new process. Think of learning to drive. We are trying to learn to drive a new technology.
"Is There a Channel for Additional Work to Be Created"
Often in a technology project, new work comes up that is out of scope for the current team. The new work may impact a related system or may be under the jurisdiction of another group. In the process, there needs to be a channel for trapping these issues and routing to the correct group(s).
All of these process issues take iterations to work out. We need to pilot the policy and process portions of the project in the same way we pilot the technology. The Process Pilot needs to be included as part of the project plan. Communication and eduction are needed to explain that this is pilot and that there will be bugs and issues. With iterations and feedback, the process and the policy can develop into as robust system just like the technology.
- JJP
Posted: Wed - November 17, 2004 at 05:57 PM
