Welcome to Project Management Questions!

You can ask any question on Project Management and you can rest assured that real Project Managers will answer your shortly!

Whether there are too many processes in the PMBOK?

PMBOK is generic and prescriptive, and the description of PMBOK has outlined 42 processes span throughout the 9 knowledge areas. But I am just thinking when we develop a method i think it would lead in producing much more processes because the nature of method itself is prescriptive and the process is specific according to the project type. Therefore, there will be more processes in the method. I can say that the processes outlined in the PMBOK are basic, but when we tailor them to specific project type there would be additional processes? Am i correct and logical?
asked 6 years ago by hairul (1,320 points) edited 6 years ago by MaplePM
related to an answer for: What are the disadvantages of PMBOK?

1 Answer

There are only 5 overarching processes in the PMBOK Guide.  I've found that in common practice, 7 or more are usually defined in methodologies for software development projects (design is often inclued as a separate process, as is testing). You may create more or fewer processes in your methodology, and more is not uncommon for large projects.  Smaller projects may want to define fewer.

The PMBOK Guide was meant to document best practices, but not prescribe, so there is a lot of flexibility. I think of it as a project framework, rather than a methodology. Its why it can be successfully used for projects of all sizes and in many industries.
answered 6 years ago by sdcapmp (45,840 points)
What is the best practices that PMBOK referring to? Is it refer to the suggested tools and techniques in each of the process?
6 years ago by hairul (1,320 points)
I tend to look at the PMBOK Guide a little more broadly.  Yes, the suggested tools and techniques represent best practices.  However I believe the authors would have us also consider the processes themselves.  A lot of thought has gone into how the processes are sequenced and interact. My approach to methodology creation, for example, has been to first draw on the requirements and my own experience, then go back to review the PMBOK Guide to see if there is something helpful to consider.  WIthin existing frameworks, I've been able to identify meaningful consulting engagements.  For example, a Risk Analysis Workshop to review risk of major software projects and define response and mitigation strategies, the result of which protected the investment in the software. The guides produced for the workshops benefited from having PMBOK Guide suggested approaches and were used by other consultants to review projects.  This workshop was added as an optional step to planning and later during project execution (although it might be possible to use anywhere in the project life cycle).
6 years ago by sdcapmp (45,840 points)

Related questions

© 2010 - 2012 Project Management Questions - All Rights Reserved