Knowledge House Information System project updates

Following the launch of KHIS 2.0 late last year, accounts were created for only the core KHIS users within each of our five member universities.

However, now that the system is stable and users are reporting excellent feedback, the rollout of accounts to other individuals and groups within the universities has begun.

KHIS is underpinned by a bespoke security model which allows access to data to be customised on a per user basis. For each record in the system, four levels of access can be granted:

• None (record is invisible)
• Summary (user can see core data such as project reference and owner)
• Read only (read-only access to the full record)
• Full (write access to the full record)

These levels of access can be granted to a single user, a collection of users, all users with access to a specific project, or globally to all users.

This flexible security system is one of the prime advances over KHIS 1.5, and allows highly customised user groups to be created. Indeed, several such groups have now been set up.

At one university, for example, a group of accounts has been set up for staff from a research centre. Users have full access to projects created by staff from that centre, plus summary access to all other projects running within the university. Projects from the other four universities are completely hidden.

Further accounts and groups will be created over the coming months.

One of the reasons KHIS has been so successful over the years is down to the active engagement between the user community and the development team. This is due in no small part to the KHIS Champions meeting.

Established several years ago, this monthly meeting sees key representatives from Durham, Newcastle, Northumbria, Sunderland and Teesside universities meet with the system developers. The forum is useful for a variety of reasons:

• New functionality can be demonstrated and instant feedback obtained from people who actually use the system
• Opportunity to plan potential new functionality and features
• Discussion and resolution of problems

During the evolution of KHIS 2.0, the meetings proved to be invaluable as users were able to contribute to the new system, right from when it was simply a few rough sketches on a whiteboard. KHIS 2.0 was actually devised to address several fundamental problems with KHIS 1.5 identified during Champions meetings.

As KHIS 2.0 progressed, the meeting was used to identify and prioritise problems, and plan solutions.

Congratulations and best wishes go to Senior KHIS Developer Rachel Armstrong, who earlier this month gave birth to a healthy baby girl.

Rachel will return to Knowledge House in 2011.

As with the launch of any new system, no matter how much it is tested beforehand, once it goes live bugs are inevitable. This indeed was the case with KHIS 2.0, although the majority have been minor. Several mechanisms were used to record bugs:

1. Automatic error logging

   KHIS 2.0 automatically logs errors and emails the system administrator whenever a problem occurs. This enables problems to be actively tackled and there have been several occasions where bugs have been fixed and reported back to the user within an hour of the problem occurring!

2. Bug reporting system

   The open source TRAC bug reporting system is used to allow users to lodge tickets. Often problems don’t result in an actual error message; instead there could be an anomaly with missing data, or a user might want to request an additional system feature. TRAC allows such things to be recorded, with the progress of tickets being tracked and reported back to the users.

3. Monthly KHIS Champions meeting

   Once a month, nominated representatives from our five partner universities (Durham, Newcastle, Northumbria, Sunderland and Teesside) meet with the KHIS development team to discuss problems and ongoing development work. This forum has proved to be an excellent way of identifying problems, eliciting feedback and educating the users about how to use the new system. There have been instances in the meeting where someone has reporting what they perceived to be a problem, only for another user to intervene and explain how to resolve it.

   By actively involving the users in this forum, their trust in the new system has steadily increased.