Women in Tech Can Make a Real Difference

This latest piece is by Louise Powell, Business Analyst, Markerstudy and offers some insights into how tech needs to work for the customer, not the IT department.

I work in IT, but I’m not a techie

I’m a business analyst (BA) working in business technology at Markerstudy Group in an IT department that works on a host of partner /business changes across a lot of different technical platforms. I am part of a 10 strong team and originally started my career at BGL Insurance (BGLi) over 20 years ago before moving over to Markerstudy as part of the acquisition.

If you asked my mum, she’d say I was a ‘techie’ – I have frequent calls from her when her phone or tablet goes wrong, most of the time I just advise to turn it off, wait a few seconds then turn it back on. Only the other day she didn’t know why her car lights were now dipped after she cleaned her dashboard; I just moved the dial back-up, she thinks I’m a technical genius.

I don’t write code, I’m not a gamer in my spare time, but I work as part of a successful development team, delivering technical solutions for our partners.

I originally started in the call centre, and BGLi has been brilliant at funding my qualifications and allowing me time off to continue my development. I’ve worked as a BA for about 10 years now, I really enjoy my job. Because of the project work, no day ever really feels the same.

IMPROVING SYSTEMS

A BA improves company systems and processes. This includes gathering and documenting requirements, then working with the development team to put a solution in place. Projects can last from a couple of weeks to a couple of years.

Normally when a change comes in, I get a high-level understanding of what the change is; changes can range massively, from a new question being added to one of our online journeys, to a new FCA requirement, impacting all our brands and all our products.

We have team session/s (depending on size of change) to discuss with the change owner and main stakeholders what is required. During these meetings, the software developers talk about any technical restrictions and ways the change would work best. Part of my role is to facilitate the workshop; we need to get the best from the wealth of expertise in the room (or online) at that time.

Part of my job is to ask ‘those’ questions:

· What’s the quickest way of doing this?

· What’s the best way, in terms of quality, to do this – even though it may take longer?

· Is this a short-term fix?

· What systems does this need to integrate with?

· What else will this change effect?

· How does it affect our customers? What would our customers want from this?

· What are our options?

DIFFERENT APPROACH

One of my favourite questions, that I cringe a little inside as I ask (imagine the eye rolls of my supportive team, who by this time are maybe a little tired of the questions):

Why are we doing it that way? I know we’ve done it that way in the past but why? Would this approach work instead?

A lot of the time, we’re reassured that this is the best way, we then go through the pros and cons of the solutions available, but this question also allows thinking time. In some circumstances, there is a better way, a simpler approach, or it may create less technical debt, a better customer outcome or enable a more robust test approach. We’re reminded of the value the whole team adds to the delivery of the business solution. It’s very easy for routine to dictate how things progress, rather than to stop and ask: is this still the best way? In software delivery, things never stay static.

THE BUSINESS CASE FOR INNOVATION

We need to make sure we are delivering the outcome that has been asked, and that we have thought about all the possibilities. Sometimes we can enhance the outcome, deliver more than expected. There is never a perfect solution, so we work out which is the best customer outcome, the best solution for the business and deliver what has been asked of us.

Questions drive innovation, they elicit information, they help the whole team understand the issue; it’s dangerous to not understand the issue properly, at the very least, you may get quality issues, the worst, you deliver the wrong solution and both of these cost money and time.

Remember, no question is a bad question. If you are thinking it, then other people may be too.

Be confident, ask your question – and listen.

All the above can only work if your team works well together; you need collaboration. No one team member could deliver a project on their own.