Functional and Assurance requirements
In the world of information security, we make a distinction, in determining our requirements for a tool or a system to help us, in regard to the requirements. We specify two types of requirements: functional requirements, which have to do with the actions of the actual tool; and assurance requirements, which answer the question is the tool doing actually performing, and is the tool actually doing what we intend it to do.
These two different types of requirements can, in fact, be applied to pretty much any task that we asked anything, or anyone, to perform. What is it that we want done, and how do we know that it is being done, and that it is effective.
I I got what I thought was a nice illustration of this idea one day when I was getting lunch. I was in a store that sold sandwiches of the types known as hoagies, or hobos, or submarine sandwiches (presumably because of the general overall shape). When you are eating in a restaurant, or getting food from a takeout place, you will know that there are signs, in the washrooms, saying that all staff have to wash their hands after using the washrooms, and in between every order that they prepare. This is good hygiene, and pretty much everybody understands why it's there. This has to do with the functional requirements of preparing food. You want to ensure that people the people involved in preparing, or serving, food, have clean hands, and definitely hands that are not contaminated by germs transferred from somewhere, or something, else.
The thing is, the only *assurance* requirement that there is that this functional rule is followed is the sign in the bathroom. Sometimes there may be a sign at the counter instructing the staff that they have to wash their hands between each order. But, if you pay attention, you will realize that the staff are mostly facing *away* from that sign, and that they actually very seldom wash their hands between one order and another.
But in this particular shop, every time the staff made a sandwich for someone, they pulled a couple of disposable plastic gloves out of a box and put them on. The disposable gloves fulfill the same functional requirements: being sure that any germs that are on the food preparers has don't transfer to the food that is being prepared. And, indeed, because the use of the gloves is immediate and fairly easy, it's fairly plain to see that, as they move to somebody else's order, they throw away the gloves that they were wearing, and put on a new pair of gloves.
The functional requirement is the same in both cases: making sure that germs don't transfer from the preparer's hands to the food. But the assurance requirements are much different. In terms of determining that the food preparers wash their hands every time they use the washroom, well, you really can't check that out unless you go to the washroom with them. But, with the gloves, you can see that they put on the gloves. You also can see that they throw away their gloves when finished with your order, and put on a new pair of gloves when they go to prepare somebody else's order. So, while the functional requirements for both hand washing and gloves are the same, the assurance requirements are much stronger for the gloves than they are for the hand washing. Gloves have it all over hand washing in terms of the assurance requirements.
This is something that should be applied to the management of pretty much any task, whether for a commercial enterprise, or for volunteers. There is the functional requirements of the task that you want done. Those are generally specified. But the *assurance* requirements, that the job actually has been done, and that the task that is performed has some effective results, is generally given rather short shift. Very often, when we send volunteers out to perform a task, we asked them to fill out some kind of report as to what task has been done, how many times, and if there were any incidents in the performance of the task. To a certain extent, this does fulfill the assurance requirement. The job has been done, and, a certain number of times.
But there is that sort of second half of the assurance requirement: was this task effective? That is something that relatively few managers actually think about. There's an awful lot of work, both paid and volunteer, that gets done, and is a complete waste of effort. No one has ever checked on the assumption that what we are doing is, in fact, having some kind of benefit. Think about this some time. How is it that you know that what you are doing is, in fact, effective?
(In other management literature, some of this issue of assurance requirements is covered under what is known as "metrics," or key performance indicators. But that's a topic for another time.)
One of my volunteer jobs is community policing, and one of the tasks that we undertake is speed watch. We take down a lot of statistics: how many total cars do we see, how many of them are under the speed limit, how many are roughly at the speed limit, how many of them are driving about ten kilometres an hour over the speed limit, and how many of them are driving twenty kilometres an hour over the speed limit. (For this last set, that's the group where we take down the license plates, and they get a polite but pointed letter from the local police.)
The data and statistics that we collect go to the provincial motor vehicle authorities. Presumably, over time, they can see what the average speed is at the different places where we set up speed watch. A much more immediate, and significant, assurance requirement to which we pay attention is the fact that we can measure the speed of cars more than half a kilometer away. We can see that someone who comes into our zone at seventy kilometres per hour, by the time they get to us (and have had the time to see that we are set up), may be traveling thirty-seven kilometres per hour. We can also see when someone, quite far away from us, slams on their brakes, and the front end of their vehicle is suddenly a lot closer to the ground.
We know we are having an effect.
Volunteer management - VM - 0.00 - introduction and table of contents
No comments:
Post a Comment