At Craftsman Technology Group we are organizing and publishing as much of our body of knowledge to our blog as time allows. To provide an organization structure we thought it wise to introduce the structure provided by the Project Management Body of Knowledge (PMBOK), the global standard set forth by the Project Management Institute.

This post will break down the standard provided by the Project Management Institute. It will look at the 10 Knowledge Areas and 5 Process Groups – and begin to place their application into a nonprofit project context. This post will direct you to more detailed posts.

Plotting Knowledge Areas & Process Groups

The Project Management Institute has created a grid of knowledge areas and process groups that map the entire discipline of Project Management. Knowledge areas describe overarching topics in project management such as managing time, cost, schedule or risk. Within each topic there are sets of processes representing the logical stages within a project.

For example, Project Communications Management is a Knowledge Area focused on how communication will be organized and executed through the project. Process groups identify the activities within each knowledge area and how they are applied within the project. (see below)

Knowledge Areas

Each Knowledge Area generally does what the name implies:

• Project Integration Management: Integration Management is concerned with creating a framework for managing the project. This area includes matters of governance (e.g. how project authority is applied), methodology and how the other process groups will align into a coherent project management plan.
• Project Scope Management: Scope refers to the contents – or requirements of the project. This knowledge area gathers requirements and defines them through an actionable scope of work (SOW). Typically, a project is comprised of multiple SOWs – one for each vendor and a larger SOW encompassing the entire project. A common occurrence in the nonprofit sector is an organization treating a vendor’s SOW as the project SOW. Focusing solely on the external SOW runs the substantial risk of not considering the impact on internal resources (ex. internal project team time)– and therefore can become a major source of tension and result in long nights and weekends.
• Project Time Management: Time Management is concerned with establishing and controlling the project schedule. This is done by identifying, sequencing, estimating and resourcing activities. The schedule is the primary representation of time on a project, though it is important to consider the energy that went into building the schedule and considering the effort required to maintain the schedule over the course of the project.
• Project Cost Management: Cost Management estimates costs and leads to the development and oversight of the budget. Costs should be inclusive of all direct (ex. software licensing, hosting, data storage, services) and indirect (ex. staff time, training or ramp-up time) costs.
• Project Quality Management: Quality Management defines and assures project outcomes meet expectations. Defining quality metrics early in the project planning effort is critical to ensuring that the project will effectively meet the intended outcomes. Often we look at project success as arriving on-time, on-budget and adhering to the statement of work. Though, without a clear definition of quality, it is possible to do all of those things and still have a project fall short of objectives. Imagine a project where a fundraising system was deployed on time, on-budget and as described in the scope – but only half of the intended data arrived in the new system. Such a project outcome is unlikely to be seen as successful from a quality standpoint.
•  Project Human Resource (HR) Management: HR Management is concerned with how the individuals will be managed on the project and includes establishment and oversight of the project team. HR Management is also concerned with management of external parties such as contractors, implementation partners or other resources.
•  Project Communications Management: Communications Management refers to all communications internal and external to the organization. This knowledge area overlaps significantly with Project Stakeholder Management, as that knowledge area will identify and organize the recipients of your communications.
•  Project Risk Management: A risk is any event that, should it occur, would positively or negatively impact a project. Risk Management is the process for attempting to identify, plan for and monitor risks throughout the project.
•  Project Procurement Management: This knowledge area is concerned with acquiring the resources needed to conduct the project. It may involve selecting tools, vendors, equipment or anything else required to successfully complete the project.
• Project Stakeholder Management: A stakeholder is any individual that will be impacted by the project outcomes. Stakeholder Management represents those activities to identify stakeholders and manage their expectations throughout the project. Stakeholder Management is likely to also overlap with integration management (ex. governance – as a way of organizing the project and making decisions), risk management (ex. as a response strategy to mitigating risks of limited adoption) and elsewhere.

Process Groups

As we mentioned earlier, process groups are the horizontal axis that plots project activities. Process groups have a chronological feel to them, though it is important to note that they are not the project life cycle itself. All process groups could run multiple times within a single phase or segment of activity within a project. The process groups are:

• • Initiating Process Group: These activities define a new project or phase of a project. These activities support gaining formal approval to move forward with the project and provide early definition to the work involved.
  • Planning Process Group: These activities define how the project will be managed. The key output of these processes is a Project Management Plan and the many sub-plans found within.
  • Executing Process Group: This process group includes what is typically seen as the actual work of the project. Activities may include design, configuration, testing, migration of data.
  • Monitoring and Controlling Process Group: This process group is concerned with oversight of the project from beginning to end.
  • Closing Process Group: This process group formally ends the project or that segment of the project. This might include a project debrief and ensuring all vendor agreements have been honored (and invoices paid).

Conclusion

It would be hard to fault someone for thinking that the PMBOK takes an already complicated activity – project management – and adds many more layers of complexity. But, rather than get buried in trying to grasp the standard, I would suggest looking at it as more of an inventory system. The standard is really just a means to organize the many different perspectives and intersections that occur within a project.