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.

words

The business analyst's world is about words. Words make up the requirements. Words occupy interviews and meetings to obtain information. The information itself is usually words, occasionally interspersed with pictures or diagrams. Much of our analysis is done by analyzing words. Words are variable and ambiguous and vague and many times describe the wrong things. They even lie. They are, however, what we have. We tried pictures once, and discovered that drawing pictures, while less ambiguous, was also much less efficient as a means to communicate.
With all this emphasis on words, and the corresponding frameworks of grammar, punctuation, oration, and exposition, is it any wonder that technologists trained in the black and white world of bits and bytes have difficulty navigating the verbal ocean? Technologists want clear, unambiguous, concise expressions of solutions, wants, needs, and the like so they can convert the words into software and applications. In the role of translator, that's what the business analyst does: play word games of reduction, precision, and exactitude. The business analyst takes a vague notion of a barely conceived idea and turns it into a model and a plan that will eventually become a best selling web site or an innovative medical device that saves lives. It's all in the words.

The Business Analyst as Innovator

One of the agile precepts is the build it as you go approach. Regardless of the size of the final deliverable, the product is created and delivered in small releases, each release adding some value for the customer or product owner in an iterative process. The decision of what should be developed each release is done by listing all the features and functions a customer wants and then carving out those features the solution team can implement in the next iteration.
There is an underlying assumption here which is rarely true: all the innovation and capture of new ideas for the product has already been done before the implementation effort takes place. I'm wondering where that innovation took place and who did it? The solution team innovates, but the team innovates in terms of software development process improvement (a standard mandatory element of the Scrum process, for example) and technology. But who is providing the business innovation: the new product that will eclipse the competition, the variation in service offerings that will increase the efficiency of business service delivery, the internal improvement invention that will reduce the overall cost of doing business?
While agile does not address this issue with its focus on development of working software, someone needs to do it. The product owner is focused on getting the defined features implemented to solve the immediate business problem and then getting back to work. Who addresses innovation? The business analyst. The very role the agilists have claimed should be removed from the agile equation.
Perhaps it is a better and more valuable role for the business analyst in the overall organization to be focused on innovative ways of improving the businesses processes thus directly returning value to the bottom line. A higher calling, perhaps. So when the business analyst role is summarily excised from the agile development cast of characters and product owner is not an option and scrum master doesn't seem to fit, perhaps Corporate Innovator or Business Process Improver might be the role to pursue.