Skip to main content

Notes to Self - Three different concepts of probability…

In the series, ‘Notes to Self’, I will be noting down concepts I read some where and relate it to my experience, just for my reference. These posts do get enriched as I learn more on the topic. The first topic I have chosen is probability.

Whenever we talk about probability, tossing a coin or picking a card from a deck of cards come to our mind. Both of these belong to what is known as Classical probability. Classical interpretation of probability is a theoretical probability based on the physics of the experiment, but does not require the experiment to be performed. For example, we know that the probability of a head or a tail on a balanced coin is 0.5 without performing the experiment. Here, probability of an event is defined as the ratio of the number of outcomes favorable to the event divided by the total number of possible outcomes.

Sometimes, a situation may be too complex to understand the physical nature of it well enough to calculate probabilities. How ever by running a large number of trials and observing the outcome, we can estimate the probability. This is called Empirical probability. Larger the number of trials, the more accurate is the estimate of probability. Calculating the load bearing strength of a bar by subjecting the bar to stress test or predicting the time to complete a task by a person, based on historic data are examples of subjective probability.

(Note: past outcomes need not always predict the future outcomes. Take the example of a turkey being fed (prepared) for thanks giving. If one goes by the time when the turkey is fed, beheading of the turkey is never a possibility. The scenario in this example is more suited for Subjective Probability. Hence we have to be very careful when using Empirical probability and more about this in another post).

A manager faces situation in which neither of the above are useful. For example, in the case of a product launch, the probability of success can neither be calculated nor estimated from repeated trials. In such a scenario, people are forced to take educated guesses regarding the outcome. More educated the guess is, better is the probability of the event. This is known as Subjective probability. In the absence of better information to rely on, subjective probability may be used to make logically consistent decisions. But the accuracy depends on the knowledge of the factors involved and the accuracy of their impact on the final outcome.

The difference between Subjective and Empirical is that Subjective can't be modeled like Empirical, due to the large number of factors involved. Even if you try to simulate it using computers, it still may not be possible to cover all the paths involved.

In conclusion: In real life, we rarely come across theoretical probability. Real life is too complicated to allow us to use theoretical probability. Situations that we face either call for Empirical probability or Subjective probability. Understanding the difference between these two helps us to understand the limits of our knowledge and hence our own fallibility. It also helps managers to take the right decisions.

Concept as read and understood from


Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …