Data Integrity and Chorus – An Interview with Gemma Holmes
Please introduce yourself
I’m Gemma Holmes – I’ve worked for Chorus for just over 2 years. I was originally the Customer Relationship Manager (CRM) for Wales and the South West, but about 4 months ago I changed roles to become the new Lead Business Analyst.
.
What does the Business Analyst (BA) role entail?
The BA role was created to manage product development, requirement capture, documentation and user acceptance testing (UAT). This means I work closely with the technical leads and software developers to translate customer and/or business requirements into new system features whilst maintaining data integrity. Essentially, I am the link between the user, the business and the technical team – part of my role is designing processes to ensure those links are efficient and effective and that customer needs are always taken into account when discussing the direction of our products and services
Can you explain how you collate customer requests?
We launched our product feedback form on the client area of our website back in May 2019. Users can use this form to submit feedback on the product or suggest new features. These requests then come to me and I review and log them. I look for themes – often users want the same/similar things and under this new structure we can more effectively analyse the requests coming in and link them. I will contact the user if I require further requirements around any of the requests and also look to run focus groups for the themes identified as appropriate.
How do these requests get prioritised?
Firstly, I would look at the requests and perform an initial assessment – if the request fits in with an already identified theme or requirement then I might be able to incorporate the new request into an existing project. Otherwise these then go to a weekly meeting I chair where there are discussed with my colleagues (CRMs, technical leads, testers etc) to agree an initial priority. We consider a variety of factors when prioritising and take a wholistic approach. Once agreed, these then feed into a monthly strategic prioritisation meeting with the directors to agree the priority and where they fit in the release schedule.
How do you ensure data integrity?
Customer requests for new functionality via the website isn’t the only way I collect requirements – there are several other ways cases can be raised. These could be from users via the helpdesk, from the development team or from the CRM team. When cases come in via one of these streams the first thing we do is assess whether it affects data integrity or not. Any case that does is treated as a high priority issue. If it’s critical we will deal with this as urgent. Data integrity is paramount to us and our industry and comes above all else.
This feeds into our new product roadmap – you may have noticed we now have three main releases per year and then one smaller update in between. The main releases will contain major functionality improvements and user requests. The smaller updates will contain any minor changes e.g. rule tweaks or new templates etc. This more structured release pattern is to make it easier for users but also to ensure they’re not waiting for a release to get any data integrity updates. As part of this process we also have a formal communications plan, so we’ll keep you informed of any data integrity issues and let you know when to expect the fix.
You mentioned you carry out user acceptance testing (UAT) – what is that?
Every release and update is tested via our team of software testers. They functionally test every new feature as well as every change to the system. Once a case has successfully passed testing, for new features or complex changes it will then be passed to me for UAT. Essentially, I will then test the system from a user’s point of view. This is different to functional testing – for example a feature may work correctly as intended, but for some reason might not be intuitive for the end user. Both forms of testing ensure the end product is to a high standard and protects against data integrity issues.
It is not until a case has been through testing, and if required UAT, that we consider it committed to a release. This is why often the estimations of when you can expect a particular fix or feature are not set in stone – the testing process is vigorous and if a case fails testing, we may choose to remove it or bump it to another release rather than delay the rest of that release. I appreciate this can potentially be frustrating but this process is in place to ensure you get the best possible product.
Any questions?
If you have any further questions about my role or how we deal with data integrity you can contact me at [email protected]
