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.