Soft Skills

“I may not know much about art, but I know what I like”. This famous punch line to a Monty Python sketch about a fictional conversation between a disgruntled Pope and innovative Michelangelo (who wanted extra disciples, multiple messiahs and a kangaroo in his first draft of the Last Supper), can also be seen to satirize our own modern fixation with creativity, feedback and the idea that ‘the customer is always right’.

Like it or not, every business analyst will have to stand up in front of a group and present. The group might be your business clients, the project stakeholders or just your fellow team members but for many people, one of two things will happen: it will frighten the life out of them OR they’ll umm and ah their way through, sending the audience to sleep.  Why is this so?
 

If you work with other business analysts, you are fortunate. Together with your colleagues, you can experience greater effectiveness than you could have achieved on your own.  Additionally, your colleagues can provide you with a diverse and convenient pool of expertise from which to draw.

What we have witnessed in the last 25 years is a series of programmes of change failing to achieve their intended outcomes. Customer Care, ISO 9000, TQM, ABC, BPR. All the research and experience show that the latest panacea does no better than its predecessors. Over and over again improvement programmes are thwarted by commonly-known but illusive forces. The problem is labeled as ‘organization culture’, which typically leads to rationalizations like ‘change takes time’, or ‘each programme is an element in the total change programme’.

Rationalizations prevent learning.

In virtually every industry in which business analysts find themselves, employers are trying to do more with less. Normally, this means budget and personnel cuts, which are forcing many analysts to also do the work of project managers, prototype designers, and other roles—and often with a smaller budget for software and other analysis tools. In this environment, it may seem challenging for analysts to find ways to cut back even more, but proactively doing so will benefit not only your employer but your projects and your career. Here are a few ideas to research and pitch to your manager for cutting costs as you go about your daily work.

There are many qualities that contribute to great business analysis. You have to be a good communicator and be able to analyze problems. It generally helps to have some solid background in the common techniques of business analysis. For some jobs you need domain knowledge, for others technical expertise. All of these are debated and discussed often in BA circles across the web. One of the attributes I don’t hear people talk about quite as much is being results-oriented.
 

Smooth stakeholder participation is integral to the success of any project. Sometimes stakeholders hold information that is essential to thorough requirements discovery, so it is important that they be forthcoming. Other stakeholders must sign off on requirements as being final in order for a project to move forward, so it is important that they be decisive and willing to let go the discovery stage of a project.

I have been in the business analysis profession for many years and the one thing I have constantly had to challenge myself on is leading without really leading, or what I call leading from the side. As a business analyst, many times we are not in a position of authority yet we have to have significant leadership skills to be successful.

From a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.

I am not sure if there are many other fields in corporate America that require the finesse necessary to execute the professional pushback as greatly as business analysis. Just by the shear nature of what analysts do, we are constantly uncovering inefficiencies and making recommendations for improvements or enhancements. Sometimes those recommendations are system-focused but they can also be people and process focused.

The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.

A couple of months ago, I was driving along a well-traveled road here in town when my headlights fell upon a large pool of standing water. The little boy in me still loves splashing in puddles, whether on foot or in my car. I smiled at the thought of creating a huge spray. Unfortunately, the harmless puddle of standing water was actually a large pothole. What I thought was going to be a fun splash turned into a blown tire and bent rim. As business analysts, we encounter these water-filled potholes all too often.

A lot of people think that coming up with solutions to business problems is the hardest part about being a business analyst – particularly when working with a client who knows more about the business than you ever will. Don’t believe it, after all you’ve already made considerable progress in understanding the problem – and your understanding is based on level-headed analysis rather than a potentially emotional interpretation by your client.

Now it’s time to look for solutions – to be creative and think outside the square. In this paper we’ll offer a few tips and techniques for getting the creative juices flowing. We’ll show you that anyone can be creative and that solutions can come from the most unexpected places – you don’t have to be a subject matter expert to come up with valid, workable solutions to business problems.

Where application development is concerned, the ability to produce great code is just one small component of overall success. Just as essential is the ability for the developers to clearly grasp the business requirement – and deliver against an accurate functional specification.

Nick McKenzie, technical director at nVisionIT, notes that the process for the creation of an application is not always clearly understood. “From the business owner, to the user, to the developer, there are different perspectives and different expectations at play. As requirements pass through this chain, inconsistencies or assumptions can be introduced which can derail this process.”
 

No matter what requirements gathering process you subscribe to-waterfall, unified, or another approach-your discovery will be markedly easier if you can identify the right subject matter experts from the beginning. Whether they exist inside or outside your organization, people who intimately know your project's product or service, its actors, and its building tools will help you create more inclusive requirements, identify your unknowns, and grow in your own knowledge of the industry.