Why did we take a cake?

Sometimes what we say is immediately contradicted. Probably the reason is that often what we say is completely out of the box. It takes people more than just a second to understand us.

A decade back I wrote an article supporting child labor in Kashmir and, as one would have expected, I was ridiculed. However, those who read through saw sense in what I was talking about and I soon found hundreds of supporters. This topic might be similar and it would be nice to try and understand my point of view.

Last month we went to greet a friend on starting new business. When we left home, we intended to pick a bouquet of flowers on the way. Though we passed a few florists, I did not stop. Rather I could not stop because somewhere in my subconscious mind I dislike the idea of taking flowers. Finally we ended up buying a cake that easily cost three times more than what flowers would have, but I did get my satisfaction for not having done something that I would consider unethical.

I considered taking flowers unethical because I found it very similar to buying stolen goods. If one is aware that the goods that one is buying are stolen, then one becomes party to the theft. As I am convinced that commercialization of floriculture at a magnitude it is in India is very bad particularly for the poor, I consider consumption unethical.

Who cares for the government statistics and the bench marks? On one hand we have 30,000 top executives in India drawing more than 10 million a year and on the other I think 90% of the population is still poor. Starvation deaths and suicides triggered by problems due to poverty have become so common that such news no more make headlines. They don’t even get a place in the cover page, do they? I doubt if these people are even acknowledged to be below poverty line as per the Indian standards. I would say every such family whose net worth drops to zero any time in a month few times in a row should be considered poor.

In India more than 90% of the population is affected by the rising prices. Even people with decent salaries have to spend rather too wisely. Average monthly household income in India is less than 1500 Rupees. When we look at the cost of commodities, 1500 Rupees can fetch you 6 kg of mutton or 50 kg of rice or 93 liter of milk. If a family of 4 dines at a small average hotel, probably 1500 Rupees will buy 2 meals. You could buy one leg of jeans if that were an option so at the most you can buy an average quality branded shirt. In Bangalore city you can probably find a six feet by six feet room in a slum for that kind of rent. Let us not talk about other stuff but try and stick to Roti, Kapda aur Makan (Food, Clothing and Shelter). Let us assume people never fall sick and never meet with an accident.
Coming back to the food, if one third of household income is spent on food, that would leave us with a small amount of 500 Rupees for an average family size of 4 persons who are not considered to be below poverty line by the government of India. One packet of dog biscuits costs more than 1000.

What has all this got to do with flowers? I am sure you are still wondering that are you might be thinking what is wrong with this guy. Commercial floriculture is definitely not responsible for the poverty of this nation but it is one of factors that make the matter worse. There might be dozens of issues, if we remove one or two we can definitely expect a reduction in the number of suicides and poverty deaths. How?

The agricultural as well as the forest land is shrinking at an alarming rate. It is already a bit smaller than what the mankind needs to survive and conserve flora and fauna. Being a human being a farmer, rather the land owner, wants to derive the maximum out of his land. Some sell their land at exorbitant rates. Such land is mostly converted to non-productive land. Some opt for higher paying crops like flowers and palm for palm oil. This results is drop in the supply of food items thus increasing the price. The high demand in the commercial land for buildings and roads, flowers and oil for fuel have made the food so scarce that people are willing to pay whatever they have just to survive another day.

Nobody is going to even care for such a small issue. After all who cares for human lives? We actually did not need to care if the governments did.

I believe there is a single root cause for problems like inflation, food shortage, depletion of fuel, global warming and disappearing forests. Nature has the power to heal everything up to a certain limit. If we exceed the velocity with which the nature can mend, we will see destruction. We have precisely been doing that for past hundred years or so. The development has been so fast that nature has not been able to keep up the pace. All we need to do is to allow it to catch up. We cannot stop development and neither should we. The only and sufficient thing to do would be to utilize the resources very wisely till the balance returns.

PMPC 2009 was a waste of time.

It has been a week since I attended this PMPC (Project Management Practitioners Conference) 2009 organized by PMI, Bangalore chapter. I would say it needs lot of improvement. Actually it needs much more. It needs a life first. There were several good things that were planned and managed very well. But overall, the event was ……… dead!

Many of the presenters were brilliant. Their knowledge and maturity level was sky high and yet they were so down to earth, humble and sincere. I plan to meet and be in touch with each one of them.

However, calling PMPC 2009 a conference would be something like calling the isolated half a dozen coconut trees on the beach a forest. It was a collection of a few very good presentations and a few bad presentations. Between the presentations, there was a vacuum.
Interaction was probably not welcome. Any questions had to be written down on the chits of paper and passed to the presenter through a moderator. Out of dozens of questions, one or two were answered. Probably the organizers were under an impression that people attend the conferences so that they do not have to read books. They probably saw the relation between the presenters and the audience as that of teachers and students. How badly mistaken they were.

The food was horrible. Some vegetarian stuff was served in a way that looked very similar to high school hostel mess. The worst part was that people had to stand in long queues under the hot sun for that terrible stuff that was served in an undignified way. Oh did I mention that there was a separate arrangement for the organizers and a chosen few. Probably something that is acceptable in Indian culture. After all it is very similar to caste system that still prevails.

There was absolutely no representation from PMI. There were no international figures. In fact for a while I thought the organizer was Prime Minister of India (PMI) and not the Project Management Institute (PMI).

I was looking forward to attend the conference at Hyderabad in November. I saw it an opportunity to meet Fredrick Harren once again. However after the experience from PMPC 2009, I suppose I should not take that risk.

And for PMPC 2010; Thanks but no thanks!

Bangalore Metro - A project management disaster.

As a child, I used to accompany my father to market, holding his finger. Few hundred meters from my house there used to be a river known as "Nallah Mar." Nallah Mar was full of silt and the water moved at a snail's pace. As it passed through the heart of the city, there were bridges after every few hundred meters. The nearest bridge to my house was Saraf Kadal and we always used to cross Saraf Kadal on foot and buy bread and cakes from a bakery on the other side.


I must have been four or five, but I clearly remember the day when while walking across the bridge we saw people all along the side watching something with excitement. Though, we did not stop, I did have a glimpse. I saw cranes and dozers at a distance rolling loads of soil into the river, filling it up. For several months we did not pass that way. I was told that the bridge was gone and there was no way to cross over, besides the area had been sealed off. Then one day we went again and not over the bridge called "Saraf Kadal" on the river known as "Nallah Mar" but over the road known as "Nallah Mar Road" at a place known as "Saraf Kadal." The road was still not asphalted and was not open to traffic.


Because of my insistence out of my curiosity, my father walked me almost a kilometer up to the place where they had reached filling up and I could see the giant machines again. It was a painful sight because as a kid I did not give a damn to the roads. Rivers and houseboats in them were much preferred sight. It took many years after that for the full length of the road to complete and get ready for traffic. Entire length of the river from its origin in Dal Lake up to the point where it merged with River Jhelum was filled up and turned into this magnificent road.


Since the topic of filling up of the river was most happening topic of discussion those days, I must have heard dozens of times from my elders the stories of Nallah Mar. I learnt that just a decade before it was filled, that would be a few years before I was born, Nallah Mar used have to have crystal clear water flowing considerably fast. There used to be houseboats on both sides and boats all over. The main mode of transportation, particularly goods, used to be the rivers and Nallah Mar was the second most important after Jhelum. There used to be several varieties of fish in the river and in summer one could see children swimming and playing on the banks. Though all this made it an important river that should have been preserved, the most important is yet to come.


After Nallah Mar was turned into a road, the city had to face something new. Jhelum started flooding every year in rainy season and few areas including some uptown posh localities stayed submerged in water for several weeks, if not months, after floods. The floods were mainly because something that our great grandfathers had created to prevent them was removed. Let me rephrase it, "Some unnecessary and unwanted nonsense that our idiotic grandfathers had created, these geniuses got rid of that."


Jhelum originates almost a hundred kilometers from the city and by the time it enters city, in rainy season, it is swollen after it has collected rain water from thousands of square kilometers. Dal Lake, with its total area of 24 square kilometer and with a mountain range, Zabarwan Range, on one side also has a cashment area of several thousand square kilometers. When the waters of Dal Lake flow into Jhelum, floods are imminent. Nallah Mar was similar to the outer ring road. It used to drain the waters of Dal Lake and pour it into Jhelum after it had left the city. The point where the rivers merged was a big basin that could contain the water, thus saving the city from floods.


When we analyze what was achieved and compare it with the cost, the project seems to be a disaster. It was one of those projects which are designed to fail and due to the magnitude the failure could be catastrophic. The purpose of Nallah Mar Road was to gear the city up to accommodate the traffic growth of then and future. It miserably failed to do that. Since all the bridges on the river, which were there after every few hundred meter, were all main roads, the new road looked like millipede with hundreds of legs. There were intersections after every few hundred meters and there were countless unmanaged and unmanageable traffic signals. It did not ease the traffic, if at all it did not worsen it.


As project managers we learn that projects do not exist in isolation but are parts of larger systems. Just like a project is affected by a number of factors, it affects a number of things in addition to the main purpose of the project. The project has results, secondary results and tertiary results. While for small projects we only consider primary and probably secondary results, for large projects we have to consider several levels. Just as we consider political, economic, geographic, environmental, human, social, cultural and a number of other factors to influence our large projects, we have to consider the effects of the project on all the mentioned factors plus many more. The most challenging but most important aspect of large projects is to foresee the future and be able to figure out how the project would influence the future given that the entire environment too would have changed. A project manager needs to have a clear point of view on how the world is going to change without and with the project. To put it in simple words, let us consider the example of building a flyover that would take five years to build. To consider today's traffic conditions is only important to plan how to build, but whether the flyover is going to serve the purpose is not dependent on today's traffic. What if after five years couple of super highways are also going to come up in parallel and there is no need for this fly over. On the other hand, what if the situation was something like the Richmond road flyover, which looks more like a joke now. Probably it is the only flyover in the world that has a traffic signal on the top. It does not even serve half the purpose that it was intended for.


Richmond road flyover was quite fine when it was commissioned but just within a couple of years Richmond road as well as the Residency road were made one way for traffic. The authorities then overlooked the fact that sooner or later these two roads would have to be made one way. In fact making of the flyover was one of the reasons it had to be done so soon.


Bangalore metro is being built with the intention of providing faster and cheaper public transport that would ease traffic on the roads of Bangalore city. In next few years it will be ready and put to use. The traffic growth on the roads will not slowdown but would continue to grow at the same pace. Traffic jams would be so bad that many people would run away from the city. Even after that traffic would continue to grow. Building of flyovers and tunnels will be impossible on most of the high traffic routes because of the metro. Widening of roads will be difficult and building new roads will be too costly.


Long back I happened to watch an ad spot of "IBM - On Demand Business," which I must have mentioned at least in ten conferences, seminars or workshops. The ad starts with the outside view of an airplane and immediately the next shot is inside view. An old man, depicted as owner of the aircraft is shown in bed and there is chaos in the plane. A person comes to the old man and informs him that the plane was going down. Their subsequent conversation is as follows:
Old man: But why is the plane going down?
Person: Because an engine has failed.
Old man: Is there only one engine?
Person: No there are two.
Old man: Why don't they start another engine?
Person: The other engine is running but the plane is still going down. The plane is too heavy for a single engine.
Old man: Then why don't they make the plane lighter?
Person: How do they do that?
Old man: Perhaps they can throw out things like furniture.
Person: But the furniture is fixed.
Old man: Then throw out what is not fixed.
Person: Everything is fixed.


Similarly ten years from now they will say that nothing new can be built because everything is fixed. Bangalore metro will make Bangalore so rigid that Bangalore will go down.


I am not suggesting that the persons, particularly the project managers working on the project are not competent. Some people at the top of the hierarchy who have the power to override always mess up and that is not going to change.


Bangalore Metro might one day prove to be an engineering marvel but it is a project management disaster.

Extra pair of eyes

"If you were given an extra pair of eyes, where would you like them to be?" This was the question Fredrik Haren, author of the idea book asked the audience. Almost all replied instantaneously, "At the back of my head!" This sounded like the best answer, as then one could look in all directions without having to turn around. "This is probably the worst answer," said the author.

By the way this was on Feb 9, 2009 at Kuala Lumpur where Fredrik was the keynote speaker at PMI Asia-Pacific Global Congress. I would not go into details of what else he said as I have already discussed that in an earlier blog. However, if I was given a choice to choose where I would like this extra pair of eyes, I would say "on the person next to me." I do not see much use of this extra pair of eyes when my brain is not capable of processing two different views at the same time. I do not mind turning my head for another view, as I do not want to mess my brains up.

If the two eyes came with the brain too, that would change the situation. If the two eyes and brain came with rest of the body parts and everything that makes a person, that would be perfect. Yes, there was an easy way to say all this, I need another person, but the story says something more than that. It says that the two persons would still be working on the same task. Contrary to the hypothetical scenario where we expect two pairs of eyes to look at two different views, here the situation is realistic and needs two pairs of eyes and the two brains behind them look at the same view from two perspectives. That would give us something closely resembling a 3d view.

Much earlier in my career I worked for a company for fifteen days when I was between jobs. On the first day the company was faced with a situation where we had to decide in a minute whether we would take up the job of digitizing a few thousand key-value pairs from handwritten hard copies. We could refuse the job but if we accepted we had to deliver the soft copy in six hours with absolutely no mistakes. My bosses were not even discussing it as they were pretty sure the target was out of reach. They were particularly scared of errors that would have landed us into trouble. However, on my insistence they decided to give me a chance.

It was 4 pm in India and we were required to deliver by 10 pm Indian time, an hour before our counterparts in US were supposed to demonstrate a particular solution. It was a simple, clear cut, well defined and a pretty critical job. I, first of all, assembled the whole team and explained to them how important the task was for us and how it could shape their careers. In just a few minutes I got 20 volunteers who were willing to stay back till 10pm and were well motivated and energized. Instead of splitting the data into twenty I paired up the team and distributed the sheets among 10 teams. The target given to them was 9 pm but I received all 10 files before 9. Then I interchanged the files between teams and they once again verified each other's work. It took me hardly 10 minutes in the end to combine the 10 excel worksheets into one and the file was sent by email before 9:45.

Next morning we had a friendly chat session with the management and it was acknowledged by all that the best thing that we had done was working in pairs. In a way we used only 10 people with an extra pair of eyes for each and the value we got in return was much more than just 20 pairs of eyes. Probably this is what happens in extreme programming.

Basically when we do a code review or even otherwise analyze the root cause of bugs going into the code, we realize that most of the bugs are not due to inability but due to oversight. My experience as programmer has also taught me that it is more time consuming to detect and fix an issue if it is small and difficult to reproduce. Generally such issues are detected much later and cost an arm and a leg in terms of money and somewhat similar in terms of time. Sometimes it is just a typing mistake, where a programmer thinks something but his fingers have typed something else and sometimes a programmer just overlooks a reasonably evident potential issue. Even in the unit testing most of the defects that a programmer detects are very simple mistakes. Most of the times when we write a piece of code, it does not even compile for the first time. We discover that we have missed a semicolon somewhere, we have also missed to import some class and we have missed to declare some method correctly. Very small and simple mistakes that we fix in less than a minute. We compile again and it works. But what about other such small mistakes that the compiler does not tell us about?

Before I move on I would like to sincerely apologize to the non technical people as there was no way I could have explained my next point with simpler language.

Suppose we are required to code a java method that updates the last name of a member. The programmer writes the query in two lines appending the second to the first and both are inside a try-catch block.

String query = null;
Try
{
query = "UPDATE ACCOUNT_TABLE SET LASTNAME = " + newName;
....... some code .........
query += " WHERE MEMBERID LIKE " + memberID;
}
Catch (exception exp)
{
//do nothing
}
updateQuery(query);

I suppose most of you already know what is wrong with the above code, but for those who do not, let me tell you what it is. This is a perfect recipe for disaster. This method will be called hundreds of times every day if the website has millions of users and there are good chances that due to whatever reason on some value of memberID an exception will be thrown or there might be an exception thrown due to a bug in the code between line one and two. With the result the second part will not be appended and the query that is executed will change the last name of all the users, probably millions of users to the new name. What are the chances that a programmer will write the code as above without realizing what's wrong? It will be a small and simple mistake with catastrophic impact. The recovery will be somewhere between very difficult and next to impossible if not detected within a few hours, unless there is a backup.

An extra pair of eyes makes it almost impossible for a programmer to make such mistakes.

An extra pair of eyes can also be a savior in management. Often the c-Suite executives face the challenge of being lone decision makers. They find lot of people who nod their heads in affirmation of whatever they do or say but very few to show them the reality. This is not just done by the reports to get themselves in good books but also by the friends and family. The impact is again often catastrophic. Few years back one of my friends who was the CEO of a well established company came up with some weird idea. He wanted to build a product that did not seem to have a good revenue model. The problem was that, even though being an MBA from a reputed university in US, he thought less about the risks and was more interested in listening to his friends who told him:
"What a wonderful idea!"
"Nobody has done this before, you will be the first."
"People are going to love it."
"That is so innovative."

Nobody told him that since he was making a loss per piece, the more he sold more he would loose. It was just not an idea worth considering but he was able to see it from a single perspective and from that perspective it looked wonderful. Had somebody shown him the reality, he would still be the CEO and more important the company would still be functioning. This is precisely the reason many management gurus advocate employing a mentor, an advisor, a coach or a consultant (whatever the name). It is definitely not because the extra help is better in any way but only to show the reality as and when required.

The extra pair of eyes can do wonders.

A leader without followers

Technically speaking, a person is a leader if and only if he has followers. However, there is nothing technical about leadership. The definition of leadership neither needs to be logically correct as it is not purely science nor does it need to be centuries old definition found in dictionaries as it is not an art that somebody created and it stays as it is till eternity. In fact these definitions are misleading.

According to wikipedia.org, "A leader is someone who has the authority to tell a group of people what do to. A leader can also represent a group of people." I disagree. Mahatma Gandhi was a leader and when he became a leader, he had absolutely no authority. He proved to be even greater a leader by choosing not to accept the position of authority but continuing as a leader. Leadership and authority are two different things. They have a small area of intersection but the bottom line is one can be a leader without any authority and one can have all the authority and no leadership.

Another definition that I have come across is, "Leader is a person who has followers." I disagree. Firstly, a person can be a self leader. Leading self is the first rung on the leadership ladder, followed by one on one leadership, group leadership and finally organizational leadership. A person who can lead himself well is a leader without followers. It is possible that a leader has no followers because people around him either fail to see the leader within them or they are just not the follower type. Sometimes the leaders are so great that they lead without making other realize and without making others their followers.

A child who consoles another child and comforts him when he is hurt is a leader. A child who offers to lend his notebook to another child who has missed a lesson or two is also a leader. A driver who stops by to offer help to a person standing besides his car with a flat tyre waiting for help is a leader too. I am not saying doing other persons work is leadership.

Some other definitions define leader as the top guy in the organization. I again disagree. For being a leader you neither need to be a CEO nor you need to have that prime corner office. Leadership can be done from anywhere in an organization and a real leader is a 360 degree leader. He leads his bosses, his peers and his reports. He even leads the people who are not his direct reports. He does not need a leadership tag or a position. He does not even need any followers or recognition.

The best definition of leadership that I have known so far is, "A leader is a person who with his deliberate effort unleashes the capabilities and inner strengths of himself and that of others for a greater good."

This definition neither talks about followers nor any authority because both are irrelevant. It does not talk about accomplishment because leadership is not about results. Leadership is an open ended journey and a choice that people make, sometimes deliberately and sometimes without realizing when they do it.

Are most of the bosses idiots?

Speak to any middle level manager and the changes are good that he will tell you how his wonderful ideas are always turned down by his boss. Probability of this is far greater if you are speaking to technical person like a project manager or an accounting person. He will also give you a pretty good (apparently) explanation why the latest plan of his boss that they are already working on is going to be a disaster. He will convince you that it is he who is the genius with very little authority and his boss is an idiot with all the authority.

I am sure since you do not know the boss you will not try and contradict this self styled genius. That is what happens most of the times. Suppose you did, the conversation could be something like this:

Him: xxx xxxx Blah Blah Blah

You: It sounds like your boss is an absolute idiot.

Him: Absolutely. He is.

You: I wonder who made him boss then.

Him: I know …

You: What do you know? I am asking you, who made him the boss.

Him: Probably himself. He made himself the boss.

You: You mean not his ability, talent, knowledge or experience, but just he himself made himself a boss?

Him: Looks like.

(By now the guy is pissed off with you already. But he is pretending to be a good guy by still continuing the conversation.)

You: With what authority did he make himself a boss and who gave him this authority?

Him: How should I know all this?

(There is a small pause. You are probably giving him some breathing time)

You: So it looks like you are saying the only different thing that he did was appointing you?

Him: Different?

You: Yes since you are saying everything he does is wrong and I am sure you would say appointing you was a right thing that he did for himself.

Him: I am not saying thaaaaat …. But….. yes somehow.

You: No be clear about what you say. You are saying that everything he does is wrong and only appointing you was right.

(Half of his steam is already out. Do not give up now.)

Him: No I am not saying everything he does is wrong, but many of the things he does are wrong.

You: You are retracting.

Him: No I am not. I never said everything he does was wrong.

You: Now you are making it sound so normal. It is just human to do a few things wrong. Why did you say you boss was an idiot then? I am sure even you don't do everything right. You would be an angel then.

Him: No I am not claiming everything I do was right, I make mistakes sometimes.

You: Five minutes back you were telling me that your boss was an idiot and everything he did was wrong and now you are telling me that you are very much like him. What do you want me conclude?

Him: I don't want to talk about this.

The above was a purely a hypothetical situation and we won't normally be in such a situation in real life. The reason is when others are portraying their bosses as idiots we would derive pleasure out of it without realizing that we would be in their position too. The funniest part is that these employees are themselves on the path of becoming idiots and are striving hard to get there as soon as they can.

I agree that not all bosses are alike, however in most of the cases it is the employees who are not even capable of understanding the bosses. I have never heard a boss saying his all his employees are idiots and he runs the show all alone. Have you?

Why this difference? Why do employees feel that their boss who is in a better position, with more experience and often with more skills and knowledge is an idiot while the boss would seldom feel the same for his employees?

In my opinion there are a few reasons. Employees do not think they need the boss, they just need the job. To acknowledge a leader one needs to have some leadership qualities himself. Since these employees are not mature leaders (yet) they do not understand the importance of the leader. On the other hand the boss knows very well that he needs to delegate the authority and well as the work to get it done. He knows he needs his people and his existing employees are more valuable to him that anybody else.

In the above hypothetical conversation I have also attempted to depict that the employee is confused when confronted. This is also very normal. If we put a leader in such a situation, there are very little chances that he will react that way. The reason is that leaders have clear "Teachable Point Of View" (TPOV). If a leader says his employee is an idiot he most likely have a pretty good explanation for that that he would be able to present as a convincing story. On the other hand generally employees in lower position lack the clarity and do not have a well defined point of view. They have a blurred idea. They think there boss is somewhere near 5 on a scale of ten, when they like they will portray him as idiot and when they like they will portray him as a genius.

Being somewhere near 5 does not apply to judging their boss alone. It applies to every second opinion that they have. Hand them a survey form and they will tick the option in the middle for every question. On the other hand, hand over the same form to your boss, he will choose the extremes. His assessment is very clear.

I have made an attempt to write this post in a different way as you must have realized above. Please leave a comment on the writing style.

Is a penny saved a penny earned?

Not always! Often a penny saved is a penny not wisely invested resulting is a loss. As soon as the news of economic slowdown started spreading people started talking about cost cuts and head count reduction, etc. I am pretty sure most of the companies started downsizing and taking other so called cost saving measures much before they started feeling the impact of the global credit crunch, if they at all did.

Last year I happened to attend a conference that was followed by a panel discussion. In response to how his company was dealing with the issue, a senior executive of KPMG Malaysia said that they had no plans of mass layoffs. They had already started cost cutting in various other ways. They were flying economy class and were avoiding unnecessary expenditure.

This kind of a penny saved is a penny earned.

Every year major companies of the world publish their net profit per employee. Even if they do not the calculation is pretty simple. Every company does publish the net profit and the number of employees too is no secret. The point is employees are there in the company to make profit. An employee adds value which is far greater than his cost to company. If that is not the case, then that employee should not even be employed. If we ignore other factors for the sake of discussion for while, laying off employees would mean saying no to profit.

On the other hand, if the company is not able to create enough work for the employees to do, keeping the employees would be a loss. Which means it should be alright to lay off people for whom a company does not have work. However, this argument changes the equation. It is the failure of the company to create enough work and no fault of the employees. Due to this very reason an employee laid off is not equated with an employee who has been fired.

This kind of a penny saved is also a penny earned.

However, most of the times the scene is quite different. The moment one company announces a mass layoff, a layoff competition starts. Suppose a company lays off 1000 employees, the competitor lays off 2000. Yet another competitor lays off 5000 and so on. The explanation, which is usually not made public, is that they would loose competitive advantage as the competators have cut down cost. Is it not analogous to somebody cutting his arms because the competitor, the poor competitor, had to chop off his finger tips due to frost bite? The poor guy was helpless; he had a good reason to get rid of a small body part. But no! Competition is competition; competitive advantage has to be maintained even if that means giving off the legs too.

We realize that doing anything for the sake of doing it without any good reason is bad. For instance making a change for the sake of making a change is bad. There should be a good reason for making a change. But this is the extreme, cutting off your arms and legs (otherwise what would you equate the employees with, hair and nails?) for the sake of doing it?

A penny spent on this employee was supposed to get me a million, so is this penny saved a penny earned?

P.S: I am not saying the above is true in every case. There are a number of good reason that companies sometimes have to lay off employees.

A small tip on passing PMP

The best tip on passing PMP exam is probably the simplest one too. To pass the exam one has to understand what this exam is all about. PMP is an attempt to find out if the candidate has actually been there working on these projects, using the right methodology, processes and tools and how capable he is of solving the problems in real time. If one does not understand that, there are easily 30% questions in the exam that might not even make sense, might have no best answer within the choices provided or might have more than one best answer. On the extreme out of four choices all four might be right.

More than knowledge PMP exam can be passed by visualizing yourself in the position as described in the situational questions and then take the decision that you would take. When I did my PMP I realized there were few questions which actually had different best answers if it were a math paper. In math when the information is inadequate, the best choice is usually number 4; cannot say or something with same meaning. In management you do not say cannot say. It is very normal and best to try and get as much information as possible about the problem before taking a decision, but when the decision has to be taken it has to be taken with whatever information is available. Once one understands that, one would at least answer 10% of the questions differently and that would make all the difference.

To elaborate a little further, imagine yourself in the situation as described in the question. Imagine yourself a project manager of a multi-million project even if you have never worked on a project exceeding a few hundred thousand.

I would conclude this post with another useful tip. Do not assume that you can do the paper in one linear flow. Even at the best, no matter how confident you are, please revisit the answers at least once and plan your time to accommodate that. You will realize that some of the questions have different best answers on the second look. On first look more of your concentration was on reading the question and understanding the situation. You still needed some time to think over it and let your subconscious mind to some work. On the second look, you have had that opportunity and you concentrate more on the solution.

It is quite easy to pass PMP exam, but very difficult to pass it if we treat it like other exams that we have passed so far.

What should be put on WBS?

I am writing this post in response to a discussion on LinkedIn titled "Do you incorporate the PM processes into your WBS?"

Technically speaking everything that is being done, has already been done or has to be done on a project must go to WBS. In other words anything that is not on WBS must either not be done or added to WBS.

Please excuse me if it does not sound very polite but there is no scope for what you think and what I think here. What is right is right. WBS must contain no less than 100% and no more than 100% work on the project. It is a living document and is updated very frequently until the closing stage.

It might not always be possible to have a perfect and complete WBS in the beginning. Very often, and particularly in the crisis situation, we might need to call emergency meetings or work on work around plans that were not there in the WBS. In such a situation, the new tasks are added to WBS and the task of adding the tasks on WBS, which is itself a task is also added to WBS.

I am not adverse to the idea of avoiding putting very minor tasks to save time and effort. However, we must acknowledge that that would be a compromise and not the correct way. That might also be the best way in certain situations, but again that will not be the correct way. After all sometimes the correct way is not the best way.

Some of the project tasks that are apparently small in nature can be grouped together into a task of visible magnitude. For instance the "secretary's time to send your package to a vendor" might be grouped with an adjacent task or a few. If it is not, then where else do you show it in the plan? We cannot put it in the schedule if it is not in WBS.

On the other hand meetings are not considered small tasks and must go to WBS without fail.

Coming back to WBS, what is WBS after all? Is it just a planning tool? The fact is that it is more a communication tool. It is used to communicate scope of the project or all the tasks that would need to be done to realize the scope of the products (derivable) of the project, to the stakeholders. After the WBS, supported by the WBS dictionary, is approved by the stake holders, particularly by the customer, the sponsor and the project team, the same document is processed and elaborated to make more than half of the project documents. The cost estimates, budget, final costing and invoices, etc everything is based on WBS.

However, there is a catch. Customer will never be happy to see "secretary's time to send your package to a vendor" on his cost breakdown statement. Customer is interested in how much it totally costs him to send the package. Customer wants to drill down, but does not want to go beyond a certain level of granularity. Therefore, the WBS presented to customer along with the cost estimates or cost break down statement looks a bit different. We do not have to prepare two WBS, but just roll up the activities to the control point level.

Another thing to consider is the two groups of tasks namely value adding tasks and non value adding tasks. What if the customer says, "I will not pay for the secretary's time, why can't the manager spare two minutes to send the package?" What if the customer says, "I won't pay for the project manager, let the programmers manage the project themselves." How do we handle such a situation? The solution is simple; we do not show any task on the cost plan that can be attributed to a single person. We instead show groups of tasks which together are value adding, a derivable or a tangible part of the derivative. Now the question is, is schedule a derivable? Of course it is. Then who says the tasks involved to create a schedule, pure project management tasks, are not shown on the WBS? Is CPI within some range and SPI within some range not a requirement? Then who says the tasks required to be done to achieve that are not shown on WBS?

To conclude, the 100% rule which states that WBS includes 100% of the work defined by the project scope and captures all deliverables - internal, external, interim - in terms of the work to be completed, including project management is no non-sense. It is simple and accurate.

Contingency reserve planning

Not only are the risks identified or sometimes discovered at various phases and stages, the risks are also pertinent to various levels. There are risks to a task, to a work package, to a set of tasks, to a module, to a phase, to a few modules, to a few phases or to the whole project, etc. The best approach to plan the contingency reserve is the bottom up approach, calculate it at the stage where it can occur, base it on the actual probability and roll it up to get the project or phase buffer.

Before I write any further I would like to make it very clear that I do not advocate using this approach on each and every task or each and every project. Often it is not a challenge to identify what can be done, but the real challenge is to know what not to do and then not to do that. It is rather very difficult to resist the temptation of doing something that we can do. Particularly for the less experienced people, it is painfully difficult. For instance a new web designer wants to show all his creativity in the first web page that he is designing and makes a mess out of it. Although he thinks he has done a great job, it takes his team a great deal of effort to teach him what not to do rather than what to do. Therefore, please do only as much as adds value compared to the cost.

I would also like to say loud and clear that all risks are not mitigated. Further there is a tendency of taking negative risks or threats into account and ignoring the positive risks or opportunities. So much so that many people would argue that opportunity is not a risk. They would say it is a risk only if the affect is bad. That is not the case. There are positive risks called opportunities and not taking opportunities into account will result in loss of opportunity and would attract opportunity cost.

Therefore, our job is to decide whether to avoid, transfer, minimize or accept the threats and how to exploit, attract and maximize the opportunities. Cost is a big factor that very often makes it most viable to do nothing.

I would restrict this post to the risks at the work package level and the same approach can be extended to all levels.

For the risks at the work package level, contingency requirement must also be calculated at the work package level after the risk mitigation planning. However, the reserve is added to whole project or a phase. This reserve is directly proportional to the root of the sum of individual standard deviations and proportional to the function of confidence level required and normal distribution curve. Confidence level is a requirement that has to be defined. So next time when you are asked to prepare a schedule, please seek agreement on the confidence level, if you are not already doing so.

Most of the projects fail to meet the schedule because most of the schedules are based on 50% confidence level. Therefore, 50% projects are scheduled to fail.

Adding buffers in lump sum is a wrong approach. Though it might seem to work in some cases, it is very similar to the approach of "take your best guess and multiply it by two." I am denying the fact that, that approach might also be acceptable sometimes.

Coming back to the topic, this approach uses pert balanced average like most of the scheduling methodologies. However it does not use the weights of 1:4:1 that most of us are familiar with. It does not even use the same weights for all the tasks. That does not mean that MS project can't be used, though I will not cover that part in this post.

By the way, using the weights 1:4:1 is an assumption and taking the sixth part of the difference of optimistic value and pessimistic value as standard deviation is an approximation. The correct way is to base the weights on the actual probability and calculate the standard deviation using the formula that we were taught in school.



In this approach we do not consider the most optimistic, most likely and most pessimistic estimates, but we consider every possibility individually. After estimating duration for all the possibilities a task would take to complete, we find the actual balanced average based on the probability of each possibility and the actual standard deviation. We then find the project standard deviation and the sum of the balanced averages of the critical path tasks. Finally we can calculate the total duration and the contingency reserve based on the confidence level required. I think everybody knows that 100% confidence is neither mathematically possible nor logically. Generally 95% confidence is taken as acceptable, though it is highly industry, domain, organization and individual specific. By the way, we can do most of this work in MS Excel.

Although, only tasks on the critical path need to be considered, we must also check the near critical paths as sometimes after risk mitigation planning, critical paths change. Therefore, non-critical tasks can become critical tasks and vice versa.

Let me use an example to explain:
Let us assume we are working on a project with three tasks, say A, B and C with finish to start dependency. Which also means that all three tasks are on the critical path. Task A can be completed in 10 days. However there is 10% likelihood that a friend might lend his machine free of cost and the task can then be completed in just 5 days. There is also a 25% probability that another machine that we are supposed to receive might come late and might delay the task by another 10 days.

Based on the figures so far:
The correct balanced average is
m1 = ((10 * 5) + (65 * 10) + (25 * 20)) / 100 = 12 days
And the standard deviation
s1 = 4.87


Now suppose there is another risk that might happen and has a probability of 5% of happening. If this happens, it will take twenty days extra to fix the issue. Then:
Balanced average
m1 = 13
And standard deviation
s1 = 6.23



Suppose for task B:
Balanced mean, m2 = 15
Standard deviation, s2 = 5


And for task C:
Balanced mean, m3 = 20
Standard deviation, s3 = 2


From above figures, if the confidence level needed is 50% then
The total duration
D = m1 + m2 + m3 = 13 + 15 + 20 = 48 days


If we need a different confidence level then we need to calculate the project standard deviation:
Project standard deviation S = SQRT (s1² + s2² + s3²) = 8.23


Suppose we need a confidence level of 90%, then from the cumulative (single tail) probabilities of the normal probability distribution we have
Z = 1.29
Buffer = 8.23 * 1.29 = 11 days
Total duration with 90% confidence = 59 days


Similarly we can calculate the buffer and total duration for other values of confidence level.





In conclusion I would like to remind that contingency reserve is not a piece of cake to be eaten at will; it has to be managed well and utilized only when needed. The whole idea of this approach as well as recommended by PMI is to remove the buffer from task or work package level and roll it up into a contingency reserve.

Project Manager or a Technical Leader

Does a project manager need to be a technical person? This debate has been going on for years and probably decades. There are thousands of excellent blog and forum postings, mostly by project managers. The general opinion is that project managers do not need domain knowledge as good project managers are capable of acquiring whatever it takes, inclusive of domain knowledge.

Contrarily, most employers insist on domain knowledge, without which it is almost impossible to get jobs these days. Project managers feel that is tragic and being a project manager myself (irrespective of the job profile) I agree with them. However, we must try and look at the whole issue from the perspective of top management in order to have a better understanding.

About a decade back, when I was working for an advertising agency, I was assigned the task of screening candidates for the selection of sales representatives. It was kind of a situation where supply exceeded demand a thousand times. Therefore, the screening was expected to be very thorough. Though freshers had not been instructed not to apply, there was little chance that we would have selected a fresher. I personally felt bad for them but not as bad as I would feel seeing experienced people, who generally have families to support, jobless. Nevertheless, I took great care avoiding my feelings influence my decisions.

After interviewing a candidate, who was brilliant but not experienced, I asked him if he had any questions. He had one, and that was, "If a fresher does not even get a job how can he gain experience?"

I replied, "If freshers do not get jobs then where do these experienced people come from? The fact is that freshers do get jobs but at places where they can accommodate freshers. So far we have not taken any decision on selection of any candidate or otherwise. However, if we can accommodate freshers, the most deserving ones will be offered jobs." What I told him was a fact. If a post can be filled in by an employee with the least pay scale (fresher) who would want to hire an experienced person and pay several times more. On the other hand, if the salary is fixed, who would not want to hire a person who can deliver most?

The bottom line is that like every kind of buyer, an employer tries to strike the best deal. This is the reason why organizations want project managers with PMP as well as domain excellence. "Java project manager" no more makes me laugh as it has become a norm. It has been widely and happily accepted through out. I won't be surprised if PMI introduces credentials like PMP-IT and PMP-Construction, etc in near future and PMP-Java and PMP-dotnet slightly later. After all, as shopkeepers they need to keep on their shelves what they expect customers to come looking for.

If I were to choose between two project managers who were equally good at project management but one had domain knowledge, I would definitely choose the one with the domain knowledge. Most ideally I would rate all the candidates on the basis of their project management skills and I would consider domain knowledge if the best candidates tie. Would you not do the same?

Coming back to the example cited above, what is the harm trying to choose a project manager with domain knowledge from the ones who would score 10 in project management skills? I don't see an issue with that. However, the problem is when a good technical person is assigned the role of project manager without gauging his managerial and leadership qualities. More than often technical people find impossible to step out of their technical mindset in to the world of business.

Top level managers and executives are "why people", they are concerned with why a project, why a task, why the business and why this project manager, etc. On the other hand technical people are "how people". They are concerned with how to do it, how to write this piece of code, how to build this piece of hardware and so on. In a balanced organization why people and how people keep a check on each other, correct each other and complement each other. When a how person is put in the place of why person, he is most likely to fail keeping check on and correct how people as he is basically one of them. He also fails to adjust in his role of why person because he cannot stop thinking how and he does not know how to think why.

Managers assure but they do not ensure. They have their teams to ensure. On the other hand technical people seldom assure, they ensure. One of the most important jobs that a manager does is delegate. Technical people would any day prefer to do it all by themselves. Both these approaches are very important for the respective role but they can be damaging if interchanged. If the manager finds it difficult to delegate, the team will go nowhere.

Managers are good at looking at the bigger picture while technical people can see the finer details more clearly. Just as they say "A product for everybody is a product for nobody," I think a person who can see every level of granularity from the top most to the bottom most level can actually see nothing.

People with technical aptitude are no less or no more than people with managerial aptitude. They are just different. A manager is not made up of what a programmer is and vice-versa.

Employers insisting for domain knowledge are actually multiplying the probability of hiring people with wrong skill set. I wonder if they know the cost of hiring a wrong person which some estimate put up to two years of basic salary of the wrong hire in direct costs and much higher when indirect costs are added.

Are they striking the best deal?

I sincerely recommend them to read "Who" by Geoff Smart and Randy Street.

What is project management?

A PMP considers PMBOK his professional Bible. I very much do that too. At the same time I strongly disagree with the very definition of project management in the PMBOK.

The exact words in the PMBOK are as follows:
Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements. Project management is accomplished through the appropriate application and integration of the 42 logically grouped project management processes comprising the 5 process groups.

What does the above statement say? It says application of knowledge, skills, tools and techniques is project management. Is that so? It also says project management is accomplished through appropriate application and integration of whatever. Is that so?

Let us look at an alternate definition.

"Project management is the process of right planning, executing and controlling of the project to achieve project objectives, effectively and efficiently."

Like the general management, project management is all about the effective and efficient utilization of men, material, machines and money to maximize the throughput yield within the parameters of time and quality.

I think PMI needs to relook into their definition of Project Management.

Living in the fools' paradise

We often say, "Failure does not just happen, it is designed into the system." One of the most important inputs or required inputs for each and every plan in the project is the assumptions. If you don't do a good job managing them, it is very difficult to do things right. You don't even have the requirements complete, leave alone the specifications, until you have not converted most of the assumptions into requirements. That is the importance of assumptions.

I suppose it is needless to say that the easiest way of designing failure into the system is to base it on wild assumptions or to ignore assumptions. It is the assumptions (or call it sky high expectations) that kill hundreds of businesses everyday even before they start, though they realize it much after.

You build a magnificent website with a beautiful UI. You have a wonderful revenue model and you expect millions in first couple of years. Worst of all, your best friends praise your site and the brains behind it. You know everybody around you likes your site. All that turns out to be meaningless when in reality you even fail to make enough money to pay your salaries. Sometimes you don't even make enough to pay for the hosting costs.

The root cause for this failure, most of the times are the wild assumptions, some of which are listed below:

Everything will go as planned

It never goes exactly as planned. Small changes and adjustments need to be made even in the most well thought and well prepared plans. The difference is that wise planners keep the provisions for easy identification and implementation of changes and others, who think they are wise, do not think any changes will be needed as they are sure that everything will go as planned.

There are buyers for everything

We often assume that everything sells if you try. There are buyers for every product and no matter how weird your product is or how exorbitant your price is someone, somewhere will be willing to buy. In reality people are not so dumb. I am glad I belong to the species in which there is hardly anybody so dumb to pay you for whatever you have to offer. People pay either when they see the value or when there is something in the product that their other feelings override the simple logic. For example excitement, love, anger and suspense, etc. Even for taking advantage for these feelings you need to have the right product, available in the right place and at the right time.

For instance, people do not mind paying ten dollars for a rose that would otherwise cost one dollar on the Valentines eve provide it is sold in urban areas, places that are easily accessible, where there is no problem of parking and provide it stays fresh towards the evening when most of the shoppers are going to look for it.

People will somehow find your website

Some people think cyber space is exact replica of real world. They think everybody cannot fit in one place and that is why we are distributed over the planet, over continents, over countries, over states, over cities and over lanes and by lanes. Therefore, wherever you are on earth, as long as there is a road to reach you, someone will reach you. Similarly they think as long as your site is on the internet someone will find you.

In reality nobody turns up of his own. People have to be pulled or at least told that there exists this wonderful site in the world.

People know what you are offering

People around you might but others don't. Some of them might go beyond you index page and try and understand what you are selling, but most of them will just walk away unless your website is sticky enough to hold them back. Therefore, provide as much information as possible in the least possible words.

Users know how to use a website

I will not say they don't because most of the users actually do. But they might not know how to use your website if your website is too different. It might be easy, but the moment they find it different they walk away. They do not want to take the trouble of going through the learning curve again and again.

Therefore, while on one hand innovation is the backbone of you website on the other don't try and make you UI too different or complicated.

People don't mind to signup

Their minding to sign up or their not signing up is exponentially proportional to the amount of data that you ask them to fill in the signup form. Therefore, ask them for the data that is really important and leave the rest for later.

People will contact you in case they face problems

"Who cares!" that is the attitude of the customers most of the times? When a customer faces a problem that prevents him for doing something that he intended, he simply closes his browser or goes to another website. If he was really there shopping, he would land up in competitors' websites.

Customers are loyal

Many people believe that they can have loyal customers and loyal customers are all that they would need to keep the sales on the top of S curve. If you are one of them, I would strongly recommend Loyalty Myths by Lerzan Aksoy, Henri Wallard, Timothy Keiningham and Terry Vavra. In actual practice, and particularly on internet, customers are not loyal enough to stick on to your website. Instead they are more inclined to try different stuff often just for a change.

Though it is good to try and hold your existing customers, often it is even better to focus more on new customers. From your old customers some will stay anyway and some will leave anyway, that leaves a small group that you are trying to keep compared to a much bigger group out there that you can attract. It is often even less costly to attract new customers than to keep the old ones glued to you.

That does not mean you should not try to hold you old customers but don't do that at the expense of getting new ones and vice versa.

The debate between Scrum and PMI

In the words of my ex boss, "This is a chicken and an egg situation." Here the issue is not what came first, but what is better. I fear if we toss a coin to decide that, the coin will defy the law of gravity and refuse to come down.

In 2004 I attended my PMP exam preparation course. It was wonderful and I hold the trainer Mr. Gurudev Randhawa in very high esteem. That course was a turning point in my life. Besides knowing what the project management was all about, the PMBOK (Project management body of knowledge) kind of got embedded into my mind. After the course I could see very deep into the PMBOK but I could see nothing beyond it, or rather outside it. I thought PMBOK was the ultimate and you simply could not fail once you knew PMBOK. (Gosh, how many times did I have to type PMBOK?)

In 2005 I did my Six Sigma Green Belt certification and attended a training course on Six Sigma. Does the history really repeat itself? It did! We were told that Six Sigma was the ultimate that was required for success by any organization. In the four day (32 hour) training program, project management was hardly given two hours. That was a bit strange. A bit hard to digest, but that is what they probably thought so called project management deserved within the all important Six Sigma.

In 2006 I did my PMP. Third time I was told the same. "After PMP you will be in demand, because PMP is blah blah blah!!!" Few questions through in my exam, I knew I was doing everything right and expected around 90%. Probably I had started dreaming that HR of a few top companies were waiting for me right outside the door. The moment I step out they will all pounce on me with their offers. All I had to do was to accept the highest offer. I agree that is a bit exaggerated, but just a bit, just to make it spicy. The advocates of PMP had painted such a rosy picture of "post PMP myself", that I was already feeling on top of the world.

In 2007 I attended another training program titled "Managing program professionally." Probably that was my first step towards PgMP. This time I was sure I would have been able to do what I had not been able to, after my PMP. But looks like time is a wheel and same things have to happen again and again, though with some small differences. The fact is that there was an improvement in my capability, but not so extraordinary.

In 2008, after reading lot and hearing a lot, I gave a try to scrum in my organization. Now this scrum, as the advocates claimed, was expected to do wonders. It did. We produced the same "value adding output" that we did earlier in one third the time. Rework was almost eliminated as the product owner was virtually with the development team throughout the project, in every project. We were also able to effectively take the advantage from the ideas that sprung from everywhere. Probably everybody had collected so many ideas but before this they did not find the right opportunity to speak out.

Having said so, I still do not recommend anybody to blindly adopt any methodology, not even scrum. At the moment scrum is quite happening and it is not bad at all, but it is slightly risky. Rather I should say it has its own pit falls, like other methodologies. The biggest assumption that we make in scrum is that the programmers are knowledgeable and skilled. How can we even make this assumption when the statistics show that 75% of fresh IT graduates are not even "Industry ready?"

Basically there are four types of people. 1. Intelligent and hard working.2. Intelligent and not hard working.3. Not intelligent and hard working.4. Not intelligent and not hard working.
Most agile methodologies and particularly scrum is bound to fail if there are just a couple of team members from group 4. It has very high chances of failure even if there are a couple of team members from group 2 or 3. In other words, scrum is very likely to succeed only if all the team members are intelligent and hard working. How many such teams have you seen? Such teams can be developed by differentiation and elimination. However, that will have significant negative effect.

In practical situation, no matter how hard we try, we end up having employees with wide range of knowledge, skill sets, aptitude and motivation level, etc. All cannot be on the same level.
Another big issue is expectation level of the customer (sometimes the attitude of the customer). In a typical B-B customer-vendor scenario we come across two types of people who disagree with us. For the sake of confusion avoidance let us call them type A and type B.

Type A people disagree because they have their own valid and logical point of view. They often have a clear teachable point of view (TPOV). While it might be a little discomforting working with type A for a short while, in the long run it is a great opportunity. With them, often in just one or two rounds of discussions a third approach evolves that takes care of everybody's concern. From such people we get to learn.

Type B people disagree because they have to disagree. Disagreement is in their nature. They can never tell you why they are disagreeing. At the most they will tell you they want things their way because they want it. "I think it should be like this," that is what they will say in the beginning and "I still think it should be like this," is what they will tell you after days of screaming, shouting and head banging. Neither in the beginning nor in the end will they be able to tell you why they think so.

Do I need to explain why scrum will miserably fail with type B people? The only way of saving yourself from a heart attack will be to commit suicide.

So far I mentioned only PMBOK approach and scrum. I did that deliberately because that is what the debate has been about. Further I am not saying that PMBOK is a methodology and neither does PMI prescribe any methodology except the mention of waterfall model and spiral model, if I correctly remember. PMBOK is a collection of all the processes recommended by PMI, out of which the ones relevant to the project can be chosen and adopted for results. On the other hand scrum is very much a methodology.

The overall list of methodologies from the two main families is quite long. I do not think any methodology is bad enough not to deserve a place in the respective list. But for the practical situation I feel one size fits all does not work. The proper choice of methodology can be made based on the nature of project, resources available, capabilities of the organization, customer, other environmental factors and circumstances, etc.

In the end I would say, scrum worked for me because none of my projects related to lives of people. Had I been working on medical equipment hardware or software or a banking project, scrum would have probably been the last choice, system development life cycle (SDLC) the first.

P.S: Many websites refer to PMBOK as a methodology. I do not intend to contest anybody. In my blog I write what I know and believe. In legal language one would say, "To the best of my knowledge and belief."

About e-Centric Internet Marketing and Business Blog

There is only one thing that is common in all the business owners and leaders (almost all). That is their desire to succeed. However, desire alone has not made anybody taste success.

Over past few decades, the business landscape has changed so much that if our business leaders of the past were reborn, they would prefer to die again.

In our present age apparently it has become too easy to start a business, and more so a web portal. Most people are under an impression that all they need to do is to hire a part time programmer who would download some php scripts from here and there and shape them up into a website running on a free database, hosted with a service provider for 50$ a year. A start up cost of a few thousand and recurring cost of 50$ a year. On hearing this, anybody who has not tasted the failure already, would jump and say, "It is hardly any money. I spend more than that at Mc. Donald's. Why not give it a try." Thanks to them, they are the people who were responsible for the dotcom boom.

There are hundreds of thousands of people who jump into this, destined failure. Let us call them business owners.

The first surprise these business owners get is when the freelancer they had hired, does not even show up for every two out of three meeting. For next few months they discuss and just discuss when they meet and the business owner keeps looking for the vendor (the freelancer) rest of the time.

After a few months, the business owner decides to hire another freelancer, say another vendor. Obviously the sunk cost does not have to be considered but the business owner also forgets his initial intentions i.e. "It is hardly any money. I spend more than that at Mc. Donald's. Why not give it a try." The new vendor quotes three times the amount that the old vendor had. The business owner still agrees to carry on because by now he has lost the vision already. What he is seeing now are dreams, the dreams that are destined to prove nightmares.

Finally after few more meetings the new vendor starts working on the website. All looks well in first few days. Over their meetings, they laugh together and curse the old vendor together and the business owner leaves no opportunity to let the new vendor know how lucky he was to find him and get rid of the old vendor.

Months pass, several deadlines are missed and relation is no more the same. Now the meetings are for a different reason. The vendor wants more money. The business owner initially does not agree to pay, but his stubbornness is overcome by the thoughts, "After coming so far, I don't want to loose all the time and money that I have invested for a few more thousand."

After paying double the amount than what this vendor had initially quoted and six times the amount that the business owner had initially based his vision on, and after waiting for a year instead of couple of months that he had initially planned, the website is up and running. It is alive and kicking, but with hundreds of bugs. If the customer is lucky, the mischievous guys out there will never try their hands on this site to exploit the vulnerabilities of these downloadable free scripts that are powering this site.

Finally the work is over. The customer is excited. Poor guy does not even apprehend what is to come next. He waits and waits for people to come to his site, but hardly anybody shows up. He tries to create a few fake accounts, some fake postings but nothing works. He starts with requesting and ends up begging his friends to visit his site, but alas everybody is sympathetic to the extent that they offer to help him in various ways, except that nobody visits his site. It is just too boring.

At this stage he consults the son-in-law of his brother's friend who has just passed out from the management school. "What made him an expert?" I can't comment on that.

This new expert comes with another shock, rather shocking term, "Marketing Dollars." It is a great shock because all along the business owner had been thinking that it was just the matter of going live. One user will get 10, 10 will get 100, 100 will get 1000 and so on. He has had been pretty sure that out of a billion internet users out there, even if one tenth of one percent come to his site, we will still have a million users. "After all what is 0.1 %. Why can't he get even 0.1% to his great website that just takes 10 seconds to load a page? A site not ranked in the bottom one percent by Alexa, because it is not even ranked."

Old habits and beliefs are hard to change. The business owner still thinks, "After coming so far, I don't want to loose all the time and money that I have invested for a few more thousand." He is willing to invest more. This time his most trusted person in the world is the newly found expert (somebody's son-in-law). On his advice the business owner agrees to pay for PPC (Pay Per Click) to Google. Not withstanding fact that PPC is a very strong tool to drive high volume and relevant traffic, this unlucky guy gets just blank cartridges instead of live ammunition. The site is bombarded with hits but nobody seems to be interested to venture beyond the landing page. The money, or "Marketing Dollars", just burn and burn and burn. They don't even help keep him warm as they burn in the cyber space.

"Till bankruptcy do we stop?" As long as he can, the business owner keeps pushing his cash eating monster and finally puts a lid on it. In most of the cases, the business owners do not close their misadventure, but simply want to push it under the carpet till they have more money to waste. Finally such projects die and decay under that carpet.

There are very few people who admit the failure earlier in the "website portal failure lifecycle" described above in time and turn to more professional people for help.

The whole idea behind e-Centric Consultancy Services is to become an organization that such business owners can depend on to reinvent, reposition and sell their business to make it highly profitable.

This blog is a part of that effort.