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.

Knights and Orcs - on how initial perceptions may deceive you

As you might have noticed, it's been a while since the last post, mostly due to a larger workload in the past weeks, which has also limited the number of incidents, and because I have promised to not bore you with more traffic stories...
 
Normally I just write about some of the thoughts that pops up in my head, and how they can relate to the everyday life of a busiess developer. The ideas usually comes from small incidents during my daily life, but this one is a little more peculiar than most others, so I thought that this time I would also share the origin of the post with you.

The origin for this post is actually one word "Orc" which was uttered by a colleague I passed in the hallway. I do not know what the conversation was about, but I guess using the word Orc in a conversation is not that uncommon in an IT environment.

That one word got me thinking about communication and problem solving, and how first impressions may deceive you, when trying to get to a common understanding or solution.

Here I will only use with two extreme categories, but there are probably many more in between.

First impression can often be classified as one of two, here expressed in a "Lord of the Rings meets Shrek universe" (Don't worry, it will make sense in a minute or two... I hope):

"Orcs" - Loud bully like creatures which seems to have no capacity for listening and understanding arguments for other solutions than their own. They are usually not slow to voice their opinion and to stress out that their solution is the only right one. - Think the Uruk Hai from the Lord of the Rings (I have now committed the sin of assuming that you are all familiar with this book and/or movie, for those who are not, they are highly recommended to read or watch)

"Knights" - Friendly chivalrous persons who seems to be able to engage in conversation and democratic process to reach the best possible solution. They are usually more modest, and give a good impression. Think Boromir, just to stay in the Lord of the Rings terminology.

I know this is probably stretching reality a little bit, but I'm sure you can recognize some features in a colleague or two.

Now in real life, the Orcs may be knights, and the Knights may be Orcs, when you get to know them.

Someone can seem almost unreachable to begin with, but if you can make the right arguments, they are usually good cooperators and can be a valuable asset to your project. Think Shrek - the ugly monster who everyone was afraid of, but turned out to be quite a Knight and a good guy.

On the other hand, someone who seems courteous at first, may be impossible to move form their own ideas, and they can be a real obstacle in the future work. Think the Sheriff of Nottingham from Robin Hood - he might be able to portray himself as a man of high class, but is not afraid of slaying anything in his way to get what he wants, quite an Orc at heart.

This is of course nothing new, and we all know the saying "Never judge at book by its cover" - which is still true, but sometimes we maybe need another analogy to remind us, so I have tried to provide one here.


But also remember that some Orcs are Orcs - Think again of the Uruk Hai, and some Knights are Knights - Think Aragorn. 

The morale of my little tale here is, I guess, to give everyone the benefit of the doubt, until they get at chance to reveal their true identity, be it Knight or Orc or somewhere in between.

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"

Handling known risks (and something about matching expectations)

Last time I promised to try to stay out of the traffic metaphors, and I shall do so...almost.

As business analyst we are used to working with risk analysis and risk mitigation.

Thus it makes me wonder how almost everyone, myself excluded of course, gets surprised by frost and snow here in Denmark. By everyone I do mean everyone from individuals to large government controlled companies.

It is a known statistically proven fact that sometime in November or December, even with global warming and all, the first frost and/or snow will appear. Nevertheless it always seems to catch a rather large group by complete surprise.

(On a side note it is rather the irony of destiny that it is snowing in Copenhagen during the COP15 summit)

In our projects we usually identify risk a plan mitigating actions according to risk size etc. Somehow we fail to do the same to a risk that is almost sure to occur at the same time every year.

In the current case of snow and frost mitigation actions are of course to to fit the appropriate tires to the car, make sure the cooling fluid is frost resistant etc. and should this not be enough be sure to keep blankets and drinking water in the car.
How the train operators prepare I'm not sure, but it is often not that effective, or rather it is probably a cost benefit consideration/decision.

To project this to our project world, do we have similar risk that we can almost guarantee will occur at a specific time in a projects life cycle?
I think so, examples could be the ability to gathered the user requirements on the scheduled time, testing takes longer than planned and probably many others.

Do we not have the mitigation in place? Sure, add more time! Cut functionality! Cut on Quality! But that is however not always the option, as this now gets political and I will not go into that here.

But the least we can do is mach the expectations of action from all involved parties. If a risk is high enough, and we are more or less sure that it will occur, then we must at least trust that we take the agreed action.

If we can agree on who does what, we might have a chance to at least softening the blow a bit, and not get knocked off course, just like the traffic on the slippery road.

Some interesting articels

This is just a little intermezzo, with a few links to articles I think give some good advise.


Creating Compelling Executive Summaries in Seven Easy Steps - from Business Analyst Times

10 Ways to explain things more Effectively - also from Business Analyst Times

And finally I would suggest you visit the site www.batimes.com There are plenty of good articles and blogs, and if you don't want to search for them, just subscribe to the newsletter :-]

Why doing the unexpected may be a bad idea...

Picking up where we left off last time, with the traffic on my way to work, another little traffic incident got me thinking.

Traffic is based on a set of rules to which we all have agreed to adhere to, if we don't bad, possibly lethal, things will happen. If all do as they should according to the rules - and here i won't get into the differences found across countries on our little planet - we should be able to navigate the system in relative safety. At least taking into consideration the fact that we put ourselves in 1000 kg metal cans that moves at 100+ km/h.

However there is always someone who, with the best of intentions, decides to disregard the rules and do something unexpected. It is of course a nice gesture to stay back at let the cars from a smaller side road move into the main road, but it usually causes confusion a possibly dangerous situations, because we do not know how to react. We have no verbal communication, and at this time of year probably not much visual communication either.

The problem is that I do not expect someone to give way to me when I'm entering from the side road, and when they do I am not sure that I trust they will stay back, thus taking extra time to survey the situation. In this time the nice person in the other car could have moved along, and I could probably have hit a natural hole in the traffic, thus not holding up everyone else trying to get to work.

This can be translated to a business analyst work, when dealing with business areas, contact persons etc. The best way to get everybody moving along the same path is to follow a certain set of "Traffic rules". If we have agreed on how to navigate through our common project it might cause less bumps in the road along the way. In this way we are relatively sure that our counterparts will react in a foreseeable way, and not cause any accidents.

Now at this point there are probably someone screaming - WHAT ABOUT INNOVATION AND PROGRESS - is doing the unexpected or new, a way of ensuring innovation and progress.

YES - you are absolutely right - but my point here is that you should do it in a foreseeable way. Don't drop your new idea as a bomb in the middle of a meting, taking over the agenda and have everybody seeing either possibilities or problems. The only thing you will get for certain, is a very unproductive meeting.

Instead call a meeting with the specific purpose of presenting your new idea, then you have followed the traffic rules and everybody is probably much more inclined to follow your idea.

In our traffic metaphor I guess you could say that instead of causing problems at an intersection, you send an idea to the city council, suggesting that traffic lights are put up.

A final point is that the "traffic rules" might not be written down or agreed upon, they can simply be culture. For example at another intersection, not too far from the one that gave the inspiration to this post, there is a culture of letting fellow road users on to the main road, this is of course not in accordance with the official laws, but all of us who pass by there every morning have a common non-spoken agreement that we do let them out.

For the next post I will try to get out of my traffic metaphors, but no promises.