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.

The Quality Toolbook

The Quality Toolbook

This is an interesting site that gives a very good description on how to use the various tools and charts. They have a very simple and effective structure:
1) When to Use it
2) How to understand it
3) Examples
4) How to do it
5) Practical Variations

Do visit this site to get a very good insight into how to use the various quality tools and charts.

Using SideWiki...

Just trying out this new tool to check out how this works...

in reference to: Google Toolbar Button Gallery (view on Google Sidewiki)

Problem With Averages

If a 4.5 feet person (who does not know swimming) is to cross a river which at its banks is 2 feet deep, and in the middle 6 feet deep.
If he is to consider the average depth, then it would turn out to be 4 feet deep. So as the person is 4.5 feet, and if he crosses the river just because it has an average depth of 4 feet, he would drown when he reaches the middle of the river. This is the problem with the averages. It usually hides the real scenario and it is usually difficult to determine anything properly by using averages. Thus it becomes very important to use variation and targets instead of averages while doing Quantitative Project Management. One example where I can think of where average is used considerably well and across many organizations is the Customer Satisfaction Survey (CSS). With the known issue of averages, what would be the best way to determine the CSS?

Back in Business

Hi all,
I have relocated from Hyderabad to Bangalore to a New Organization. Would be updating the contents of the site soon.
Thanks for your patience.