Structure Considerations for a Project Management Related Body of Knowledge (PMrBoK)
In Part 1 of this paper I discussed the nature of projects, their unique features and what they are not, and their life span (life cycle). In this Part 2, I have looked at the PM's job, the PM as customer for a PMrBoK and his/her patterns of work, activities and environment. Now let us look at how we might structure a PMrBoK so as to make it significantly useful and readily understood by our PM practitioner.
Much has been achieved in establishing PMI's "Guide to the Project Management Body of Knowledge". In my opinion, the document is both excellent and needed. However, what I do find missing is an element of logic that serves to:
- Guide a user in how to use it
- Guide the user on incorporating revisions or additions to suit his/her own project (i.e. to create a domain-related XXrBoK, as I discussed in Part 1), and
- Guide and evaluate the need and course of future revisions or updates to PMI's guide, or in fact any other XXrBoK.
I believe strongly that this element of logic, or structure, would be most valuable and is badly needed. It would guide evaluation and permit easy codification as new additions or expansions are proposed. Historically, whatever rationale existed for a structure at the time of the original effort, it was never really formally or forcefully presented and so is now lost in antiquity. In any event, it might no longer be appropriate. This is precisely because when PMI initiated the original "Ethics, Standards and Accreditation" (ESA) efforts it released such a flood of thinking and writing on PM subjects that any structure of that period would now be overwhelmed. Nevertheless, judging by the current product, imperfect as it may be, but based on those original ESA efforts, considerably better and clearer ideas of the concept(s) of project management have emerged and developed.
Since the early days there has always been a recognition that some additions to the PM knowledge base could be very useful, even if special, unique or otherwise beyond the Guide's content of "applicable to most projects most of the time".[1] There was agreement that such additional requirements could arise in connection with such aspects as:
- The nature of the industry, sector or segment undertaking the project, or
- The type of product from the project, or
- The particular activities, tasks, steps or efforts required to effectively plan, direct and successfully complete a given project.
So, what has not been provided so far are any rules, guidelines or clarifications for deciding what aspects need to be considered to produce a custom version for a particular project environment. Nor how extensively they need to be considered. Similarly, what rules or guidelines should you consider to customize the document for the new project you are just about to start.
In Part 3 of this paper I will present a proposal for resolving some of the questions surrounding PMrBoKs that I have raised in Parts 1 and 2.
1. A Guide to the Project Management Body of Knowledge, Project Management Institute, 2000 Edition, p3
|
Corrective Action
