Reacting to Complaints

Sometimes we have a situation where a particular stakeholder, maybe a manager or a client or customer which makes the issue more difficult, is a complainer. They complain about everything all the time. Some people are simply like that. And we allow for that and tolerated for humor the manager was doing that. But sometimes the complaining gets in the way. When you have a meeting and the first 20 minutes of that hour-long meeting I spent listening to complaints and the last 20 minutes are spent listening to complaints then you were losing quite a bit of time and that is quite a bit of productivity and money. So the question is what can you do about the manager or anyone for that matter who spends an inordinate amount of time complaining?

A complaint always reflects an unmet expectation. Someone expect something to happen and it does not happen, or expect that it shouldn’t happen and it does.

An unmet expectation is a problem. Using Jerry Weinberg’s definition of a problem: “the difference between the way things are and someone’s perception of the way things should be” we can see that an expectation is someone’s perception of the way things should be and that does not match the way things are.

So when a complaint occurs it is a signal, a trigger, to begin a problem solving process.

bsuiness analyst and domain knowledge

A recent posting came out in favor of the business analyst possessing significant domain knowledge in order to be successful. I don't know if I agree with this. 

Ostensibly a business analyst should not need domain specific knowledge to be a top BA.  What the BA needs is the ability to communicate well in all media to all receivers, and the ability to analyze and think critically: to question and consider.  These traits are hard to learn if you don't come by them naturally, but they can be learned. Domain specific knowledge is easy to learn.

Agile or non-agile BA?

When you consider it, if as a business analyst you focus on identifying and solving the real business problem, it doesn't matter whether you are working in an agile or non-agile environment.

Expansion of business analysis scope

The activities that absorb the attention of the business analyst seem to go in cycles. Sometimes the business analyst is involved with more technically oriented work and other times the business analyst is more strategically involved with business planning. Much of course depends on the events and circumstances of the times. Right now there seems to be a significant emphasis on security, especially business and information security and disaster recovery and business continuity.

Granted the experienced business analyst should be able to pick up any business area in a short amount of time applying his or her skills and abilities as communicators and analyzers which equate to fast learning. But the areas of business continuity, disaster recovery, and information security, even when not talking about the technical aspects, are not necessarily what might be considered business lines.

Perhaps there will be business analysts who specialize in the business aspects of disaster recovery and business continuity. Unfortunately these areas are not full-time long-term jobs because once the business continuance and disaster recovery plans are created they are turned over to the people who will test them and then in the unfortunate event that they may be needed, to execute them.

Business security should be a constant and ongoing concern of the business analyst, but seems to only draw the attention of the business in general and the business analyst in particular when there has already been a security breach. Prior to that most businesses, and unfortunately business analyst as well, seem to have either an “it won’t happen here” or “it’s somebody else’s job” attitude.  Each of us as business analyst has to be aware of the risks and potential for security breaches from all sorts of threats and attackers.

Business Analysis Predictions

I was talking to a group at a meeting the other day and they asked me what prediction I would make for business analysis over the next few years.  I have made predictions in the past, but cannot remember what they were or whether they came to pass. So take it for what it’s worth, here is what I said:

Executives will still look for the silver bullet and quick fix especially where people can be removed from the product development equation. At the same time analyzing the business (marketplace, product mix, competition, business structure, root cause analysis of business problems, business capabilities, business capacity, etc.)  will become increasingly important as a factor of business success. Business analysts will move away from IT and requirements orientation and take a more strategic position analyzing the business to uncover problems, weaknesses, vulnerabilities and opportunities which will then be passed to Agile teams to solve or implement. Business analysts who are requirements documenters only will find their jobs dwindling while those business analysts who focus on solving business problems will flourish.

The agile coaching contradiction

Agile teams are supposed to be self organizing. And yet when teams have trouble organizing, the common solution is to bring in an agile coach. But the agile coach is not on the team. If the agile coach provides the motivation or approach to organization, or organizes the team him or herself than the team did not self organize. If all teams, according to agile, are supposed to be able to self organize, what does it mean when a team can self organize? In the agile philosophy if a team does not self organize do you disband the team and try again? Or do you assume that that show this work?

Defining Goals

The business analyst is often associated with goal making, the definition of a goal. While the project manager is the role primarily responsible for the goal of the project, the business analyst is the one who defines the goal of the product, what does the organization intend for the product to do for it. Is the goal of a new product to increase revenue, stay competitive, move into new markets, complete a product line?

Clearly the goal associated with solving the particular business problem has a great effect on how the project is done and how success is determined.

To assist the organization in defining an achievable goal business analyst needs to understand what a goal is.

A goal according to the dictionary: "the result or achievement toward which effort is directed; aim; end."  Being the result, it must state something to be achieved. However, saying "our goal is greater safety for our workers (using Georgy's last item)" does not help us.  How high? Will one defect less than before be considered 'higher quality'? It satisfies the goal. 

So we need to apply a measure to the goal for it to have meaning: "Our goal is to have ten percent fewer worker injuries."  The goal now has more meaning in terms of achievability, but the results are still questionable. Ten percent fewer injuries over the next day? the next month? the next century? 

For the goal to be effective - and what is the purpose of stating a goal if we don't care whether it achieves the results? - we need a time frame for achievement. "Our goal is to have ten percent fewer worker injuries this fiscal year than last fiscal year." 

Three elements of a functional goal (functional means the results are achieved and not just stated): a statement of achievability, a measurement that prove it has been achieved, and a time frame by which it should be achieved. Then we can state the goal (what results we expect) and achieve those results - and most importantly for everyone, know that we have done so.