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.
No comments:
Post a Comment