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...

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.

From BA/BD to Bsomething

My apologies for the lack of new posts, this thing they call work, seems to take of a lot of my spare time these days :-]

Usually our finest mission as a Business Analyst / Business Developer is to facilitate a solution that creates value for our business or our customers, hopefully both.

Therefor I find it frustrating to have a task where the deadline is determined by outside factors, usually legislation and what we have develop only gives very little or no value at all anyone. Or rather not what we have to develop, but what the deadline allows us to develop. The Business Areas usually have plenty of good ideas on how e.g. new legislation can be used to give value either to the customers or to the company internally, but these cannot be put into practice within the time allowed.

Where do I as a business analyst find my motivation here? On one hand I have a business which of course has to be compliant with new legislation, but which also has some decent ideas on how to get some value out of something we have to do anyway. On the other hand I have a project with a fixed deadline and a limited amount of resources.

The clash of these two worlds results in me spending most of my time finding minimal solutions and telling the business that we cannot deliver what they would like, at least not within the allowed time frame.
The only point of value I can find in this, is that hopefully the company will be compliant with the legislation, thus avoiding penalties and generally bad publicity.

This is somehow just not enough, as a business analyst or business developer I see myself working with the business to find new potential and new ways of creating value to both the business and the customers. How do I find the motivation to keep doing as good a job on the compliance task as on any other development task?

For once I don't have the answer, but I'll take any suggestions.

The post was originally intended to end here...

But as usual something shows up when you least expect it, a small glimpse of hope in a day that didn't look to good from the beginning of it, so maybe I have at least a part of the answer anyway.

I think one trick is to remember to celebrate the small successes. If you cannot yet see the value of the whole project or task, at least remeber to celebrate your personal successes. This will reinforce you in that you are indeed doing a good job, even if you can fit your results into the greater scheme of things yet.

The Wave

First of all, a happy new year to everyone!

The following may seem a bit over-interpreted to some readers, and I do probably agree with you, even before having written it, but nevertheless I think there are some valuable points.

Yesterday I saw the movie "The Wave" or rather a modern German remake of it called "Die Welle". That fact that the movie was in German somehow added a subconscious scary feel to it. Perhaps because the teachers rally speaks reminded even more of Hitler. I can actually recommend this version, as it is updated to today with modern technology for communication, financial crisis, high school shootings etc. taking it a little closer to today's society.

For those of you who does not know "The Wave" it is a novel written by Todd Strasser (under the pseudonym Morton Rhue) basen on a Screenplay for at movie written by Johnny Dawkins.
The story takes place in a High School, where the teacher, in an effort to explain how Hitler and other dictators could gain such a following, creates his own movement "The Wave" with himself as the leader. The experiment includes uniforms, a special salute etc. Within a few days "The Wave" takes on a life of it's own. Read more about it here.

The moral of the movie is that the movement becomes the most important thing and if you are not for "The Wave" you are against it, and some members will resort to any means to protect "the Wave", its members and especially its leader.

A now, how does this relate to our everyday work as business analyst?

Well many business analysts, including myself, are employed in an IT-organization developing solutions for customers either internal or external.Most IT-organizations have one or more playbooks, guidelines, methodologies, development models, call it what you will. Common to them is a certain set of what we believe to be best practices, and they often are. But this is also where the clash with the customer is often experienced.
They know nothing of our "development model" and when they ask why we perform a certain activity, they get the answer "Because the model says so!"

Have we created our own "Wave" here?
Don't get me wrong, I am not about to argue for the removal of all development models...

But, if we can not explain how performing a certain activity will add value to the customer/solution, at least indirectly because it it necessary for the project, why should we then do the activity? And in this case we have chosen our base, community or what you would like to call it, above the needs of others, and in my mind that is a sort of "Wave". Not as extreme as the one portrayed in the movie, but it is nevertheless counter-productive to what we want to achieve with our project.


We have to be careful not to see the world as "Them" and "Us", which sometimes happens when the customer and the IT-organization does not agree on certain parts of the solution. In these situations, it is our job as business analysts to see the problem from all sides and try to find a solution that can satisfy all parties.

In short we sometimes have to see beyond our own "Wave", and understand the needs of others as well, in order to ensure finding the best solutions.

I'll end this post with a quote from a song by the British Band Faithless "You don't need eyes to see, You need vision"

Obligatory passage points

Over the last couple of days I have been stuck in traffic on my way to work, due to traffic accidents often many kilometers from where I start my daily journey.
I puzzels me, how a single accident, that even occurred two hours before I left home, is capable of tying up the traffic for a 25 kilometer radius.

As I had plenty of time in the car to nothing but listen to the radio and think about the problem, something came to mind. And right here I have to disappoint you, I do not have the solution to traffic problems in the central part of Zeeland, Denmark, where I happen to live. But, it did however occur to me, that what caused the problem in the first place, is a situation that we need to be aware of as Business Analyst and similar professions.

The problem occurs when an accident happens on or after a particular part of the highway, which collects the traffic from several parts of Zeeland. There are of course smaller roads, which can be used, but as the access to these roads are at the same point as the access to the highway, it usually blocks most of the traffic in the area.

And now, enough about traffic, but it is a good analogy to the work we do when designing new business processes etc.
Usually we design a business process as a highway, where most, if not all, of the "traffic" pass along.

But what if something goes wrong and we have a "traffic" accident? Do we have a backup process in place? What is our "B-road"? Usually there is a manual procedure to be used in emergency situations. But what if the entry to this backup procedure runs through the same passage points as the entry to the highway? Then we might have a situation where both the highway and the b-roads are blocked, not exactly what we intended.

Thus if our highway is important enough, we need to design the "b-roads" in a way that ensures that we can actually by-pass the highway, and not get tied up in a single point of passage.

(On my way to work I Usually have a b-road, that takes me clear of these passage points, but at the moment a bridge is closed completely due to maintenance. The relation of this to the business analysis world, I will leave up to the reader.)

For the more academically interested this is very much built on the Actor-Network Theory (ANT) developed by Michel Callon and Bruno Latour, among others. Obligatory Passage Point is a central concept in ANT.

I can highly recommend reading Bruno Latours article "Where are the missing masses - The Sociology of a door". Which desribes the concept of ANT and obligatory passage points.