Knowledge Jolt with Jack

Incubating twins

2008-11-20T22:32:25Z

No, I do not have another pair of babies coming. I have, however, seen two articles on business incubators this week. It's not something I usually worry about, but the coincidence strange. I almost thought they were reprints on reading the opening paragraphs, but quickly found that they were not.

Art Murray has an article in the Nov/Dec 2008 KM World, The Future of the Future: Incubating the next-generation enterprise. And Director Magazine from October 2008 has an article from Joanna Higgins, Slicing the pie on the same topic.

They each take a slightly different view. Murray is surprised that the incubators never accomplished their high-minded vision of enabling small business owners to collaborate on common business needs. That said, there are nearly 5,000 incubators around the world (from National Business Incubation Association). Higgins' article talks about some new incubators that are starting ("Incubator 2.0") with the hope of tapping exactly the knowledge that Murray finds is never tapped. Interesting.

The real world for enterprise 2.0

2008-11-19T04:08:16Z

James Robertson and Matt Hodgson had a pair of articles recently that I see as related on the topic of doing something with Enterprise 2.0. James gave us some tips on what teams should consider when Implementing enterprise 2.0 in the real world (abbreviated):

Now that the hype of enterprise 2.0 is starting to settle, it’s clear that there are many valuable approaches that can (and should) be put into practice.

Don’t be afraid to experiment.

Take a ’safe-fail’ approach.

Have a clear purpose.

Take it seriously.

Make it work now.

Match the culture.

Build on the experiences of others.

And Matt gave us some important thoughts on If you build it will they come?, suggesting that there's much more to technology roll-outs than simply implementing the latest must-have technology. It is all about understanding the needs of the community, including how the organization is aligned (or not) to take advantage of those tools. His summary:

The question, then, should be “If you understand what users want, and then build it in such a way as it aligns with their needs and those of the organisation, will they come?” The answer, of course, is yes!

I think this pairs very nicely with James' thoughts, and I think they are both in Australia. Maybe there is something in the water.

Simple list-based task management

2008-11-18T23:16:41Z

Mark Forster has posted his Simplest Time Management Method.

I discovered that all I had to do once I’d drawn the list up was to draw a line at the end of it. Then I continued to add new items to the end of the list but didn’t allow myself to work on them until I had finished all the items up to the line. I could do those in any order I liked.

Once I’d finished the items above the line, I drew another line at the end of the new items and did the same again.

I like the simplicity of this approach. You get everything in the list, and you give yourself a basic rule that prevents leaving those tasks-I-don't-want-to-do behind. And you can still feel like you are getting things done.

Web 2.0 as applied to chemical engineering

2008-11-18T23:09:33Z

I'm in Philadelphia this week for the AIChE Annual Meeting, which is its usual collection of networking and technical sessions about all things engineering. (I am participating on a panel on the future of chemical engineering education on Thursday.) There was a session today on the application of Web 2.0 ideas in chemical engineering.

The opening talk by Scott Butner of PNNL gave an overview of the standard Web 2.0 ideas and concepts that I won't repeat. And he also gave the best discussion of how and where Web 2.0 might apply in chemical engineering. These applications include

Collaborative knowledge management, whether in local teams, in the entire enterprise or beyond the walls of the organization. Just imagine being able to gather experts on arcane technical topics without having to be all in one room. Or even not-so-arcane topics, but bringing to bear the collective knowledge and experience of many more people.
Building upon communities of interest.
Increasing access to rich data sources. As more and more data become available with associated metadata, we can use some of the mash-up tools to recombine that data and visualize it in new ways. For example, EPA data about waste streams drawn on a map or recombined with other relevant data.
Educational opportunities. He didn't give many details, beyond mentioning that there was a YouTube video contest. There are opportunities for sharing videos and presentations, but that is barely Web2.0, other than the sharing-across-boundaries aspect.

Beyond these topics, I could imagine a few other ideas, particularly in light of the other talks on pharmaHUB, virtual organizations, building ontologies, and value network analysis.

Making engineering calculations available online. Of course, this has been happening for a while. The Web2.0 twist is that we should make the calculations available by web services as well as a user interface. And you could pull data from many potential sources, not just from a data file sitting on your local machine. And then publish the results as its own model for further re-use, or as an educational module.
On the other end, provide API's for doing the data analysis, whether that data comes from a physical system or from a model of that system. Again, these things exist, but they are frequently locked into closed systems.
Outside of engineering calculations, there is the basic need of getting chemical engineers more engaged in these online communities. I've never been excited by the level of participation and interest from the larger chemical engineering community.

One of the discussion points was around "what is truth" in the context of user generated content and information that can be changed by anyone. This is a familiar worry in the context of wikis, but it also has implications for the academic peer review process. If one can publish and get nearly instantaneous feedback - both supportive and negative - why would you want to submit to the traditional blind review process that takes months at its best. Even more important is the idea of disseminating your ideas quickly with those people who are truly interested in what you are studying.

Who is smarter?

2008-11-18T03:30:59Z

I have a bunch of articles awaiting comment, but this one seems to demand quick turnaround. A colleague forwarded How Companies Are Using IT To Spot Innovative Ideas by David Greenfield from InformationWeek's 10 November 2008 issue. It highlights how research organizations are adding prediction markets to their process of selecting new ventures to pursue.

The use of these collective decision-making technologies, both sophisticated prediction markets and simple voting tools, is spreading, and they're increasingly being paired together as a component of corporate innovation programs, helping companies sort through reams of ideas--from new products to customer service to productivity improvements--to find that handful of blockbusters.

The idea of prediction markets always leads down the discussion path for wisdom-of-crowds. In these examples -- people with related domain knowledge all working together to gauge what ideas seem to have the most value for potential research. But this isn't that much different from what goes on within good research companies on a regular basis. And this article highlights that prediction markets aren't necessarily a silver bullet. If you aren't getting valuable ideas to begin with, using collective filtering on bad ideas isn't going to do much good.

But where do companies get those better ideas? That's the golden question. Based on everything I've seen and done, the surprising new ideas come from a combination of "the prepared mind" (expertise) and strange ideas that appear to come from left field -- the innovation-in-the-gaps concept.

The article from InformationWeek is clearly focused on technologies that support prediction markets. Bringing together opinions from people spread around the company, or around a larger industry, essentially requires smart use of technologies. It be fun to play with some of these in real-life situations. I could even imagine doing something like this with customers -- assuming we had a large enough body of people who would participate.

Product Management 101 from Christopher Cummings

2008-11-12T19:26:39Z

I attended a webinar on Product Management today entitled, Product Manager 101: What Does A Product Manager Actually Do by Christopher Cummings of Lycos (did you know that they still exist?). His short form definition:

The product manager is the glue that binds the team together and the grease that keeps the product moving in the right direction.

So, what does a PM do? There are some key areas where product managers get involved, and these sound rather familiar from other presentations and recent training. A product manager

Understands the market
Develops market-based product strategies
Creates relevant and usable documentation
Brings products into the market
Bridges every department that touches the product.

Of course, he went into detail on each of these elements with examples and highlights. Of the items that caught my attention:

Use the software - a lot. Product managers have to know how the software works and what it does, and how customers expect it to behave. I've heard / seen others that have said the product manager doesn't necessarily need to be intimately familiar with the software. I suspect this depends on the anticipated usage. I have colleagues who sell infrastructure software that is difficult to "use" unless you have a full scale manufacturing plant outside your office.
Keep a record of customer (and potential customer) compliments and complaints.
Do plenty of research in understanding the market and developing those strategies. This is a key long-term activity that is easy to let drop when the short term work rears its head.
The product manager is the face of the product. This swings both ways: Just like your waiter at a restaurant - they can make or break the perception of the product. In my experience the product manager is much more critical for internal perception, as the marketing and sales teams are heavily involved on the externally-facing work.
The 5-C's of customer interactions: be Clear, Concise, Confident, Courteous, and Completely understand issues.
The PM is responsible for profit & loss (P&L). This is a new one on me.
Leverage your networks. Access experts inside and outside the company. Find customers and potential customers via your network connections.

Cummings keeps his own blog and posted a short set of slides along these lines few weeks ago. The presentation spent more time on the details behind these.

Product Management 101: What Does A Product Manager Actually Do?

View SlideShare presentation or Upload your own. (tags: lycos senior)

So you think you know something

2008-11-07T05:01:26Z

Kevin Meyer has a great story about visiting a Toyota manufacturing plant, getting to see what lean is really about. JKE Day 1: Toyota Kyushu - The Manufacturing Ballet.

Do you think you understand lean? Then you might want to visit Toyota Kyushu on the Japan Kaikaku Experience.

His story is great. Many of the things I have heard and seen about Lean are right there in plain sight during his tour of the plant.

This article, particularly his introduction, where he says, "I thought I understood lean pretty well. I was wrong." reminds me that everyone has need of continuous improvement -- or at least that it is always possible. Many professions require continuing education, but the sense that I get from most people is that they do these things because they have to -- not because it brings new depth or breadth to their expertise. Of course, the fact that he had this particular expertise enabled him to see things that others may not have noticed -- or he sees implications in ways that others may not. That's the beauty of the prepared mind.

My father, retired many years, still reads his technical journals and heads to the local university library to collect still other technical papers. He's still writing Fortran code from time to time! Lifelong leaning in action.

This whole past year has been a learning experience for me in a new position, (somewhat) new industry, and a new city. And I expect that to continue, regardless of where i work and live.

KM must be a gender thing

2008-11-05T07:09:47Z

I've been catching up on some backlogged blog reading (either by reading or just skimming), and I realized that I need to move Mary Abraham's blog, Above and Beyond KM into a different category, so I see it more often.

Mary's KM and the Pantyhose Fallacy from last week strikes a humorous realization for me. The Pantyhose Fallacy?

Here's the Pantyhose Fallacy: for years retailers have sold us a bill of goods -- that it is possible for people of varying sizes and shapes to wear an article of clothing sold in a single size. They call it "one size fits all." The sad truth is that the one size fits badly and doesn't remotely fit all.

Mary suggests that KM vendors (and IT departments) have fallen into this fallacy, assuming what works well in one place must work for everyone. I think there is a strong connection here to the idea of failure-by-consensus.

The problem is, of course, that in men's clothing there is the concept of one-size-fits-all, and it sorta works. (Well, maybe not one size, but one basic design that fits men's shapes.)

Maybe this is the reason for such troubles. We just need our organizations to be more "manly" and accept that they are just like everyone else. I'm sure that those KM solutions will work just perfectly.

Passive and active knowledge

2008-11-04T18:44:42Z

In a conversation at a user group meeting, we were talking about options for adding foreign language to our products and the need for training in local language. Like many companies, we've made the effort to internationalize, but there is so much more to be done. The comment that I got today was that these customers don't particularly need local language for the software -- using the software is passive knowledge -- what is needed is that the training should be offered in the local language.

On the other hand, in training users get to think about their problems and ask questions. This is technical knowledge that's being discussed. It's hard to hear it in another language, even one where you might be proficient, and translate that into how you work. Even more, it is difficult to ask detailed, technical questions outside of your mother tongue. It is this active knowledge that is much harder to manage in another language. Having trainers who understand the language (or who's mother tongue is something other than English, so both sides have to work at translation), is much more important than converting the software for local language. And... it should be lots cheaper.

[Of course, there continue to be new markets for our products where local language in the software may be of more value.]

Has this idea of active / passive knowledge come up before? There is a connection, I suspect, to implicit / tacit / explicit. But this articulation of it seems to make more sense. At least it did a few hours ago as we were talking.

Product Management training from ZigZag

2008-11-02T21:12:20Z

My company brought in John Mansour of ZigZag Marketing to do some refresher training and provide some ongoing guidance around our product management / product marketing function. While I am not going into details about the company perspective on the training, I can provide an overview of the training for reference.

A key element of all the training was simplicity. John Mansour repeated a number of times that if the new system isn't simple and helpful, then it doesn't make sense to use it. And for me, with no previous product management training, simplicity and the whole course were quite useful to put everything I've been learning on the job into context of a process. The in-class exercises also helped me formalize the knowledge I have about the industry and my products in a useful way.

The bulk of the training was spent in going through key elements of their Product Management Framework, which provides much more structure around what and how product managers and colleagues are supposed to be doing. Many of us expressed sentiments of the variety, "I already do many of these things, but not in a way that helps me complete the next task or reuse the material when I come back to it later." For people who have seen Pragmatic Marketing's Framework, I see a lot of overlaps.

The ZigZag framework makes a lot of sense from this perspective too. Get an understanding of the market in general, strategize on how to address that market, figure out specific customer needs, design & develop products to meet those needs and then launch & market those products. There is a lot of reuse of material from one step to another. John Mansour joked that this is "green product management" because the general outline is to re-use as much content as possible. Oh, and repeat the process in a sensible cycle.

In an interesting connection to Theory of Constraints, in the discussion of Strategy elements, I heard some parallels with the TOC idea of the "throughput operating strategy." Once the strategy for the company has been defined in conjunction with the product management efforts, make sure that everyone is aligned with that strategy. For those very familiar with TOC, this is the hardest: Step 3 - Subordinate everything else to the [decision].

Usability: "It's easy to make a product hard to use." Implication being that it's difficult to make a product easy to use. The key is to go back to the business problem users are trying to solve: Does the product help them or hinder them?

Proof point: "The product is nothing more than a proof point." Proof that we've done our research and really understand our customers' business problems.

Chemical supply chain is the same as any other

2008-11-02T18:13:57Z

I've re-joined the AIChE (American Institute of Chemical Engineers), and one of the benefits is their monthly magazine, Chemical Engineering Progress, which looks a lot different than it did when I was a member five years ago.

In the September issue there is an "Ask the Experts" column on Managing a Responsive Supply Network (pdf) by Ray Adams of SAP. He covers a lot of familiar ground on the impact of variability and predictability of the supply chain. But he doesn't take it to the next step in discussing what one could / should do to mitigate all these factors.

There has been a lot of work in chemical engineering circles (and others) on optimizing the production at individual facilities and across entire networks. As Adams indicates in his article, however, the traditional mode has been to produce whatever can be produced and shove it into the supply chain. This has the guaranteed effect of having a glut of stuff that no one needs AND absences of things that the supply chain wants.

What are the variables in the supply chain? (Adams again): demand forecast, production rate, transportation times (upstream and downstream). In multi-product plants (and supply chains), the optimization problem can get fairly complex fairly quickly. On the customer end, there are also variable time from a perceived need for the product and placing an order.

Why are these things a problem? Typical practice is to attempt to forecast demand out many months -- much longer than the time needed to actually make the products -- so that the plant can have as much flexibility as possible in arranging the "optimal" schedule for equipment utilization or other metrics. When variability rears its head on this kind of time frame, you are guaranteed to have overstocks AND shortages at the same time.

In this case, the problem can be significantly solved by decomposing it. The time for getting a product from the plant to the customer is some version of time customer waits to order + time to manufacture + time to ship. If there is a layered distribution network, there are multiple order-ship cycles in this case. The way to reduce this time (I am assuming a manufacturer wants to reduce the time from raw material to delivery to the customer), is to check each element and see what is happening.

Forecasting is mostly a black art. Use it to drive longer-term marketing efforts, but not the production schedule. But, but, but you need that forecast to decide what to make! No, just make what your customers are buying. This means your production time and your distribution network can move quickly in response to those needs. To do that, the entire supply chain needs to know what is being consumed at the end of the chain, and it should work in concert to pull goods through as they are sold. In other words: remove the customer-order wait time. Make it daily (or instantaneous) with electronic reporting. The transportation time variability is what it is, but shouldn't be a significant portion of the lag. The big work has to do with shifting the manufacturing facility to be more agile and flexible, working with smaller batches, so it can respond more rapidly to demands of the market. I suggest that Theory of Constraints can work in the plant and in the network as well.

How do I decide what to blog about?

2008-10-31T02:52:25Z

James Dellow of Chieftech has asked me (and some others) How do I decide what to blog about?

It seems pretty obvious to me: I blog about the stuff that interests me.

But this isn't the whole story. I clearly go through periods where I blog more or less, depending on a wide variety of factors. And I don't think there is a serious change to the amount of "things that interest me" over time, though which things catch my attention certainly do shift. So what else affects this decision?

I base some of the decision on what I think my audience might want to read. The stuff that brings me a lot of feedback definitely influences my future blogging decisions. I also pay attention to what my readers and the wider circle of my friends and colleagues read. And I do that by reading many other blogs, twitter feeds, books, periodicals, etc. I do ego searches and explore what other people are saying about what I've written to see if that inspires still more writing.

And there is the time and propriety issue. I find myself being consumed with family and work, and have less time to devote to longer posts. And some things about work, and in the past my clients, don't belong in this blog.

So, to sum up: I blog about the things that interest me that I think will interest my audience, when I have the time.

And I noticed that Dennis Kennedy has posted on a similar topic (with brevity) and linked to Andrew Sullivan's article from The Atlantic on Why I Blog. Two slightly different topics, but both interesting. Rather than claiming that the blog is dead, this path on the discussion is much more fruitful.

If you think this is an interesting meme, feel free to pick it up and run with it on your own blog. I'm not going to tag anyone explicitly.

South Euclid has a cool library

2008-10-31T01:38:19Z

I grew up near Cleveland, and my wife discovered this article on the America's 10 Coolest Public Libraries from MSN City Guides. The South Euclid library is mentioned on the 2nd page.

The South Euclid Branch of the Cuyahoga County Public Library doesn't just look like a mansion -- it is one. Built in 1928 for the aptly named William Telling, this gorgeous house has 26 rooms, all filled with books. Library-goers can explore the space and find fiction in the solarium; paperbacks in the aviary; and teen books, music and magazines in the dining room. The building was modeled after a French country house and, per Telling's request, decorated throughout with carvings, tiles and details of birds and flowers. Visitors can imagine that they're in the French countryside instead of Ohio.

I know exactly where the South Euclid library sits, as I used to drive that way quite frequently on my way from high school, but I never stopped to visit. I guess I have a reason the next time I am visiting the family.

10K hours to develop expertise

2008-10-30T03:57:24Z

Christopher Penn wrote about what it takes to become an expert, in response to a Daniel Levitin claim that it takes 10,000 hours to develop expertise. Why you need 5 years at a job to be successful.

Consider this: in an economy when the average worker lasts about 2 years in any given job, how many workers have expertise? How many workers have achieved any degree of mastery? 1 in 4 workers at any given company has been there less than a year, according to Department of Labor statistics. 1 in 2 has been with their company less than 5 years.

Interesting thought. Of course, it isn't just one job that builds expertise - it's the work one does, which Christopher acknowledges.

One element that Christopher also touches upon is the importance of the network of people I know and rely upon for advice, guidance and input. That network grows and changes as I work. And if I am changing jobs before that 10,000 hours clicks by, it is my larger world of work and the people who I interact with that help me describe my expertise. Afterall, if no one thinks I am an expert, how do I establish the claim?

Seven rules for the KM-lords in their farm of cubes

2008-10-29T04:13:26Z

David Snowden has expanded his three rules to seven principles. Now I have to wonder if there are nine rules somewhere. And if there is One Rule to Bind them All. Rendering Knowledge (rules excerpted)

Knowledge can only be volunteered it cannot be conscripted. [original]

We only know what we know when we need to know it. [original]

In the context of real need few people will withhold their knowledge.

Everything is fragmented.

Tolerated failure imprints learning better than success.

The way we know things is not the way we report we know things.

We always know more than we can say, and we will always say more than we can write down. [original]

The four new elements sound familiar from David's other writing. Taking time to think about these principles and the additional context David gives them, they begin to sound like common sense. Of course people learn from failures. Of course we build things from fragments of other things. But then why do we forget this common sense when building approaches to knowledge management? Maybe not so common?

p.s. Thanks, Tolkien.