While I was studying for my PMP certification I learned many things that over my course of 10 years I was doing differently. Now after being a PMP for a year, I see how you can get value from the knowledge on the PMI framework.
What I still don't see is the gap between real world projects and all the projects in the PMBOK.
The main purpose behind my question is to understand if other PMs see this paradigm in their work. I see a big distance between the theory and the practice.
The main benefit I saw after becoming a PMP and studying their framework was a consistent, exhaustive framework that targets all parts of the project and project life-cycle. Everything from creating and managing schedules to managing unruly team-members.
PMI has their own goals (like pushing Project Management as a real position, and as a professional vocation). While they have provided a framework, the most benefit I find is from applying their concepts wherever you see benefit.
For example, I regularly tie risk identification and analysis into agile/Scrum development processes (even though it's not addressed in that methodology). Similarly, the PMP framework is like a giant toolkit to me: you pick and choose whatever helps, apply it, and be happy that your projects are just that much better than they used to be.
PMBoK is a toolbox. It's full of useful tools. Think of the project manager as a carpenter. He gets certified to use every tool in the toolbox. It doesn't mean they're going to use each one when building a piece of furniture.
The biggest gap is the art of applying the right tools and techniques to each situation to get the best results.
There is a ton of knowledge there. The trick is in using it properly -and not getting sucked into the dark side : )
Bear in mind that PMI PMBOK is not an execution method. I.e., it will not tell you what to do on Monday morning at 9:07 am to move your project forward.
In case you're wondering, my favorite project execution method is Goldratt's critical chain project management. Complementary to CCPM are: kanban supplemented by GTD.
According to that, all 42 process are subjected to apply only in the very complex project and it is necessay for a project manager to identify the process which are required for that particular project [We usually do it in Develop Project Managemenet Plan Process].
There may be some process which you might be following from the last 10 years, may be not yet documented well. PMBOk defines no process different from the real world. Remember, PMBOK is not written by an indiividual, it is actually written by the real time project manager. Even you and I can contribute in that. So, everything that is written in that reflects the real world example and procedures.
There is a huge difference since there are real people in real projects. You will be facing issues with motivation, morale, stubbornness and a lot more.
However, the processes can guide you through a project. You probably have to figure out the rest yourself.
There is a large gap. You are correct that you see a large gap; all of us see a large gap. The critical feature is that we don't all see the same large gap.
That is the reason that every project plan must be tailored. Quite frankly, that is the reason to write a project plan; the process of negotiating and writing the plan is the process of examining all the possible elements of the plan and identifying which are the most important to the successful closure of this project. (And although it is implied in that sentence, it bears explicit mention that the plan also documents the elements that are unimportant.)
The PMBOK contains the groundwork for all possible plans. Your project(s) will have reified plans that contain only the processes tools and technology useful for your project
But let me finish where I started; your observation is correct.
