Can any dry textbook definition truly describe the project of climbing Mount Everest for the very first time? Or a project to find new sea routes in uncharted seas?

Yet, when you observe projects in real life a little more closely, you will see a lot that is familiar about them. Big or small, high-risk or no-risk, personal or mega-scale, there are some specific parameters that unify every project.

Project – the definition

In everyday life, projects of every size, budget, risk, and complexity can be found, but here is a definition that defines the soul of a project:

"A project is a temporary and unique endeavor with defined objectives."

While this definition is as generic as it can get, there are some crystal-clear points to break down:

• Temporary nature: Projects are temporary in nature – there has to be a clear, time-bound start state and end state. Projects cannot go on forever.
• Uniqueness: Pay special attention to this word; it says a whole lot about projects. Manufacturing cars is not a project (because mass-manufactured cars are not unique); it is more of an operation. Similarly, providing a car wash is a service. However, setting up the factory where cars are mass-manufactured is indeed a project.

  Moreover, exactly because projects are unique, they often face more unknown factors. The customer's reaction to a new shoe may really be unknown; a newly engineered door on the Mir space station may not function properly because the conditions cannot be 100% replicated during engineering. Often called unknown unknowns, this risk with projects is widely acknowledged and implicitly understood.

  We will discuss risks several times in this book, and how Microsoft Project can help with risks associated with schedules, resources, and budgets.

• Endeavor: Projects are purposeful by nature. They don't happen by accident. Or rather, accidental happenings are not called projects. The word endeavor also implicitly means that something has to be accomplished.
• With defined objectives: This means both the result and the limits it must be achieved within. For example, if you are building a house, you will expect to finish it to an acceptable quality, in a reasonable timeframe, and within a limited cost.

  Note

  Definitions in this book are not the official or standard definitions. It is my humble attempt to make the definitions as easily understandable and memorable for the reader. For the most definitive reference to all the terminology used in this chapter, please consult Project Management Institute's PMBOK® Guide (A Guide to The Project Management Body of Knowledge). In fact, this chapter is based upon this widely accepted standard.

Project management

Project management is the art and science of achieving project objectives by applying knowledge, tools, and techniques.

The science aspect of project management is derived from the body of knowledge. And the art aspect of project management becomes evident depending on how you apply the available knowledge to your project in your unique situations. This is because there is no single way to execute a project; and the execution is approached based upon the collective wisdom and other resources of the team. Therein lies the art of project management.

Microsoft Project is the preferred software tool. With the scheduling aspects of your project, it can prove to be the most important software project tool that you will use.

Project management done correctly can help you do the following:

1. Achieve your business' end goals
2. Manage constraints in the project – scope, quality, and costs
3. Increase predictability – even for subsequent projects
4. Optimize the usage of precious resources – money, people, machinery, and materials
5. Recover projects in trouble

The application of good project management practices and Microsoft Project will greatly enhance the success of your project.

Pitfalls

A common beginner's pitfall is to use MS Project only to create a schedule. The new user starts enthusiastically, and might even create a schedule at the beginning of the project. But they will not know how to use it to track the project, how to leverage one-click dynamic reports, how to identify risks, or for the long list of other features.

By reading this book, you will identify Microsoft Project's role in all major process groups that you will perform as a project manager.

The project manager

The project manager is the person around whom the project universe revolves. They are directly responsible for the success of the project.

To accomplish such a responsibility, the project manager is expected to bring a great deal of skills and competencies to the table. Project management skills are always expected: awareness of best practices, domain knowledge, business analysis skills, industry standards, and regulatory policy knowledge are just some of the fundamentals. If the project manager also has technical skills, they are highly valued.

Amongst the so-called soft skills, people and organizational leadership skills, good communication, conflict management, administration, and general management are just some of the fundamentals.

Moreover, this is a field where experience can make a big difference to project outcomes and is valued at a premium.

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.