The leafblower solution

It is autumn and in my part of the world the leaves start falling from the trees, and land on streets, bike lanes, sidewalks, train rails and so forth.

This can be a problem as wet leaves on the sidewalk or bike lane become slippery, and thus become dangerous to pedestrians and bike riders.

The transportation authorities do a great job in trying to keep the sidewalks and bike lanes safe, but I do use the word trying very deliberately here.

Because although their intentions are the best, I am not so sure about at least one of their solution alternatives - the leaf blower.

Now why do I have a problem with leaf blowers? Well they seem very prone to only solve the problem temporarily, at least if they are not put together with appropriate additional equipment.

I watched the following scene the other day:

A worker was using a leaf blower to blow leaves from the bike lane onto the sidewalk, and then from the sidewalk on to a strip of grass running along the sidewalk. It worked as a short term solution, but it does not take a genius to realize that a small change of wind direction or pickup in wind power would push the leaves right back onto the sidewalk.

Now, aside from the point that it of course is a sort of job security for the individual assigned with the task of cleaning the sidewalks and bike lanes, it does seem like a very short sighted solution, which could very likely result in twice as many leaves on the sidewalk the next day.

Now if we transpose the leaf situation to a more generic problem solving situation, there is actually a point here.

When dealing with a problem, there is often a nice quick fix which can push the problem aside, clearing the situation for now. Unfortunately these quick fixed have a habit of coming back to haunt you very quickly and with greater strength. Very much like the leaves in my little case.

The point being, that it is not always the quick fix that works best. Maybe a leaf vacuum cleaner to collect the leaves would be a better and more permanent solution.

And if you do decide to use the quick fix, make sure that you combine it with measures that keeps it as a fix.
In the leaf blower analogy it could be to use the leaf blower to gather the leaves, and then put them in a bin and take them somewhere they do not pose a hazard.

Decision doors - how does your business representative make decisions.

No, I'm not talking about a 60's rock band, who lost their front man way too early, although that might be one of the reasons for their legendary status.

Walking through the hallway of the building complex in which I work, I somehow got annoyed with the automatic doors which has been installed over the last couple of years.

Previously the doors were either manual or semi automatic, meaning you had to press a button to open them.

Many doors in the building complex are now equipped with sensors, so they open automatically. Very convenient in many situations, but in the upgrade process, the opening mechanism has also been made slower.

Previously the door would open at you command, either because you decided how hard to push a manual door, or when you pushed the button, it would open in a "yes sir" fashion. The "yes sir" refers to a swift quick opening, letting you pass through.

Now the door opens in more "let me see.....yes i'll open" way, resulting in, even though it is equipped with a sensor, you have to stop and wait for the door to open.

I don't know if this has been done because someone actually was hit by a fast opening door, but I have never heard of such an accident.

Now, I'm not on a mission with doors to attribute human feelings or decision making to the doors in the building, but they got me thinking about ways to think about decision making and especially how to react on request for decisions. See, now we are getting nearer to the business analysis world. 

Because many might not know the doors in the building complex where i work, I will try to use a couple of more widely known examples from the world of movies. Especially science fiction movies have a thing about doors.

In the Hitchhikers Guide to the Galaxy, the doors in the spaceship were equipped with an especially pleasing sound, letting you know that they were happy to open for you. (Which annoyed Marvin the depressive robot immensely, but that's another story). Now that's the sort of business representative I would like to have as a BA. One who says, we are happy to help you with your decisions or issues.

Another great example is the Star Wars movies, where buildings and spaceships have many creative door solutions. Some of the them seems rather over-the-top and elaborate. This is not what I want from my business representative, I need them to help me make a decision, not to design an elaborate decisions process involving to many stakeholders. It might look fancy, but takes forever.

My favorite example from Star Wars is a door when Luke Skywalker and Han Solo enters cloud city (In the Empire Strikes Back) there is a control room, where the door opens and closes almost instantly. Now thats the kind of business representative I would like, especially in a case with a tight schedule. A "I'll get right on it" attitude.

I'll leave it up to the reader to interpret what the many blast doors in Star Wars would relate to in a business representative.

I'm sure that there are many other examples out there of good and not so good doors.

I guess the morale here is to make sure that you observe how your business representative or other decision making partner, is going about the way of getting the decisions made. And if it is not going as you would like, be sure to talk to them about your expectations.

Now, I'll go and see if a can tweak the opening mechanism a bit...

Oh, by the way. If you're interested in more about doors and their apparent human like characteristics, I can highly recommend reading Bruno Latour - Where are the Missing Masses? Sociology of a Door

Seeing through the right pair of goggles...

First of all, Happy New Year!

Ok, I have decided to stop making excuses for not updating the blog as often as I had set out to do, so without further comments, here's a new post:

One of my hobbies, some might call it an obsession, but I don't think I'm quite there...yet anyway, is alpine skiing. Since I have been skiing for many years I prefer more challenging ski runs, either because they are steep or because they are off-piste or not prepared.

When you start skiing at higher speeds and in more difficult terrain, the more dependent you become on your equipment. Many focus on skis, boots and clothing, but a more overlooked aspect of the equipment is the ski goggles.

As long as you ski good conditions in good weather you can get away with a lot in the world of goggles, but when the weather turns worse and the runs turn more difficult, you become very dependent on what you can see, in order to react in time.

Thus you have to be careful with which pair of goggles you wear or what lens you fit your goggles with that particular day. Wearing a lens suited for good weather on a foggy or snowy days, means that you loose contrast, and are not able to see changes in the slope and in worst case obstacles, as they are white when covered with snow.

The solution is however not wearing a bad weather lens all the time, as wearing one i bright sunlight will blind you, and you are not able to see any contrast because everything is just white.

You can wear an intermediate lens, but it only does both things half way, but on an cloudy day with spots of sunshine, it's the preferred choice.

Now why all this talk of ski goggles...

Well, in the world of business analysis we also have to choose the goggles with which we see the world, out goggles in this case being the models and analysis methods we choose to use to understand our problem area.

Like ski goggles each model has it's strengths and weaknesses compared to what you wish to achieve.

Some models look at the big picture, like the business context of a project, but fail to shed any light on the more detailed specifics of the problem area. You can compare this to the good weather lens, which provides you with good (in)sight when the world is clearly illuminated, but fails when things get more muddy and you start to look for the details.

Other models look very much in detail on one or more specific areas. You can compare this to the bad weather lens. You are able to see details in a confined area of the world, but if you try to use them to look out at the world, when the sun comes out, you will get blinded by the level of detail.

Some models are equivalent to the intermediate lens, e.g. SWOT or Porters five forces. They are a good starting point, but they do not provide all the answers, and depending on what you are looking for, you probably have to change lenses during the day.

My point here is that we as business analysts need to be aware of which pair of goggles we put on. Are we in the bad weather looking for details or are we out in the sunshine, looking for the big lines?

The ability to make the right choice is highly dependent on experience. Do you know the area you are skiing in? Have you been there before? what does the weather look like? If you don't know, it is always a good idea to ask the locals...

Choose your goggles wisely, and if possible have a backup pair in the backpack, in case the weather changes...

The curse of the fast(er) delivery

During the recent years different agile concepts have been introduced into many organizations, in order to minimize the time from a projects inception to the first delivery.

There is nothing wrong with that, as we all wish to deliver working software to our customers as fast as possible, and this blog post should not be seen as an attack on any of these methodologies. It is however an attack on some project managers, and others, rather loose interpretation of some of the concepts of multiple release projects.

In the organization where I work there is a goal of a nine month period from project inception to the first release.

Here we come to one of the points where the concepts release and business delivery are put into play, and these are used to tweak the a view on the project, to satisfy managers and perhaps the business leaders, because we will deliver "something" within that nine month deadline.

Let's just clarify the concepts, at least how I interpret them.

- Business Deliverable - a logical entity in the project containing related functionality, which could stand alone, should it be release to the customers. How much benefit it will give is a whole other discussion which I will not go into here, perhaps in another post...
 - Release - the implementation of one or more Business Deliverables into the "real world"

Now, what I suspect the management meant when they set up the nine month deadline, what they meant was that they would like to have a release within nine months. However, the fact of the matter is, as projects go along and they get more complex than anyone had imagined, we start to talk about doing a Business Deliverable within the nine month deadline. - and hey presto, we have now bought ourselves more time, because we have something to deliver within nine months but it might not make sense business wise, so we will save it for a later Release.

Thus we still have the same 12 - 16 month delivery period for something that actually gives value to our customers, but we have satisfied the management because we have lived up to the nine month deadline as well.

My point here is, that if we take a look at the situation from the customers or business representatives side, we have done absolutely nothing to improve the delivery time of actual working software.

As a Business Analyst I would like to cut through the concepts of business delivery and releases, the arbitrary deadlines put up by managers, and instead focus on the business needs.
If what the business wants takes 12 months to deliver, and it does not make sense to split it into release, so be it! But lets not kid ourselves that we have delivered faster because we had a business delivery done after 6 months, the business gained no value from it.

Don't get me wrong. Business Deliverables is a great project management tool, to ensure that you focus on the right part of the solution and can prioritize, but do not think that a business deliverable without a release is something that gives value to the business. Even if it is the business that have decided to wait until several business deliverables can be joined in one release.

To me what matters when setting goals for projects delivery times must be business value - When can we create value for the business! The rest is just manipulation...

Guilty pleasures....

After a long summer, I guess it is time to revive this blog from it's hiatus, and once again start to ponder the mysterious ways of business analysis. At least the mysterious ways in which my slightly twisted my reflects on business analysis.

As human beings we all have our guilty pleasures, be it something eatable, drinkable or whatever. Its the small things that we sometimes indulge into, perhaps to celebrate our successes or in grief over out failures.

As a business analyst I, and I can only speak for myself, also have some guilty pleasures, which may not be very productive, but at least they make me feel better.

For one thing there is complaining, about the stupidity, ineffectiveness, lack of insight, stubbornness, (add more words yourself) of the business representative, project manager, senior manager (add your favorite complaining target). By complaining I mean the non constructive uttering of words into the air letting everyone in the vicinity know how you feel about the person in question. At this point I assume that you have checked that this person is not within hearing distance, as we then turn from complaining to stupidity...
A good approach could be to utter sound or general complaints, letting people nearby know that you are not happy with someone/something. If they then ask what the problem is, you have the chance to censure what you tell them...

Complaining in this form usually gets you exactly nowhere, but it does make you feel better, especially if your complaints are backed up by people who heard you.

Now, at this point I should probably offer some sort of more or less valuable insight, so here we go...
If you feel the urge to complain, please do so (after the aforementioned check of the presence of the target or any others who might report to the target), but do yourself the favor of turning the situation upside down. By this I mean, that if you are unhappy with the behavior of someone, ask yourself whether you have done something to induce this behavior, if yes, try to correct the situation, if no ask yourself if you can do anything to make the situation better. Neither may be possible, but at least you have identified that you cannot do anything about it.

Another guilty pleasure of mine, is to celebrate, usually inside myself, if after a discussion with a business representative, project manager, senior manager (add more yourself) I turned out to be right. Again this makes me feel good, but it is not very productive, and the other part may not be so happy.

Instead of just celebrating, a please do that, that you were right and the other one was wrong, try putting it in a lager perspective, hint: you might not be right the next time.
If you the next time you meet the other part express your satisfaction with the compromise you reached last time, I know I know, you were right all along, but by giving him or her a stake in the result they tend to be less unhappy with it, a it might be easier to reach other compromises in the future.

I think a guy, or girl? some call God got it pretty much spot on a few thousand years ago "Do to others as you want them to do to you".

Stick to the plan or re-plan on the fly?

First of all, sorry for the lack of updates, but this thing called work seems to have been occupying a fair bit of my time recently, but now I'm back.

For this post, the inspiration actually came from the department to which I am currently allocated, which have been working with improving meeting efficiency. One point is the preparation of a meeting/workshop, which among other things requires the preparation of an agenda, topics to be discussed etc. Usually it is good meeting etiquette to stick to the agenda, make sure that there is time for all parts of the agenda and so forth. These are all sound priciples, but...

I think everyone knows the dilemma, stick to the plan or go of in another direction? It occurs daily to all of us, whether we were just on our way to the grocery store and "accidentally" stepped into our favorite clothing store, or we were on our way home, and decided to take another route to avoid traffic even though it might be a longer drive. (I know, I know. I promised, no more traffic metaphors!)

In the world of business analysis, it is not uncommon that a meeting gets "high-jacked" by someone with a different agenda, and the question is then how do we handle this? The answer is of course a clear cut: Well, it depends...

To keep it simple, I see three basic outcomes of our decision:

1: We fend of the high-jacking attempt and return the originally proposed agenda, but not being pirates, we also make a decision on how to handle the issues brought up as the alternative agenda.

2: We declare a ceasefire, ending the current meeting/workshop and convene at a later point in time to discuss the new situation.

3: We declare us beaten by the high-jacking and change our agenda to accommodate the new information.

No strategy is better than the other, per see, as they are highly situation dependent.

So how do we as the meeting leader/facilitator decide which strategy to use? I see four important parts which have to be taken into consideration.

A: Are the meeting participants the right ones to discuss and make decision on the new agenda?

B: Is the necessary information present, both with the meeting participants and are documents etc. to be discussed available ?

C: Am I as the meeting leader/facilitator prepared to/capable of changing the agenda?

D: Does the information in the "high-jacking" render the current agenda useless?

Based on this we can make a decision:

In order to change the current agenda, we need to be able to answer yes to A, B and C. Otherwise we cant continue the meeting with a new agenda. If we answer yes to D we only have option 2 left.

If we answer no to A, B or C, we can choose between options 1 and 2. Here question D becomes the tie-breaker. If we answer yes to D, we should end the current meeting and convene at a later point in time when we have the necessary information or attendants.

I have tried to illustrate it in the figure below:

While question A, B and D are quantifiable, question C is tricky and a point where the meeting leader has to be honest with him-/herself and the other participants.

As the meeting leader it is hard to announce that you are not capable of continuing the meeting, even though the necessary people and information is present. I do however think it is better to make the decision to postpone the meeting rather than continuing with a meeting where we are unsure of the outcome because we don't now whereto or how to steer our ship.

Continuing without a captain can cause worse results than dropping the anchor and make sure we have the right position and direction.

Trusting your BA - or - Using your Business Representative

The inspiration for this comes partly from a Dilbert cartoon strip and partly from recent experiences in the world of collaboration with the business representative.

To start of with the Dilbert quote:

"Why did you add this button to the user interface?"
"You told me to. You always suggest random changes to create the illusion of added value."
"Well, remove that button."
"It's only on your copy."
- The Boss and Dilbert

Is this a real scenario, do we actually as business analyst* "bend" the facts in order to get on with the work, or are we really so pure at heart, that we take everything to the business representative.  I would like to believe that the latter is true, but must also admit that I am tempted in doing the first sometimes.

The more detailed and "nitty-gritty" the problems become, the harder they usually get for the business representative to even understand, mostly because they are rooted in some half-technical issue which is quite far from the high level requirement posted by the business representative.

These issues often represent some remote possibility of something happening, and it should be considered how much energy to put into them. I know; 20 percent of the solution takes 80 % of the time, and I also know Murphy's Law, so don't get me wrong, we do of course need to take care of these issues.

The question is at what detail level do the business representative need to review and comment on the solution?


As a business analyst you will inevitably gain some detailed knowledge about the very detailed operation of the solution and the inherited problems herein. Would it be feasible to let the business analyst decide the best course of action, for some of these remote probability issues, and let the business representative focus on the major part of the solution?

The business analyst is of course welcome to seek advice with the business representative, but in many cases one guess is as good as another.

Don't get me wrong, I'm not going to argue withholding information from the business representatives or anything like that, but there has to be a mutual understanding between the business analyst and the business representative regarding in what areas the business analyst can work at his/her own discretion and where the business representative should be involved.

There is no clear cut answer on how to do this, as it very much depends on the business knowledge and experience of the business analyst, as well of the nature of the project.

In a project based in regulatory / legislative changes the business representative(s) might need to be more closely involved than in other projects.
And in projects more concerned with infrastructure the business analyst might have more freedom to interpret the solution on behalf of the business.

* In this article the concept of "Business Analyst" is used in a broad sense, and could include related areas of project work, e.g. solution architects and others.