Project management knowledge

As we understood earlier, today, there are multiple global standards for project management. Each of these methodologies provides a holistic set of guidelines, practices, tools, and techniques in self-contained packages.

These methodologies have evolved to cater to different sectors, business domains, geographies, and engineering practices. Organizations that specialize in executing projects, and for whom project success is business critical, will adopt one or more of these methodologies.

Choose your fount of knowledge

Some of the most popular methodologies are the following:

• Project Management Institute (PMI)'s – A guide to the Project Management Body of Knowledge (shortened to PMBOK and pronounced pimbok) is a globally recognized standard and is widely used across industry domains. This book will draw upon the PMBOK Sixth Edition.
• The International Organization for Standardization (ISO) has several standards published, notably ISO 9000 for Quality Management Systems in Projects and ISO 21500:2012 – Guidance on Project Management
• PRINCE2 (Projects in Controlled Environments) is popular in the UK, some European countries, and Australia. This originated in the UK for government usage, and today is also a globally recognized methodology.
• New kids on the block: Relatively recently introduced and originating from the software and information technology worlds, there are several other methodologies that are adaptive, iterative, and incremental in nature.
• Agile and Lean are a couple of the most popular ones in global usage. These methodologies are slowly making inroads into broader acceptance in other fields.
• Hybrid and customized methodologies are also being elaborated and practiced, especially in emerging markets and technologies. These take the best of the predictive and agile methodologies and tailor them according to specific project requirements.

So, what is the bottom line?

• Companies will usually adopt and adapt one or more methodologies, based upon their business domain, customer demands, go-to-market constraints, regulatory guidelines, and other requirements.
• Even with the established traditional methodologies, there is now wide recognition of adaptive frameworks. In fact, PMBOK Sixth Edition is packaged with the Agile Practice Guide included.
• Microsoft Project, starting circa 2017, has started providing some capabilities to support Agile, Kanban, and Hybrid, though widespread adoption by users remains to be seen.

The project life cycle

Since projects have a start date and an end date, the intermediate period (between those two end points) can be described as the life of a project. But in reality, the project manager's role and involvement will usually exceed even the closure of the project, for example, usually in the financial and support aspects.

The duration of all projects, irrespective of size, can be described as a series of phases that together make up the project management life cycle. This describes the stages of development the project passes through to reach completion.

Here is a graphical representation of the project life cycle:

Figure 1.1 – Project life cycle

The phases can be stated as follows:

1. Starting the project
2. Planning, organizing, and preparing the project
3. Executing the project on schedule
4. Completing the project

While the sequencing direction is implied in the diagram, some of the phases can be iterative depending on the nature of the project.

Project management processes

The project manager will execute a large set of activities during the life cycle of a project. These simple activities can be logically grouped together as the Project Management Process.

The following diagram depicts a generic Project Management Process:

Figure 1.2 – Representation of a generic project management process

As we can see, a process consists of a set of prescribed tools and techniques applied on some inputs and producing expected results as outputs.

For example, Develop Project Charter is one of the very first standard processes, performed by the PM once in the project life cycle. Similarly, Acquire Resources is another process, albeit performed on a need basis – as and when required. Another example, Monitor Communications, expectedly happens throughout the project life cycle – and many times.

Tip

How many project management processes are there? The current PMBOK Sixth Edition lists 49 processes. The number will vary depending on what methodology and version you reference. The semantics may vary but the philosophy will remain the same.

Every single project management process can be conveniently categorized under two different classifications: as Process Groups and as Knowledge Areas.

Project management process groups

You, my astute reader, might now have extrapolated that individual project processes themselves can be logically grouped – and this is correct.

Before we proceed with understanding process groups, here is a note of caution. A common pitfall is to confuse process groups with project phases (or the project life cycle). You will soon see why such confusion can be prevalent.

Here are the process groups:

• Initiating Process Group: Whether it is the start of a new project or a new phase within a running project, initiating processes are performed. These help in defining the project or phase.
• Planning Process Group: All planning processes are grouped here – including the scoping of the project (or a phase). Create WBS is an important process in this group and we will learn more about it later in this chapter. Every time there is a change in the project requirements, this group will get activated at any point in the project life cycle.
• Executing Process Group: Processes in this group deal with the execution of the project. Providing direction for the project, managing quality, building out a project team, and acquiring resources for them – all these are processes within this group.
• Monitoring and Controlling Process Group: The processes in this group help the project manager ensure that everything runs according to plan – and within project tolerances. The control of the cost and schedule are some of the important processes within this group.
• Closing Process Group: When it is time to officially close a project (or a phase, or even customer agreements), use the processes within this group.

It is easy to see why new learners confuse process groups with project phases, as there is some semantic overlap in the naming convention.

But, as a reader of this book, you should be aware that processes belonging to a group might be executed anywhere in the project life cycle. In particular, the Monitoring and Controlling Process Group is something the project manager will perform through most of the project life cycle.

Project management knowledge areas

There are 10 distinct specialization areas utilized by the project manager when managing projects. These are called Knowledge Areas. Each of these Knowledge Areas is also a collection of the same project processes that we have discussed so far.

Now, we will learn about the second way in which project management processes can be classified into Project Management Knowledge Areas:

• Project Integration Management: This knowledge area will be under the direct control of the project manager and deals with the co-ordination of all other processes utilized in a project. Other knowledge areas, which follow, can potentially be delegated to subject matter experts, such as a technical lead, quality lead, business analyst, or software architect. Another special point to note is that the integration management knowledge area has processes that are performed across the entire project life cycle.
• Project Scope Management: Ensuring that the project includes all the work required (and nothing else) to achieve the project objectives.
• Project Schedule Management: Concerned with the temporal aspects of the project such as sequencing activities and achieving time-related constraints.
• Project Cost Management: Deals with processes to ensure that the project does not exceed budgets. This includes estimating, budgeting, and control of costs.
• Project Quality Management: Using appropriate processes to achieve stakeholders' expectations of project quality.
• Project Resource Management: Resources include people, machinery, and materials (consumable or otherwise). Often, third-party vendors may be involved, or your own project may be part of a much larger project. In all cases, making sure resources are utilized optimally and on time is covered in this knowledge area.
• Project Communications Management: Project information should be periodically disseminated to participants in a project. A good project manager should understand the distinction between raw project data, information, and actionable knowledge.
• Project Risk Management: The skill of a project manager is in mitigating risks before they materialize – and if risks do materialize, designing contingency plans for them. All risk-related activities, including identification, analysis, response planning, and implementation, belong to this knowledge area.
• Project Procurement Management: Your project will often need products or services from outside your own sphere of control and you will be required to procure them. Procurement processes are within this area.
• Project Stakeholder Management: Stakeholders are those people, groups, or organizations that will be impacted by your project. So, a project manager uses appropriate processes to engage appropriate stakeholders, both during decision making and the execution of a project. These stakeholder-related processes belong here.

So far, we have understood project processes and learned about two different categorizations for them: Process Groups and Knowledge Areas. If you understand these systems, it will enable you to view your project processes from multiple perspectives.

Work breakdown structure (WBS) – a special mention

Running a project without a work breakdown structure is like going to a strange land without a road map – J. Phillips

In this section, we will examine a key project deliverable called Work Breakdown Structure. This is encapsulated in the project management processes that we have just familiarized ourselves with as the Create WBS process.

So, what is a WBS? The WBS is the breaking down of project work into smaller components to achieve the project scope.

The WBS is created during project initiation to manage the scope of the project. It is an application of the divide and conquer technique to break down the project scope into manageable components. After that, we use the WBS to create the project schedule (using Microsoft Project). Subsequently, the WBS is referred to, throughout the entire project life cycle, to monitor and control, and to close the project.

Despite its simplicity, WBS creation takes practice and skill to do correctly; and when done, will add significant benefit to the project. Due to the importance of WBS in executing schedules successfully, Chapter 6, Work Breakdown Structure – the Single Critical Factor, is dedicated to the practical aspects of creating a WBS.

Pitfall

Projects with a well-defined WBS might also fail, but a project with an incorrect WBS will seldom succeed. If your roadmap is incorrect, how will you reach your desired destination? In such a situation, course correction must happen, starting with the WBS.

How is a WBS different from the task/activity list? If someone asks about your project What are the project deliverables? the answer should be listed in your WBS.

Pitfall

The most common pitfall is to include the tasks in the WBS (instead of only deliverables and outcomes). Implementation details (tasks) belong to the task list and not in the WBS. The task list is, in fact, derived in a later stage, using the WBS as a foundation.

Why is a WBS important?

• The most important function of the WBS is Scope Management. A WBS helps in ensuring that the project includes all the work required (and nothing else) to achieve the project objectives.
• A WBS helps you to understand the work in the nascent stages of a project. It is also the critical step to proceed from Scope to Schedule.
• Changes are inevitable in projects and a WBS helps both in avoiding scope creep (uncontrolled changes to the scope) and as a reference baseline for scope change control.

Who should create the WBS?

The project manager has ownership of the WBS. But the actual bulk of the WBS content should be contributed by the following:

• Domain-specific experts
• Technical experts
• The team that is actually going to work on the project
• Business analysts

Reviews can be done by the following:

• Key identified stakeholders of the project
• Other project managers and teams that have done similar work

Why is a WBS so important in this book?

The WBS of your project should ideally be the input to create your schedule using Microsoft Project. So, it will really help to get familiar with this technique, through repeated practice.