km

Knowledge Repositories. “No one goes there any more; it’s too crowded”

Posted on

Yogi Berra: “No one goes there any more; it’s too crowded”

The success of any knowledge repository  within an organization depends (largely) on the information contributed to the system by employees, project teams, communities, departments. However, the truth is that knowledge repositories in most organizations end up rarely being used.

Contribution to knowledge repositories remains minimal — although employees are required to contribute lessons learned to the knowledge repositories and also consult the repository regularly. In reality, with passage of time, as less people use the repository, the information becomes stale and irrelevant — presenting another reason for employees not to use the system. And, not surprisingly, soon the word spreads that  the repository is outdated and does not include the information they are looking for. That reinforces the  famous quite from Yogi Berra: “No one goes there any more; it’s too crowded”

Employees could have gripes that the knowledge repository  is not user friendly, lacks certain features & capabilities. Those are often the right reasons for people not using the knowledge repository but not the real reasons. The real reason is that the knowledge repository is NOT part of the day to day work process of an average employee in the company. it is at the periphery, something that needs to be transacted with ‘after work has been done‘ or during appraisal cycles.

Knowledge Repositories need to be treated like living ecosystems, living things, like a garden with continuous need for tending, monitoring, careful purging and at times a full over haul. Then only will the garden bloom with flowers that provide value to the whole ecosystem.

Till then the adage  “No one goes there any more; it’s too crowded” will continue to hold true for knowledge repositories

Why project managers act like a frog in boiling hot water

Posted on Updated on

Imagine a frog and then imagine a pan of boiling hot water. Now imagine that some crooked mind lifts the frog and puts it in the pan of boiling hot water. What do you think will happen? Yes, the frog will jump straight out of the pan within a faction of a second (if the lid of the pan is not closed).

Now imagine the same frog and a pan with room temperature water. Now imagine an even more crooked mind leaving the frog in that pan and putting that pan on a burner with a slow flame underneath it. What do you think will happen now? Yes, in this case the frog will not jump out but will feel at home in water.

Now, over time, the water in the pan will get warmer. What do you think frog will do? It will feel even more at home; feel happy at the warm water giving it a gentle massage to its skin & legs.

Now the crooked mind increases the flame and slowly the water starts getting warmer & warmer and then hot. What do you think the frog will do? As the water gets warmer, it will feel happier but it will not be able to realize when the water has become too uncomfortable for its own good. As the flame gets bigger underneath & water gets boiling hot, the frog will have lost all the energy in its legs to jump out. Its mind will tell to bail out but there won’t be any energy left in the frog and it will continue to be in the pan and face a slow death…


So, what has this got to do with project management & project managers?

Well, analyze carefully and you will realize that there is not much difference between a frog & the most project managers. There is also not much difference between the pan (with water) & the project environment. Most project managers, if asked to take over a project in between, would know how ‘hot or cold’ it is and then take appropriate action. This is just like the frog being put in hot water and it taking immediate action.

However, what most project managers don’t realize the 2nd scenario they land up in — where they start with water at room temperature & the water gets warmer at first and with the flame getting bigger over time the temperature under the collar gets soaring. At the start of the project, just like the water in the pan at room temperature, things look perfectly in control for the PM – a small team, key members staffed, not much confusion.
Things remain fine for some more time (till the water is warmer) but somewhere down the line things just implode and before the PM realizes things have gone out of hand (water is too hot, in the pan, for the frog to take any action). There are quality issues, builds are failing, customer is dis-satisfied, the team is unhappy & clueless, senior management is watching with eagle eyes, your family life is ruined and while driving to office you wonder how things came to be where they are today…
You wonder how & when that excellent Tech-Lead became a bottleneck & the go-to person for even small things – such as from where to setup the development environment or which version of IDE to be used with what plugins — you wonder why the leads are spending more time in answering routine questions & forwarding emails rather than doing their actual work. You wonder why the testing team doesn’t have access to the latest requirements in order to prepare the test cases. You wonder why the same question is being asked and answered a gzillion times. You wonder why customer wants you to resend the status update report of last month. You wonder when this project will end..!!!!

The fact is that we don’t realize or observe or are blind to the small changes happening around us and the long term impact of these small changes. Many downstream issues are caused by our inability  to react to significant changes that occur gradually. And in today’s era, nobody pays attention to anything ‘small’ unless it is on fire or priority#1. Everybody loves a hero – a person who turns around a losing situation into a winning one (organizations reward people who get troubled projects back on track but not necessarily those who avoid trouble and go unnoticed.) Because changes (from room temperature to warm to hot to boiling hot) happen so slowly that they go unnoticed and you are then left to wonder where and when things went wrong.

The irony is that it is not just first time PM’s who fall for this. Experienced PM’s also fall into this over & over again and then blame the ‘system’. Great PM’s foresee & preempt the ‘upcoming changes’ and plan accordingly. They plan like good chess players – several moves in advance and multiple scenarios. They manage the environment of the project accordingly to prevent the effects of ‘global warming’ within the project. Such PM’s ensure satisfied customers, happy people and predictable outcomes.

So, how can PM’s foresee & preempt the ‘upcoming small changes’ and prepare well? What can they do?  That’s for another post 🙂

What do you want? User adoption or compliance?

Posted on Updated on

I believe that successful KM initiatives & professionals pay a great deal of importance to the change management aspects. If, there is one place where “build it and they will come” doesn’t work, it is KM. After all, users are tuned to a way or working and majority of them would resist any kind of change. It’s a natural reaction and for various reasons a very tricky area to deal with.

Now to counter this tricky area of change management, KM initiatives/professionals rely on approaches which could be counter-productive to what their intentions are. Once such approach, that is commonly adopted is the “top down” mandated approach. On the surface of it, this looks simple, obvious, fast, scalable, logical and the most powerful approach that one can envision. What could be better than the top most management sending out a ‘memo’ asking people to do things a certain way.

I have seen this approach and have observed that this works best when you need ‘compliance’. Areas such as ‘time sheet entry’, ‘filing expenses’ etc are best suited for this approach. Anything transactional can be rolled out on a mass scale using this approach.

The issue arises when you try & roll out KM initiatives with this compliance driven/top-down method. Chances are that more often than not this will not yield the desired results and one can get in a vicious cycle of asking for more ‘top down compliance support’. This can frustrate the hell out of people who are leading these change management initiatives as they can’t fathom why on earth the seemingly obvious method of top down/compliance driven approach is not working.

We all know the results of a top down approach that mandates submission of 2 documents to the knowledge repository every quarter by each employee. On the last week of the quarter you will have a deluge of submissions and most of them would be not worth the bytes contained in them.

On the other hand, KM initiatives/professionals that rely on the adoption approach have greater chances of success. On the surface of it, the adoption approach looks to be an insurmountable obstacle but with patience & a long view of time this can be achieved. Adoption happens when people ‘buy into’ things and not because they are being ‘told to do so’.  Adoption happens because people see that things actually help them, appeal to them on an emotive/cognitive wavelength. Adoption happens when people, who we trust, tell us that it is good, they are using it & it makes sense. Adoption happens ‘through’ people… (We adopted facebook, twitter etc using these principles of adoption.)

The key to adoption approach also lies in finding the right set of people, who you will work with initially. They are going to be your evangelist and believe me they will be like customers who “tell 1 more person, at best, if they satisfied and will tell 100 people if they are not satisfied”.  Starting the process of adoption is slow and takes time. However the growth over time can be exponential and usually has a more stable foundation which is not only dependent on ‘top down’ directives. Adoption approach is akin to trying to move a heavy flywheel… lots of effort & commitment is required initially to even move the flywheel but as the revolutions go by the speed increases and over time the flywheel literally moves on an auto-pilot mode.

I have also observed that a combination of adoption (at a macro level) & top-down (at a micro level) also works in several circumstances. The key is in knowing which one to use when and for what. And that’s comes from experience & losing your hair over the years 🙂

Compliance is best achieved through systems & adoption is best achieved through people. So, if you need compliance of initiatives then build systems that monitor themselves for the compliance automatically. However; if you need adoption then be prepared for the long haul & work with people

Where’s the KM Function in Apple Google & IDEO

Posted on Updated on

Earlier this month the North American MAKE  (Most Admired Knowledge Enterprise ) award winners were announced and the list is as below:

  • Apple
  • APQC
  • ConocoPhillips
  • Fluor
  • Google
  • Hewlett-Packard
  • IBM
  • IDEO
  • Microsoft
  • MITRE

Some of the parameters on which MAKE awards are given are:

  • Creating a knowledge-driven enterprise culture
  • Developing knowledge leaders and workers
  • Innovation (R&D, creativity and new product/solution/service design and delivery)
  • Maximizing enterprise intellectual capital
  • Enterprise-wide collaboration and knowledge sharing
  • Creating a learning organization

The question I have is:

How many of the above organizations have a dedicated KM Function responsible for implementing KM within these organizations and full time CKO’s leading the KM Function? To the best of my knowledge, Apple, Google, IDEO do not have any KM function and yet they are considered.

Some time back I had written this post about “Does KM needs a Dedicated KM Function to be successful” where I had raised some questions about organizations like Apple, Google and others being truly representative of today’s knowledge led enterprises in every sense and do not need a KM function to practice KM. It’s just a way of being for them…

So, do we really need a dedicated KM function for achieving the above? Well, Apple, Google, IDEO and others don’t think so…

Surely, somewhere something is just not right in the KM world…

Will Crew or Military Models(for team formation) work in Software Development Projects?

Posted on Updated on

Dave Snowden in his address on Social Computing & KM during the KM India summit brought about a point on how current organizational structures are not suited for creating social networks and hinder performance. Dave explained this with the Matrix Organizational Structure where people have multiple reporting relationships and no one is sure which way their loyalties should be.

Dave talked about the “Crew or Military Model” of team formation which he termed as more adaptive in nature based on the concepts of  “Role” & “Expectation of role”. He explained this with an example of how teams are formed in airlines or ships. People who may or may not have worked before come together to form a team and work as a team based on an understanding of what each persons role is and what to expect from that role.

In the IT industry this model, in intent, is a model that most software development organizations ‘aspire’ to implement while creating teams for developing software. I believe that in theory this is a good concept but there are several questions that need to answered and various soft aspects thought.

  • “Crew” model would work for teams where the tasks are repeatable, tasks which have little room for variation and have to be done “the same as before way” on time. Tasks which have the procedures defined and the job of the person doing is to just follow the procedures and do it.   For example;  airline crew. pilot, co-pilot, air hostess, stewards, checkin counter assistants. The kind of tasks involved are routine, repeatable, well documented, and need to be performed with precision every time.
  • In the software industry, for example each development project is unique and the development life-cycle is ‘not predictable‘ to say the least.  To compound matters, skills required may not be available and training may have to done while on the job. This is not the case in crew model where almost all the times things are predictable and follow a predictable sequence.  For example, in an airplane you can predict what would happen from the time you take a boarding pass and go to your seat to the time you get down from the flight. It is all very very predictable, linear & sequential. There is no room for variation — unless it is a private chartered russian flight 🙂
  • Though one may say that even in software development we have roles like PM, Technical Leads, DBA’s etc etc and we know what is expected of that role. However, the reality is that software development is an iterative, some what chaotic, emergent process. There is a complex interplay between all stake holders to create the ‘intangible’ software that people want. Now by very nature of their business, airlines/ships can’t have an iterative, some what chaotic, emergent process to the nature of work that teams do there. Imagine a team of  air hostess emulating an iterative, some what chaotic, emergent process to serve the passengers.!!!
  • Another important element is the “customer engagement” in the whole development life-cycle itself where requirements are fluid and can keep changing. Now one could argue that even in a ship or a airplane there is engagement required with the customers, but that engagement and the choices available and hence the options that the crew can exercise are from a limited set that is almost well known in advance.  It would be only in an adverse situation of a ship capsizing or a plane mishap (e.g. hi-jack) that the engagement model between all the participants becomes fluid and relatively unknown.
  • The most important aspect I feel is the “nature of work” itself.  By very nature, software engineering calls for continuous learning & updation of skills while on the job. This is not necessarily true for airline or ship teams. Not to say that they don’t need to learn or improve their skills but that is within a very narrow band and at a slow pace than in software engineering. This aspect leads to totally different  behavioral, motivational, aspirational & emotional factors within individuals that then influence people, teams & how they work.
  • I also think that teams in crew models the teams need to “coordinate” with each other to perform the task whereas in software development teams need to “collaborate” with each other to perform the task. These two things may look similar but call for totally different actions, engagement models within teams.

The above are just some of the many questions out there. What do you think?

Would ‘Crew or Military’ models of team formation work effectively in software developments? What could be other challenges and opportunities?

After Action Reviews[AAR] in software development

Posted on Updated on

AAR’s is a process used by the US Army where after each action [in army’s parlance] the team meets to capture the learning’s and lessons, what went well and what could be done better. The advantage of such AAR’s is that the activity performed is fresh in the teams mindspace and they can reflect better on the activity performed and learn from it.

Variations of AAR have been used in the software industry(and in other industries also) in form of Post Harvests, Sunset Reviews, Post Mortem Report etc where the team meets at the end of the project, to look back and reflect on what went well, what could be improved and how to gain from the experience.

While all such practices are fine in theory, there are some fundamental issues in their execution. Few of the limitations are:

  • Projects, programs etc get executed over a long span of time – maybe months, years. If a post harvest, sunset review etc is conducted at the end of several months, then it is practically impossible for teams to remember what went well and what could have been better. These meetings then usually will turn into blame game, finger pointing, or of things at a very superficial level. The real learning’s may not surface in such scenarios.
  • The importance if learning’s, lessons may become trivial. When the team of individual is facing an issue, or trying to solve a problem, then the lessons they learn while solving the issue/problem the first time is the most important. The next time they face the same situation/problem, then they will see little value in the lessons. They already know how to do it and over a period of time, by the time the post harvest, sunset review happens, the very important lesson that the team had while solving the problem could have become trivial to even mention it.
  • Team members join and exit the projects/programs throughout the life cycle of the projects/programs (This is especially true of software development projects). This is compounded by the fact that people leave or join a project not in one shot but in a staggered manner over a period of time. Post harvest, sunset review do not account for tapping into the lessons learnt by people leaving the project, nor do they try to tap into the lessons that people joining a project/program midway bring with them.
  • Many times during Post harvests, sunset reviews etc, the team members who had left the project and are now part of other teams are asked to join for such meeting. The intent is very noble — to also tap into the learning’s that these people had and benefit from it. However, the problem is that these team members who had left the project are mentally NOT associated with their previous project anymore, they are mentally switched off from their previous project and are very unlikely to contribute any meaningful learning’s or lessons, and even if they do, it will be very superficial. NOTE: It is not that they have noting to contribute, but the very fact they are mentally, emotionally and physically removed and no longer part of the project, make it difficult from these people to contribute anything meaningful.

There is no doubt that learning’s from Post harvests, sunset reviews can be applied to new projects, but the very fact that lessons/learning’s of AAR’s can be applied right away in the next activity of the current project make it very powerful.

It’s about time that the software industry looks real hard at the value it derives from Post Harvest processes.

Relationship of KM with other functions in an organization

Posted on Updated on


After working in the KM arena for many years now, one thought has started puzzling me — “The relationship of KM function with other functions in an organization and the consequences of these relationships — in terms of the KM viewpoint & outlook, success etc.”

I have observed many different Indian IT organizations [I presume it must be similar in other countries also], that each organization has it’s own structure for KM within the organization. For example in one organization, KM reports into quality and is part of the quality function, In another organization KM reports in Education, Training & Research, In another it is heavily distributed and some parts report into Marketing & Sales, some into HR etc. In another one we have a separate KM function that reports directly to the COO.

I have observed the KM initiatives in all these above organizations from close quarters, through various interactions and in all of these cases, the results of KM and the road map, the view of KM, what KM is, is all different and very heavily influenced by the function/person KM reports into.

– KM being a cross-functional discipline, also is similar to an elephant being viewed by blind-folded persons and each person [function] having it’s own view/perception of the elephant [KM] depending on what part of the elephant they are seeing.

– At the same time, KM’s cross-disciplinary nature can create structural tensions within an organization if it is a separate function, with developing working relationships, alignment on directions, strategy, over stepping on other functions toes.. being just some of the issues..

– KM being a relatively new discipline and not very well understood by the stakeholders also contributes to this dilemma. For example, Quality as a function has been there for ages and is pretty well understood. You will very very rarely see quality reporting to say CIO or HR or Marketing or Learning/Training function..

– Also, KM itself is a journey within an organization and goes through various stages.. from repository/technical platforms [CIO function alignment] to communities [HR/Learning function alignment ] to reuse of knowledge [Quality function alignment] to deep integration within the line function [function head alignment] to complex change management & Innovation [COO/CEO alignment]

Surprising isn’t it? We are in the knowledge era and the position of KM function within the organization structure is neither well understood or defined….

I think every organization that is starting a KM journey needs to ponder over this in great depth and align KM function appropriately within it’s organizational structure