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.
Wednesday, December 16, 2009
Wednesday, December 2, 2009
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 :-]
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 :-]
Friday, November 27, 2009
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.
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.
Expectations - A service announcement
After a short dialogue with a reader - nice to know there is at least one out there - I thought it would be appropriate to write a little section about my aspirations for this blog.
It was never my intention that I would update it daily or several times a week, and on the other hand I am well aware that some new content is required in order to keep you interested. So expect new post a couple of times each month, and with variable intervals.
I have no fixed schedule for posting here, as I do no have a list of subjects lined up.
Usually a post evolves in the following way. I experience something, that puzzles, annoys or in some other way forces me to react to something. I then start to analyse the experience and maybe at some point I come across something which has analogies to the business analyst world. This will then start to evolve in my head to a description of the situation and to the point that I wish to draw from the experience.
After that it is a question of finding the time to write the post.
This was a short intermezzo, and I promise the that the next, more business relevant post, is just around the corner. I just need to write it, the idea is there. I can tell you so much that it continues the trend of traffic observations and includes more about expectations.
It was never my intention that I would update it daily or several times a week, and on the other hand I am well aware that some new content is required in order to keep you interested. So expect new post a couple of times each month, and with variable intervals.
I have no fixed schedule for posting here, as I do no have a list of subjects lined up.
Usually a post evolves in the following way. I experience something, that puzzles, annoys or in some other way forces me to react to something. I then start to analyse the experience and maybe at some point I come across something which has analogies to the business analyst world. This will then start to evolve in my head to a description of the situation and to the point that I wish to draw from the experience.
After that it is a question of finding the time to write the post.
This was a short intermezzo, and I promise the that the next, more business relevant post, is just around the corner. I just need to write it, the idea is there. I can tell you so much that it continues the trend of traffic observations and includes more about expectations.
Tuesday, November 10, 2009
Obligatory passage points
Over the last couple of days I have been stuck in traffic on my way to work, due to traffic accidents often many kilometers from where I start my daily journey.
I puzzels me, how a single accident, that even occurred two hours before I left home, is capable of tying up the traffic for a 25 kilometer radius.
As I had plenty of time in the car to nothing but listen to the radio and think about the problem, something came to mind. And right here I have to disappoint you, I do not have the solution to traffic problems in the central part of Zeeland, Denmark, where I happen to live. But, it did however occur to me, that what caused the problem in the first place, is a situation that we need to be aware of as Business Analyst and similar professions.
The problem occurs when an accident happens on or after a particular part of the highway, which collects the traffic from several parts of Zeeland. There are of course smaller roads, which can be used, but as the access to these roads are at the same point as the access to the highway, it usually blocks most of the traffic in the area.
And now, enough about traffic, but it is a good analogy to the work we do when designing new business processes etc.
Usually we design a business process as a highway, where most, if not all, of the "traffic" pass along.
But what if something goes wrong and we have a "traffic" accident? Do we have a backup process in place? What is our "B-road"? Usually there is a manual procedure to be used in emergency situations. But what if the entry to this backup procedure runs through the same passage points as the entry to the highway? Then we might have a situation where both the highway and the b-roads are blocked, not exactly what we intended.
Thus if our highway is important enough, we need to design the "b-roads" in a way that ensures that we can actually by-pass the highway, and not get tied up in a single point of passage.
(On my way to work I Usually have a b-road, that takes me clear of these passage points, but at the moment a bridge is closed completely due to maintenance. The relation of this to the business analysis world, I will leave up to the reader.)
For the more academically interested this is very much built on the Actor-Network Theory (ANT) developed by Michel Callon and Bruno Latour, among others. Obligatory Passage Point is a central concept in ANT.
I can highly recommend reading Bruno Latours article "Where are the missing masses - The Sociology of a door". Which desribes the concept of ANT and obligatory passage points.
I puzzels me, how a single accident, that even occurred two hours before I left home, is capable of tying up the traffic for a 25 kilometer radius.
As I had plenty of time in the car to nothing but listen to the radio and think about the problem, something came to mind. And right here I have to disappoint you, I do not have the solution to traffic problems in the central part of Zeeland, Denmark, where I happen to live. But, it did however occur to me, that what caused the problem in the first place, is a situation that we need to be aware of as Business Analyst and similar professions.
The problem occurs when an accident happens on or after a particular part of the highway, which collects the traffic from several parts of Zeeland. There are of course smaller roads, which can be used, but as the access to these roads are at the same point as the access to the highway, it usually blocks most of the traffic in the area.
And now, enough about traffic, but it is a good analogy to the work we do when designing new business processes etc.
Usually we design a business process as a highway, where most, if not all, of the "traffic" pass along.
But what if something goes wrong and we have a "traffic" accident? Do we have a backup process in place? What is our "B-road"? Usually there is a manual procedure to be used in emergency situations. But what if the entry to this backup procedure runs through the same passage points as the entry to the highway? Then we might have a situation where both the highway and the b-roads are blocked, not exactly what we intended.
Thus if our highway is important enough, we need to design the "b-roads" in a way that ensures that we can actually by-pass the highway, and not get tied up in a single point of passage.
(On my way to work I Usually have a b-road, that takes me clear of these passage points, but at the moment a bridge is closed completely due to maintenance. The relation of this to the business analysis world, I will leave up to the reader.)
For the more academically interested this is very much built on the Actor-Network Theory (ANT) developed by Michel Callon and Bruno Latour, among others. Obligatory Passage Point is a central concept in ANT.
I can highly recommend reading Bruno Latours article "Where are the missing masses - The Sociology of a door". Which desribes the concept of ANT and obligatory passage points.
Friday, November 6, 2009
The failure of project specific process descriptions
Admitted, the headline is a bit of an overstatement, but it got your attention, right?
The inspiration to write this came when I actually had to look at our project processes, which project it is doesn’t really matter, if it happened to us, it probably happened to someone else too.
Don’t get me wrong, for a very long time I have been advocating tailoring and choice of processes to be used in a project. But - and to all you trained facilitators the “but” is used intentionally – when opening the projects process description document actually invokes a physical reaction, I feel that we in some way have gone in the opposite ditch here. And to those wondering, no it is not a violent reaction nor a reaction involving bodily fluids, it’s just the sensation telling you “this can’t be right”. In the project in case we now have 56 pages of process descriptions, and I for one have trouble keeping my concentration reading just a couple of pages.
The first process described is a process for developing/describing processes – now here I’m already starting to get that weird sensation that something is not right, and then when I start to actually read the process and come across the sentence:
“The purpose of this process is to establish a process for establishing project processes. “
When I read this the first time, I actually had to say it out loud and start making jokes about it, just to make sure I was still at a reasonable sanity level – and fortunately I was, so I started to investigate why this had happened.
Reading through some of the described processes, alright I admit it I have not read them all thoroughly, I started to understand why this strange feeling had occurred – I already knew what the process was, but how can this be true if the process is project specific? And here is the point where the headline start to make sense, the processes are not project specific, they describe what is already in the development model or just common practice.
This lead me to investigate what the development model actually says about project processes, the following is taken from the description of the work product “Process descriptions”.
“Process descriptions for the project makes it possible to describe the project’s processes in the same way as processes are described in the Development model”
That is all well it makes sense that we describe the processes we adhere to in the same way no matter where we store them.
The description in the actual template makes it even clearer:
“The purpose of this template is to describe both simple and complex processes, which are necessary to carry out in the project and which are not already described in the Development model.”
Aha - here lies what I consider to be the failure of the project specific process descriptions. If we take all what is already described in the development model, because we think we have to fill out every field in the template, we have failed. No one wants, or has the time to, read something of which they already know 80-90 percent in order to gain the last 10 percent of knowledge.
The project specific process description should include, and ONLY include, that which is changed from already described processes - and argue why this is valuable to the project.. This is where they can be valuable, because it is now obvious to everyone where we have chosen to do something different and why.
Now why did I feel it was necessary to take the time to write this? Well – for one thing it made me feel better, thus making sure I am capable of continuing with other tasks. And for those worrying about my physical state, I am now much better – thank you. Furthermore, if this can help others to save time describing and reading the project specific processes, I think the time is well spent.
Subscribe to:
Posts (Atom)