Business Analysis: A Guide to Better Business Requirements

Better Business Requirements

In the world of business, some projects gain management support and fly, making an enormous difference to the success a company has in the marketplace, whilst other projects crash and burn, whilst
still radiating heat from the printer. At times, it is not the potential of the project that determines whether or not it gains support, but how it is presented.

Corporate business operates in a similar way to family business. We all have finite resources to allocate to our projects. We all face choices in the daily routine of life:

• Do I buy a new outfit or go out to dinner?
• Do we replace the front fence or extend the home?
• Do we implement a new customer relationship management system or acquire another company?

In companies, it is up to management to decide what projects will gain resources, both in the form of funds and talent. The vehicle for gaining and maintaining access to these resources is the
reports and presentations we prepare to gain management support and commitment.

So why does one project get up and another fall over? What is the difference between a winning proposal and a losing one? The intent of the business analysis guidelines shown in Figure 1 is to
describe some characteristics that make the difference. These principles illustrate heuristics or patterns that are evident from successful projects to help your projects take off for full flight.

Figure 1: Guidelines 

Guidelines Explained

Tell a Story

How do organisations create a sense of purpose, possibility and mutual commitment that will inspire ordinary individuals to feats of collective heroism?

It is done by creating a visionary story that captures the imagination of the intended audience. It’s not about telling “porkies,” but about telling a story that engages your
audience’s attention because it is both interesting and easy to read, listen to and visualise –  story that clearly summarises the what, how and why of the project.

Be mindful of your intended audience’s interests and the message you want to leave with them. Describe the problem and outline how the solution will address the problem. Always be
pragmatic. Manage your audience’s expectations by clearly describing the benefits that will be achieved and the issues that still need to be addressed. If you feel confident, begin with a
creative introduction that reinforces the key points you are making.

Remember that engaging stories create the emotional difference necessary to achieve success.

Take Ambiguity, Make Certainty

When an idea begins, it is but a seed surrounded by ambiguity in the mind’s eye of its creator – still waiting for the nourishment of certainty required for it to grow and reach full
bloom.

The business analysis and design phases of the SDLC provide the opportunity to supply the nourishment necessary to take the generalities described at the outset of an idea to the specific details
required to implement that idea.

The role of the business analyst is to act as a communication conduit by helping the business to articulate their requirements in a form that has meaning to the technical staff that will deliver
those requirements. The requirements, context diagram, process models, entity relationship diagrams, mini-specifications and entity descriptions deliver the nourishment of certainty required to
implement a system solution.

Make the Invisible, Visible

Once the idea is formed, then the stakeholders must enlist support to gain organisational acceptance of the proposal. Often the decision makers are not involved in the detail of the problem
underlying the proposal. To gain acceptance, you need to build empathy to these problems, which is why a story needs to be told.

In order to have a story, the pain and suffering must be made visible to inform the decision makers why the proposed change is necessary. For example, staff taking 10 to 15 minutes to respond to
a phone call is not a big problem that warrants management support. But, think again!

Large corporations running a help desk function can receive 5,000 fault status call backs per month. At 15 minutes a call, assisted help is costing $60,000 to $100,000 per month.

Don’t Confuse the Story with the Detail

Pictures and summaries are great for describing concepts and the shape or form of the solution; but when it comes to providing a system solution, you still need to provide the appropriate level
of detail necessary to either build a system or select a software package. The level of detail that must be recorded to deliver a system solution includes:

• Process activities performed and the steps undertaken.
• Business rules to which processes must conform.
• Data provided to support operational and decision-making processes.
• Concepts that describe where flexible configuration capability is required.
• Non-functional features and metrics to establish system performance criteria.

This information should provide sufficient detail to design the system solution and write each line of code. Without the detail, the story will always be only a story and will most likely only
make the fiction shelves of your local bookstore.

Enough is Enough

What is enough? Enough is enough.

As you can see by the circular argument, there is no simple answer to this question. This is a judgement call based on experience. As a guide, if your business stakeholders understand your
requirement specification and the delivery team can clearly articulate how they will deliver the requirements, then you have done your job well and enough is enough. If either of the parties is
unclear, then more is required. Figure 2 illustrates the project characteristics that require more of enough versus those that can get by with less of enough.

Figure 2: Plato’s Guide to Enough

When all else fails, ask the project stakeholders what they need in order to sign off on a document or to complete the next follow on activity, such as providing a quote within 20% tolerance
level.

Analyse Your Audience – One Medicine Does Not Cure All

Before you begin writing, stop, think and then write.

Think about what your audience wants to hear, pitch your presentation to that level and leave the message you need to communicate. You can do this by assessing your audience’s interests and
then determining the best approach for communicating your message. Figure 3 provides an example of the approach that meets the interests of both a management and a technical audience.

Figure 3: Example Approach

It’s Your Client’s Project, But Your Outcome

The client pays for the problem resolution and the project team’s responsibility is to deliver the solution according to the requirement. As good as an idea may sound, it is the project
sponsor’s responsibility to determine the scope of the project. If we, as business analysts, find an opportunity to solve a bigger problem or a different problem, then the client must be
made aware of the opportunity and given the option to decline or accept the additional functionality. This decision can only be made once all the facts are presented, i.e. a project impact
analysis that outlines the cost and effort required for delivering the recommended changes.

If we fail to manage the scope of the project tightly, then the project team risks losing its credibility and the confidence of the project sponsor. Rigorous scope control, risk assessment and
issue management will ensure that this does not occur.

Methodology is a Toolkit not a Process – Choose Wisely

Over the course of a three-month period, a plumber visited our house twice to make some repairs. The first time he came, he replaced the washer on the main supply to the house. This was a quick
job. All he needed from his toolkit was a shifter and an American screwdriver (hammer) to loosen the head of the tap and fit the new washer. The next time the plumber came to add an additional
downpipe to the guttering. This time he needed a lot more from his toolkit, including a soldering iron, solder, a length downpipe, a shovel, a number of lengths of PVC pipe, collars, PVC glue, a
brush to apply the glue and my chequebook. These two plumbing jobs dealt with water and pipes, but required very different tools to get the job done.

Information technologists use their toolkits in a similar way. They have a broad range of tools they can select from their toolkit in order to deliver system solutions. The difference is that the
IT toolkit is a methodology that contains many tools and techniques, such as process modelling, data modelling, use case modelling, object modelling, sequence diagramming and state transition
diagramming, prototyping and report templates. Not all these tools have to be used for every job. The trick is to be agile and select the right tool for the right job. With experience, you will
find you can use a common subset of tools to complete certain types of projects and different tools for other types of projects, just like the plumber always uses a shifter and a hammer to
replace a tap washer.

So choose wisely and create your own fast path routes for completing different types of projects by preparing your own business analysis project planning map. Build on your experiences and fine
tune your product each time you undertake a new assignment.

Mirror What is Good

If someone can do it, anyone can do it. This is the premise behind mirroring other people’s practices and work. So when you meet someone you know that does their job well, then don’t
ask “How do you do that?” but rather, ask “How can I do that?”

Mirroring can occur at a number of levels. One level is to take a good deliverable and use it as a performance standard or benchmark for your own work. Observe the structure and nature of the
content, and then try to produce similar examples with your work. When you start to get the hang of it, then try to improve on your performance standard so that your work becomes the standard for
others to follow.

On another level, you can ask the producers of the work you are mirroring how they do what they do? Try taking the opportunity to observe these practitioners in action, or – even better
– work with them on a short assignment by offering your help on their project. By building on your experience in this way, you will be able to make incremental improvements to your work
products.

A Problem Shared is a Problem Halved

Each employee is a capable and respected member of the project team. They have personally developed competencies, unique knowledge and individual capabilities that add value to the company as it
works toward achieving its goals and objectives.

By collaborating on joint work products, people will gain greater personal satisfaction through delivering higher quality output. Collaboration will extend the organisation’s core
competencies beyond specific individuals because people transfer skills to one another through on-the-job training, sharing and mentoring.

This excellence is achieved in a collaborative work environment because the whole team contribution is greater than the sum of any individual parts. Encouraging your staff to share their
knowledge in this way will result in developing self-sufficient interdependent individuals and an energised team.

References:

1. Covey, S.R. (1999) The 7 Habits of Highly Effective People. London: Simon
   & Schuster Inc.

2. Streitberger, Stephan (1992 – 2007) The Facilitator’s Field Book, Unpublished.
3. Streitberger, Stephan (1996) Help Yourself by Using Your Intranet, Victorian ACS News, May/June, pp. 7.
4. Streitberger, Stephan (2005) Business Analysis Project Planning Map, Unpublished. Request a free copy via e-mail from http://www.designerdata.com.au/.
5. Photo images, © 2007 JupiterImages Corporation.