The Whack-A-Mole strategy is pretty much exactly as it sounds. It's a reactive strategy where you wait for a problem or issue before attempting to deal with it. This is opposed to a "proactive" type strategy where you attempt to predict the problem before hand and deal with it in a way that prevents it occuring.
The ideas of "Proactive" and "Reactive" seem to often be cast in terms of "Proactive is good" and "Reactive is bad". However there are lots of scenarios where this is neither true nor efficient.
My current problem is to update a group of students from using one document based data entry form to an updated version to refelect both changes in the course and changes in the data retention requirements. Simply by their nature and some pre-exisiting use of the old form version, I reasonably expect some to not immediatly comply with the request, no matter how its delivered.
The proactive solutions that have been floated are:
1) Deliver the upgrade message in such strong terms that no-one will even consider not complying.
2) Build the system to cope with multiple versions of the data entry form and accept that they will not comply.
As you can see, the cost of proactivly solving the problem is unpleasant in both cases.. because mostly the problem is "people factors" rather than a technical issue. I could implement both solutions, but they lead to bad places both technically and personally. So, the best solution is to politely ask all the students to update their forms, give them a short cut-over period and then use the whack-a-mole strategy to individually handle any students who have problems with the upgrade.
Another benefit of this solution is that we also learn exactly what sort of problems people are having with the new system (if any) and that can inform us about either bugs or unexpected "people factors" without the students feeling like they are at fault.
And everyone sleeps well...
No comments:
Post a Comment