“Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it” – Samuel Johnson

Happy 2010! It’s my first post of 2010 and I’d like to use it to address the question of what it takes to be a Business Analyst and what skills should you expect a BA to exhibit?

This is a question that I imagine vexes employers, particularly those, that understand what a BA does and now want to employ one of the best. The question is also relevant for those looking to pursue a career as a BA.

Below I’ve compiled a list of the 5 key skills that I look for in a Business Analyst, I’m sure the list is not exhaustive and that you can add to the list, in fact, feel free to leave your suggestions below.

1. Technical Knowledge

While the first priority of any BA should always be the business and their requirements, a BA still needs technical knowledge.

Most BAs have a technical background, I started out coding in VBA and SQL. I was never very good at either of them and was always far more interested in the planning and analysis phases of any project, rather than the actual coding itself.

As useless as I was at actually coding, the exposure to different types of technologies has allowed me to a much better Business Analyst, primarily because of how that knowledge allows me to interact with two of the key stakeholders in any project; the technical teams and the business.

Knowledge of relevant technologies allows a BA to have informed discussions with the technical teams. A BA may not understand the ins and outs of Java, for instance, and probably can’t even code in it, but they should understand the principles of development, be able to relate to issues faced by a development team and their knowledge of technology should allow them translate that knowledge into a language that will be understandable by the business.

This ability allows a BA to build trust with the business. Often the technicalities of a project will be confusing and complex for the business, a BA that can be the bridge between the technical and business worlds and can explain technology to the business in language that the business can understand will give the business confidence both in the development process and the BA.

Technology should never be the main focus of a Business Analyst, but they should understand enough that they can build trust, understanding and vital relationships with both IT and the business.

2. Thirst for Knowledge

A BA has to have a thirst for knowledge. At every stage during a project people are going to bring questions to the BAs door, be it the business, development, testing, project mangers or any one of a number of stakeholders. Not only will people bring the BA these questions, they’ll expect them to have answers as well.

Right from the start of a project, a BA has to be a detective, think of all the questions have to be resolved:

- What’s the problem?
- Why is it a problem?
- How will fixing the problem help?
- Is this the most important problem to fix? Why?
- What’s the solution?
- Why will the solution be a success?

There is a lot of pressure in any project to answer these questions, and many others, immediately and the BA has to be up to the challenge. The best BAs will feel exposed if they can’t answer a question, they have to understand, they need to know, it’s something biological in them.

This need that BAs have to understand and to learn leads to massive benefits for projects. For instance a BA that has taken the time to understand, not just the businesses’ requirements, but also the context in which the requirements exist, will be able to talk authoritatively about the business in discussions with technical teams, helping them to understand the background to a project and the importance of what they are doing to the business.

Likewise, a BA that has taken the time to understand why technical solutions were chosen or how technical issues will impact a project, can save a massive amount of hours when explaining these issues to the business as they won’t need to have technical teams attend crisis meetings, allowing them to concentrate on actually fixing the issues rather than discussing them.

This thirst for knowledge and the need that BAs have to understand, is the main reason why I believe that domain knowledge should not necessarily be a prerequisite for a BA when starting a new project.

3. People Person

A BA has to be interested in people, they spend all of their working lives surrounded by them, immersed in their issues, their problems and their needs. The role of the Business Analyst involves documenting their requirements and designing systems that address and alleviate their problems. Without a degree of empathy for and interest in people, it does not seem possible that a BA would be able to do any of these things effectively.

Additionally, the Business Analyst is often the face of change on a project, which is possibly one of scariest things that any of us experience, either in life or in our careers. Change is always frightening to someone. People are always afraid of the unknown, yet it’s the very currency in which a BA trades. It’s therefore important that people trust and like the Business Analyst that they are working with. Change may well be scary, but it’s inevitable, when it’s introduced by someone we like, respect and trust, it becomes easier to accept.

4. Creative

BAs appear to be a very conservative bunch, wearing suits, working for very serious organisations, such as banks and spending most of their days documenting something or other, they don’t at first glance strike you as being very creative. Many believe that it’s the long haired, jeans wearing, young people from the development teams that are the creative types. I don’t want to detract from what they do, but they’re not the only creatives on a development project.

More often than not, despite the conservative image, it’s the BA that will throw out the template in an attempt to present information relevant to a stakeholder in an effective manner. When a project is at a road block, with two or more stakeholders unable to agree on the best way forward, it’s the BA that will put them in a room, propose different ways of working and get their brains working to resolve the issue.

And given the fact that a BA is neither technical nor the business, it’s the BA that has the freedom from the expectation that they are the expert, allowing the BA to claim ignorance and ask the so called “stupid questions”, the seemingly obvious questions, like “Why do you do that?” that once asked, demonstrate a lack of understanding amongst the experts and open up avenues in peoples brains that allows them to re-frame problems and to look at things in different ways.

5. Communicator

A BA must be able to communicate and be clearly understood by their audience. As BAs we derive an awful lot of knowledge on any given project. None of it is worth anything though if it’s not accurately communicated to the people that need the information to complete the project.

A more fundamental communication skill for a BA than simply being able to convey information accurately to others is their ability to listen. Listening is often the most under estimated of all the skills involved in communicating, however, for a BA it’s the most important.

Before a BA can communicate accurately with people, they must first have listened to and understood other stakeholders. A BA cannot explain a requirement to a developer unless they were able to listen to the business convey that requirement in the first place.

A BA should never be afraid to just go quiet in a meeting and listen, it’s surprising what you’ll hear that no one else did.

Well, those are my thoughts on what it takes to make a great Business Analyst, I hope this helps you either in choosing to be become a BA or indeed in choosing your next BA. If you have your own ideas as to what it takes to be an excellent BA, then please feel free to let me know by leaving a comment below.

If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.

“It is not necessary to change. Survival is not mandatory”~ W. Edwards Deming

I’ve discussed in a previous post how it’s the role of the business analyst to seek out and embrace change. However change is often chaotic, expensive and unless you happen to be the stakeholder sponsoring the change, it’s usually about as popular as a tester at a developer’s convention.

As enthusiastic proponents of change, our challenge as Business Analysts is to sell the need for change to sceptical stakeholders and budget holders alike and also to point out when a change is neither desirable nor in the best interests of a project.

Enter then, the humble Change Request, a BA’s most trusted tool in the change process. A tool that allows the Business analyst to detail what the specific business problem is that caused the need for a change, what can be done to resolve the business problem and what impact those changes will have on a business or project.

This post delves into the change request itself and describes what a Business Analyst should include in their change request to ensure that key stakeholders are in a position to decide if change is really necessary and if so, how should the change be implemented.

1. Why Change?

When creating a Change Request, the first question that we, as Business Analysts, have to answer is, ‘Why is there a need for change?’. Business Analysts are keen on change, it’s what keeps us employed, but change is difficult so a Change Request needs to establish very quickly that a change is really required. Try to answer the following questions when describing the need for a change:

- Who is the Sponsor?: The very first question to answer in a Change Request (CR) is, ‘who is sponsoring the Change Request?’. A CR needs to be raised by the right person, a key user is unlikely to get much buy in for changing business requirements, but may justifiably want to change the layout of the user interface for instance.

- What is the problem?: What problem will any change actually solve? Are there new regulations that change the nature of the project does functionality not work quite as anticipated. Whatever the problem, describing it in detail will allow stakeholders to decide if it’s a problem worth solving.

- Can you Justify the Change?: Can you explain why this problem should be fixed? What benefits will it deliver to the project or business? If you were a stakeholder, would you consider fixing this problem a change worth making?

2. Identifying Solutions

The next step in completing a Change Request is to work out how to fix the problem. A required change with no clear solution or next step can often lead to paralysis on a project, so it’s the role of the BA to offer solutions and possible ways for the project to move forward. The following points describe the things you need to pay attention to when identifying solutions:

- List Multiple Options: Always try to include more than one solution for consideration by the responsible stakeholders. Even where no other reasonable option exists, you should always include the option of doing nothing.

- Do Nothing: Doing nothing is often the least expensive approach to any change and should always be an option for discussion. This challenges stakeholders to consider if a project really needs to go through the pain and expense of implementing a change.

- Articulate the Solution Clearly: Treat the solution like you would a requirement, clearly state what each solution will entail in an articulate and unambiguous way. The change board responsible for picking a solution must have a common understanding of what a change entails, in the same way as they would need a common understanding of a business requirement.

3. Analysing the Impact

Each solution identified by the Business Analyst should include an impact analysis. This analysis should help the stakeholders to identify the solution that has the most positive impact on their business or project. Listed below are the areas that the BA should cover in their analysis:

- Tasks & Milestones: Identify the steps required to implement a solution, even if this can only be done at a high level. This has two benefits, firstly, detailing each task will allow reviewers to understand the solution and make a more informed decisions as to whether or not it is possible to implement. Secondly, by identifying the activities required, the BA has begun the process of re-planning that will have to take place once a solution has been selected for implementation.

- Costs, Time & Resources: Estimate the time that a solution will take to implement, the resources required and most importantly the costs involved. These are the key indicators that any stakeholder will look for when making a decision. Don’t forget to specify what types of resources (testers, developers, etc) will be needed, not just the total amount of people. Also, be clear about whether or not you are specifying actual time taken or the duration of time required.

- SWOT: Complete a SWOT analysis. This will allow you to highlight other points of interest to stakeholders about a solution that may not be immediately clear by simply looking at the cost involved. Regardless of the cost of a solution you should document clear pros and cons for each solution as well as any opportunities that may present themselves

- Quality: Finally, be clear how stakeholders will know that they have got what they paid for. State clearly how a solution will be tested, if it will need business acceptance testing or will technology sign off be enough to push any implementation live.

4. Selecting an Option

Even when we get a say in the option selection, it’s unusual for Business Analysts to actually select the final option to be implemented. What we can do though is present the options to the key decision makers and make our recommendations based on what we’ve learned.

- Identify Key Decision Makers: Assuming that your project doesn’t already have a change review board in place that will take decisions on all changes, then you’ll need to identify who can sign off on and agree to implement a change. All of the important stakeholders, including IT, business and users, should be represented on the Board. The main stakeholder, typically the one that owns the budget, should chair the board and have the deciding input into the eventual solution selection.

- Recommended Solution: After completing the Change Request, conducting the analysis and considering their understanding of the requirements, you are well placed to recommend a solution for the change board to consider. Make sure that your justification stands up to close scrutiny and be prepared to present your recommended solution to the Change Board.

5. Implementing Change

As with any implementation, once a change has been selected by the Change Board, it’s your role as the Business Analyst to ensure that what is required by the business is actually delivered. Tracking changes associated with a Change Request can be a challenge, so here are a few points to keep in mind.

- Store Change Requests: Keep the Change Request, along with a record of which solution was chosen, under lock and key. This document is your proof to show that a change has been requested and has been approved by the proper authority.

- Conduct Further Analysis: You may have had to put a change request through quickly or sketched out the exact steps that need to occur which require a lot more detail to be added before they can be implemented. Now is the time to do that analysis. Get back into the requirements gathering mentality and ensure that you understand exactly what the business want and why.

- Update your Documents: This is always a big step for me. You are about the change signed off documents, so make sure you update the document versions allowing you to track how requirements have changed over time. Include the CR itself as a new appendix in any documents that change. Also, go to the trouble of getting sign off for any changes that you make to your documents, your business will be reluctant to go through this process again, but in terms of ensuring clarity it’s vital.

One thing is for sure, embracing change can create a lot of work. Creating a Change Request with the right information will help make sure that the right change happens for the right reasons.

If you have any of your own tips on how to create a Change Request, then please feel free to let me know by leaving a comment below. If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed?

“Deficient requirements are the single biggest cause of software project failure.”

(Hofmann and Lehner, 2001)

We’ve probably all been on a project where the requirements have been deficient or where the business has articulated a solution instead of a need. As an example, a requirement that I’ve often heard articulated on projects in the past has been; “The solution must be delivered via the Intranet”. This appears to the business to be a very clear requirement and, if left unchecked, it’s what the development team will eventually deliver.

However, is it what the business actually needs? Why did they request a web site? Did they want to avoid the need to install software on client machines or was it to reduce the processing that has to be done on the end user’s laptops. If so the project will either fail or become much more expensive if all the computers in an organisation need to have the flash player installed for the Intranet site to run or if all the processing is done on the client machine to reduce the stress on the web server.

Projects with requirements that are clearly deficient, such as the one above, are doomed to failure as Hofmann and Lehner stated, so it’s important that the person gathering the requirements, the Business Analyst, ensures that they are accurate and clearly articulate a business need. The following five tips cover areas where requirements usually fail and offer advice on how you might improve your requirements:

1. Improve the Clarity of your Requirements

Defining requirements is a tricky business. In my experience the business owner will either not read them or go through them word by word looking for ambiguous requirements, hoping that they will give them a get-out clause or room to negotiate change at a later stage of the project.

I also find that when a development team are faced with a half decent set of requirements, they will instill a lot of faith in those requirements and interpret them very literally. It’s only later when issues arise that they will look for ambiguity in the requirements.

Employing the following tactics should help improve the clarity of your requirements:

- Read your requirements out loud. This will highlight where grammar needs to be improved and will make you think about what a requirement really means.

- Use fewer words. When writing a requirement, I try to use as few words as possible. A blank piece of paper cannot be misinterpreted is my motto when writing requirements.

- Avoid big words. Your parents may have spent a fortune on your education and I could have typed polysyllabic words instead of big, but you should avoid assuming anything about your intended audience, go for plain language that is easy to understand without a dictionary or being a native English speaker. Also, avoid technical language unless you include a glossary. In the world of requirements, big beats polysyllabic, simple beats complicated and short beats long by a country mile!

2. Ensure your Requirements are Complete

An incredibly expensive mistake to make when creating requirements is to overlook one. Discovering at the last possible minute that you need to include a brand new requirement will be expensive, painful and damaging to your reputation. Employ the following strategies to help avoid this potentially disastrous error:

- Correctly identify your Stakeholders. At the beginning of any project, draw up a list of potential stakeholders in your project, talk to everyone on that list and ask each one of them not only if they should be on the list, but who else they believe should be on the list. When you think that you have a final list, be sure to review it one last time with the same attention to detail that you would a set of requirements. Finally, once you believe that you have identified all stakeholders, don’t forget to talk to them and get their input into the requirements.

- Review, review and review again. The requirements gathering phase of a project is often the most time constrained part of any project. A well run analysis phase may well save big money on any project, but it is often difficult to sell the benefits of this phase, especially where a project is IT led. Whatever the pressures though, don’t compromise on the number of reviews. Get your first draft out early, no matter how bad and make sure that you go through at least three iterations before the final review. Set expectations early about how long this process will take, see point 5 for details!

3. Avoid Stating Solutions

“I want a web site” is not a requirement, it’s a solution. Defining a query that will generate results for a report, is not requirements gathering, it’s solution definition. The development team will rave about ‘requirements’ like these. They are easy to deliver and don’t require much thought at all. As a Business Analyst, you should be wary of these kinds of requirements as they narrow your focus and prevent you from defining the best solution to resolve the business need. Next time your confronted with a solution instead of a requirement, try the following:

- Why, what, when, how? When faced with a solution, don’t give up, be persistent, keep asking why?, what?, when?. You’ll know when you finally hit the requirement when the stakeholder states either a problem or a genuine need that a solution that you can design will address.

4. Don’t take Knowledge for Granted

A Business Analyst is often at their most effective when they have little or no domain knowledge. This lack of knowledge will force the you to ensure that you have correctly understood how a business works and will help you to document requirements in a way that will be understandable to the technical teams that may also have very little domain knowledge.

Over time in a particular area you will inevitably pick up a lot of domain knowledge, so it’s important that you keep in mind that not all of the people that will use your requirements document will have the same knowledge as you, or your business. Once you find that you can talk fluently and knowledgeably about a business, try to employ the following tips to ensure that you are still communicating at an appropriate level:

- Add a glossary to your requirements. And make sure that your stakeholders review it. In this way, you can ensure that you have correctly documented any jargon that is used within a domain in a way that will be understandable to any audience.

- Review early with the test team. Get the test team or test manager to review your requirements at the earliest opportunity. They will not only have to test your requirements later, but the very literal way in which they think will help you to identify where you have made assumptions about the knowledge of non-business stakeholders.

5. Plan the Requirements Gathering Phase

Every Business Analyst has felt the pressure to complete the requirements gathering and analysis phase in the shortest time possible. This pressure, whilst understandable, risks forcing the BA to take short cuts in the process. Reduce the pressure on yourself and the project by following these steps:

- Create a plan. Create a plan for the requirements phase showing at least the following; when you will reach each milestone, when the first workshop is, when each review is scheduled for and when the final draft will be delivered. This will set expectations amongst all stakeholders and gives them no excuses for not clearing their diaries.

- Book the appointments now. You’ve devised an aggressive plan that conforms to the time-lines that you’ve been given, so now book each of the meetings as per the plan. Don’t let diary conflicts nearer to the actual dates derail you.

- Keep an issues log. Every open question, every missed attendance at a review, every action taken. Make sure you log all issues, who owns them, when they were opened and when they need to be closed by. Use the issues list to hold your stakeholders to account, don’t let their lack of commitment be the reason why the requirements phase gets squeezed. Flag all issues and their potential impact to any stakeholder with responsibility for delivery.

- Set expectations. You’ve created your plan and booked the meetings, now don’t let things slip. Keep track of your deliverables and notify the project manager and relevant stakeholders as soon as you believe that you may miss a deadline. Use your issue log to help you get the support you need in getting things back on track and to explain any slippage.

If you have any of your own tips on how to improve requirements, then please feel free to let me know by leaving a comment below. If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.