SID roll out to Faculty Student Hubs


We’re now half way through SID going live in each of the faculty hubs. Health Sciences launched it two weeks ago, and last week Business, Law & Politics went live. This week it’s the turn of Science & Engineering and next week we finish off this piece of work with FACE.

So far we have 49 colleagues using the system to deal with student enquiries, and there will be another 43 users across the remaining two faculties. As soon as it went live the teams were using it to manage student enquiries.

  • On the first day in FBLP the team dealt with 47 enquiries through SID after (including one click enquiries)
  • After three days, they had dealt with 163 enquiries (including one click enquiries)

What are the Benefits?

For students:

  • Students can now raise enquiries directly with their faculty hub and can log onto SID to follow the progress / resolution online.
  • If they aren’t logging onto SID, they can go into their hub, and get an update on their enquiry, regardless of where it was raised. For example, they could raise one with Ask HU, but then call into their Faculty Hub and get an update.

For staff:

  • Faculty Hubs will now be able to get a precise picture of the amount of enquiries they deal with and when they get them, which will allow them to better plan their resources.
  • Staff will save time, as they won’t have to trawl through mailboxes, remember what voicemails were left, chase colleagues for progress, etc. – all enquiry progress and history is available to them in just a couple of clicks. SSD (specifically Ask HU and Registry Services, who have to do this a lot), can now pass enquiries for the faculties directly through to the Faculty Hubs within SID, without having to call, e-mail, etc. So all enquiry history can be tracked and managed in one place.
  • Staff will be able to better see trends in student enquiry types and enquiry history. They can see each student’s history in a couple of clicks. This will allow them to be more proactive in managing individual students.

The FBLP faculty hub team has dealt with a range of enquiries from coursework submission issues to graduation queries.

Holly Ilett, SID Subject Matter Expert and FBLP Programmes Manager commented “We have been really pleased with the progress made over the first few days of implementation in the FBLP Student Hub. The support we have received from the SID team has been fantastic, and they have made the implementation process easy for us.

 The professional services staff in the Student Hub have embraced the system, and are already making suggestions on how we can build SID into our current processes. We are really looking forward setting up some of the additional features (standard responses and FAQs) to reap the benefits of what the system has to offer.”



Posted in SID | Tagged , , | Leave a comment

SIS Programme Team welcomes ICT Development Team on board

Earlier this month here in the SIS programme office we crammed six more desks in to make room for our ICT Development Team colleagues – who are responsible for supporting the current AIS system – as they came to join us from the ICT Department.

As the ‘old’ joined the ‘new’ this marked a significant stage in our programme journey as we come together to streamline the progression from the old world (the AIS system) to the new (the SITS system).

Steve Ward, ICT software development team lead, who joins the SIS programme management team, commented “It’s beneficial for us to work together in this way from now on to ensure we get all the relevant student data into SITS before we start decommissioning the AIS system.”

Steve, along with our other new colleagues Rich Garbutt, Nathan Graves, Jon Higham, Wayne Thompson and Matt Turner, can now be found with the rest of the SIS programme team in MR4 and MR5, Level 2, Student Central.


Posted in Development | Tagged , , , , | Leave a comment

A beginner’s guide to User Stories

We recently told you about our ‘sprints’ and how these two-week-long work schedules help us prioritise our work in developing the software to do what our users need it to do. The sprints, as we said, are made up of ‘user stories’.

Here’s a bit more about these stories, who they come from and what we’re asked to do.

Our stakeholders using the new SITS student information system have been working with us as we configure the basic product provided by our supplier, Tribal, to perform the functions we need it to here at the University of Hull. Such stakeholders might include our colleagues from AskHU, Admissions, Student Support or academic staff. Here are a few examples of user stories our team has worked on recently:

  • “As a Direct Admissions Officer I want to inform applicants of their new Applicant ID after they have been migrated to SITS”
  • “As a member of Registry staff I want to be able to complete online enrolment on behalf of a student so that students who turn up to face to face enrolment without completing the online element are not turned away
  • “As a Visa Compliance Officer I want to approve or reject student uploaded BRP (biometric residence permit) documents SO that we are not accepting insufficient data from the student
  • “As a member of the Student Support team I want the content of the SpLD communication which is sent to applicants who have declared a ‘code G’ disability to be amended, so that I am providing applicants with more detailed information on the facilities we have available to offer.”
  • “As a Finance Administrator I would like to see all application deposit payments and sponsored applicants that are awaiting review, and be able to mark them as accepted once offline payment has been received or if a valid sponsor letter has been provided.”
  • “As a student I want to see the schools and subjects associated with a Faculty when I log on to SID so that I can direct my enquiry to the correct Faculty.”
  • “As a Clearing admissions tutor I need information entered into the “Internal Notes” field on the Course Action Details screen within Clearing to be visible to staff only so that information intended for staff use is not included in applicant communications.”

User stories do what they say on the tin – they ensure that the people regularly using the system have their requirements logged. The programme team’s engagement with the business is boosted by following this approach too as our team is out chatting with colleagues elsewhere in the University, to gather their requirements.

The manner in which the user stories are written aids the development team to better understand how the system will be being used, and just what a user needs to achieve. The developers can then go away and provide a solution within the system allowing us to meet these requirements.

Additionally in the agile sprint methodology, user stories also ensure that chunks of development are delivered regularly. Something which in a project of this size, can only be beneficial to our stakeholders.




Posted in Development | Tagged , , , , , | Leave a comment

Sprinting to the Finishing Line

With all the coverage of the Winter Games at the moment, we thought it’d be timely to tell you more about these ‘sprints’ we keep mentioning. Are they runs, dashes, races, rushes?  Actually they’re none of these – they’re basically ‘chunks’ of work.

Definition: sprint (software development)  In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review.

For the SIS programme our sprints run for two weeks and when one ends, the next one begins.

Who gets involved in our sprints?

A mix of developers and testers complete the work during the sprint.

How does a sprint work?

We start our sprints with a planning meeting where the person requesting the work (one of the product owners on the SIS programme) and our development team agree what work will be accomplished during the sprint. The product owner will have already liaised with our stakeholders across the University –  for example, the Admissions Team – to discuss developing a specific piece of work which is then assessed for the sprint.

We break the work down into ‘user stories’ which are relatively sized (in Story Points) so that we can work out, using the team’s previous track record, how much work can realistically be achieved during the sprint.

The chart below shows the SITS team’s track record to date. You can see that Sprint 6 was a very busy one – that was to ensure we were fully prepped for Clearing.

Each user story details the criteria to be met for the work to be approved and accepted.

Once a sprint begins, the product owner must take a back seat and let the team do their work. During the sprint, our team holds stand up meetings each morning to discuss progress and brainstorm solutions to any challenges. The product owner can’t make requests for changes during a sprint and only the scrum master or project manager has the power to interrupt or stop the sprint.

What sort of work is done in a sprint?

Basically, it’s a set of these user stories – all of which are different shapes and sizes. There are business stories – recent examples include

  • A student making a deposit payment online
  • Admissions sending out an offer letter to an applicant
  • Registry enrolling a student

which form the majority of sprint work.  Then there are technical stories, including backups, refreshing environments, making technical improvements etc.

How many pieces of work, on average, do we get through each sprint?

It all depends on the size of each story – but a general rule of thumb is that the total number of story points determine what goes into each sprint – and we usually aim for around 120 points per sprint.

At the end of the sprint, our team presents its completed work to the product owner who then uses the criteria established at the sprint planning meeting to either accept or reject the work.

Then it all begins again, with another two week sprint. Currently we’re on Sprint 21.

Source: sprint definition and parts of this article adapted from Margaret Rouse, via



Posted in Development | Tagged , , , , , , | 1 Comment

A Day in the Life of a Trainer

In another of our ‘behind the scenes’ insights into our programme and the people who are making it happen, today we dip into the world of our training team.

Training manager Emma, and training officers Blake and Beccie, deliver training sessions, produce user guides and provide group, one-to-one and ad-hoc support to the teams around the University who use, or will be using, the new Student Information System. Currently we have around 1750 staff with access to SITS.

We recently caught up with Blake to find out more about what the trainers do.

What skills and experience does a trainer need?

A trainer needs to be able to confidently equip users who have differing abilities and backgrounds with the skills required to use the system. I could be training staff with limited confidence in using IT and staff who use IT regularly in their role in the same session. It is also important to be able to quickly learn a new process. If a user guide is required then I need to be able to document that process in a way that makes sense to someone who has never seen it before. This means I need to find out exactly what it does, what it doesn’t do and where any potential issues may arise. Being able to liaise and build relationships with colleagues across the university is also really important, as part of the role is to help the business with the transition to the new system. We are available to them when they are beginning to use the new processes and offer our support through approaches such as floor-walking.

How does your role fit in with the development and implementation of the new Student Information System? At what stage do you get involved?

We are involved at all stages of the development and implementation of SIS. The earlier we are involved, the more time we have to learn the scope of the new functionality of the software. We hold regular meetings with product owners, project managers, developers and the business to understand exactly what is being built and what the requirements of the training will be.

What is a typical day like for you?

At a time when there is a lot of training going on, a typical morning could involve a training session for staff from a department in the University. The afternoon could involve a meeting with a product owner about upcoming training needs or with the training team catching up on what we have coming up and any issues we can see in the future. On most days I will spend time preparing for the next training session and learning parts of the system that are currently being developed.

What have been some of the biggest challenges you’ve had to deal with?

The biggest challenge was learning the new system and all the acronyms used in SITS! Getting used to the different ways of working was a bit of a challenge for me as well, as my job before this was in a more customer focused role and I was used to being on my feet all day dealing with enquiries.

What part of the role gives you the most satisfaction?

When a training session goes well. There are a few factors that can influence this, including how the attendees reacted to the training and how involved they were, if there were any problems that arose and needed addressing during the session itself or whether I felt I kept the attendees engaged. Even if there are issues that need sorting out such as IT equipment not working as planned, it can still be a good session if it is accepted by the audience and they engage with me as a trainer and get involved in the session.

What does a typical training session look like?

Most of the group sessions are with cohorts of eight or nine staff as anything higher than this is difficult to train a hands on session with, but at busier times – such as pre-Clearing training – we might run a number of sessions, with an audience of up to 100 at a time. All sessions would gear information towards the staff attending and will use relevant demonstrations. Most sessions will include a hands on with the system for the attendees and will include a user guide for them to take away.

At this stage of the project, the training team is keen to ensure University staff are familiar with the new SITS system as we gradually transfer from AIS. It can’t be done in a single sitting, as different teams use different functions within the system to perform their roles.

To date, the team has trained nearly 400 university staff on the new Student Information System. Some of the training they’ve delivered includes:

  •  Undergraduate Admissions
  •  Clearing for Academics and call centre staff
  •  Student Inquiry Desk (SID) for AskHU and Student Services Directorate
  •  Training faculties on programme maintenance
Posted in Uncategorized | Tagged , , , , , | Leave a comment

Student Testers join our team

January marked the start of a new initiative between the SIS programme and some of the University’s computer science students.

We decided last Autumn that we’d like to offer around a dozen students the opportunity of gaining some experience with our team, by training them to be testers, whilst benefiting from their skills and feedback on a system ultimately aimed at student users.

We explained how our programme is overseeing the implementation of a new student information system across the University, which will provide both students and staff with quick and easy access to the information they need. We told them how we’re making a significant investment to update and transform the existing technology and processes so that we can provide a higher quality service, reduce technological risk and increase our adaptability. As this new system will be used for everything from recruitment, application and enrolment to student status and progression, exams and assessments, grades, student support services, and graduation, we wanted to make sure that the system is fit for purpose before it goes live – and what better testers, alongside our own professional team – than the students who’ll be using it for their own needs?

What work would they be doing?

Their role will vary depending on when testing becomes a key requirement for each element of the project but their work activities are likely to include:

  • meeting with system users to understand the scope
  • working with software developers and the project support team
  • writing and executing test scripts
  • running manual tests
  • testing in different environments including web and mobile
  • writing bug reports
  • reviewing documentation
  • working towards departmental and project deadlines
  • quality assurance
  • providing objective feedback to software development project teams
  • problem solving
  • designing tests to mitigate risk
  • communicating findings to technical and non-technical colleagues.

In addition to getting a great chunk of experience on their CV, we offered up to 16 flexible hours’ work per week to fit around their studies and we are providing any training they need to support them in their role.

We’ve been extremely keen to get student feedback on our developing systems before they go live, and to get students to test the software and applications on a variety of hardware. We know from our own stats that applicants and students accessing our Student Portal or SID use a mix of desktop, mobile and tablet. So we want our student testers to test what we’re developing using desktops, ipads, phones, laptops and so on, just as our actual applicants and students do.

Our thanks must go to Dr Neil Gordon, Head of Computer Science, who helped us make this happen. He commented:

“It was great to be approached by the SIS team when they decided to recruit computer science undergraduate students to work as formal testers on the SIS implementation. This has provided an opportunity for the students to get practice with an enterprise level software project, to learn skills as formal software testers with the opportunity for training to support that, and enable them to add some new skills and experiences to their CVs. On top of that, they also got paid to provide some valuable additional income. Overall, a great initiative.”

Our recruitment drive brought in over 70 applications, which we whittled down to a shortlist who were invited to come for an interview and give our panel a presentation. This has now resulted in a final 12 student testers.

First year student, Nathaniel Read, told us: “I’m excited to join the SIS team and support my studies through gaining experience working within testing and live environments. I think that together the student team providing objective feedback on software development and our own user perspective on the service will help deliver the best product possible

We’re currently putting them through their paces with initial training and familiarisation, and then they’ll be testing for real and using our procedures to report on testing results. We’ll follow their story and publish updates on their progress.



Posted in Student Testers | Tagged , , , , | Leave a comment

2017. Didn’t we do well!

As we head towards the end of 2017 we thought we’d share a quick recap of some of our achievements on the SIS programme this year. It’s been a  year of much behind-the-scenes work to get elements of the system designed, developed and tested ready for deployment. And while we’re already working on many things to go live in early 2018, we’ve already delivered:

  • A secure Staff and Student facing responsive design portal, accessed via the internet.
  • Integration to the University Data Exchange (UDX) for integration with 3rd party and legacy solutions including single sign-on for applicants, students and staff.
  • A stable platform with 99.999% uptime and 24×7 world wide availability.
  • Formation of our motivated, efficient and credible delivery team.
  • Complete lifecycle solution for UCAS Undergraduate Admissions.
  • Paperless decision and academic view workflow for applications.
  • Simplified Academic Model for undergraduate programmes.
  • Funding Predictor within our applicant portal so applicants can get a feel for what scholarships and studentships might be available to them.
  • Confirmation of Acceptance for Studies (CAS) generation.
  • Exam results import and robust UCAS Embargo processes.
  • A Self Service Clearing enquiry solution – A Tribal First!
  • Clearing & Confirmation functionality with access for over 300 staff.
  • UCAS 2018/19 cycle roll over with c400 applicants imported.
  • SID Student Enquiry software live in Ask HU, Student Welfare, Careers and Student Accommodation Services, providing a single online solution to track and manage student enquiries.

For 2018, we’ve got G0-Live deliveries for each and every month until September. And we’ve made a series of presentations this month that’ll be rolled out into faculty roadshows in the New Year, so watch this space!

Posted in Uncategorized | Tagged , , , | Leave a comment

A Day In the Life of a ‘Dev’

Ever wondered what goes on behind the scenes in the SIS Programme Office? Amongst our team we have Project Managers, Testers, Trainers, Developers, Business Analysts and more. Today we’re looking at a day in the life of a Developer or ‘Devs’ as we call them.

These are the people who work on our new student information system to develop it to meet our customers’ needs. They also develop new apps and software to make the new system even more efficient. We caught up with Andy Larter, one of our five developers, to find out a bit more.

What skills and experience does a developer need?

Experience of working with relational databases and large volumes of data is essential.

Specifically for us, an understanding of HE processes and the student lifecycle helps when designing and developing solutions

Technical skills such as working with the SITS tool set along with an understanding of Javascript, jQuery, HTML, CSS, SQL help us to complete our day to day developments.

Non-technical skills such as communication and teamwork are also important. This becomes apparent when working to deadlines in our fortnightly development ‘sprint’

How does your role fit into the development cycle? At what stage do you get involved? When do you hand things over?

The development team contribute to the design, development and support of the Student Record System. We are also involved in testing, release deployment, project planning, prioritisation and requirement gathering.

For a typical development job we are given the requirements as part of a ‘User Story’. This is something that has been created by the product owner and will include the acceptance criteria of what the development should achieve. It is at this point we can start developing.


When the solution has been developed we handover the solution to the testing team for them to execute test plans. At this stage we may become involved again to answer queries or fix issues.

After testing is complete we work with the release manager to deploy the development for User Acceptance testing, and from there deployment to the live environment.

What’s a typical day like for you?

We start each day with a ‘stand-up’. This is a 15 minute meeting for developers and testers to talk about what work has been done the previous day and what we’ll be working on today. It’s also an opportunity to discuss any impediments

The main part of the day is spent developing solutions.

Regular development work is aligned to a two week ‘sprint’ which contains a list of developments we need to complete in line with the priorities of the programme. At the end of the sprint we have a completed list of developments that will form a release to the live environment. These can be bug fixes, enhancements and technical jobs such as software upgrades.

At the moment we have jobs in place to upgrade SITS to version 9.40 and for this sprint we’re doing this for the test environments.

In this sprint we also have developments to complete in the areas of Recruitment & Admissions, Academic Model, Assessment & Progression, Student Finance and Interface Management.

A developer is also assigned to be the designated support developer for a given day. This means they will take on any issues raised by the live user base. This could be, for example, applicant queries or queries from staff regarding live processes and also quires about data being interfaced in and out of the system (e.g. UCAS offers and responses)

Aside from the support channels above, a developer can also be approached with a number of day to day system related questions. An example recently would be system access for external consultants from the software vendor.

Developers are also required to attend various meetings on a daily basis. Today, for example, we’re attending a session to review the vendor supplied template for Student Enrolment. This will form the basis of requirement gathering and allow us to configure the template to make it fit to the UOH process.

Other sessions involve meeting colleagues from within the University such as ICTD and Admissions.

What have been some of the biggest challenges you’ve had to deal with?

The University is a big and complex organisation so the biggest challenge is developing software to meet its requirements. This, however, is also one of the main reasons for doing the job. The challenge of creating the software makes the job interesting and provides motivation for all of us.

We also often have pressure to resolve issues in a short space of time, for example, if a solution is being tested for user acceptance we’ll have to solve the issue quickly to meet a release deadline.

The same can be applied for issues in the live environment, because these are business critical processes they need to be investigated and resolved in a timely manner.

Which part of the role gives you the most satisfaction?

Working with the talented people in our team and seeing our solutions being used by our applicants, students and staff.





Posted in Uncategorized | Tagged , , , , , | 1 Comment

UCAS Embargo Success

In the months leading up to the 2017 A-level Results Day, we were approached by UCAS and asked to raise awareness around their zero tolerance approach to embargo breaches. The embargo was being imposed to ensure no applicants received their grades or information about their status prior to A-level Results Day.

Why did they do this?

In 2016 a number of universities confirmed student places a day early, breaching the A-level results embargo imposed by UCAS. Sharing such information ahead of the official release time is strictly forbidden.

One university had released grade information directly to students, triggering a UCAS investigation into the university’s automated systems, which were blamed for the error. Place confirmations from other universities, which weren’t named, went to students with a conditional grade offer, meaning the students could make assumptions about their achieved grades.

It wasn’t the first time this has happened. Back in 2014 the Guardian reported that Nottingham Trent had accidentally emailed a number of students saying ‘sorry you didn’t get your predicted grades’.

When such breaches occur, the universities are duty bound to inform UCAS immediately and swift action is taken to correct the errors.

After the 2016 breaches a Joint Council for Qualifications (JCQ) spokesperson said exam boards take security of results “extremely seriously” and they were “concerned” to learn of the breach. JCQ, which represents all of the exam boards then had talks with UCAS to gather all of the details of the error and understand how this could be avoided in the future.

We’d never had a breach but wanted to ensure our sheet remained clean.

How did we ensure there would be no breaches?

We invited all staff involved in the process to attend a presentation by UCAS, followed by a compulsory online module for them to work through (and pass!). Colleagues outside of our Admissions team then had their access revoked, so that they were not able to view or make decisions on clearing enquiries during the embargo period. Once lifted, wider colleague access was restored to deal with applications again.

So, how did this affect our systems and processes for Results Day and Clearing in 2017?

It was more of a challenge for us this year because we were in transition to the new systems as part of our SIS programme, rolling out SITS and SID, so we had to refresh our approach to the embargo. Although we’d not had a breach before, this year there was a heightened awareness around threat of sanctions in a year where we were possibly at greatest risk.

John Hemingway, Director of ICTD, was asked to take oversight of the approach for the first time this year and the earlier embargo period in early August for SQA results release was also used a rehearsal for the A-level period. So for the A-level results embargo period from Friday 11th August at 12 noon until Thursday 17th August at 7am, we froze our applicant portal (MyHull) to ensure no automated emails went to students based on our early sight of A-level results. For example, had a student achieved the required grades, an email offer of accommodation could, possibly, have been triggered.

The downside of freezing the system for this period of time meant that applicants couldn’t access it to see any status updates or upload documents. We’d already made them aware of this and had a message on our portal throughout the embargo period. We told applicants that the system would reopen at 7am on 17th August, and that they might receive multiple emails from us that had been queued during the embargo period. We also let them know that they could send us documents to support their offer conditions via email if they needed to.

Simon Pownall, Service Manager for the SIS Programme commented, “The new implementation of the Student information system together with the hardening of the UCAS embargo, led to increased pressures on the implementation team and admissions colleagues. Despite the pain involved in excluding staff and applicants from the system during this period we provided a credible process and ensured that we did not put the University at risk. I’m very pleased that the time and effort invested in ensuring the embargo was embedded in the processes and communicated across the University paid dividends.” 


Posted in Admissions, Clearing | Tagged , , , , , | Leave a comment

A great way to end the week!

If Carlsberg made end of the week reports…No live incidents, no live service requests and no live fixes! We’re going home very happy this weekend.


Posted in Uncategorized | Leave a comment