I attended my first evening meeting of Boston's KM Forum. At the start of the meeting, we enjoyed a nice conversation about what each of us are doing with knowledge management. Several people are dealing with SharePoint, and several others are interested in semantic analysis, and several others are related to librarianship at some level.
Gian Jagai of Hitachi Global Services was the main speaker discussed the entertaining topic of "So You Were Just Promoted to Knowledge Manager - Now What?" Much like my original job at Pharmacia, he created the position himself. For Gian, the need was based on the realization that there were a lot of holes in the way information moved around the organization. He now works for the Global Services organization.
One definition that Gian uses for knowledge management is "Bridging the gaps between product features and customer needs." Interestingly, this is essentially what I'm do as a product manager.
Pillars of the KM program from Gian's perspective are
- Communities of Practice
- Platforms
- Recognition Programs
- Service Development & Delivery Processes
- Internal KM Services
The rest of his discussion focused on the efforts around communities of practice. The justification handily tied into several of the core values in the organization: Community, Openness, and Ownership. Other justification work for the project looked at what's-in-it-for-me, both for the community members and the company. This sparked a conversation about Buckman Labs' efforts and the idea of having human mediators in the knowledge communities. And it turns out that Gian's first role had to do with being a community coordinator.
The next step for Gian was to build the initial community into a corporate-wide effort in early 2007. He drew several people from the initial community and built out an early group of 30 people from across the company, all focused on a common business need. There was an interesting discussion in the meeting of some of the cultural aspects in dealing with the behaviors in various parts of the world.
As Gian was talking about the work he has been doing, I had a realization about one of the things I am doing in my job. We have internal "product core teams" that meet to discuss various aspects of the products: what's happening, sales tips, market intelligence, etc. This is exactly the kind of thing that a community should be doing. Now I just need to figure out how to make it something that my team develops together, rather than being so driven by me.
Several friends, new and old were in attendance. I think David Hobbie is planning to post something about the event too.
Usually, this isn't terribly interesting information, but I made connections around the globe with friends in KM and technology.
I went to the KM Forum meeting and met Ray Sims (for the first time), David Hobbie (again), Lynda Moulton, Larry Chait and several other members of the forum. Among other things, I discovered that David is a new neighbor.
Sadly, Matt Moore didn't make it to the KM Forum on his whirlwind tour of KM aficionados in the United States, but that didn't stop me from meeting up with him for dinner.
Since I had seen mention of PopSignal on Twitter, I decided that Matt and I should go there. We saw a bunch of Boston Tweets: skalik, amandagravel, Nathan, the other Nathan, vanhoosear. And based on my Twitter feed, I missed several others. I also got to meet Paul Michelman, the host of HBR IdeaCast, which I've been following since I got my iPod.
Then Matt and I went off for dinner and had a great conversation about knowledge management, Theory of Constraints, buying real estate and other fun.
And how does it end, but I stop by Joining Dots and find this great rendition of Lou Reed's A Perfect Day. I love the original, and this one does a nice job too. That has to be Shane MacGowan with the teeth.
I have been very fond of the term "context" in talking about knowledge management for a variety of reasons. But I hadn't thought much about the definition.
I was reading something today that just clicked for me. Context provides a frame of reference to what you are reading or hearing. The better I understand the particular frame of reference (context), the better I can understand what this information or knowledge means.
It's an obvious definition, but it just made a whole lot of sense today.
On recommendation of a friend, I re-read Necessary But Not Sufficient
This book contains something very valuable that I have mistakenly attributed to The Haystack Syndrome
- What is the power of the technology?
- What limitation is being overcome (limited capacity, for example)?
- What old rules were followed because of the limitation (and need to be eliminated)?
- What new rules need to be created?
I liked how the authors walked through the discovery and articulation of these rules with the characters. The "limitation" is often hard enough to discover, but those "rules" that came about because of the limitation are a bear. They quite often have nothing to do with the technology being proposed, but without acknowledging them, the limitation becomes the rules themselves and the technology (or any other change) will never see its full benefit. I enjoyed the comment by the software engineer that many of the change requests that come from customers have to do with their desire to re-implement many of the old rules into the new software - thereby ham-stringing any hopes for benefits.
My friend recommended it because I am now working for a good-sized software company, and he thought some of the lessons here could be useful for my thinking about how our software impacts life for our customers. We don't sell ERP, but the common justification for my products has to do with efficiency, visibility, streamlined processes, improved collaboration, etc. Of course these things are helpful, but if you don't know which of these is connected to the bottom line, they are fairly meaningless. And this is where I have been struggling with understanding our customers.
Happily, there are some specific examples of how our customers used our software to significantly improve things at the bottom line. I have one story that I hope to document in more detail where a customer nearly doubled the capacity of a key manufacturing plant by optimizing a specific operation with our software. But, in my view, that is just an example of how the software could be used. One could just as easily use it to optimize an operation that has nothing to do with a real constraint.
So, my struggle is how to understand our customers well enough to make strong connections to value at the end of the day, not internally-allocated savings that never end up on the bottom line. And one thing has become clear in re-reading this book and thinking about our customers: there are a lot of internal rules and ways of doing business that need to change if our software is going to have anywhere near the impact we claim it will have. How do I get that process started?
What about the book itself?
With regard to the story in the book, I enjoyed it for what it was. It follows the usual path. The vendor and implementer see they have a problem meeting their forecasts. They come upon the idea of selling bottom line value, rather than the usual justifications that their industry offers. And they discover just how hard it is to turn "visibility" into a number that means anything to the bottom line. Eventually, they hit upon a way to think about their software in a new way - a way that is inspired by Theory of Constraints.
It's about this point in the book that it seems to shift from being mostly "novel" into mostly promotion of the TOC way. While the story continued, there seemed to be far too many leaps in logic and discovery within the novel that it was very distracting for me. (Lot's of "how did they jump from X to Y?" thoughts running through my head.) I don't recall it being so heavy-handed the first time through, so maybe it just goes over the heads of newcomers to TOC.
If you have anything to do with software and are interested in TOC, I think this is a good book to get you thinking about how things really impact the business of your customers. But you might stop after the halfway point, unless you are interested in seeing one view of how all the TOC pieces could come together. Of course, the rules for technology don't show up until that second half, so maybe keep reading anyway.
One of my masters students happened to dredge up a quote from Herbert Simon that nails the problem of information overload. And then I have to laugh when I see that he was thinking about this back in 1971. This from the description of Attention economy in Wikipedia:
"...in an information-rich world, the wealth of information means a dearth of something else: a scarcity of whatever it is that information consumes. What information consumes is rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it" (Simon, 1971, Designing Organizations for an Information-Rich World, p 40-41.).
The focus of the quote is on attention, but that is the problem of information overload - we lose the ability to focus our attention on those things that really need it.
Love the title of the book too!
And I see this isn't the first time this quote has opened my eyes. I knew it sounded familiar!
A couple tools lists turned up recently that might be of interest. First, the Improvement & Development Agency (I&DeA) for Local Government in the UK has published a KM library: tools, techniques and case studies (here's a link to the report pdf) that provides brief outlines of a dozen methods, grouped into three areas:
Connecting People to Information and Knowledge
Connecting People to People
Organizational Improvement
The report concludes with several appendices that provide a little more detail on some of the techniques. I like appendix three: some quick thoughts on how to map your personal relationships. It's not quite clear how this fits into the larger guide, but it might be helpful to use as a tool for personal effectiveness. And, if done as an exercise within a group, could be a useful way to build some understanding of how information flows. A social network analysis, of sorts. [Found via Above and Beyond KM via Talking Knowledge Management]
The second item is Dennis Kennedy and Tom Mighell's The Lawyer's Guide to Collaboration Tools and Technologies: Smart Ways to Work Together. The blurb at ABAnet claims
This first-of-its-kind guide for the legal profession shows you how to use standard technology you already have and the latest "Web 2.0" resources and other tech tools, like Google Docs, Microsoft Office and SharePoint, and Adobe Acrobat, to work more effectively on projects with colleagues, clients, co-counsel and even opposing counsel. In The Lawyer's Guide to Collaboration Tools and Technologies: Smart Ways to Work Together, well-known legal technology authorities Dennis Kennedy and Tom Mighell provides a wealth of information useful to lawyers who are just beginning to try these tools, as well as tips and techniques for those lawyers with intermediate and advanced collaboration experience.
Collaboration technologies and tools are the most important current developments in legal technology and are likely to remain so for the foreseeable future. Explained with minimal technical jargon, the book focuses on highly practical and usable ideas that you can put to work straight away.
With practical advice on how to use specific tools and concrete action steps to take, lawyers and law firms at all levels will benefit from working together better.
When the table of contents to a book is 13 pages long, you know that it is either incredibly detailed, or there are a lot of topics to cover. Or both. If I were doing more in the way of legal KM, this would definitely be a hand reference and possibly a field guide. Of course, the ever-changing nature of KM - and Web 2.0 in particular - will require regular deletions and additions to the various tools described throughout.
Metrics (what a researcher client of mine calls indicators) for quantifying personal productivity improvements is a topic I started tracking when I get into the field. Having some kind of measure is important if you want to determine whether your presumably improved changes have actually helped.
He puts some good thought into the topic, providing a background on metrics (Drucker: If you can't measure it, you can't manage it.) and some thoughts on how that fits into the realm of personal productivity. And I particularly like the list of challenges to productivity and performance from Do You Know The Real Productivity Problem?
- Unnecessary Interruptions and Distractions
- Poor Planning and Scheduling
- Unclear Priorities
- Excessive Paperwork and E-Document
- Ineffective Meetings
- Ineffective Delegation
But what about those measures? Well the problem is that either you get very complex and specific to the job with the not-entirely-useful metrics like number of articles written or lines of code written. Or you step back and look at the evidence of effective and productive work. Combining my thoughts with those from Matt's article you have things like:
- Time spent on activities directly related to your objectives and those of the company.
- Previously-read mail in the inbox (awaiting some action). Ideally, kept to a minimum
- Amount of incoming / outgoing email. There is no specific number here, but I think the flow of email indicates something. Too much flow and you are spending all your time reading and responding - there is probably a better way to spend your time.
- Similarly, outside of email, there is time spent looking for things: files, information, people. Can you organize your own information in ways that make sense for you? Can you work with the company to provide better access to information that is otherwise hard to get?
- Time spent on interruptions: colleagues, phone calls, IM's, etc. This should also be kept to a reasonable minimum. Learn how to tune out that co-worker who always talks over the cubes.
What about you? What measures make sense for you?
I took We All Fall Down
The book is a business novel that tells the story of how a hospital administrator discovered the Theory of Constraints and applied what she learned to the operation of her hospital -- and in classic business novel style, she applies some of the principles to her personal life.
The novel walks through the use of several TOC "thinking processes," such as the conflict cloud and the current reality tree. One thing that was interesting to me was the way in which the central character developed these tools and then turned them around for use in conversation with people with whom she was trying to come to agreement about a course of action. There was a methodical process of developing the logic, and then just as methodically turning it around for use in discussion. The way this worked out in the novel was the demonstration of how each subsystem interacts with the others - and that when the subsystems act locally, they can easily make a mess of things for the system as a whole. This is the classic local optimization problem.
In my life today, I see application of the lessons of the book. I frequently hear from our users that there are barriers to extending the use of the software beyond a certain point, even though many people agree in general that the software could be worthwhile. I think there are some elements of the plan missing between the general agreement of value and actual implementation. And as the vendor, we need to help our customers see where that resistance might be and look for mechanisms to help them devise the best solutions possible.
Where were you at 8:05 pm, Saturday, May 9th, 1987?
Sounds like a wild question, doesn't it? How could you possibly remember events that specifically, unless that happens to be the day you got married or some other key event in your life.
This is essentially what the government (and shareholders) want to know. The FDA and other government agencies want the ability to dig into the history of any data or facts used to support your claims. They want to be able to see how you've come to the conclusions you have drawn, and they might want to dig through the reports and get to the source reports and even the original data. Essentially, they want to know the provenance of your information.
Before the preponderance of electronic records (and the acceptance of such by the government), this was done through painstakingly digging through paper records via bibliographic references. Today, essentially everything is electronic, which means there should be some mechanisms for tracking through the data. Unfortunately, to do this the right way requires a significant technical infrastructure and business support for doing it, so the bibliography is still of significant value. There are some products out there, notably NuGenesis (now owned by Waters) has created and promoted the scientific data management space with a product I've always thought was interesting. As I state above, it requires a significant commitment to use the tool throughout the long lifecycle of new products in order to get as much provenance built into documents as possible.
This is inspired by another Communications of the ACM article from April 2008, The Provenance of Electronic Data (pdf available), by Luc Moreau, Paul Groth, Simon Miles, Javier Vazquez-Salceda, John Ibbotson, Sheng Jiang, Steve Munroe, Omer Rana, Andreas Schreiber, Victor Tan, and Laszlo Varga. Interestingly, there is a Provenance Aware Service Oriented Architecture project.
A friend commented recently that I should check out Newly Corporate, a group blog about Gen Y's who are new to the corporate world.
Dan has a recent pair of articles on expertise in the business world that I found interesting. These are 5 Ways to Establish Yourself as an Expert and The Curse of Knowledge. In the first, he talks about some methods to get your name out there as an expert:
- Provide answers.
- Get published.
- Get a patent.
- Print it and hang it on the wall.
- Learn the market.
And in the second article he talks about making sure that you (the expert) aren't so far removed from the early days that you forget what it is like to be a non-experts. When you forget what it's like, it becomes very difficult to see things from their perspective and thus help solve their problems.
Neither of these are earth-shattering ideas, but they are consistent with what I've read elsewhere. Interesting to see the ideas being promoted to people who are relatively new to business. It just reminds me how important it is to become "known" for some type of skill and expertise as soon as possible.
Here's another take in the long line of "lots of email" discussions. This time it is Are You Really Being Paid to Read 200 Emails a Day? by John Care of Mastering Technical Sales.
Email is a wonderful productivity tool – but usually it seems like someone else is being productive at your expense! How do you harness the power of email, without being a slave to your inbox or becoming addicted to your Blackberry? Read on for some proven tips and techniques which will sharpen your communications, put your inbox on a diet, and give you and your team more time selling and less time typing.
John Care does something interesting with this article. Sure, he talks about the basics of being smarter around processing the email, but he couches the discussion in the bigger picture. I particularly like the last section where he talks about receiving fewer emails. This is where the balance of personal effectiveness faces outwards to the group. John's suggestions in bold.
-
Exercise your power. Stop an email thread if it is getting out of hand. Use other means, like your feet and the phone.
-
Tell them what you want. Don't be circumspect. Don't bury requests in the body or end of a long message. Clarify what you need up front, then use the rest of the message for details.
-
Make the subject meaningful. What is it you are asking for? Make the subject as clear as possible. Pretend the subject line is Twitter for the rest of the message (but only ~50 characters).
-
Make your boss (or client) more efficient. This is a collection of #2 and #3, but it is repeated for the impact it can have on managing up.
-
Monitor the email groups you belong to. This isn't as clear, but if you expand it to "monitor what's going on," it makes more sense. Basically, if you are aware of current events, there is less chance you will get those red-flagged, emergency emails at the end of the day. This one requires balance, though. Too much attention paid to monitoring can feel just like too much time in email.
[found via Steve Johnson at the Pragmatic Marketing Blog.]
There is an interesting pair of articles that focus on collaboration in the April 2008 Communications of the ACM. And one of them leads to even more interesting stuff.
The first, Missing Links: Building Critical Social Ties for Global Collaborative Teamwork by Ilan Oshri, Julia Kotlarsky, and Leslie Willcocks talks about the importance of face-to-face (F2F) meetings in the world of truly global operations. Their focus, however, isn't just that team members should meet in person. The paper goes another level deeper into thinking about what should happen to build and maintain those social ties.
They describe a life cycle of social ties that starts with introduction then build-up then a renewal cycle. And they talk about the kinds of activities that should be happening during each of these phases. Most of these have to do with the things that need to happen socially to improve the ties. There is minor discussion of the supporting tools. The tools are there to support what the people need.
The second article is an opinion piece by Peter J. Denning and Peter Yaholkovsky, Getting to "We". They provide a fairly straightforward description of collaboration as compared to information sharing, coordination, and cooperation. (Thomas van der Wal discussed this article last week.) Collaboration defined by D&Y:
Collaboration generally means working together synergistically. If your work requires support and agreement of others before you can take action, you are collaborating.
They also use these four elements to highlight the various "collaboration tools" and where they fit in their primary function. For example, blogs are information sharing tools; project management is about coordination; discussion forums are about cooperation (usually); and brainstorming is an example of collaboration.
It is interesting to come back to this article after reading the "Missing Links" article later in the issue. I note that none of the tools mentioned in the collaboration bucket are technology - they are methods of doing work together.
In their definition of collaboration, Denning & Yaholkovsky referenced Scott London's Collaboration and Community paper, so I popped over to have a look. Interesting parallel with what they have said, not surprisingly. I particularly liked his list of characteristics of collaborative endeavors.
Collaborative endeavors generally share a number of basic characteristics:
- The problems are ill-defined, or there is disagreement about how they should be defined.
- Several stakeholders have a vested interest in the problems and are interdependent.
- These stakeholders are not necessarily identified a priori or organized in any systematic way.
- There may be a disparity of power and/or resources for dealing with the problems among the stakeholders.
- Stakeholders may have different levels of expertise and different access to information about the problems.
- The problems are often characterized by technical complexity and scientific uncertainty
- Differing perspectives on the problems often lead to adversarial relationships among the stakeholders
- Incremental or unilateral efforts to deal with the problems typically produce less than satisfactory solutions
- Existing processes for addressing the problems have proved insufficient
