Thursday, October 12, 2006

Fog of War

01/24/2006

Fog of War

Many of you will know the name of
Von Clausewitz. In the middle of the 19th century, the prussian general Carl Von Clausewitz wrote an encompassing treaty on the art of war. It is still a fundamental book on the subject, a textbook in all military academies.
Among the others, a fundamental point Clausewitz made is about the Fog of War. He states that war is the kingdom of uncertainity. The details of war conduct tend to blurr like in the fog. This means that commanders must inherently take decisions based upon incomplete information.
If you have ever led an IT project of any complexity, most likely you have faced the fog of war.The analogy is not complete, as it should be applied in a competitive environment, where both parties actively fight each other. None the less the continous bargain between the client and the consultant may well be regarded as clash. Each one of us hopes to work in a fully cohoperative environment, but, often, this is not the case.
What is the fog source? There are many, on different layers.
The first layer is an incomplete/inaccurate requirements collection. As IT people, too often we tend to automate our reply to the user need. If we are asked by a customer about, let's say, better customer knowledge, we reply automatically with the acronym CRM. We are ready to provide a contact database full of glamorous fields like "contact first son birth date", a bunch of insightfull reports which tell wether the client is likely to churn or not etc. Maybe the client only wanted to know which are the clients which have been visited by salespeople in a quarter. (This is not a fake example, this happened to me, as the number of covered clients was by far the most important indicator of business wealth in that case).
The second layer derives from the customer lack of IT experience. They often divert you to interface details, cluttering the horizon of the process which is going to be automated. This does not mean that the user interface is not important; more often than not the customer experience is the key to success. The point is that polishing the user interface is the last task to be accomplished. This is very hard to achieve as an ugly-looking system will often be considered just ugly in spite of any other consideration.
The third layer is ours. A project involving more than one developer is inherently prone to insidious details. If there are no clear rules on coding and naming conventions, is sure that you will end up with collisions that will cause an unnecessary waste of time and efforts.
At the top of all this there is the project manager. He/She will inevitably lose a correct view of what's coming on and risk to take uninformed decision. This happens when, like me, you are managing 3 or 4 projects a time.
What is the solution? The obvious one is being carefull, or paranoid, and pay the highest attention on these aspects. Probably I do not have anything to teach you on this subject.The second solution is, trust your istinct. Experience and thorough knowledge of the basic issues involved will often point you in the right direction. I listen to my istinct more often than I will, and it is often right.
Is this not scientific? Yes, but what do you expect from an hen-master?

0 Comments:

Post a Comment

<< Home