Well, not quite an easter egg of the hidden keystroke variety, but I did find something I wasn't expecting when I reinstalled Office 2007 on my computer (after re-installing the OS because of major problem - lots of fun).
The source of the surprise? Microsoft themselves.
Outlook 2007 comes with an ASS reader that I hadn't bothered to explore before, and the default installation includes subscriptions to two Microsoft "tips" feeds. One is Microsoft at Home, containing tips and suggestions for maintaining and using your computer (and Microsoft's software). Mostly at the fairly basic level. But it was interesting to see a few of my favorite "hidden gems" in one of the "Crabby Office Lady" columns (use F2 to edit just about anything in Windows). It helps that the articles are written in a light style.
The other is Microsoft at Work and contains a similar set of tips and suggestions for the working set. These range from "dealing with the economy / jobs" to more technical tips and tricks.
I don't know if these feeds belong in my regular reading cycle (particularly since they don't do full text feeds), but it's nice that they exist for more beginning users. Of course, I don't know how many beginning users know what feeds / RSS would be.
Photo: "Egg hunt" by Lilia Efimova.
Are you subject to lots of clichés? Are you a frequent user of clichés? Be careful. Phillip G Armour writes The Cliché Defense in his July 2009 Communications of the ACM "Business of Software" column:
A guide to playing the ploys frequently employed by cliché-driven management.
Unfortunately the full article is behind the Premium Content wall.
It's a fun piece because he goes through several common clichés and tears them apart. And it is always fun to by cynical with a little smile in your eye. Here are the ones he tackles:
- Do it right the first time.
- Work smarter, not harder.
- Quality is the most important thing.
- Our customers are the most important thing.
- Our people are the most important thing.
You might guess a trend with those last three. Armour discusses the cliché and the context in which it is used, what the subtext might be (generally negative toward the recipient of the cliché), and then a defense. He also warns that the defense is not for the weak of heart - or weak of humor.
In all cases, Armour's interpretation under the cover of the words is that the speaker is either insulting the recipient (you mean I usually do it wrong?), or missing large swaths of truth about business (quality is lacking, so I have to remind you it's important). The defense is either a smarmy comeback or just a data check: if we are important, do management behave in a way that confirms this statement?
How does this relate to knowledge management and personal effectiveness? My take is that clichés, can be useful or not, depending on where they show up. They can help make things make sense by referring to common themes, or using a familiar statement to reflect a deeper sentiment about the business. This can also turn on its head, as the examples in the article show. They all say something much more than was probably intended. And then there is always the simple misuse of clichés and metaphors. This often when the speaker uses them with people who aren't familiar with the original (usually non-native speakers of the language).
Photo: "Lisbon Cliché (aka Lovely Decadence)" by Rampant Gian.
As most who read my blog on a regular basis, I am a fan (and consultant) of Theory of Constraints. On a personal level, I really like how the TOC concepts blend with a lot of the personal effectiveness concepts. A big element of both is stop doing so much. More specifically, get rid of all the work in process, and focus on getting things done.
On the other hand, I was reading a semi-random interview with Jason Womack at the Lijit blog. He mentioned his coaching philosophy of "just get started." An I see a lot of benefit to this view too. As they say, if you never try, you will never succeed.
So which is it? Do it now? Do it later? Some thoughts below the fold.
Mary Abraham, always interesting, has a good one that relates to something I heard recently from one of my clients. If technology is the answer, What's the question
At the Enterprise 2.0 workshop I attended yesterday, someone asked Livio Hughes of Headshift the following question: What’s the worst mistake we can make with respect to law firm technology? His answer was interesting: Don’t fall into the habit of thinking that problems can be solved only by launching a massive multi-year IT infrastructure project. In other words, don’t assume that big technology is the answer to every question.
The comment from my customer? "This project is really about communication, isn't it?" Well, actually, um... Yes! Yes, it is about communication. It's about communication because the project we are working on has highlighted this fact that has been missing within the organization. And there is no chance the the primary project will succeed without this other element. This was only highlighted in conversation with the people within the organization, and the implementation team being open to this information.
Here's another bit from Mary (with my redactions), focused on technology.
Do you have an inadequate ____ system? Don’t assume the answer to that problem is the latest model ____. You may be able to side-step the pain of replacement and go straight to a really robust ___. Or, ..., Or..., Or... After all, we rarely need [every feature of] ____.
It's interesting that individual projects are often "about" much more than is written on the package (or the PowerPoint slide deck). It is these additional elements that have a lot to do with the success or failure project overall.
[Photo credit: Thomas Purves]
I had lunch the other day with Johanna Rothman and the topic of planning research work came up. It is difficult to plan research work because the very nature of research is one of iteration and uncertainty. You don't know if your experiment is going to work, so how can you build a formal plan of everything you plan to do?
Johanna pointed me to her article on inch-pebbles, How to Use Inch-Pebbles When You Think You Can't, and specifically highlighted this paragraph on using inch-pebbles in research:
When you do research, as my colleague Sally does, it's sometimes difficult to know when you're researching or going off into never-never land. Sally plans her work, by using a set of questions to know when she's discovered what she needs to know. Her questions are specific and detailed, so in a sense they work like inch-pebbles, but because she doesn't know where she's going, she does not create a specific plan to get there. When it's time to transition the research out of her lab, she creates a project plan and works with a project manager to create inch-pebbles for a successful transition.
What kinds of questions are useful in this context? I am not completely sure, but I have some inklings:
- What is the goal of this phase of research? (How will I know when the research is considered done?)
- What information (experiments, outside research, etc) will tell me to stop? (Stop pursuing this line of research)
- What information do I need to make it through the current phase?
- What experiments do I need to conduct?
- What are the key variables (today) that I need to explore? What experiments will give me the data I need?
The other element that I haven't fully wrapped my head around is associated with a Theory of Constraints view on the research work. I think the concept of "planned load" that primarily comes from discussions of S-DBR (such as that in Supply Chain Management at Warp Speed, my review). If I know the key constraint in my research organization (the lab, equipment, person that limits the flow of work through research), is it possible to look at the planned load on that resource and work out the flow of work that comes across it?
I think it is possible. Planned load requires knowing the capacity of that resource AND the work that I want to send across the resource. This means that I know, in general, what types of experiments I will do in the next time horizon and how much capacity those experiments require. The time horizon is generally the lead time of experiments (how much time from initiation to completion of the experiments). The time horizon does not need to be months or years (unless you have very long experiments), just enough to look forward to see when there will be capacity to run your experiments.
I'd love to hear other thoughts on this topic.
Steven Wieneke has been active in the KM scene for quite some time. I came across him while he was at GM, and he has now hung out a consulting shingle with a deep interest in knowledge management. I discovered a white paper entitled, Success in any Economy, which talks about the value of BOTH written knowledge (explicit) and personal know how. Nice compilation of thoughts.
It is true that the KM community often dismisses the value of written knowledge, but without that written material, people often have no resources and reference material to start their hunt for other people and other knowledge.
Knowledge assets are documents, technical references or other intellectual properties. These assets are one of three categories of intellectual capital an enterprise has. The other 2 categories are individual know how (technical excellence) and good discussions (intellectual exchanges).Knowledge assets can be structured, semi structured or unstructured. In this article, structured assets are virtual documents managed in a knowledge base. Semi structured assets are template documents. Unstructured assets are free-text documents. Semi structured and unstructured assets can at best be used passively, at the discretion of an individual. Structured assets can be used either passively or actively. Active knowledge assets are directly tied to individual workflow (processes or design math data) allowing continual assessment of compliance.
The TOC ICO has awarded Boeing with its award for achievement this year. Congratulations!
From the press release: Boeing Integrated Defense Systems at El Segundo Satellite Development Center Wins TOCICO North American Achievement Award for 2009
The Theory of Constraints International Certification Organization (TOCICO) at its North American conference in Tacoma, WA is recognizing the Boeing Integrated Defense Systems at El Segundo Satellite Development Center on June 7, 2009. Boeing will be presented an achievement award for its demonstrated longevity in the successful use of Theory of Constraints (TOC) tools and significant contribution to the TOC community. Mr. Charles Toups, Boeing Vice President will be on hand to accept this highly coveted award.
The 2008 award was won by the US Marines. It's not clear from the TOC ICO website if there have been awards prior to 2008.
I came across a new-to-me KM blog from Chris Jones of SourcePOV and found this piece on KM and culture: Why KM Struggles: Fighting a Culture of Control. And it seems to connect to another discussion on KM and ROI elsewhere.
Here's a great comment from the midst of Chris Jones' commentary.
KM is at it’s best when knowledge workers receive the tools and training they need to generate insight and act on it. Gearing-up for KM is lots of work, but it's the foundation for success of a knowledge enabled company in a marketplace that is beginning to reward players that are savvy about how to leverage knowledge and collaboration to innovate.
I really like the "give them the tools and training they need" and let them get rolling. The key idea behind Chris Jones' post is that while these things are important, it cannot happen if the culture doesn't allow for it.
A very similar comment came up in the knowledge management group on LinkedIn, where someone asked about ROI (again) in the discussion (not sure if that link is valid). To that, I commented:
Maybe it is not time to implement software? Instead approach the executives with the problems they have articulated (such as "innovation"), and propose changes to the process that will help remove or reduce the severity of the problems. A lot of that will have to do with the way people work, regardless of whether there is specific software in place to make it happen. What can you do with the software you have today? What could you do in addition if you were to buy the software you are proposing to buy?
I get the same sense from both of these discussions. There is a KM initiative that requires the culture and interest in the business in knowledge management or innovation or <insert knowledge term>. Once that culture is embedded within the organization, the specific projects or implementations should be able to fit within the context of the organization and the appropriate justifications.
[Yes, I realized that I am posting this at 10 pm on a Friday night.]
I'm assuming this will get reblogged by many other's, but the ideas Andrew McAfee mentions in Toward a Pattern Language for Enterprise 2.0 are interesting to me. He applies the ideas of Pattern Language (which is new to me) to the differences between Enterprise 2.0 and Enterprise 1.0. This goes much beyond the difference I site between knowledge management driven from the top or knowledge management driven from the bottom.
I’ve had for some time now the vague sense that the iPhone, Twitter, Gmail, Googling, Facebook, Wikipedia, Delicious, and other runaway successes are trying to tell us something about how we want to use technology in our lives and in our work, and if we enterprise technologists listen carefully we’ll hear what that something is.
I don’t believe that what they’re telling us is that we have to throw out all of our existing devices and applications and start enterprise IT from scratch. But we do need to throw out some tools, approaches, and philosophies, and incorporate other ones. The enterprise technologists that do the best job of this will be the ones that see their offerings succeed.
Have a peek at the couple dozen patterns that Andrew proposes. It's nice to see the differences between 2.0 and 1.0 more explicitly articulated. And some of the comments have suggested still more differences.
One area where I'd suggest some additions is in expertise:
1.0: People find experts by asking their colleagues locally or searching the company yellow pages.
2.0: People find experts through discovery of what those experts have discussed online.1.0: People answer questions by asking people and then finding specific content buried in the document management system.
2.0: People answer questions together by posing questions of their colleagues locally and distributed across the network.1.0: Experts are inside the company.
2.0: Experts are everywhere, and people can find them.
Craig Roth has posted his view on how the (Enterprise) Attention Management lens can look at the technical side of email to help with the information overload issue. E-mail Overload: No Cure, but Enterprise Attention Management Can Shed Some Light
The most popular “overload” topic in offices today is e-mail. But after all these years of incremental improvement to IBM Lotus Notes and Microsoft Exchange, surely there can’t be any low-hanging fruit left to pick to help people manage inbox overload. Or is there?
The Enterprise Attention Management Conceptual Architecture to the rescue! Rather than relying on a set of personal pet peeves or specific annoyances that have happened in recent memory, a model such as the EAM conceptual architecture provides a systematic approach for analyzing the attentional characteristics of a system.
A number of Craig's suggestions fall in line with what I've thought and commented on before. He also includes some interesting aspects associated with attention: making it easy to turn off notifications (I think they should be off by default); scheduling email deliveries (instead of "all the time"); more flexible / powerful rules...
These are all technical solutions that it would be nice to have. We still have to deal with the human side: Don't abuse the power of sending email. The inbox is not meant to be a task list.
With apologies to my dear friend Luis Suarez and his goal of eliminating email, there are just times when email does the job fairly well.
In Connected & For Better and Worse, Jon Husband pulls from today's NY Times piece on Smartphones as necessity. Quoting, Jon:
I have any number of friends and colleagues who have worked hard to eliminate or give up email … always because of the jam-ups they experienced, always so that they could avoid much of the intrusion from unwanted communications, and so that they would have more time to “converse” or communicate in other more effective ways. Now I am sure that they will spend much of their time in other, unintended intrusions from unwanted communications, or find out that email as a way of following and building a conversation, in context, is not so bad, etc.
The good parts of email is that, when it works well, it provides this ability to follow and build upon a conversation amongst a few people. The back-and-forth doesn't have to be real time, but over the course of a few days, it is a useful place to have and record a conversation.
The difficulty - and I think one that causes many people to drown in email - is that these conversations extend far beyond one or two people, or they extend outside of the single email conversation to include other email threads, websites, documents, and references to conversation fragments that happen outside the email environment (lunchtime, phone, IM, etc). In other words, the thread of the conversation gets lost or overwhelmed with everything else. Another element that Jon and the NY Times article touches upon is the social assumption that a reply is expected. This "overload" is why it is so important to have good practices around anything you use in your communications.
Some of those practices for email?
- Don't send email to people who don't need it. (Don't clog someone else's inbox.)
- Send email with clear subject lines and clear calls to action in the first few lines. (If people don't know what to do with your mail, it will clog up their inbox AND delay any response you were expecting.)
- If you must send attachments, tell people what you expect them to do with it. Is it an FYI? Do you want them to review it (by when)?
- Filter your incoming mail as much as possible (mailing lists and "news" blasts should stay out of your inbox).
- If you don't have time to reply to any messages, then don't bother checking your mail.
- When you make the time to read incoming mail, triage it immediately. There are many techniques. I still like the 4 D's: Do, Delete, Date, Delegate. This is all geared around getting it out of your Inbox, so it doesn't consume extra mental cycles. But you also must have a mechanism to access it at the appropriate time for those things that have been Date activated or Delegated. (Another take on email triage.)
- Be intelligent about using your smartphone in connection with email processing: many platforms make it difficult to file away mail, meaning you have to process it again when you get back to your main mailbox. The smartphone should be used to clear out the obvious Delete messages and potentially respond to emergencies.
This discussion of the limitations of email leads me to comment briefly on the written excitement over Google Wave. I'm not about to watch the 80 minute video posted to their website, but several commenters have boiled it down to something that makes more sense to me, namely the quote from Lars Rasmussen: What might email look like if it were invented today? (Good reviews from Tim O'Reilly and Mashable's Complete Guide.)
To my eyes, Google Wave is an attempt to address the many drawbacks of email that I mentioned above. It still assumes conversations are happening entirely electronically (and that the technology will be around to support Waves), but it also acknowledges the naturally distributed nature of communications. We will see what comes of it when they get around to releasing prototypes sometime later this year.
Back to the original topic... People want to be connected, and email has been a good source of this connection since the 90's. The problem is that there is just too much of it, and that it is over-used. Luis Suarez' is taking an extreme position intentionally, but many people would benefit from simply sending less.
Michael Idinopulos at SocialText has an entry telling CIOs: It's Strategy Time in which he argues that Web 2.0 concepts and ideas (as described by Enterprise 2.0) provide an opportunity to move away from dealing with servers and firewalls to helping define the strategy for the business.
If you're a CIO, your company is looking to you to show the way. How will Enterprise 2.0 change the way you do business? What benefits can your company realize? How will this change the way you collaborate internally? How will it change your interactions with customers?
Social software and the enterprise versions of it are clearly hear to stay, as evidenced by the Internet Evolution series from Information Week and others. My take on this is that the IT group are often the last to know. They are fighting fires and dredging up money for the big XYZ implementation, and budgets have been cut so much that they find very little time to do forward-looking, interesting research.
So... it will be the business again who ask for the tools to transform the business.
Or will it? There are plenty of forward-looking groups out there who have a deep connection with the business already. They provide suggestions to the business as to what might help, the business gives it a whirl (often the early adopters), and if it works, a larger effort is made. But these are exact the kinds of CIO's and their colleagues that businesses need.
And it isn't just the CIO's who need to work with the business - it is everyone. It's the call to collaborate on getting the work done, as well as on the future of the business. It's just a question of which end of the discussion you happen to be.
KJolt Memberships
