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.
Comprehensive, powerful, simple & user friendly Web Based ERP system configurable to suit all business processes of any organization of any size. TUHUND is truly an enterprise solution admired by many young entrepreneurs and successful leaders across the world.
Showing posts with label PMBOK. Show all posts
Showing posts with label PMBOK. Show all posts
Monday, April 27, 2009
Saturday, April 18, 2009
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."
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."
Subscribe to:
Posts (Atom)