Converting to PMBOK-ism
You’d think that I would have better things to write about. I have allocated three hours today re-reading the first two chapters of the PMBOK. Notice how I used the word “allocate” — I am a recent convert to PMBOK-ism.
There are over 100 global practitioner/volunteers on the core team that have contributed content for the PMBOK. Management practitioners, you know, they do a lot; for instance they deal with stand-alone projects and with projects managed as a group (i.e.,programs), AND with their lifecycles, activities, objectives, focus and benefits. They measure a program’s success by investment performance and benefit realisation. They elaborate requirements. This level of detail typically encompasses talking and writing “PMBOK-ish”.
You know you speak PMBOK-ish when you use the verb “elaborate” instead of “obtain” because the former sounds a tiny bit more formal.
For many IT workers, communicating and writing at work is nearly as worrisome as public speaking. If you give a computer science graduate the PMBOK, they will start talking PMBOK-ish to people. Now, try and put this person in a room with a team. Will the team understand the convert?
That’s why I thought, everyone in the room should have at least a basic knowledge of PMBOK-ish.
Even when you speak the simplest of “PMBOK-ish” like “scope”, “goals”, “unique product”, “strategic objectives”, “benefits” and “project quality”, you have to make sure that your team knows what you are talking about.
Because it’s people and not processes that meet the project objectives. I think that’s what the Agile Manifesto tried to say with “Putting people over process”.
I mean, if something like that aligns with your strategic vision and organisational objectives and OPM, of course… :P
