Why be Concerned with the Business Analyst Role?

It is my contention that, without the analyst, real gaps occur. For example:

• Who looks at the bigger organizational problems?
• Who identifies the underlying conflict between what management want (the Customer who pays for the software development, after all) and what the “Users” (a horrible term – but that will be the subject of another discussion) need in order to do their jobs effectively?
• Who identifies the fact that there are (say) 1500 people who are currently doing their jobs in one way, and that after we’ve implemented the new software will need to significantly change their work patterns?
• Who helps these people design new organizational procedures to ensure that the business continues to run smoothly as the changes are made?
• Who identifies the potential lost business due to a poorly thought out customer interaction?

I could go on, but you get the picture.

Alan Cooper gave a great talk recently at a conference wherein he spoke with passion about the need for inclusion of Interaction Design in Agile projects, someone who understands how people behave and who can help the Customer come up with guidelines for the technology implementation to ensure that the resultant product works effectively in real-world use.

My contention is that this role is one which is ideally and effectively undertaken by the Business Analyst, and is something that we should have been doing all along. It is part of what we are trained for – understanding the broader business needs and interpreting these needs in ways that make sense to team members who are more focused on the technology. Traditionally the custodian of the focus on the human need has been the Business Analyst.

Business Analysts Contribute to Team Success
I strongly believe that the de-emphasis of the importance of this role is one of the major gaps in many Agile teams today. In many organizations the analyst role is hobbled – unable to effectively deliver the value they promise due to organization structure and lack of management support. The business analyst needs to be seen as the customer advocate, part of the business-focused solution provision team, rather than a purveyor of technology. Politically empowered, trusted and acknowledged for the perspective and understanding they bring, the business analyst should ideally report into a business improvement area, not into the information technology group. In this structure the business analyst will be empowered to recommend changes with a clear focus on the business value, rather than being perceived as the “lackey of technology” as part of the technology group.

What about Systems Analysts?
Note the distinction here: we are talking about Business Analysts, not Systems Analysts. Where does the “Systems Analyst” fit? While the systems analyst often has the skills to undertake business analysis effectively, I make a distinction between the two roles based on their perspective – the business analyst focuses on and is driven by an understanding of the business needs whereas the systems analyst is often biased towards, and focused on, a technology-based solution, sometimes to the point of being detrimental to actually solving the business problem (“Wow, have I got a solution for you!”). Systems analysts can be good business analysts, but they need to be very careful to suppress their urge to propose technical solutions!

Why Use an Analyst? We Want a “Customer”
The analyst spends time getting close to the diverse “stakeholders” – people who represent groups and organizations that care about the successful delivery of the business change. The analyst needs to understand the multiple dimensions of the business need; discussing with management the overall goals and objectives; working with the legal department to identify any legislative or litigious impacts of the new/changed business processes, working with the logistics department to identify changes to office space or warehouse layout and to understand the potential impact of the processes on the flow of materials or products through to dispatch; with the administrative staff to understand the potential bottlenecks that could result from a new approval process… and so on.

At some point in the analysis investigation it will become clear that solving this business problem potentially warrants an investment in technology. At this point the analyst role changes a bit and we get involved in the technical feasibility discussions – the “build vs buy” decision, the insource or outsource decision. At this stage traditionally the BA role is involved in developing the Business Case, which is still needed by the business when using the Agile approach – projects still should be justified in terms of the business benefits they will deliver to the organization. Without this valuation, the ongoing prioritization effort required for Agile backlog management can lack “big picture” vision, resulting in requirements thrash.

Once these decisions have been made and it is decided to spend some money on the technology, the analyst role changes yet again – now we become the shepherd of requirements; the collector and guide of stories. This is where the analyst actively intersects with the Agile project and becomes a vital participant with the Agile software development project team, representing customers and end users, and collaborating with the other team members to meet a clearly identified Business Need which we believe will benefit from a technology-based solution.

The Analyst works with the project team to corral the stories – acting as the customer advocate to the team, facilitating User Story definition, and being the project advocate to the wider stakeholder community, taking responsibility for getting the right customer voice to the project team at the right time. This “customer”, so blithely referred to in much of the Agile literature, is not usually a single homogeneous individual, rather they are an amorphous mass of “stakeholders” – a diverse, often contradictory, frequently competitive, sometimes negative group with divergent points of view about what the business need is and what “done” looks like.

Does the previous paragraph imply that I don’t believe in the “on site customer” – NO! I believe very strongly that we need an onsite customer for the Agile development process to be successful. The challenge we face is that there will be many customer voices, often shouting contradictory orders at the team. The Analyst must be able to filter the signal from the noise and help to identify the right representative customer(s) who should be involved with the project at any point in time.

So What Does this Analyst Actually Do?
On an Agile project, the Analyst also becomes the shepherd of stories – guiding the discovery process and facilitating the communication among the team, helping the customer representative(s) by asking probing “what if, what about” type questions, based on the broader investigation which initiated the project; building on their mapping of the stakeholder community, their understanding of the intricate political and influence relationships which underlie the formal structure of the organization and their ability to tap into funding sources to gain access to real-world clients (the people who actually pay for the services the system will provide) to gain an understanding of what is needed to create competitive advantage and Customer Delight – which ultimately results in commercial success.

The analyst needs to have a broad range of investigative and interpersonal skills, the ability to think critically and skeptically, using a variety of modeling techniques and other tools to help the customer representatives discover the range of stories which will ultimately make up the system. The analyst helps them express these stories in clear and understandable ways that make “done” explicit and knife edged, works with the testers and customer representatives to help identify and clarify the acceptance criteria for the whole gambit of stories.

The best analysts are involved in every aspect of story identification, and actively involved in the interaction design for the system. They have an understanding of the various ways the broad community of users will need to interact with the system, understanding the divergent needs and smoothing the differences to identify the design aspects which will work for the disparate stakeholders.

Agile Analysts are Designers as well – with an understanding which goes far deeper than simply identifying and documenting the requirements for the system. They understand the implications of screen flow and ensuring that process flows match the way people actually work, they are aware of the impact of colors and fonts, of screen layout and response times on the productivity of the people who use our systems. They look for opportunities to create truly useful systems that people want to work with, and work to guide the creation of intuitive and natural interfaces; ideally interfaces that seem to disappear, so easy to use that the operator doesn’t even notice that they are there.

The traditional analysis “what before how” approach doesn’t apply on Agile projects – most often we understand the “what” by showing the “how”, in a productive and iterative cycle that is an inherent part of the Agile development process.

Look and Feel matters – the Agile Analyst helps bring this into sharp focus when the interaction aspects of the system are being worked on.
The Agile Analyst focuses on ensuring that real business value is exposed and uncovered by working with the project team and customer representatives to find those aspects which make their work easier, more productive and deliver Customer Delight, the “stickiness” which keeps our clients coming back to do business with us over and over again.

Who Should Play the Analyst Role?
The Product Owner or chief customer advocate in a Scrum project is a role ideally suited to the Agile Analyst, provided they are empowered and supported to act on behalf of the customer. The Analyst is in the position to actively manage the product backlog and identify product priorities. Building on relationships with business stakeholders and an understanding of technical realities the Analyst can actively manage the delivery of value in the project.

The Agile Analyst needs to be an active and productive member of the business project team, not trying to produce a lengthy tome of “shall” statements, but representing, advocating and shepherding the many customer voices, asking the hard “have you thought about. . .” questions, ensuring that the products we deliver meet the diverse and competing needs of our customers, understanding and indentifying flaws, flows and issues with discussions and interactions within the entire project team, based on the User Stories current and past.

The Analyst Role is Necessary for Success

Technology exists to serve, not to be, the human need!
– Malcolm Watson, the Development Manager at Pronto Software in Melbourne

The Business Analysis community needs to step up to the mark – becoming active participants in collaborative Agile teams focused on the creation of systems that deliver real-world value and Customer Delight. An active move back to the “Analyst” part of the role – breaking the problem apart into its constituent components in order to understand the real underlying needs, then working as an active participant on the project team to deliver a solution that creates competitive advantage and customer delight!

There are two main objectives of any interview. The first is for a company to determine if you, the candidate, are the right fit for the position. The second is for you, the candidate, to determine if the company and position are the right fit for you. The following tips will address how to present your best to the prospective employer. In addition, you will find some helpful tips for determining if the company and a position are the right fit for you.

Interview Guidelines

• Relax
• Dress one better
• Turn your cell phones and pagers off
• Understand the question
• Show interest
• Show confidence, not arrogance
• No badmouthing
• Do your research
• Be on time

Relax. Many people tend to tense up at an interview. While you should always remain professional, don’t forget to relax and let you personality come through. The hiring manager should get a real sense of who you are. You will be working for or with this person every day, so it’s important for them to feel they can get along with you easily. No one wants to work with a business or systems analyst with a difficult personality.

Dress one better. A good rule of thumb is to dress one degree nicer than the group you are interviewing with. If the employer has a business casual dress code then you should dress in conservative business attire. If the employer has a casual dress code (jeans, t-shirts, etc) then you should dress in business casual. This ensures that you are always presenting yourself in the best way possible without seeming completely out of line with the company’s culture. You would never want to appear underdressed, nor would it be wise to show up in a full suit or conservative business attire if the company has a culture of being very casual. It would appear as if you wouldn’t fit it.

Turn your cell phones and pagers off. Simply turning off the ringer or placing the phone on vibrate is not enough. Everyone knows the sound off a vibrating phone or pager, and it’s very distracting. By turning off your electronic devices ahead of time you can remain focused on the interview at hand. Nothing is worse than trying to focus on a question the interviewer has just asked you while your phone buzzes incessantly.

Understand the question. Listen carefully to the question being asked as well as what it not being asked. If you don’t understand the question, or you believe the interviewer has left out some important information required to answer the question, then ask a series of clarifying questions to obtaining the necessary information. This an excellent way to demonstrate one of the most important skills required of a business or systems analyst (information gathering). Be straightforward and concise with your answers. How long or short your answer is isn’t nearly as important as the content of your answer. Don’t be evasive and don’t lie or bluff. Bluffing will destroy all credibility. If you don’t know the answer, then say so. If you think you can make an educated guess then let the interviewer know that you aren’t sure but based on the experience you do have you believe you can figure it out. Let the interviewer see your thought process as you work out your answer. Many times how you go about problem solving is more important than whether you arrive at the right answer. In any case, take a few seconds to think about your answer and formulate a structured response. Rambling and saying the first thing that comes to mind conveys that you think randomly and in an unstructured way.

Show interest. At the end of the interview thank the interviewer for taking his or her time to see you and shake their hand. If you are still interested in the job make sure to let the interviewer know that you are interested and that you want the job. Let the interviewer see that you are excited about the position.

Show confidence, not arrogance. Always present yourself with confidence, but be careful not to come across too strongly or the interviewer may perceive your confidence as arrogance. This is always a delicate balancing act. State the facts of the situation needed to get your point across and convey the information using powerful action words.

No badmouthing. Be positive and avoid making negative remarks about former jobs, managers, or employers. Business and systems analysts need to be able to work with a wide range of personality type. Badmouthing others will not help you land the position.

Do your research. Prior to the interview research the company to learn as much about your prospective employer as possible. Make a list of questions to ask the interviewer. This shows that you are able to research areas that you know little about, another important skill of business and systems analysts. Convey what you’ve learned from your research and what you found interesting about the company.

Be on time. You only have one chance to make a first impression. Plan to show up for your interview at least 15 minutes early, and plan for unexpected delays. Showing up early gives you the opportunity to clear your head of the day’s events. Take the time to refocus on the interview at hand. If you do encounter an unexpected delay, be sure to call ahead and let the interviewer know that you may be arriving late.