An Insight into Knowledge Transfer

Folks,
Here is an interesting presentation on Knowledge Transfer. The author segregates people involved (roles/population) into five different categories:

1. Innovators (2.5%)
2. Early Adopters (13.5%)
3. Early Majority (34%)
4. Late Majority (34%)
5. Laggards (16%)

Though this presentation is not from a typical Software Background, it does provide a good insight into how these aspects affect even the Software Industry.

Hope this presentation provokes you to identify the people with whom you interact on a regular basis, into the 5 categories, and aid you in adapting better way of instigating the project folks to get into the rut of proper Knowledge Transfer.

Measurement, Metrics, Indicators

Here is an interesting article on the difference between Measurement, Metrics and Indicators: http://www.stsc.hill.af.mil/crosstalk/1995/03/Measure.asp

This article can be compared to the importance of Standards, Frameworks and Models.

1. Measurement is like a standard – which has been established globally (like the value of a $, or lines of code or function points or time etc) or locally within an organization (like man months etc)
2. Metrics is like a framework – which uses a combination of measures to arrive at a meaningful outcome (like cost variance, size variance, productivity, etc)
3. Indicators is like a model – which is to be established and interpreted based on the need of the business (like cost variance should be below 5%, size variance should be less than 2%, productivity should be greater than 8 FP per work day etc).

It is very important that we use the right combination of all the three to ensure that the business/organization benefits from these in line with their business objectives.

Model, Standard or a Framework?

We are surrounded by many models, standards and frameworks to help implement various business and quality needs. But how do we differentiate between the three?

First let’s look at what the dictionary says about these words (taken from http://www.m-w.com/) – which is relevant to our context:

1. Standard - something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality
2. Model – a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs; a computer simulation based on such a system
3. Framework – a basic conceptual structure (as of ideas) ; a skeletal, openwork or a structural frame

Here are specific definitions of these words:

1. Standard - Very rigid, generally accepted methods of doing something. Very specific. A standard will usually only include a single element (i.e. do this, this way) whereas a framework or model defines a system of doing things.
2. Model - This is the process of how we get from point A to point B. If we were using the house analogy, if we were a builder then we would construct houses the same way every single time. Other builders might to it different ways, some might be faster, some might produce a better quality product, but they all arrive at the destination. The model is just the path we take to get there. These are our processes. We aren't going to be building one house one way and another house completely different, right?
3. Framework - A framework is a support system. It may not be the whole picture, but it provides a strong base for building upon. I always liken it to the frame of a house. It can stand on its own, but it's really there to be added to. However, you can never just take it away.

So, as you can see, ITIL is a framework, it is used for a specific purpose and can be implemented in more than one way, but what needs to be achieved is very rigid.
All ISO’s are standards – very rigid – in terms of the outcome and also on how it has to be done.
CMMI on the other hand is a model. It is a combination of ideas and experience put together for the business to interpret – in the context of the business. The model would expect certain things to be in place (like SEPG, SQA), but is not very rigid in terms of how it is done. All it focuses on is that the end result should benefit the business.

All the three have a focus on the satisfaction of how the business can be bettered, but the usage will depend on what is required for the business. In my view, for ensuring proper rigor in the members, an implementation of standard is very important – like ISO27K, ISO20K or ISO 9000. These standards have fixed objectives and can be easily be assessed against. But the ‘how to’ can be tailored to fit the need of the business. So, the standards are assessed based on the objectives rather than the how to.
To ensure that the members abide by a certain set of rules that guide them to achieve the how to of coding, or incident management etc, ITIL, PMI or various SDLC can be considered. These are all frameworks that have been proven to help in ensuring that activities are done within a certain boundaries – so it may vary across different businesses. The interpretation of the framework will impact both the objective and the “how to”. This is the reason why we cannot assess organizations against a Framework.
A model (like CMMI) on the other hand has a different way of addressing the issue. It provides a set of “how to”, but also gives a very wide set of ideas to implement them. The objective here is to address just the “How to” part of it which in turn is mapped to the BUSINESS OBJECTIVES – where the organization has to define the business objective. The assessment in this case happens on how the various processes that are required to be in place are mapped to the Business Objectives of the organization.

It is only the right combination of all the three that drives the true improvements in an organization.

Constituents of a Process and do we actually require a checklist?

Here is an interesting pdf on “the difficult process of defining a process” which speaks of the importance of ensuring that a “process” should ensure that the “big picture” of the activity should be taken into consideration to ensure that the process is accurate. But let us step back a bit and ask ourselves – why do we require a process?

Typically a process is put in place to ensure that there is a ‘common’ way of executing an activity. The need for this is usually governed by the fact that the activity in question is to be performed to achieve a business and project goal – and is to be performed by a set of identified roles who are required to ensure that the business and project goals are met. Having mentioned that, let me cite an example that is common but does not seem to have a process in place – brushing your teeth. Is there a defined process in place that talks of brushing our teeth? Though the answer is a big ‘NO’, we still go about its execution in a nearly perfect manner and at the same time, would ridicule if one were asked to write a process of brushing our teeth.
The ridicule factor is not due to the fact that it is a common way of execution, but due to the fact that the so called process has been “hard coded” into our system so much that we can do this with our eyes closed – which in many cases typically is, as one does not always get up early in the morning fully awake.

So, what kind of activities actually require a process? A process should not be defined just for the sake of definition, but a proper due-diligence has to be made before one even decides to define a process. All should be aware that every process has a cost associated with it – either in terms of effort, cost, or time. So defining a process for the sake of defining is a full waste of time, effort and cost.

So what are the constituents of a process? Page 77 of the CMMI Development constellation V 1.2 has a neat list:

• Purpose
• Inputs
• Entry criteria
• Activities
• Roles
• Measures
• Verification steps
• Outputs
• Exit criteria

Once the process has been defined, one way to help its users to follow it is by providing templates.
Checklist, however has a different purpose altogether. One creates a checklist only when the details of the constituents of a process is too much or when the defined process is not clear. As in the earlier example, we do not use a process to brush our teeth and similarly we do not use a checklist to check if the brush is available, or if the paste is there etc. The checklist is also “hard coded” into our system.
Similar to the need of a process, the need of a checklist is there to ensure a quick check to assess the compliance of a process. It is in no way a complete assurance that the process is being followed – for example, if the process has been tailored, the checklist should have covered that fact, else, the intent of the check that needs to be performed is lost. For example, our minds are tuned to use a brush and not a stick from a Neem tree. But the intent of the process of brushing our teeth is still met and our hard coded mind can still accept this and live by it as we ‘know’ that the intent is met.
Similarly, the user of the checklist should “know” the project and the process to be able to effectively use the checklist else, the intent of the usage of the checklist is lost.

Value of Variance

All data analysts will keep a keen eye open for variance from the norm of any process or product measure. The main objective is to keep the performance of the measure stable and capable - within the acceptable norm.
Lets quickly look at a situation where there is no variance:

• Great quality
• Great performance
• Great predictability
• Very stable and capable process

But to achieve this, we would require 'machine' like people who can execute the process and these people will cost the company a lot of money to hire, sustain and retain as these people typically come with perfection all around them and taking decisions in a perfect world is almost impossible.

The downside of zero variance is:

• No mistakes - so no learning from mistakes
• No improvement possibility (in terms of knowledge)
• No growth path beyond what has been achieved

Variance gives the intent and the opportunity to dream beyond and the hope to achieve it. It promotes mistakes, lessons learnt, knowledge sharing etc - all provided, it is within an acceptable range. Variance promotes the business of an organization to grow and facilitates the true value of the organization (it's people) to be truly valuable - thus increasing the maturity of the organization.
This will in-turn create more visions for the organization, based on which the organization can go on a mission with the enhanced value.

Variance control should not be an overdrive as it would kill a lot of necessary aspects of the DNA of an organization.
This big picture on the value of variance is a must have view for all professionals. This is the basic intent of ensuring that variance must exist.
Yes, it cannot be beyond a certain limit and that is what the data analysts should be able to determine - keeping the intent of variance very much alive.