Mark Temple, IT Service Project Manager
A bit about me
I’ve worked at the University of Glasgow for the past 27 years, the first 12 of these as a Motor Mechanic, so like many people, I had a real job before I got into IT Service Management… just kidding. My current role is varied to say the least – I’m the System Administrator for our IT Service Management platform, I manage our staff and student IT Helpdesks, and also our IT Tutors and IT Trainers – never a dull moment!
About the University
The University of Glasgow dates back to 1451 and is the fourth oldest university in the English-speaking world. Today we are in the top 1% of the world’s universities, and a member of the prestigious Russell group of leading research universities. As you can imagine, supporting the diverse range of learning and teaching and research activities, together with all of the professional services requires a small army of dedicated staff, together with the right mix of systems and services.
What’s this blog all about I hear you say?
For a good few years now, we’ve been expanding the use of our ITSM tool into other areas of the University – Accommodation and Living Support, Student Support, parts of HR and Finance, Campus Security and Data Protection/Freedom of Information, but we’ve never quite got University-wide coverage, or even consistent usage across all IT teams (we have 4 colleges with their own IT support, as well as centrally provided services and support) – a complex landscape to say the least.
On top of all of this, we were looking to upgrade our ITSM tool, which had served us well for 10+ years, but being a public body, we are bound by public sector procurement rules, so needed to go to tender – even to move to a new tool with the same vendor.
So, the tender process began, and we were all a bit tender by the end of it!
Here’s our story:
The thought of putting together a requirements document which adequately sets the scene for prospective vendors, together with listing every conceivable feature that the diverse range of functional areas required was daunting. Did we need to spell everything out to the nth degree, or does common sense dictate that a modern system will generate unique reference numbers?
After much cut and paste and numerous re-writes, we ended up with a document which all of the interested parties agreed upon – no mean feat.
This then had to be loaded onto the procurement portal (an independent website which acts as a drop box for vendors – we can’t see bids until the submission date, so a very fair way of working), then we had to wait for the submission deadline to come around.
We proved to be an attractive proposition, with 19 vendors submitting the pre-qualification questionnaire. Each of these was scored and the shortlist was reduced to 12, which shortly became 9 as some vendors dropped out and others joined forces.
The next stage distilled the “can your system do x?” into “how will your system deliver each of the requirements, and at what price?”
After much deliberation, the list was narrowed down to 3 vendors, each proposing a different solution (there had been multiple submissions from different vendors proposing the same solution in earlier rounds).
Onsite demos and follow up web clarification sessions ensued, and we were pleased to announce that Ivanti and their Service Manager product had been selected as the preferred bidder. This then led us into the mandatory “stand still” period, where unsuccessful bidders could seek clarification or challenge the award – no challenges were forthcoming, so that closed the door on the procurement process.
Whilst all of this was going on, we had formed a project board, whose membership represented a cross-section of the University community – would we have a meeting room with a big enough table to seat them all?
Note to self – we should have put the board in place much earlier…
Time now to work with our new partner, Ivanti, to flesh out the details of workshops and consultancy days – more on these in the next instalment.
