Are you qualified to do business analysis?

In a recent discussion I was asked if there are a set of competencies, other than a certification, that could define a business analyst. Is there a list of characteristics that will indicate whether a person will make a good business analyst or not? Here is the paraphrase of my answer: For one thing, many of the competencies, such as ability to communicate in both written and verbal formats, do not have finite measurements. Some people communicate better than others and some communicate well in writing, but not verbally. All might be good business analysts, and all might not. I think a list of competencies (abilities, traits, talents, etc.) that a person typically needs to possess to be successful at business analysis would provide a good guideline for all those interested in performing as a business analyst. If a person is honest about their own competencies - where they are above average in performance and where their ability or knowledge is lacking - the person can seek improvement in that area. And that is a good thing. In the end, if you took the winner of the Nobel Prize in Business Analysis and sat them next to an average workaday business analyst, you might not be able to distinguish between them based on a competency list. In fact, the Business Analyst of the Year may not be able to pinpoint what he or she does differently than the average business analyst. The competencies, such as communication, inquisitiveness, empathy, analytical abilities such as critical thinking, visualization, curiosity, system thinking, networking, influence skills, negotiation and mediation skills, and so forth, have become so habitual and part of the prize-winning business analyst that he or she would not be able to describe them. The list of competencies should not be used to distinguish a person as a business analyst or to qualify a person's ability as a business analyst, but to provide a guideline for those in the profession and those who would join the profession as to what they have to work on, to hone, to improve, so that the competencies become inherent, habitual and automatic.

The business analyst and ITIL production requirements

I spend a few weeks in London in September and October capping a year long project that involved both analysts and production and operations managers. I had assumed over the years that the physical move into production was a project manager's responsibility. The PM was the one working with the production people to ensure a smooth transition into production, usually while the developers, business analysts, QA and users are completing the acceptance testing and getting final sign off of the product. In this particular company which follows ITIL it turns out that there are a number of standard procedures (which I helped initiate many years ago and are now refined into smoothly running processes) that are more business-related than project related. As we worked on various projects and processes I began to realize that the business analyst can actually do a lot during the project to make the transition easier for production. I talk a lot about the business analyst making the transition easier for the users, which does not go away, but there are also tasks the business analyst can do to ease the flow of the application into operations. It turns out that the overall business requirements do not only come from the users and business stakeholders. It is not enough to just make sure the problem is solved and the requirements are met. It’s not enough for a business analyst to ensure the described well enough for the developers to build. The business analyst also needs to work with the production people to make sure that the application moves smoothly into operations. There are requirements from production, for example ITIL standards to meet, that have to be defined as well. While these are not necessarily business requirements, they do affect the business in that they affect the ultimate delivery and use of the application in the operational environment. Since the business analyst is responsible for solving the business problem, the business analyst should be aware of requirements for that solution to go live. The guiding principle is always: if the users (customers, stakeholders) are not using the solution to solve the problem, the problem is still not solved.

Some thoughts on BA goals

I just received a series of questions from a number of different beginning business analysts. I thought it would be good to share some of their concerns and my responses to them. Feel free to send along your questions. I enjoy responding and helping out. One new business analyst / project manager is required by his company to establish goals for himself and his project and he sent along his goals to see what I thought of them. The first several related to the project itself and were more in the line of a series of goals that, when achieved, would get the project in a good standing. The last one stated: • Use critical thinking skills to gather information and negotiate with sponsoring unit This goal came from some previous correspondence in which I recommended enhancing his critical thinking capabilities to be more successful as a BA. (More on that in a future blog). Here is my response: "This statement is good and in alignment with general business analysis tenets and good practices. However, it states a continuing effort rather than something to be achieved. For example you might write the following goals: "1. Gather enough information from the sponsoring units to make good project decisions "2. Negotiate with sponsoring units (instead of automatically agreeing to specifications of time or resources) Now your plan to achieve these two goals might include "Ask at least three questions for each directive the sponsoring unit gives me. "Suggest at least one alternative approach or solution to each directive the sponsoring unit gives me. "This exercise forces you to think critically about all your interactions with the sponsoring unit. You may decide on a political basis not to actually voice the question or alternative solutions. However, even if you do the exercise on your own back in your office, you will be building your critical thinking powers so that the questions will begin to come naturally to you." It is not enough just to have goals. Once you establish the goals you need to devise a plan for achieving them. That plan could be a simple improvement or change in the way you are doing things that gets you closer to the goal as I suggested above. or it could be a step by step approach to achieving the goal. Either way, without a plan to achieve the goal, the goal sits like a target in a shooting gallery and you do not have a weapon.

Box checking

Box Checking Processes don’t have a good name, except with management. Management likes processes because they are easily controlled and managed. You can see the numbers. You can see where things are as opposed to where they should be. You know these things because there are reports that tell you. And many of these reports and activities have no other purpose than to provide management with the numbers and evidence that the process is working as defined. I had a job recently which required me to duplicate work in various ways. It was a contract and I was paid for my work, but it seemed terribly redundant and, well, silly, to keep putting the same information into different formats. When I asked my contact about the demands for the reports and numbers, he said he didn’t know why they were required. “Management needs them to check the box”. The implication of that statement, which for some reason of serendipity I have heard over again the past year, is terrifying. Management is not reading, assimilating, monitoring or actually doing anything with the information. They are just making sure it got delivered so that they can be sure the process is proceeding according to plan. There is a certain amount of reason in keeping TODO lists to make sure that everything is done and nothing forgotten, and to check off the items as they are done. But with a TODO list the items serve a purpose when they are done: you have bought the milk, bread, and eggs; you have washed the car, mowed the lawn and taken out the trash. When the items on the TODO lists that make up processes have no meaning or use in the current process then it does not make sense. Many of those items, like reports, sign offs and verifications are left overs from previous manual or early automated processes where such checks were necessary. Some are left over from the early stages of a process when activities were tried, determined to have no value, but left in anyway. So the additional reports that have the same information in a different format are costing the company money. So, I violated protocol, my own included, and in a meeting asked the senior manager who was requesting the reports if it were necessary to prepare the information a third time in a different way. He stammered a bit (he actually stammered) and then said “I don’t want you putting in extra work if the information is already available.” He asked one of his direct reports, Tom, if the information were available in a form they could use. Tom told him that he currently had the information and was using it and would not use any new version of the information. The senior manager rescinded the request for the new report. Sometimes it only takes asking why the information is needed, what is it used for. If the answer is to ‘check a box’ then you may be performing a useless activity and no one has realized it yet. If you are not worried politically you may challenge the work you have been asked to do. And you should if you feel the work is not adding value to the project, the organization or your job. You have that right.

Resume Tips

In a bit of a departure from the normal comments on the philosophy and essence of business analysis, I thought I would respond to a number of requests I have gotten recently about how to get a job as a business analyst. Mostly the requests have centered around resumes and what they should contain. Now I am not an expert, but I have been around a long time and I have written many resumes for myself and others (when bidding on consulting work years ago). I have also read hundreds of resumes for the purpose of hiring. So what I have to say is based on that experience and nothing more. Basically when you write a resume it has to sell you. It is a sales document, and you are the item for sale. Each point on the resume should answer the question: why should I hire this person. The sales begins with the Summary which all the experts tell you to place at the top of the resume. The concept of the Summary is to make it easy for the resume reviewer to grasp who you are and make a decision without having to ready the rest of the resume. So in the Summary you want to make statements that grab the reviewer’s attention right away. Don’t just list the companies you have worked with. Make statements about why you are special. These are called “discriminators” and state what makes you different from everyone else. For example. While I don’t send my resume out much anymore, I do keep it current and the Summary references the fact that I have written a book on business analysis among other accomplishments. The idea is to get the reviewer interested enough to read the full resume. After the Summary, state any other important pieces of information about you, for example, degrees, professional certifications, other education and training, and the like should be first. Tie the Summary to this list, for example, if you got an award, state the reason for the reward in the Summary. If I put these items at the end of your resume, the reviewer might never get there. The rest or your resume which states your experience is not simply a laundry list of what you have done in your work life in chronological order. The most important things you have done for your previous employers and the highlights of your career should be first, regardless of when in your life they occurred. This means for the typical job applicant that the first items might well be the most current because we keep getting better and doing better things as we get older and wiser and gain experience and responsibility. In addition the most current accomplishments and activities are probably those most pertinent to the position you want. I don’t see any reason for including dates or even company names in this section. Just a sentence or two about each accomplishment. I managed a project which replaced the company’s insurance processing software bringing the project in under budget and ahead of schedule saving the company $250000 a year. While investigating the inventory control process at a large manufacturing company I devised a new method for increasing the speed of inventory turn and reducing waste. The method was adopted by all the manufacturing centers in the global organization. I managed a 3.5 million dollar program for a US Federal Agency, managing 105 direct reports over a four year period. And so forth The list of positions you have can be listed with the company name (if you wish) in reverse chronological order after you have told them what you have done and what you can do. That is what is interesting and appealing to a resume reviewer, not what company you have worked for. The reviewer can relate the company names to the accomplishments, and if not they may be interested enough to call you in for an interview. If that happens your resume was successful. The purpose of the resume is to get you an interview. Write the resume as though the reader won't get past the first paragraph, so you have to grab his or her attention right away. Tell them why they should read further. Tell them why they should be interest in your rather than anyone else. Make them wonder what else you can do. Make them start asking themselves questions about you and they will want you in for an interview. Remember, a resume alone never got anyone hired, but it is necessary to get you in for the interview. And getting you to the interview is the purpose of the resume.

Words

I have been working on the Business Glossary for the Third edition of the Business Analysis Body of Knowledge for the IIBA. I am finding interesting the variances in terminology for what are considered to be simple and common terms even among the standards organizations. If they cannot agree on simple definitions of our terms, how can the average business analyst? And how much more difficult is it when talking to business stakeholders?
The lesson here is clear: we cannot assume a common understanding of business terms. The terms vary from organization to organization and even from department to department within the same organization.
This is where listening naively comes into play. Ask the questions and have people explain it to you like you are new to the organization. Just to be sure. Just to be clear. Just to be unambiguous. Better to get the "I am humoring you" stare now than the "You misunderstood what I asked for' complaint when the solution is delivered.

How to Handle Being a Slash Part 2

We addressed some actions you can take when you are both project manager and business analyst in the last couple of blogs, now let’s talk about attitude.

One of the problems with being both a business analyst and a project manager or even a business analyst and a system analyst or maybe all three is that the tasks and activities are basically the same. Both roles define problems, communicate with all levels of the organization, define solutions, define requirements, assess risk, perform stakeholder analysis, define and maintain scope, handle changes, plan, manage expectations, and so forth. The difference is in focus.

The business analyst focuses on all things pertaining to the business or the product (the result of the project). The project manager focuses on all things pertaining to the project. In other words, while the project manager identifies and assesses project risk, the business analyst identifies and assesses product or business risk. The project manager defines problems in the execution of the project. The business analyst defines problems in the business. And so forth. To the degree that you can retain and not confuse your focuses will be the degree of success you achieve as a slash.

Keep in mind a couple of tenets. The project manager has authority; the business analyst does not. This means that when you make pronouncements about the project make sure you are not doing it while performing the business analyst role. To retain as much of the checks and balances that are built in when there are two people playing the roles, keep your focus as business analyst away from the project. For the most part, the business analyst should not be concerned with deadline or budget. The business analyst is focused on delivering the solution to the business problem. The project manager however is very much concerned with the project deadline and budget.

The project manager will resist any changes that will impact those constraints while the business analyst should resist any attempts to reduce scope to fit the constraints where the reduction causes the problem not to be solved completely. This is a healthy relationship, as long as it remains professional. As a slash, you may have to argue with yourself about these issues. But that should be all right in today’s environment since most people will assume you are talking on your cell phone.

The tricks discussed in the last blog are techniques to assist you in maintaining separate focuses. There are some other tricks we can talk about in the next edition.

How to handle being a slash part 1

The first thing to do is to separate your roles as much as possible. This can be done physically. For example, put your business analyst materials and files and folders on one side of the desk and the project manager materials and files on the other. Under your project directory separate the emails and other documents into a “business analyst” folder and a “project manager” folder. In other words, do what you need to do to separate the two roles so that you will be able to focus only on one role at a time.
Then you want to make sure all communications are with the appropriate role.
When you start a meeting make sure everyone understands who is moderating the meeting, the business analyst or the project manager. Do not assume that because you have convened a “requirements session” that the participants will understand that you are a business analyst. Make it clear at the risk of sounding redundant. Reminding the participants what your role is will help them focus on you in that role and the meeting will be more productive.
Also when talking one on one, make sure that the person clarifies which role you are expected to be in that conversation. Do not assume, or try to deduce it from the conversation. Ask. You will be surprised if not amazed to find a project manager conversation was really aimed at the business analyst. If you are successfully separating your roles, those conversations will be different, even when the topic is the same.
When you are making pronouncements or tendering opinions, it helps to state where the pronouncement or opinion is coming from. “From the project manager’s perspective, I think…”. This way there is no misunderstanding. Remember that what you say as project manager has the specter of authority behind it while the statements of the business analyst may be accepted as opinion only.

In the next blog we will talk about focus and how that helps the slash to handle both sides.

Understanding the slash

When you are assigned to be a “slash” – a business analyst / project manager – the important thing to remember is the focus. The business analyst has a different focus than the project manager. In most cases the tasks performed are quite similar – both roles communicate; both roles define and solve problems; both roles assess and deal with risk; both roles handle expectations, stakeholders and change requests, and so forth. However the focus of those tasks is different. The business analyst focuses on the business or product aspects of the solution while the project manager focuses on the project aspect solution, how the solution is going to be implemented and delivered. The ‘slash” can be seen as more than simply a convenient grammatical symbol to show the combination of roles. It can be seen as a divider of focus. The question is where that divider falls. When there are two players taking on the roles of business analyst and project manager, the dividing line can be set by mutual agreement and the tasks assigned between them. When there is just you handling both sides, it should be easier to come to an agreement with yourself about which role does what. Unfortunately because the tasks are so similar we tend to blur the division and that is where we run into trouble.
The idea is to separate the two focuses so that we truly focus on only one side of the slash at a time. How do we do that? I’ll have some tips in the next entry.