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...
Monday, November 1, 2010
Wednesday, September 8, 2010
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".
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".
Friday, June 11, 2010
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.
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.
Tuesday, May 11, 2010
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.
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.
Friday, April 16, 2010
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.
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.
Monday, March 15, 2010
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.
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.
Tuesday, February 16, 2010
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.
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.
Tuesday, January 12, 2010
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"
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"
Subscribe to:
Posts (Atom)