Insurance Australia Group (IAG) is Australia’s leading general insurance group. It provides personal, commercial and rural insurance under some of the countries most well-known brands including NRMA Insurance, SGIO, SGIC, CGU and Swann Insurance.

Like most insurers, IAG’s business is supported by web based processes and information channels and its various websites reflect the Group’s diversity of products and brands. In this article, IAG Senior Business Analyst, Andrew Kendall discusses an approach to Volere’ requirements gathering that supports these ever changing business needs.

It seems to be a constant dilemma for those in the eBusiness arena to try to balance the rigour of systems development with the quick time to market demands of today’s business environment.

Moreover, how do you do this in such a way that internal clients within the business have the feeling that they were responsible for completing the change almost without the help of IT people? Customer satisfaction must be a key driver for any eBusiness project.

We experienced this challenge recently at the Insurance Australia Group’s eBusiness development centre in Sydney. As we discovered, creating a sense of transparency in eBusiness requirements gathering requires an approach that is a bit different to the regular, ordered, ‘waterfall’ approach.

What we did — Our Requirements gathering

We used a micro-sized Volere template called a ‘Requirements Brief’. The Brief was originally adopted by IAG as a way to estimate Business Analyst effort and preceded the full Volere requirements template on large projects.

The Brief contains the background, stakeholders and the business requirements. However, to keep the document focused and to the point, no more than a paragraph describing each requirement is used. This paragraph details the requirement’s description and its rationale. The main purpose of the Brief is to show to the business that you’ve understood the intent of the change.

Once the Requirements Brief is agreed, the focus moves to design, where prototyping comes into play.

Initially, prototyping sessions use low fidelity technology – paper or transparencies. Once more detail is known, this is followed up with HTML mock-ups (around 48 hours later).

In the prototyping sessions we use questions you would normally see in the Volere Requirement ‘snow cards’, for example, “how important is this function to you if it was delivered?” The answers to these questions decide what is adopted in the final design.

Everybody in…

All business stakeholders attend prototyping sessions including underwriters and corporate lawyers. Sometimes the sessions are even attended by M&C Saatchi, IAG’s advertising agency, who provide copy and creative work for the website.

Involvement of everyone throughout the entire development lifecycle, including testers and trainers, is critical for success. The aim is to make sure people know what’s coming up so they can think about the change before the work lands in their area. It is not uncommon to hear the words “this is what has been proposed. Can you have a think about it and let me know what your ideas are?”

The thing we found most important in stakeholder management is to recognise people’s expertise. If all the experts on the project can hear each other’s views first hand, this becomes a powerful problem solving team.

However, to be successful, this approach requires open thinking on behalf of the developers and a flexible open-minded project manager. It can be quite a big mind shift for some people who are surprised to find you actually want to know what they think about something.

Currently, the development process (even for eBusiness) requires the completion of functional specifications or “external design” documents. Although, as developers work from draft versions and the business is involved throughout the design process, the final version of the design document is often an agreement to what has been done, rather than what is to be done. This is a different way for the business and IT to work.

The Agreement (Sign off process)

For those of you who haven’t endured a sign off process, try to imagine what it might feel like from the business perspective. Imagine someone leaving a one-hundred page book of insurance rates on your desk to review in two days. If you didn’t work in insurance, you would probably be tidying your workstation before summing up the courage to read, it let alone review it.

We found that it pays to identify the business owner responsible for sign off early in the process: we find this is often the person providing the requirements. Everyone else becomes a reviewer only. After a general review session, a ‘one on one’ meeting is held between the business owner and the Business Analyst to answer any questions. This speeds up the sign off process. It also avoids the business owner trying to navigate through a document that is often more meaningful to us than it is to them.

Again it comes back to customer satisfaction. It’s important to remember that the client has to run their part of the business and not the eBusiness area. That’s where we help.

The future

We found that the functional specification is still cumbersome and hard for the business to understand. We believe the way forward is to have development systems that are self-documenting. For example: “How about we show you the changes on the screen and, if you want a hard copy, we can print one out for you.” It appears that this type of technology is only emerging now.

Measures of success over time

So how did we go with our shorter requirements document and prototyping? Did we find a balance between rigour and speed?

Well it took a bit of practice. The first delivery stream we were on time but the budget was underestimated. The next delivery stream we were on time and on budget Ð and the satisfaction of our customers was at an all time high.

About the author

Andrew Kendall is a Senior Business Analyst with the Insurance Australia Group where he has spent the last 3 years in eBusiness. He has recently completed an MBA with the Graduate School of Business at the University of Technology, Sydney, with a major in Strategic Information Technology. He also has a Diploma in Marketing Management.

Concepts

Some of the concepts including prototyping and using limited requirements can be found in the ‘Mastering the Requirements Process Part 2’ course, an extension of the ‘Mastering the Requirements’ course by Suzanne Robertson and James Robertson.

This work is copyright © Andrew Kendall.