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.

The slash - working as one

One of the bigger issues in the world of business analysis nowadays is the wearing of multiple hats. The business analyst is asked to prepare a business case for a project and then when the business case is approved is asked to take over as project manager, and, incidentally, also perform the expected business analyst duties. Coming from the other direction, the project manager is assigned a project team without a business analyst and told to take care of the requirements as part of the project manager job. I call people in these situations, "slashes", as in "Business analyst / project manager".
Why does this happen? Mostly belt tightening. Organizations have to cut corners and save expenses so they combine roles. And on smaller projects this might work fairly well depending on the business analyst or project manager who is awarded the "slash". However, any project of depth, complexity, length, size, or visibility is going to be in grave danger of failure with one person trying to do both roles. The danger specifically to the business analyst is that ALL the responsibility for the project will end up on the "slash's" shoulders. There is no one else. One hopes that the combination of the roles is not simply a ruse to gain someone at which to point fingers.
In upcoming blogs I'll talk about the issue of the "slash" and how you can handle the situation, short of dusting off the resume, and turn it into a break even if not an outright success.

Business analyst: Best Practices for Success

It looks like the book is finally a reality. We're in Buffalo, NY, on a trip that included a few days in Syracuse earlier in the week, and now on our way back home. There we will get our first look at the actual book which arrived while we were gone. The book hits the book stores on November 8, but can be ordered now.
I'm popping over to the other side of Florida on Tuesday for the BBC conference in Fort Lauderdale. It's my first conference of this nature and apparently won't be my last. Hopefully I'll see some of you there.
So I'm celebrating the book's release by starting the new book which is going to deal with being an agile business analyst at the center of the organization.

Gathering or eliciting requirements

If you gather requirements, you are assuming the business people or users know what the requirements are and can give them to you - that is, they can express the requirements for their system or enhancement clearly and concisely. Gathering implies that something is already there to gather. It is a rare circumstance when the users or stakeholders or anyone in the business has a clear understanding of the detailed requirements that will solve their problem. It's hard enough to find business people who can even state their problem concisely and clearly.
Eliciting is gathering information with understanding. The business analyst asks questions and more questions and analyzes the information gathered to produce the requirements - what is necessary to solve the problem. Investigation might be a better word for what business analysts do.
You gather apples or wheat.
You elicit information which you then analyze into requirements. That is the business analyst's forte. We are after all, analysts, not gatherers.

Salute and March

"Salute and march". This is a somewhat pejorative term, even in the military from whence it originates. While on the positive side it may imply unwavering devotion to a leader and unquestioning faith in the leader's sense of direction, the phrase has come to mean failure to think for oneself and simply following orders to stay out of trouble. The epitome of this behavior was in Paris Island in the 60s when a Drill Instructor marched his troops at night into a swamp where two recruits died. Marine Corps policy was changed after that.
"Salute and march" is the negative side of being overly polite and meek. (Excessive politeness that is not assertive leads to meekness in perception if not in actuality.) Unfortunately, much of the business, especially marketing and mid-level management, who may be more concerned with their own image, career path, and reputation, expect business analysts to accept their solution and make it happen without a need to expose the business analyst to the real business problem and let the business analyst do their job (for example coming up with a better solution). The business analyst in turn faced with a senior officer in the company (someone in other words outranking them) will "follow orders" and go get the requirements. The business analyst will do so politely and conscientiously. It all works out as long as the solution implemented is in fact the best solution. When it isn't as so often happens the business manager blames the business analyst (and therefore so does everyone else). The business analyst may be perceived as being "meek" for simply following orders.
When the business analyst fails to do their job of communicating and analyzing because they are afraid of hurting someone's feelings, being impolite, crossing swords with higher authority, or they are simply afraid for their jobs, the business analyst is not doing their job. (Of course there could be other psychology at play as well. For example, some good old passive aggressive stuff: "We'll just do it their way and when it fails then they'll see how good my solution was and they'll be sorry!")
The business analyst always has the right to ask questions and more questions. The business analyst always has the right to ask what the real problem is behind any proffered solution. The business analyst has the right to challenge a solution that is flawed or doesn't go to solving the problem. And this can be done quite politely. I submit that failing to do this when the circumstances call for it might well be considered weak, ineffectual or simply "salute and march". While this may win points with the business manager who gets his or her way without challenge, it certainly is not the best for the overall organization or for the business analyst's peace of mind.