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.