One of the huge problems for records, is that the feedback loops we focus on are very long ones.
This is because we don't own the business processes that are consuming our records.
It means that we don't know whether people are finding what they need two times out of ten, or ninety nine times out of one hundred - until (of course) someone lodges some kind of information request that means we have to find the records.
This creates a problem for us.
It means that the feedback loops for our users are very short.
And the feedback loops for us are very long.
If you were going to have someone build a system for you, would you want it to be the group that were regularly getting feedback about the performance of the system, or irregularly?
This goes for anything systemic - policy, classification, architecture.
To me, this makes one of the burning questions of records "how do we create feedback loops that are shorter than our users?"
So that we can know there's a problem before they do.
There are other industries that have answers to this sort of problem.
As just one, in software development, there’s something called “test driven development.”
What it basically says, is that the first thing you do in your development process is work out how you’d test that the system is functioning correctly - and then you write some code that satisfies the test.
What it would mean for us, is thinking about how we test that something is being successful before we start designing it.
This technique has the side benefit of putting you in a position to discuss the test criteria with your organisation, and also reduces the chance you will waste time on things that don’t improve what you’re testing.
Take an information policy for instance, if you were going to write a policy that said “there’s one organisational records system, everything must go in it” - how would you test that?
There are many possible ways, here are two with slightly different assumptions about method:
Under one program assumption (everyone works in the records system), you would expect to see the data volume in all other systems stop growing altogether, and the data volume in the records system start climbing.
Under another assumption (“closed” file storage), you’d expect that the data volume in the records system would equal the combined data volume of all other systems - with some level of acceptable time lag.
Either way, knowing that this was how you were going to test your policy ahead of time would allow you to create a feedback loop that is much shorter than the typical feedback loop - which may be years or decades in length otherwise.
I’m certain there are other techniques from other industries that help us create shorter feedback loops.
How do you tackle the problem of feedback loop length in your program?
With IT systems, some of us are able to get feedback on individual transactions / services - but how many of us consult widely across our organisations? And how do people do it? Interested to know what others do
A really interesting piece, Karl - thank you.
As an IM, I wonder if the feedback loop is perhaps even longer - as an employee will often just recreate something rather than seek assistance for retrieval (that's often saved for the 'regulator x needs the evidence' requests).
Is the answer at the front-end (creation and capture) rather than the back end (retrieval) - the feedback loop being that the correct stuff is being captured correctly by the correct system? As a secondary measure, are the staff being correctly educated about a) what to capture and where and b) where and how to look?