PKM From Person to Enterprise (Business Book Summary Edition)

What is PKM?

That was the easy part.

How does PKM translate from the employee to the enterprise?

PKMExample #1

How to make beef jerky (steps Explicit

Example #2 (steps with video Tacit

Example #3 The list ( 

All personal. 

The real question here is HOW did I get this information and HOW can I use it?

The point of PKM is PKMShare

  • We search (discover) information.
  • We interpret this information and internalize what it means (to us).
  • We store the information (in our own way).
  • We share it (either as it is or through interpretation).

From “symbols” to “sense”

The Lord’s Prayer in Gregg and a variety of 19th-century systems


 Semantics, Ontology, Lexicon, and Language


  (We need to understand each other or find ways to translate so that we can understand each other.)

 Once in my head(information is personal).  It is the way (I SEE IT).


Punctuation Marks (NEW)

Understanding of words (data) and information require (internalization/ comprehension/perspective/context)

Even if you get the words right..

You may not get the meaning right!

All knowledge IS personal knowledge (that is how we work).

In order to share information with each other, we have to make a special and extended effort to express ourselves in common ways BUT that isn’t enough. 

The answer for the transition from PERSONAL to ENTERPRISE is….

  1. Enable content discovery. (search)
  2. Use common references (when you can).
  3. Link information to people. (content to context)

The “discovery” driver

If I need to find something to do my job.  I should be able to search for it.  I have to do this in order to perform.

The “discovery” enabler

(Search is required) Is that too simple?

Why does Google look like this?

Where is the dashboard with all of the lists?  Where is the taxonomy?  Where is all the complication? 

If you are a knowledge worker, you most likely use Google or Yahoo or some search engine every day.  The reason that you use this is because it is simple and effective.  As President Bush says” I’m the decider.. heh heh”  You determine what you need and how you are going to use the information.   You determine how you are going to repurpose and share this information.   You determine the fidelity of your information sharing and the granularity of the payload of information.  We already follow some common rules.  If you didn’t do this already my words and the meaning behind them would be unfamiliar to you NOW as you read this.

When common isn’t enough. All about the “P”

You knew where I was going with this.. didn’t you?

Personal KM to Enterprise KM meaning information that I am managing in my personal repository of stuff (my info stash) to what the organization needs to keep for (Our info stash).  It is back to PEOPLE again.  I need to be able to search, get content, interpret content, determine if I need more context, understand the relationship between the content that I have discovered and my desired outcome, and…. have information about the relationship between this content and the content creator or AUTHORITATIVE SOURCE.   I need to have the ability to talk to someone about what I found (from discovery).   

Tool Business

I am not trying to put anyone out of business.  In fact, I find value in semantics.  We need data and information tools, I use them everyday.  We need to share information and we need to understand the intent and context of the information provider.    All that being said, tools ENABLE us to do things, they shouldn’t DRIVE us to do things.   Even good ole’ Google shouldn’t drive us.   Discovery is independent of Google, it is an activity not a tool.
What have we learned today?  Knowledge Management and Knowledge Transfer is dependent on the person in the middle (literally).   Any information stored in a repository is always subject to interpretation and perspective regardless of how factual and explicit the information is.  If we are providing information or transferring information, it is our responsibility to make this information easier to find and provide as much (context) as possible.  When that is not enough, we must provide a communication link to the owner, provider, author, authority on this information in order to assist in our (personal understanding) and awareness of this information.


Awareness and understanding are key otherwise information no matter how well formed and governed may have little value.

Do you see the dreoilín teaspaigh?  That is a Irish word.  You can use google translate to find out what it means.   If you have a problem you can email me at the address on my about page.

Cloud SLA (Government / Defense)

I teach a cloud computing course for Thomas Erl @ Arcitura from time to time and the question that always comes up is the one about service level agreements.   It is a complicated subject that does not get enough attention in our industry.  I am presenting some of the discussions that we have had in class and some of the questions asked all relative to cloud computing and mostly aligned to the defense industry.    This is part of an SLA series of blogs to get people thinking about their requirements and to understand what an SLA can do or not do for a business.

Today I will share a short story .

It was 5:00 PM on a monday afternoon,  a routine procedure on a patient in London turned into a catastrophic challenge requiring expertise from across the pond.    Dr.  Jack Ash is a leading Gastroenterologist living in Ontario, Canada.   Dr. Ash received a call asking if he could help the patient in London.   Dr. Ash has extensive experience with remote surgery a relatively new practice taking shape using cloud oriented services.   Dr. Ash is using IT services provided by the hospital in Ontario.  The services in London are with a different hospital and a different IT service provider.   The configuration of the services look very similar to this (see figure 2)

The SLA looks something like this IT_Service_Level_Agreement_Publish_To_Customers.   Dr. Ash didn’t have much time, he needed to act fast.   He ran down to the office and coordinated all of the requirements with the remote team in London.   This situation had been discussed before and the staff had practice with dummies and cadavers.  Fortunately for Dr. Ash he routinely performs procedures like this in Ontario between hospitals often.

The stage was set, the anesthesiologist had the patient stable and all of the supporting staff acted as planned.   Due to the situation and set backs some time had gone by and the procedure took place closer to 8:00 PM .

Dr. Ash started the robotic services and invoked various commands over the network.  At first the procedure was going well, there were some minor fluctuations with bandwidth but nothing major.  In order to make sure that the network connectivity was consistent Dr. Ash asked a staff member to call over to his local IT and make sure QoS was turned on.   The helpdesk reported back quickly that all available resources and network traffic managing the robotic services had priority on the network.   The procedure continued and Dr. Ash was noticing severe latency through his video stream.   He had to act fast to finish the procedure and just as he was finishing the final maneuvers, the robotic arms lost connection.  Luckily the original staff working on patient x were in the room for Dr. Ash to talk through the final moments.

What happened?  Why did the arm lose connectivity?  How did the SLA help?  How could the SLA have helped?

Although this story was not real, the technology is real and the fact is that medical practitioners are doing something like this today.   Why did the arm lose connectivity?  I’ll give you a hint, there was a soccer game at Chelsea and there were a lot of people in London very interested in that game.

There are various reasons for the potential failure of service.   The problem is that most people focus on what technology can do as opposed to understanding where it make sense to use services like this and where it makes sense not to use these services.   There are plenty of business cases that could have created a more stable environment but more often than not businesses choose to go head first into situations like this.   It seems like a great idea and they even had an SLA!  I wonder what that would have done for patient x had this person died.

These are some of the concepts that we will need to explore further.  I will put together some defense oriented generic scenarios for thought.



Agile Experts Follow Up

A few posting back I challenged the Agile community to bring to light their process and methods.   My blog is posted on Twitter, LinkedIn and a few other places, at the very least a few thousand people get notified of an update.  A few folks in the community responded but I would like to repost Dave Lamp’s comments here because he has a deep understanding of people, process, methods and use of tools from a military leadership perspective, a government contractor perspective, and a government civilian perspective.    Change has to come from a cultural normalization with practice.   A faster more effective and efficient approach to development requires TRUST.   If we were to analyse my blog, the word that would be used most across every post would be TRUST.   It is central to all that we do and it is critical that we work to gain and manage our trust relationships carefully.    Here is Dave’s comment :

You’re not wrong in this assessment of agile, but probably are pointing out clearly the fact that most program managers are the sad and unwitting victims of the dreaded and highly contagious condition known as REIFICATION–the mental state where one believes that something is real when it is only an idea. So we continually talk about about agile acquisition, “rapid” fielding, crowd sourcing, social networking…ad nauseum…as a means of making ourselves believe that these words are making something happen by our use of them, rather than doing what they would logically demand–using Scrum techniques and shortening delivery schedules, for example!

The biggest danger of this linguistic condition is that a chronic malaise sets in usually accomplanied by a fetid and seemingly endless discharge of…PowerPoint slides! The person so infected will exhibit an emotional and tersely worded unwillingness to entertain their worsening infection, citing such things as or Govloop as illustrations of how the Defense Department is already even now moving into this rapid fielding of agile acquisition capability. The fact that their projects do not use these methods, that no process exists for sharing specifications for web service development does not prove their disease, since such outcomes are “not in their swim lane” or that their program was not funded to “boil the ocean” or “solve world hunger” which such actions would certainly illustrate.

So….how do deal with the worsening condition of governmental IT professionals? I believe that what someone must do is to create a simple, safe and secure method of creating web services, just as has been done with the Ozone Widget Framework for visualization services. If a web services development toolkit (WSDK) could be found on as an “app” for regular warfighters to build a “data-as-a-service” container that could be used by anyone for a particular function, you would catastrophically transform the Defense Department’s web service development process. We would begin to see a rapid migration to agile development by end users who would be able to take their spreadsheets, their Access databases and store them as a service for others to consume as a reliable and accountable source of specific information about a particular function, location, mission or task. As “controlled unclassified information” (CUI) data services proliferated, leaders would then demand for similar web services on other classification levels. It would be success without fighting, a way of winning recommended by none other than the ever-quoted Chiense general Sun Tzu!. After all, producers have no incentive to do this since they are all too often trapped by the “cost, schedule, performance” tyranny of the old-school program manager. So they have to console themselves that someone will eventually give them a contract to do things this way. However, all too often the old-school program manager has a doppelganger at the contractor’s management who see no value in a course of action that would lower billable hours, shorten the billable schedule and “undoubtedly” destroy overall IT development performance! NOT!

If I were able to do it myself, I’d build such a toolkit out of Google Apps that connected to JackBe’s mashups, OWF widgets and SharePoint portlets. However, I’d like to recommend it to you as one that could be done by the wise and capable readership of this blog! This could become a shared “trailblazer” project worth doing in Forge and could be a shining example of how this collaborative environment was designed to work–safely, securely and sanely in a sweetly agile way! Let’s do this!