I suppose that is exactly why we have IT professionals to help the rest of us get to grips with these issues. Unfortunately there is often a chasm of mutual incomprehension between the owners of business processes and the IT professionals, and where the resources for IT support are restricted (which is everywhere and all the time), this leaves us underskilled and unequipped to get the best out of information and communication technology. Inevitably it it the BIG business processes that get all the attention, and all the little business processes have to make-and-mend with spreadsheets and bits of paper.
Monday, 22 October 2012
The Devil resides exactly where everyone always says it does....
The summer has seen a combination of inactivity in some aspects of the project and great advances in others.
On the whole the project is producing a lot of valuable insights and helping us to understand a lot more about how we can use ICT to support mentoring schemes in a way that will be more efficient and economical for scheme coordinators and more effective for participants and their employing organisations.
In the process I would say that we are also learning a lot, generally, about how non-IT professionals (i.e. us) can define their own needs in terms of the IT tools that they want to support them and their work.
For example, if you run a mentoring or coaching scheme, you probably think you can quite quickly and easily define the scheme’s work flows and processes – and in general terms you probably can – well enough to explain it to someone else so that they could pretty much replicate your own scheme.
However, no matter how simple the design of your scheme, there will be many marginal complexities that you are not even aware of. The human brain is flexible and quick enough to respond to changing circumstances and adapt to the unexpected. Information Technology, on the other hand, is only as flexible and adaptable as you make it – and the more flexible you want it to be (the wider the range of possible circumstances and variables you want it to accommodate), the more complex it is to create, maintain and update.
So let’s say you examine the work processes in your mentoring scheme and come to the conclusion that a database would really help you manage the data and create administrative efficiencies. Then you set out how your scheme works and what you want the database to do. Easy so far. Then you realise that there is a remote possibility that someone from another institution might participate in your scheme, or that someone could be a mentor and mentee at the same time, that someone could mentor more than one mentee, or that a mentee could have more than one mentor, or that a mentoring partnership could be terminated and then reform, or that a mentee might later become a mentor, or that a mentor might leave the scheme and then re-join it later or that any of hundreds of other possibilities.
Here’s another question to consider before you make any decisions: do you think you may actually need to run more than one scheme at the same time in parallel – perhaps for different staff groups? And who will have access to the data and will you need to create different levels of access for different users, with the attendant issues around security.
….and if someone else is going to use your database, will they want to use the same terminology as you? Might they want to manage things differently than the way you have structured your database dictates?
How many of these eventualities do you want the database to accommodate? Where will the parameters of your system be? Where will you draw the line between the system adapting to differnt circumstances and requiring to user to adapt to the system?
All of this is no doubt part of the sum experience of IT systems analysts, project managers and developers. But despite the clear common sense of mapping business processes and defining work flows, non-IT professionals still do not have enough EXPERIENCE of having done this (or training) to realise how important it is to explore every eventuality of how the processes might work – even in the most unlikely, but still possible, circumstances.
The old maxim ‘the devil is in the detail’ certainly holds true here.