What does success looks like?

When you are looking at consequences you have two choices, either you try to find a quick answer, or you scour deep what is the fundamental factor or reason that generated the problem. There are thousands of superficial reasons (or symptoms) why something fails, and in the American culture there is a tendency to blame someone else (“The enemy is out there syndrome”, see Learning Disabilities section). Here are some fundamental reasons I’ve found in my experience why Knowledge Projects (KM) fail.

Leadership

Leadership has always played a key role in the success or failure of any project in history. In IT and especially in knowledge management projects, there’s primarily been a lack of information and experience about how to properly plan and execute them. They way it has been done is the same as any other IT project (trial and error). The fact that we had had rough times doing it proves how complicated it can get. Added to the mix, is the aggressive vendor sale pitch.

There are many reasons, but the biggest sin leaders commit is thinking technology IS a solution(Explained later).

Other reasons fall on the human side, meaning the way you involve, treat users, train and guide them through the process makes a big difference.

The transition from paper based processes to digital has posed as another challenge, and old traditions many times prevail.

Not understanding the big picture. Not asking enough questions about “What is the problem?”, where, why, etc. Where are the rules? What do we envision? What is OUR solution? What is our fundamental goal?

Maybe is the style of leadership we have been accustomed to.

“Show me a hero and I'll tell you a tragedy." F. Scott Fitzgerald.

A book by Joseph L. Badaracco “Leading Quietly: An Unorthodox Guide to Doing the Right Thing” looks at the opposite traits of leadership: restraint, modesty and tenacity shows us that what we see today might not be the ideal way to leadership. -If you look behind lots of great heroic leaders, you find them doing lots of quiet, patient work themselves. —Joseph L. Badaracco Jr.

Psychology

Managers complain that people frequently hoard knowledge, fail to share it with others, and generally behave uncooperatively. In many implementations little involvement is perceived from end users. In others, the system can barely keep up. Why the difference? The difference I found is in the rules and policies. In the first case, leaders put a lot of rules --who can see, not see, create, share, delete, etc information-- and those rules are completely absent in the second case. Now, in the second case people are free to express, subscribe, create, share, agree, and disagree on any topic posted. Results: The system can barely keep up with demand, meaning it is very successful as a knowledge hub.10-20 years ago (and even today) , we were told information is power. Now we are trying to push the opposite message with Knowledge Management. The result: We cannot force people to give away what they know, if they are not genuinely motivated to do so. An example: United 93's lesson yields knowledge is power “Knowledge is power, and pure knowledge must unite us.” Marc Dotson published May 30, 2006 The more we send this message to people, the harder will be the goal to share knowledge. Equaling knowledge to power, evidently will make people hold on to it, instead of sharing it, which is the key to collaboration, which in turn is the key to creativity. A twist to above quote could be “Knowledge power depends on our capacity to unite ourselves collaboratively” and would allow us to have more people actively share their knowledge with others.

Views and Concepts of people involved.

I am amazed about the misuse of words (my self included) everywhere and the lack of understanding in general of their dictionary meaning. If we decide not to pay attention to this fact, even trying to agree on what the problem is will be a challenge, because the words used to define it will have a different meaning for each team member, and the key to succeed is based on how well the team understands the problem. “Instead of thinking of ways to create a business, entrepreneurs should be thinking of ways to create value through solving a problem. And that is a deep, thorough process. "Half of all the energy we spend in inventing new business solutions is first figuring out the problem." Jay Walker inventor of Priceline.com and holder of more than 100 patents.

The way some editors write and use words that either contradict or mislead is bigger than I thought.
If not only the leaders, but the rest of the team believes technology is a “solution”, then they are bound to fail in the long term.

Discovering people believe technology = solution was shocking to say the least. I discovered this trend when sitting in various meetings, I kept listening to people talk about what the technology could do to solve the problem, instead of agreeing what the problem was in the first place and analyzing what was the goal. Even when I later asked about what was the fundamental goal, after a short pause Cristine would say “I do not know”. In another meeting, someone launched a question (maybe in desperation) that it would help me start realizing many things in this book: What does success looks like?

It was odd to say the least. Nobody responded. I kept thinking if there was an effective way to demonstrate it in simple terms. I decided to give it a try and started with a basic concept I am sure you all know. Success is the opposite of failure. Then I looked the other meetings discussions with technology and started to draw a map.
In Figure x , I typed technology and went back to the dictionary to check the meaning (Technology comes from techne (τεχνη) "craft" + logia (λογια) "saying" ) meaning the science about tools created by man applied in conjunction to solve a problem. Tools are not the solution itself, but the way you can create your vision. “Technology is a tool that can change the nature of learning” Lynne Schrum. By observing people around, I could see that they wanted answers from the tool, that would give them the solution, and then they would look at the problem mostly at the end. I kept staring at the slide and for a moment and could not believe it. At the end of that path (Right to left), I wrote FAILURE. Why? Tools (or technology) cannot give you the -right- answers to a solution of a problem that has not been defined from the very beginning (See Diagram left) ; the view I have is that problem and solution should be formulated in a non technological language. The Problem, and the envisioned solution must be simple and clearly laid down for everybody to understand. Any confusion will make harder to implement the project.

Going in the opposite direction (as in the definition) chances are you will find success by clearly defining what the problem is, what the solution is, and then you start defining HOW you will build the solution with the tools or technology available. The how will likely have technical language. Not before.

In other cases I observed people trying to link a problem directly to a tool (Software) believing again that technology = solution;

There is a WHY in every problem. And most likely will be the motivational driver for the team involved in solving it. It is very important to discover the why.

I call this method the PST system (Problem ->Solution -> Tools)

The perfect problem solving analogy I like to use is transportation. Every body can understand the concept easily. How do we go from “here” to “there”. “What is the very first thing you need to do when you want to go from one point to another?”.

1. First thing you need to do is to define or find out where you are. Looks and sounds logical, but in the IT world not everybody does it or is willing to. Why? It can be a huge effort just to know for sure where you are, especially in big corporations with terabytes and sometimes petabytes stored. So not every CIO is willing to do it because sometimes the cost can be out of question and even knowing what to look for can be confusing. This is when the underlying problems begin for any knowledge project.

* Point A : After looking around and asking questions I found I am in New York.
* In reality: many assume they know where they are and give the green light to start a project without carefully understanding the situation. This is risky to say the least.

2. Next step is to figure out or envision (definition: imagine; conceive of; see in one's mind;) where you want to go. (This is the Vision in leadership terms), where do you envision you should be heading to.
In our example, we found that we have a problem being in New York and there is an urgent (defines timing) need to move to Los Angeles (solution). Now we know where we are heading. Next step is to define time. Time will set the pace (and cost) of your project. Do we need to do it ASAP? In some cases time limits the number of options the leader has to choose from.

3.If the requirement is to do it ASAP, then cost will be probably max out, and of all the range of tools that we can use, the list will probably come down to one in this exercise, a tool that provides the fastest way. The Airplane.

Look how the tool you choose is time dependant. If the question was two hundred years ago, the tool did not exist. A Train would be the answer

Reality: Let’s imagine the current and common situation in business, you know there is a need, but do not know yet how, and a consultant or vendor comes to you and tells you --"We have a very economic and efficient 'solution' for you. It is very affordable, it will take you anyplace you want, and it will last a for ever (good warranty). "--- great!! you say. That is what I need! Show me...

Vendor: -- Our solution is called "...a bicycle".

Many companies believe they need to select a software suite first Without defining a whole range of policies and strategies—or the WHAT-- and thinking that the software will be flexible enough to accommodate their “future” requirements so that they can figure out how to make the trip to Knowledge Management easier and painless. This is my biggest concern and their biggest mistake. There is no such a thing as knowledge management in this world. Dealing with the word knowledge in the technology world is not as easy as many of the past IT projects. It involves people, and people will not provide their knowledge easily just because you try to force them with compliance and policies. It involves a lot more than just technology.

Tools & Technology

Software is a tool by definition, and it will never give you the keys (answers) to a problem and successful solution (Going to LA) if you do not know why, what, in the first place.

We should strive to check the dictionary for word definitions every time we see something we are not sure of, or if the words seem confusing.

Tools definition (Dictionary.com): Devices, such as a saw that enables you to perform manual or automatic (Repetitive) tasks. I go on to displaying side by side Construction tools and Technology tools and their fundamental goal. In construction they are used primarily as a "Leverage" that allow you with minimal effort to apply great force, or speeds up a given task. In Technology is about speed, how you can do things faster with less errors and more convenience with less effort.
Making your project a vendor driven “solution” has generated a lot of confusion out there. This is the by-product of thinking technologies are solutions which is a big misconception.

I like to think that companies/organizations as people are all too different, so no application will perfectly work for all of them in a “one solution fits all” fashion.


After some experiences and analysis I came down to ask my self: What on earth is knowledge in the first place.

The more I asked the question, the more I realized there was no easy answer. It was striking to me finding this out; no one was very sure of themselves answering what knowledge means. We all seem to believe we "understand", looking closely , I found some inconsistencies that made the topic even more interesting, and a goal for me. Find out a simple way to explain what knowledge is, so that software can be redesigned to make it more useful. In the next sections we’ll look at some definitions.

Industry fuzziness: A case that shows evidence of how we build complexity (unnecessarily) into everything we do.

There is an inherent problem with us technology people and specially the ones that sell it. They need to have a new buzz word every year to make sure they can “wow” their customers into a new product (albeit being the same with more stuff added) and make the sale. This is good for business but terrible for simplicity, and effectiveness, because they (the products) get tweaked to make the sale but are more complex with each iteration. In many cases, companies have 20-30 different software applications which does not make sense. (See occam razor principle)

The other reason KM projects keep failing is because the fuzziness and lack of clarity software provides today

Here is an example of a content management convention:

• Content Management Architecture, Infrastructure, and Applications
• Data, Image, and Content Capture: The On-Ramp to an ECM Solution
• Centralizing Your Assets: Store, Retrieve, and Preserve
• Communicate, Collaborate, and Manage - "Can You Hear Me Now?"
• Making the Invisible Visible: Measure, Monitor, and Analyze
The fourth topic that talks about Collaboration is interesting. It is amazing the number of elements I found on each topic. In their webpage it stated:
• This theme provides advice, insight, and discussions about how to best share, route, deliver, secure, and control enterprise content so attendees can meet or exceed their compliance, operational, and performance objectives. Areas of particular focus include: email, Instant messaging, Web content, and Portals. Other sources of enterprise information and best practices for process and policy analysis are addressed.
• BPM
• Workflow
• Document management
• Email management
• Instant messaging
• DRM
• WCM
• Collaboration tools
• DAM
• Security
• Localization
• Syndication
• Personalization
• Publish
• Portals
• Case studies
• Versioning capabilities & controls
• Process planning
• Case/exception handling systems
• Cultural/organizational/ownership challenges
• Unlocking valuable information trapped in transactional systems
• Building a performance-accountable organization

It might be seen as useful software, but you can see it exists in many different pieces and no simple explanation how all of them work in conjunction, what is the whole picture, what does it accomplish, what is the problem, how should we start and no concepts behind them as to why they built it like that, and in general a one-solution-fits-all approach. We are stumbling again and again trying to connect a problem straight to a tool believing that’s the answer. IT people are “drowning” in techno speak believing that tools and technology are the solution.

Opening the Flow

“Companies need to consider opening their flow of information”, said Google Enterprise General Manager Dave Girouard

Product management has evolved from being formulaic, linear, scheduled and predictable, to being unpredictable, cyclical and revolutionary. That means companies need to rely on self-directed innovators and move forward quickly, often with little planning.
"You can't schedule innovation," Girouard said.
Google is making big noise on the products they are developing, and they are changing the "corporate paradigm" upside down.

"Companies need to attract, guide and retain self-directed innovators in order to succeed in the next 10 to 20 years. --Self-directed innovators-- who don't necessarily hold high-ranking positions have a wide influence within a company and can make things happen". "Those employees can't always recall details of all of the information they have come across so they need a photographic memory, collective wisdom and the world's information, he said. The way to deal with that, according to Girouard, is to allow information to flow more freely and quickly than it has in the past" he said. He outlined the top five ways to maintain an outdated business model. They are: restricting internal publishing by failing to provide a physical means to communicate or by instituting strict rules about gaining approval; requiring publishers to follow strict metadata standards; assuming employees will use systems because they're in place rather than letting employees' behavior give cues about what works, building overly complex interfaces, and restricting access when in doubt.

All of a company's information should be searchable by all "Innovators" which potentially can be anyone you employ.