USING PMBOK’s

KNOWLEDGE AREAS

LEARN HOW TO USE THE KNOWLEDGE AREAS TO YOUR

ADVANTAGE

WHAT DOES THE PMBOK MEAN

WITH A KNOWLEDGE AREA?

The Project Management Body of Knowledge (PMBOK) introduces the concept knowledge area early in the guide, more specifically in the sixth edition, in chapter one on page 23, to be precise. The reader will understand that the knowledge areas are a second way, next to the so-called process groups, to structure the way the Project Management Institute looks at project management processes. The institute defines a knowledge area as:

"an identified area of project management, de-

fined by its knowledge requirements and de-

scribed in terms of its component processes,

practices, inputs, outputs, tools and

techniques.”

PMI actually uses the knowledge areas to define different sub-items of the project management field of study. In a way of speaking, it are the different chapters of a book "Project Management". And these chapters make it easy to explain the subject matter in a structured way. And that's what PMI actually does! Each knowledge area forms a chapter in their PMBOK guide. For practical use, I like to define a knowledge area myself as a container of information that is relevant to my project, or better to my project management activities. Therefore, I can use the knowledge areas to organize my project's documentation and my project control file.

WHICH KNOWLEDGE AREAS ARE

DEFINED AND HOW TO USE THEM

IN PRACTICE?

In the PMBOK, one can find ten knowledge areas: The first one is: Project Scope Management. It covers all the knowledge on how the scope of a project should be managed. For me, in order to structure the project control file, it is the container or folder where I would store all project documentation related to the scope of the project. Think about documentation like scope statements, requirement documents, scope change registers and scope change requests. Project Schedule Management, a second knowledge area in the Project Management Body of Knowledge (PMBOK) guide, covers the knowledge (processes, tools & techniques) on how a project schedule should be created and monitored. If you use the knowledge area as a container/folder of project management information, then it's clear that I use the project schedule management container to store all planning and scheduling related documents, like the schedule itself, including the different tracking versions, but also action registers and other kinds of lists that express activities that need to be performed on the project. Third knowledge area to be mentioned is Project Cost Management. It is clearly the field of project management which discusses all about the project budget and its related project management activities. For me, it is where I would store all budget related information and reporting. It is actually the location where a lot of excel files can be found: budget baselines, actuals versus budget analysis, financial plans, etc... Project Quality Management: For PMI, it is the area where the “quality field of study” is explained. Again, seen from the perspective of structuring the project (management) related documentation, it is the location where test plans, test scenarios and scripts, but also the actual test results can be found. Another important knowledge area that is mentioned in PMI’s PMBOK is Project Resources Management. The knowledge area that handles how the project manager should manage the resources that have been allocated to the project. It is important to understand that not only human resources are discussed, but that also other resources, like materials and equipment are considered. In this project control file location or documentation storage, I would put next to staffing plans, also staffing requests, bill of materials, construction surveys, as well as attestations of conformity and usage approvals. It is into my opinion always a good idea to further decompose the main “Project Resources Management”-location/folder into sub-folders like: staff resources, material resources, and equipment resources. A very, very important knowledge area is Project Communications Management. This is the knowledge area which explains all about how you, as a project manager, should organize your project communications. For me, it is where I store all project related communications. This documentation location is on all of my projects the largest container as I do communicate a lot. Therefore, it contains a lot of sub- folders. Each recurrent communication has its own location, further subdivided with the dates when the specific communication happened. Typical folders under the Project Communications Management-location are Project sponsor communications, Steering committee communications, Status information to portfolio management, and so on. Next to the recurrent stakeholder communication, you also might want to consider a topic structure for specific communications or event communications, based on your communication plan. Typical documents that can be found here are management presentations, status reports and so on. The Project Risk Management knowledge area is where the PMBOK sorts all information that explains to the project manager how he or she can manage the uncertainties of a project. I would call it risk and issue management since a negatively impacted uncertainty or risk, which materializes, actually becomes an issue. With that said, a further decomposition of that document location into a risks and issues sub-location is needed. Typical documents are a risk register, an issue log, problem analysis documentation, and so on. The issues location is often further decomposed into the specific issues (one folder per issue). Project Procurement Management is a knowledge area that could use some further development by PMI. But as it is clearly encompassed in the name, the knowledge area contains all knowledge on how to perform procurements on a project. In practice, on my projects, it becomes the documentation location for all procurement related documents. I highly recommend a sub-decomposition into "before" contract related information and "after" contract related information. RFP's, RFQ's are typically belonging to the first folder, whilst contracts, negotiation documents, and related communications rather belong to the second folder. Project Stakeholder Management: The Project Management Institute (PMI) combines all knowledge that you need to know on how to manage project stakeholders in this knowledge area. Interpreted for practical application, I use this knowledge area as follows: Whilst I create a “general” folder for items like stakeholder lists, stakeholder approaches documentation, and perhaps even stakeholder analysis documents, there is also one specific folder per (important) stakeholder with whom there is an interaction during the project. I have to admit that the subdivision per stakeholder proves more useful in my mailbox organization than into the project control file organization. PMI also states that knowledge areas are interrelated. Therefore, they included a tenth knowledge area, being Project Integration Management. Integration Management is weird to explain but nevertheless a very important knowledge area. In first instance, all knowledge areas are interrelated. Think for example of scope changes: "Define scope changes" requires knowledge from the scope management area but also, because of the impact on time and cost, knowledge from the schedule and the cost management knowledge areas. But you also need to communicate about the scope change and there might be risks involved, etc. But... and perhaps even more important, there is the integration of the project with the performing organization. For example; you need to obtain resources from that organization to be able to perform the project. The project needs to be approved and mandated by that organization and at one moment in time you need to deliver the project product or result to that organization. Therefore, all documentation like the project mandate, the financial business case, the go-live documentation, approval documents, decision registers, find their place under this storage location on my projects.

WHAT TOOLS ARE NEEDED?

Organizing your documentation storage, in project terms often called the Project Control File, can be arranged with simple tools like a local Microsoft Explorer folder structure to a more sophisticated in the cloud organized documentation software. What is important is the search-ability of your documentation and the first step is obviously to create a decent structure, like for example the structure explained above. Currently I like to make use of the Microsoft suite of applications, not necessarily because it is the best, but especially because it is widely used. In Microsoft Teams, I use the “Channels” as the storage container for the knowledge areas. It also has the advantage of security management to which documentation which stakeholders have access to. In Microsoft Sharepoint, I like to work with the “Columns” to defined the knowledge area structuring.

SEVEN ADDITIONAL PRACTICAL

TIPS

To conclude some additional tips: Tip One: Make sure to always consider a distinction between project management and subject matter related documentation. Structuring the subject matter documentation can be done, for example, by making use of the project management life cycle: in which phases are which documents created? Or you can organize the subject matter related documentation per subject matter specific topic. Having a decent Work Breakdown Structure (WBS) can be very helpful as you can align your documentation structure with the Chart of Accounts (one lowest level chart of accounts items is one folder). Tip Two: You can choose not to make the highest level subdivision between management and subject matter documentation, but to incorporate the subject matter documentation under the project management knowledge areas. Most relevant areas are scope and quality. Tip Three: Always explain your documentation structure to team members and stakeholders that make use of your documentation folders and systems. Tip Four: Use this knowledge area structuring also to organize your project folder in your mailbox. Actually my mailbox project folder is a one-on-one copy of my project control file structure. Your physical documentation, if still existing, can be organized likewise. For example: one binder or one closet section per knowledge area. Tip Five: The traditional local file storage on your C-drive is now already for long outdated. You better don’t use it anymore as accessibility and search-ability of your documentation by the project team and the broader stakeholder group is nowadays a key feature. Tip Six: The fifth tip also brings that you need to keep in mind security and accessibility when setting up your project control file. Especially when you work with external parties; some information like budget, procurement decisions and other things, are not to be shared with all (these) project stakeholders. Tip Seven: Use the knowledge areas as well to structure your project management plan. Each chapter of my overall project management plan is organized per knowledge area. The Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowned brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services. How to reference this article: Goeman, S. (2021, 21 February). Using PMBOK’s knowledge areas. GAPS BV. https://www.gaps.be/Mentor/pmart003- pmbok_knowledgeareas.htm