E L S U A ~ A KM Blog by Luis Suarez

From the blog

Giving up on Work e-mail – Status Report on Week 26 (K.I.S.S. on Business Processes)

Continuing further with the weekly progress reports on my new mantra of giving up e-mail, as in corporate e-mail, here I am again with another progress report, this time for week 26, where, it looks like, things have gone back to normal a bit. Or so it seems. You would remember how, for week 25 I reached a new low with regards to the incoming count of e-mails received, as I have blogged about it a couple of days back. Well last week things settled back into what I have been getting used to for the last few weeks already. Here is the screen shot of the report:

Yes, indeed, back again into the 30 e-mails coming through during the course of week. Somehow, I am starting to get used to such number, more than anything else because it makes a round number of 6 e-mails a day approx. although I am still keen on lowering it down more and more perhaps to 10 to 15 a week! Thus the fight is still on. Let’s see how it goes further…

For today though, I would like to share with you folks a couple of links that I have bumped into or that some other folks have passed on and which I am sure you are going to enjoy quite a bit. The first link comes from Alan Lepofsky, former IBMer and very good friend, and who recently moved into SocialText, for those folks who may not be familiar with the huge piece of news that hit a couple of weeks back! Alan pointed me to this particular wild idea, which I think is very much spot on with regards to the kind of e-mail overload that plenty of folks can identify with: "Broken business processes contribute to our email overload".

In it you would be able to find some really really good gems like this particular paragraph for which I just couldn’t stop smiling while reading through it:

"Worse than the volume of email is the amount of mental energy required by each email recipient, ergo worker, to parse each exception and determine what to do with it. E-mail was once intended to increase productivity and has now become so voluminous it is counter productive. Basex determined that business loose $650 billion in productivity due to the unnecessary email interruptions. And, the average number of corporate emails sent and received per person per day expected to reach over 228 by 2010."

Indeed! Maybe that’s the problem we have been having all along. Maybe that’s where it all got started. Maybe it was down to use to complicate our own corporate existence by putting together whatever the various different business processes and then create exception after exception after exception to ensure we could all possible scenarios. And as a result of that we all went mad using e-mail all over the place to process those exceptions.

I can surely agree with the idea that business processes are the main culprit, perhaps, as to a large chunk of the e-mails we get on a daily basis and kind of wondering whether we may need to STOP, re-think things again and go back to K.I.S.S. Yes, keeping things simple, straightforward, brief, with not so many exceptions would probably help us improve the way we interact through e-mail. However, why not take things further into the next level? Why not re-think the model of engagement and move straight outside the Inbox and start re-building processes with a 2.0 flavour where perhaps openness and transparency would be part of the criteria behind them? What is it out there that may be stopping us from doing that?

I mean, we all know that most of the processes we work with throughout the course of the day are somehow broken, so why not fix them? Why not re-evaluate their validity, update them accordingly and start making use of social software tools within the enterprise. Wouldn’t it be quite something to, at least, give it a try? I am sure right from the beginning we would be able to see the benefits, like that former link / idea puts it nicely within the following quote:

"Socialtext has been building out business practice support using their customizable Enterprise 2.0 platform to return email back to its rightful place in the communication stratigraphy, which is not as the catch-all for exception handling. Their business social software makes the process more productive, reducing email by 30%."

If it sounds *so* easy, what’s stopping / preventing us from diving in and address those broken processes? Exactly! Nothing!

So what are we waiting for then? Are we just too lazy, or gotten to much used to dealing with the exceptions that we just don’t care in improving the way we work? I am not sure about you, but I refuse to think that is the case. So what is stopping us?!?

The second link is eventually a whole lot more fun, as well as educational and enlightening on what the possibilities are on moving away from the good old e-mail system(s) into a much more open and collaborative environment: in this case a wiki (This particular example coming from Socialtext as well).

The link is actually a screencast that Alan himself put together over here. It lasts a little bit over three minutes and it demonstrates how certain collaborative tasks, like gathering input, or brainstorming, can be better achieved through a wiki, which, in this particular case, taps into your regular e-mail. So those folks very keen on making use of e-mail, they still can. The rest can also then go into the specific wiki and see how they can each contribute into the overall effort.

Alan’s screencast is a very good example of how a wiki, Socialtext, in this case, can help you reduce, tremendously, the amount of e-mails you get on a daily basis as well as reducing your outbound e-mails to others. And if not, check out how easy it is:

After watching the screencast you would have to agree with me that most of the times it is not that difficult, right? It is probably just a matter of thinking outside the inbox and Alan just demonstrated it how easy it is …

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

0 votes

Leave a Reply

Your email address will not be published. Required fields are marked *