PMBOK Processes Support in Allegra Tutorial – Part 1

This is the first installment from a series of three articles that focus on PMBOK processes in the modern project management practice, and illustrate the support available for these processes in the Allegra task management software. The focus of this article is to provide a background on PMBOK^® processes and to highlight some project management challenges in implementing these processes in practice. The second part’s focus is of practical nature, providing a step-by-step approach to setting up a PMBOK^® process for change management tracking purpose in Allegra. Finally, the third part illustrates a real-life scenario dealing with PMBOK® input artifacts changes and their change management process in Allegra.

PMBOK processes are still relevant for the current project management practice

PMI’s PMBOK^®, together with its certification program is not dead! A Guide to the Project Management Body of Knowledge [1] also known as the PMBOK^® Guide has reached the fifth edition in 2013 and nowadays is preparing the 6^th. This popular guide and standard, as it is so much emphasized on the Project Management Institute website, not only presents the key concepts for the project management practice but, as expected, provides comprehensive processes that need to be followed in order to do proficient and successful project management.

Although PMI insists that PMBOK^® is just a framework, in my opinion PMBOK^® is a methodology in disguise. Normally, what you really want to standardize is methodologies and processes, rather than generic frameworks. However “framework” is the new, not committing, “cool word”, and so framework it is. PMBOK^® is a framework for building your own project management processes.

According to the 5^th edition of the PMBOK^® Guide, the project management processes are grouped in 5 process groups and 10 knowledge areas counting a total number of 47 processes.

For those 714,000 and counting PMP^® Project Management Professionals out there the mission is to implement as many processes make sense for each project, and this is the reason why PMBOK^® processes are still hot.

PMBOK^® processes implementation challenges – a project manager’s perspective

Each of those 47 processes described in greater detail inside PMBOK^® is represented in an Inputs – Tools & Techniques – Outputs diagram like the one below emphasizing that each process consumes input artifacts and produces output artifacts.

PMBOK^® recognizes over 70 input and output artifacts from which 50 are day to day documents which may receive therefore many updates throughout the project lifetime. A comprehensive list of these PMPOK^® artifacts can be found on http://www.standardmethods.org/. It should be obvious that many output artifacts generated in some processes are also used as input artifacts for some other processes.

The reality of the project management practice shows that almost all projects suffer changes during their lifetime, and these changes must be tracked and reflected in the projects’ artifacts. If we consider all these 47 PMBOK^® processes and changes that may occur in many of those 70 artifacts mentioned before we can quickly see how keeping in sync all the artifacts can become a very challenging task for a project manager (PM). One task of many others!

In addition, the current project management practice shows that gone are the days when the only “interested” person in the project’s artifacts was the PM. The new trends, boosted by the Agile revolution, changed the domain mentalities and the working paradigms, and today we witness a keen interest in these artifacts coming not only from the various members of the development team but also from all the project’s stakeholders. Project artifacts are nowadays shared and many of them can be accessed and changed by people participating in the project. This makes the PM’s task even more challenging and therefore, performing the due diligence on the project’s artifacts should be included in the daily routine.

It is here, where a good project management software, like Allegra, may come in hand, helping a PM to asses which processes need to be performed again, triggered by changes of PMBOK^® artifacts.

A possible PMBOK® Use Case scenario: Developing the Project Charter Process

The Project Charter Development process is arguably one of the first and most important process that needs to be performed for any project, regardless perhaps of the applied project management methodology.

This process has been randomly chosen to illustrate the PMBOK artifacts change management, but the approach is identical for all other PMBOK  processes.

According to [1], the Project Charter Development process consumes input documents like the Project statement of work, the Business case, and so on, to create the Project charter output document by using expert judgment as illustrated in the following input – output diagram.

This process is part of the Initiating group and also of the Integration knowledge area [1].

The purpose of this process is to create a document, called the project charter that states the purpose and the scope of the project. The project charter is either created by the project sponsor (or the initiator of the project), or can be delegated to the project manager. Nevertheless, according to [1], only the initiator’s signature on the charter authorizes the project.

It is worthwhile mentioning that this process is also useful in an Agile project management paradigm and has been included, as a process, in the SBOK Guide [2] which tries to stand as a PMBOK equivalent for the Scrum world.

Create sample project artifacts for the “Developing the Project Charter Process”

To illustrate the change management issue related to this process let us consider two main artifacts that are involved in this process, the Statement of Work (SOW) and the Project Charter documents.

A SOW document identifies the business need for the project, the product scope and must be aligned with the organization’s strategic plan. A formal explanation is provided in the side-bar.

A Statement of Work document defines project-specific activities, deliverables and timelines for a vendor providing services to the client. The SOW typically also includes detailed requirements and pricing, with standard regulatory and governance terms and conditions.  [Wikipedia]

The following illustrates a fragment from the SOW document created for a fictitious project called “Money Tree – GenLife Integration” project, which contains a Schedule/Milestones paragraph.

The Project Charter document “formally authorizes a project or a phase and documents the initial requirements that satisfy the stakeholders’ needs and expectations” [1]. More specifically, one of the objective of the Project Charter is to document the objectives and constrains of the project, constrains that must also refer to the main milestones defined for of the project.

Cope with artifacts changes

Assume now, that after a while, for various reasons, one of the project initiators changes some milestone dates in the SOW document of the project. It should be obvious that changes of dates in the SOW document, in the Schedule/Milestones section should be correlated to the corresponding dates on the Project Charter. It is your job, as PM to re-execute the Develop Process Charter process and eventually update the Project Charter accordingly, obtain the formal agreement on the new dates, etc.

Considering only this PMBOK process in isolation, the task of keeping in sync these two documents looks fairly simple. However, if we consider all the 47 PMBOK processes, and the multitude of artifacts that can be changed, processes which can potentially trigger cascaded changes, all happening in real-time, over Internet, involving a multitude of project team members (stakeholders included), the task of keeping the artifacts up to date does not look so simple any more.

A good project management tool should make this task easy and intuitive and once set Allegra does it for you! Follow part 2 of the series to see how.

Note: The sample documents have been created starting from the templates provided on the Project Management Docs website.

Conclusion

There should be two main takeaways from this article:

1. If you are a PM willing to conduct the project management activity based upon the PMI PMBOK^® framework, you will soon discover that keeping in sync the projects’ artifacts is not an easy task. And this finding remains true even when you are following PRINCE2, or conducting the service management processes following ITIL, or even mixing the processes if you really need to.
2. You need to consider using a project management tool to help you performing this task. Simply and intuitively, like Allegra.

Resources

[1] Project Management Institute, PMBOK Guide – Sixth Edition (2017).

[2] SCRUMStudy, A Guide to the Scrum Body of Knowledge (SBOK™ Guide), 2016 Edition.