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.

Lessons from the Titanic...

Real life traffic, knights and orcs from the fantasy world and now one of history's most famous ship disasters, you can't accuse me for not drawing inspiration from many different sources.

The inspiration for this post is actually two-fold, a part of it was discussions during yesterday regarding software for the health care industry and another part was watching a TV show about the shipwreck of the RMS Titanic.

Should there be anyone not familiar with the sinking of the RMS Titanic, probably tho most famous shipwreck in history, I'll give a little sum-up.

When she departed Southampton on her maiden voyage on April 10'th 1912, she was the largest and most luxurious steam ship in the world. On-board were many of the richest and most influential people in the world, including John Jacob Astor and Benjamin Guggenheim.

On the evening of April 14'th she struck an iceberg in the North Atlantic, and at 2:20 in the morning of the 15'th of April, she sank to the bottom almost four kilometers below the surface, even though she was thought to be unsinkable. Over 1500 of the 2223 people on board lost their lives.

A very in depth description of the ship and the disaster can be found at wikipedia

The wreck was discovered by Robert D. Ballard and Jean-Louis Michel in 1985, which helped to shed light on some of the reasons why the ship sank.

Obviously striking the iceberg, was the final piece in the chain of events that led to the sinking, but the foundation for a disaster was already laid when the ship was built.

The ship building industry learned many a lesson from the Titanic, and perhaps some of these can be transposed into the business analyst world as well.

I will now go through some of the reasons and try to put them into a business analyst perspective.

Captain Smith and the blue ribbon
The Titanic was not only the largest steam ship in operation, but also probably the fastest. It is therefore a widely recognized theory, that the Captain, Edward J. Smith, was keen on capturing "The blue Ribbon", for being the fastest ship to sail the route from Southampton to New York. He therefor pushed the ship to sail as fast as possible, a decision which would prove to maybe be fatal, as it was almost impossible for the ship to avoid an iceberg with the visibility on that fatal night.

As an business analyst this tells me to not always go for the big price at full speed. You need to have enough judgment to see if you are potentially risking the life of the project. It is not always enough to get to the finish line as fast as possible, you also need to make sure that you get there safely. For example in the space industry time is not always the important factor, but quality and reliability is, which can mean that the process of getting to the finish line takes longer time.

The telegrapher 
The Titanic was equipped with one of the most powerful telegraphs available at the time, giving it superior range compared to other ships.
On April 14'th the telegraphers were busy sending passenger messages before they came out of range from land stations able to pick up the telegraph signals. While sending these messages, reports of icebergs came in from other ships in the area. This was not unusual in the North Atlantic, and most of the time these warnings were delivered to the bridge, but not taken much notice of. At some point the telegrapher at the SS California sent another warning, to which the telegrapher on the Titanic responded telling them rather angrily not to send anymore warnings, as he was busy.
The California reacted by shutting down her telegraph for the night, which would prove fatal, as she was the nearest ship to the Titanic, only about an hour away. But she couldn't be reached that night, and the next ship, the Carpathia, was three hours away.

There are several lessons to be leaned here:
1. Don't ignore warnings from others, they are usually well meant. Instead take them in, and then let the ones with the expertise determine if they are relevant or not. Don't let the telegrapher decide, but the captain or first mate.

2. Even if someone are annoyed with you, don't cut off communications, they might need at a later point in time. 
3. Servicing your customers are of course important, but don't forget that you also need to keep a minimum of attention to communication to peers and other projects, to pick up any warnings from them.

No Binoculars in the "Crows nest" and poor visibility
For those not familiar with maritime terms, the "Crows nest" is a lookout post on a mast at the front of the ship, where look-outs can be placed to spot icebergs, other ships etc.
For some reason there were no binoculars in the crows nest, apparently because the key to the locker where they were kept, had been lost. This meant that the lookout relied solely on their own eyes.
On this particular night, this was not an easy task, as the water was flat and there was no moon light, making it almost impossible to see objects in the water before it was too late.

So if you assign someone with the task of searching for possible risks to you projects, make sure they have the right tools to do their job, and if you cannot find those tools, be sure to adjust your speed to the ability of the lookouts.

Wrong design of water tight compartments, and poor quality rivets.
When the iceberg was discovered, the ship turned to its left to avoid it, and just scraped the iceberg with the right side of the ship.

As mentioned earlier the titanic was thought to be unsinkable, because of the watertight compartments in which the ship was divided into. With an electrical switch these compartments could be closed of, and the ship would be able stay afloat with three joining compartments being flooded. unfortunately the compartments did not go all the way up through the ship, and when the ship started to tilt forward because of water in the front compartments, the water started to spill over the top of the compartments, sealing the fate of the Titanic.

Further more it is believed that the quality of some of the rivets used could have played a part in the sinking, as they broke from the pressure of the iceberg, and the good quality rivets couldn't hold the steel plates together. Some of the rivets contained slag from the production, rendering them less strong than the good quality steel rivets used on the ships as well.

So when you build something, make sure that the raw materials are sufficient for what they are used fore, and make sure to think the worst case scenario through. Raw material can in this sense also mean computer code, hardware etc. used for example in the health care industry. 

And when you design your product, make sure you take into account the more unlikely scenarios as well. You can always decide later if they should be implemented or you can live with an inherent risk in the system. This is very much dependent on the function of the system, if lives depend on it, you may want to spend more time and money on making the solution closer to perfect.

Not enough life boats
One of the famous facts about the Titanic is that there were not enough lifeboats on board to accommodate all the passengers. The number of lifeboats required was determined by tonnage, not by number of passengers, which is why she was built to code, but that doesn't really seem to matter after the fact. The code was also changed shortly after, but that is another story.
The fact is that here were only life boat capacity for 1178 people, and as not all boats were filled, even fewer passengers were saved when the Carpathia arrived after the Titanic had sunk.
There were enough life vests on board, but as survival time in the cold water of the North Atlantic is estimated to be from 30 - 45 minutes, they would have been of little use.

So if you plan emergency procedures for your product, make sure that they are sufficient to handle the emergency, and set up rules for which part of the emergency shuold be handled first.
The latter came to view in the case of the Titanic, where the rule was "women and children first", one of the reasons why so few men survived the disaster.

I must admit that this post evolved to be a little longer than I anticipated, and I don't blame you  if you have not read all the way to the end. Using the Titanic, which has fascinated me for many years, as a reference for some learning points as a business developer just proved to interesting, so I may have been a little carried away.