My last entry was a mix of the negative and the positive, I think.
A lot of the details ended up being depressing, but it's tinged with some kind of hope - we're imagining we can somehow turn this round and get somewhere better. Or, more simply to use Gramsci's words ; "pessimism of the intellect, optimism of the will".
I often feel like that. While I'm incredibly hopeful about the prospects for improvement it is difficult, when trawling through a set of old records, to avoid feeling like you're dealing with the accumulation of the mistakes from all hitherto generations.
This is not just an IT issue, of course. Take the following scenario. Heating system in new build property (built in the last three years). System has not been flushed during install, nor since (i.e. was not installed properly). System fails and will need almost total replacement. I've no idea who will pay for the mistake, but it will cost over a thousand pounds.
As he exited our building for the evening I heard one of my colleagues mumble some of the calculations involved if the other units in the block were similarly affected. It didn't sound too promising.
Such incidents are frustrating not just because they could be avoided (we all make mistakes as they say, and the vast majority are avoidable) but because they are a recent mistake. Something which was done incorrectly thirty or forty years ago is almost amusing. The implication, I think is something like :
"Ah, look at the poor fools all those years ago. How could they dither through life not knowing everything we know now?"
Now, I think this attitude is somewhat misplaced, but it's understandable. There's a chance at least we've learnt some valuable things since the 60's. It's less likely we've learnt anything dramatic in the last 18 months. So recent mistakes are frightening. If we did it wrong 18 months ago, are we doing it wrong today?
This in turn means I am always very conscious, when beginning a project (e.g. for a new process) that it goes relatively well. That it's reasonably well thought out. That I cover all the angles. That nothing is missed.
Of course, this doesn't always happen and when I come to continue my 'Worst Practice' notes I'll discuss some of the reasons why. But one which contributes to the problem is that I am very rarely "starting" a project at all. I am almost always continuing a project. There are very few new stories, there is a selection of old favourites, with lots and lots of post-scripts.
The following analogy may help.
The Confused Customer
A customer walks into a restaurant. He is already holding a sandwich of some sort. A waiter asks the man what he would like to eat. The customer passes the waiter the sandwich and says
'This is what I am currently eating.'
'Ah', says the waiter. 'So you would like another sandwich.'
'Well...' said the customer 'Not exactly. You see, I do not like how this one tastes.'
'Ah, well I can ask the cook to prepare you something else if you like.'
'That could work. What do you have?'
'Well...we have lots of things. The Bologonese is very nice.'
'Oh, no.' said the customer. 'It has to be a sandiwch. And it has to have the same basic ingredients as that sandwich there.'
'Right.' says the waiter, slowly. 'So what were ingredients?'
'I don't know.' says the customer, slightly embarrassed. 'The label came off the packet before I came in, and I don't know who made it either.'
So the waiter takes the sandwich to the chef and outlines the problem. The chef examines the sandwich and after some thought prepares another which the waiter takes out, on a silver tray.
The customer tastes the sandwich and is disgusted. "This doesn't have one of the ingredients we had before! Take it back."
So the cook rejigs the sandwich and it is re-served.
"Well this has all the ingredients as before, but it has some of those problems; the taste chicken of this doesn't go at all well with the taste of chocolate."
'But you are saying both chocolate and chicken were in your original sandwich, sir.'
'That's right.'
'So what's the issue?'
'I don't like the taste of them together!' said the customer, getting slightly exasperated.
'So why have them in a sandwich together in the first place?!' who is also beginning to lose his cool.
'Because that's what I was ALREADY EATING!' says the customer, angrily.
And so again...there is a rejig. The cook does his best to mask the taste clash by adding another ingredient - peanut butter. And so once more, the waiter takes the sandwich out to the customer who has one more taste.
Surprisingly, he is delighted.
'Aha, perfect - the sandwich is just right. You and your cook are geniuses.'
'It is our pleasure sir!' says the waiter, happily.
And so the customer pays and leaves the shop, happy and content. The waiter and chef both feel satisfaction at a job well done.
A few hours later the customer is rushed to hospital because he failed to tell the waiter he was allergic to peanut butter.
-The End
The above is a rough outline of most of the processes where I am involved.
Most of the time I am joining a project mid-point, and can only really work with what I have. I am dealing with "ingredients" which were selected by people who will never eat the food (government, in this case) or years ago in a different context. Meals are not ordered in advanced and lovingly consumed but rushed, poorly prepared and eaten a bite at a time (with alterations at each mouthful).
Now, this should not be taken as a complaint, I actually prefer quick incremental many-revision projects as they seem to, on average, produce the most results.
But variety is the spice of life and it's nice occassionally to have an opportunity to start afresh. Which is where I come to today's task.
One of our contracts is due to renewal early next year. Because the contract will be valued at well over £144k and it is classed as a service it will need to go through EU Procurement (and advertised in a pan-European journal). So it's going to be a long, bureaucratic tender process.
What it does mean though is that I get to write into either the tender or commencement agreement some form of data guidance notes / requirements.
At the moment, this contract is run well operationally speaking (reasonable costs, customer satisfaction is OK) but with dreadful IT protocols. Our IT department's involvement was minimal in the drafting of the original processes and as a result there are re-occurring problems; inaccuracies in data, difficulty reporting, huge duplication of data entry work and so on. It is not an exaggeration to say that an entire staff members's time is wasted on doing something which would not be required at all if the process was run differently.
Of course, it is silly to blame the contractor for these problems - they are simply following the instruction we have given them.
But we now have opportunity to tighten up the process, and at the same time try and make some kind 'Best Practice' guide for anyone who we wish to give work to. Perhaps not using my powers for good, but certainly for mediocrity. Which is still better than evil.
The service we are advertising for is relatively specialist, and while there are a few companies who could do the work, it does mean that making demands like 'You must only use Free or Open Source products in your entire business' is likely to yield either
i) no-one at all
ii) someone critically weak in another area of the business
So there's an element of pragmatism here. Here are some ideas I've had. Very much a first draft.
Proposed Data Guidelines
1. All data collected and produced through course of service/project to remain our property.
2. As such, while data may reside on your systems it must be ready to transfer in full to ourselves within a reasonable (e.g. 24hr) notice period on demand. As part of running the contract, such a regular transfer will probably take place as well.
3. Any transfer of information, or report produced will need to be in (where possible) a non-propietary file format, human-readable (without additional software) and/or in an industry standard format.
In general our requirements will be plain-text comma-separated values file for basic reports on multiple properties, plain-text XML for more complex files, .PDF for reports suitable for printing and ocassionally Microsoft Excel or Word files on request.
If files can only be stored / send in other formats which do not meet these basic criteria, there will need to be specific justification given for this.
4. The exact nature of what we will require from you (in terms of reporting) will be established at commencement of contract, but you should expect to send us, at least :
- Electronic copy of individual property survey (suitable for printing)
- Paper copy of individual survey to pass directly to resident.
- Electronic report detailing survey items for multiple properties (i.e. 1 Row per Property). The structure of this report will need to be agreed with us in detail. We will ask for this on a weekly basis but you should also be capable of producing it on demand.
5. We will pass you the key details of the properties which are within our stock. We will expect you to process this information so you can confirm details of survey for each request you receive.
6. All our property information is co-ordinated through our UPRN (Unique Property Reference Number). We will need you to use this at all times as our reference. It will also need to appear on everything you send us if we are to match this with our other datasets.
7. We will strongly prefer data transfer discussed above to take place without human intervention (i.e. as part of cron / scheduled task). We can accept files emailed or via an FTP. Details of either will be established at commencement of contract.
8. We will be providing you with data relating to our customers. You will of course have to respect their confidentiality and privacy as well as your legal obligation under data protection legislation.
9. If, for any reason, software development takes place (either jointly or individually) and is solely or mainly for our agreement we will expect all code to be released under the GNU Public Licence Version 2 unless you have had prior written consent from ourselves.
---
That's it so far. I shudder at my use of 'property' in relation to information in #1, but I can think of no better way of putting it. One of our sister companies had an experience where a contractor simply did not give them any of the data they had collected during the course of a works project because they "fell out". Incredibly it was not stated in the original contract who the information belonged to.
This, among other things, is the sort of nonsense we wish to avoid.
