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!

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.

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.

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."