Wiio's Laws
Thursday, 21 January 2010

Yesterday I had the perfect example of Wiio's Laws. Just to provide a little background: Osmo Wiio is a Finnish researcher of human communication and despite the fact that his laws are seem as funny material by most people, I think they are actually very insightful. I've copied them below, so you can have an overview of the concept. I'm also providing a link to Jukka Korpela's website (the place from where I took the English translation of the laws), where you can find a synthetic yet comprehensive explanation of each one.

Well, back to my case: we are part of the team implementing a new system at our company (receivables). Our role on this project is to provide infrastructure and technical information for the third party team hired to actually manage the project and build the solution.  In my humble opinion, this project has born dead. For several reasons, though, and despite of all advice we could give before the kick off, the project was put forward by a group of middle managers. As we could easily forecast at the time, the project is now way out of budget and schedule, and this situation is causing a lot of pain and frustration to it's sponsors.

Yesterday morning (Wednesday) at 9:00AM the project team started a process to upload a ton of records to the application database. The load of data was so big and the validation constraints so slow that it would require days to complete. At 4:00PM we received a notice from our infrastructure team saying that "depending on the negotiation with some service providers we would have to stop all our servers for reallocation in two days" (Friday), and that was in order to accomplish a major task of another project. What did we? Well, the receivables' project is already delayed and the internal clients hoping to have the upload phase done ASAP (actually Monday), so we went to the third party consultant and asked for some input about the upload rate in order to know if the time window we had would be enough. I couldn't help my big mouth from mentioning that "we may have to shutdown our servers in two days" (and that was my big mistake in this case). The guy took my words as fate and sent a mail to his Project Manager telling a story (his story). The PM took his programmer's words as fate, and not even bothered to  call us to clarify the situation. His action? He sent an e-mail to ALL our managers, claiming that our move was going to impact the delivery schedule of their project. Result? People barking at us, accusing us, as if we were not aware of the implications of that situation.

The moment we knew about the possibility of service interruption we started a set of contingency measures to mitigate any impact to the receivables' project, and in order to know if those measures would be enough we had to gather more information. I like to be sincere with people - it is part of my character - and since we had two major projects at hand, with conflicting needs, our intention was to assure that both were executed with minimal impact to each other. Keeping people unaware of the situation was not an option for us, since we were depending on the understanding and cooperation of both project teams to minimize the consequences of any action we could take.

To make a long story short: we tweaked some things here and there, improving the upload performance, and a measurement made at today's morning (Thursday) told us that the process would finish tomorrow (Friday) at noon, eight hours before the servers shutdown, so all that embarrassment caused by the misinterpretation of my words spread through that e-mail has proven to be unnecessary. I tried to give the PM some feedback, but he didn't take it well. He agreed to not take actions regarding to IT resources in the future without first consulting us, which was my goal for that conversation, but he kept forcing the wrong arguments to defend his point of view (a C.Y.A. one, in my opinion).

What came to my mind with all this:

1 - Communication usually fails, except by accident.

1.1 If communication can fail, it will;

1.2 If communication cannot fail, it still most usually fails;

1.3 If communication seems to succeed in the intended way, there's a misunderstanding;

1.4 If you are content with your message, communication will certainly fail.

2 - If a message can be interpreted in several ways, it will be interpreted in a manner that maximizes the damage.

3 - There is always someone who knows better than you what you meant with your message.

4 - The more we communicate, the worse communication succeeds.

5 - In mass communication, the important thing is not how things are, but how they seem to be.

6 - The importance of a news item is inversely proportional to the square of the distance.

7 - The more important the situation is, the more probably you will forget an essential thing that you will remember a moment later.

Read more (with explanations) at: http://www.cs.tut.fi/~jkorpela/wiio.html


Professor Osmo A. Wiio (born 1928) is a famous Finnish researcher of human communication. He has studied, among other things, readability of texts, organizations and communication within them, and the general theory of communication. In addition to his academic career, he has authored books, articles, and radio and TV programs on technology, the future, society, and politics. He formulated “Wiio’s laws” when he was a member of parliament (1975–79) and published them in Wiion lait – ja vähän muidenkin (Wiio’s laws – and some others’; in Finnish). (Weilin+Göös, 1978, Espoo; ISBN 951-35-1657-1).


 

Nothing we can do can change the past, but everything we do changes the future.

Ashleigh Brilliant