As defined by Gartner, project management is “the application of knowledge,

skills, tools, and techniques to project activities to meet the project

requirements.”

Project management is an integral part of software engineering processes,

along with business analysis, requirement specification, design, programming,
and testing. It has been a topic of considerable debate for years. Even today,
when project management practices are becoming more mature, only 53
percent of organizations are fully aware of the importance of these practices.

Whatever the industry, project management is a crucial element of a

company’s efficiency. In fact, organizations using proven project management
practices waste 28 less money and implement projects that are 2.5 times more
successful.

Project management professionals define a successful project as not only the

one that is completed on time and within budget but also as the one that
delivers expected benefits.

Project management phases

Regardless of the scope, any project should follow a sequence of actions to
be controlled and managed. According to the Project Management Institute (PMI),
a typical project management process includes the following phases:
1. Initiation
2. Planning
3. Execution
4. Performance monitoring
5. Project close

Used as a roadmap to accomplish specific tasks, these phases define the

project management lifecycle.

Yet, this structure is too general. A project usually has a number of internal
stages within each phase. They can vary greatly depending on the scope of
work, the team, the industry, and the project itself.

In attempts to find a universal approach to managing any project,

professionals have developed numerous PM techniques and methodologies.
Traditional project management
methodology
Based on the above-described classic framework, traditional methodologies
take a step-by-step approach to the project execution. Thus, the project goes
through the initiation, planning, execution, and monitoring straight to its
closure in consecutive stages.

Often called linear, this approach includes a number of internal phases that
are sequential and executed in chronological order. Applied most commonly
within the construction or manufacturing industry, where little or no changes
are required at every stage, traditional project management has found its
application in software engineering as well.

Known as the Waterfall model, it has been a dominant software

development methodology since the early 1970s, when formally described by
Winston W. Royce: “There are two essential steps common to all
computer program developments, regardless of size or complexity.
There is first an analysis step, followed second by a coding step …
This sort of very simple implementation concept is in fact, all that is
required if the effort is sufficiently small and if the final product is to
be operated by those who built it – as is typically done with
computer programs for internal use.”
The Waterfall model has a strong emphasis on planning and specifications
development, which takes up to 40 percent of the project time and
budget. Another basic principle of this approach is the strict order of the
project phases. A new project stage does not begin until the previous one is
finished.

The method works well for clearly defined projects with a single deliverable
and fixed deadline. The Waterfall approach requires thorough planning,
extensive project documentation, and tight control over the development
process. In theory, this should lead to on-time, on-budget delivery, low project
risks, and predictable final results.

However, when applied to the actual software engineering process, the

Waterfall method tends to be slow, costly, and inflexible due to numerous
restrictions. In many cases, its inability to adjust the product to the evolving
market requirements often results in a huge waste of resources and the
eventual project failure.

Since its inception, the Agile methodology has come a long way to become a popular approach

among a wide variety of organizations. For those unfamiliar with the term, Agile is a method of

project management where projects are organized into epics then broken down into small

manageable sections via chapters and sprints. While this method is most often associated with

software development and DevOps, it has a wide range of applications throughout the business.

It’s a set of principles aligned with business goals that adequately handles the lack of

predictability when it comes to project management. Agile methodologies include Scrum,

Kanban, Extreme Programming (XP), and Adaptive Project Framework (APF). Agile Project

Management has its roots in iterative project management. It is a highly flexible and interactive

model where requirements and the overall project plan are regularly updated to meet changing

requirements from stakeholders, suppliers, and customers.

. Many organizations implemented a form of project management in an attempt to
improve the success rate of IT projects. However, due to the rigidity of the
methodologies, they often failed, causing “paralysis by analysis”. The procedural
approaches placed emphasis on demarcation lines, sequential step-based
progressions, and the uniqueness of role and responsibilities based upon hierarchies
and fixed responsibility sets which limited the capacity of the team and the overall
productivity of the project. Step-by-step methodologies may apply in industries such as
construction, but they are less suited to the world of software development. This
became increasingly clear as the 1990s introduced new more dynamic and flexible
software development tools. The need for a new system to conduct development in a
controlled but highly flexible fashion became paramount.

These pressures led to the development of Agile. Delivering a managed approach to

software development without conventional procedural emphasis and
compartmentalization, Agile focuses on iterating through product requirements,
encouraging continuous improvement, and responding quickly to changing
requirements from the aspect of a team mentality rather than on an individual level.

Agile Project Management has its roots in iterative project management. It is a highly flexible
and interactive model where requirements and the overall project plan are regularly updated to
meet changing requirements from stakeholders, suppliers, and customers.

Aimed at “uncovering better ways of developing software,” the Manifesto

clearly specifies the Agile fundamentals:

“Through this work, we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan.”

Complemented with the Twelve Principles of Agile Software, the philosophy has
come to be a universal and efficient new way of managing projects.

Agile approach and process

Agile methodologies take an iterative approach to software development. Unlike
a straightforward linear Waterfall model, Agile projects consist of a number of
smaller cycles. Each one of them is a project in miniature: it consists of
design, implementation, testing, and deployment stages within the pre-defined
scope of work.

At the end of each cycle, a potentially shippable product increment is

delivered. Thus, with every iteration, new features are added to the product,
resulting in gradual project growth. With the features being validated early in
the development, the chances of delivering a potentially failed product are
significantly lower.

Agile software development steps

The end-to-end Agile project management flow consists of five distinct phases
that mostly correspond to the general PM stages we mentioned above.

Envision or initiation phase. The first stage within an Agile project

management methodology is about identifying the needs of the end
customers, setting business objectives, and outlining the desired results.
A project manager identifies the right stakeholders and assigns roles across the
team.

Speculation or planning phase. The stage has two main goals:

breaking the project into milestones and setting timelines. To achieve the first
objective, you need at least a general understanding of project functional
requirements. The Agile team prioritizes features and estimates how long it will
take to develop them. The phase results in creating an execution plan that,
unlike in the Waterfall scenario, will further adapt to changes.

Exploration phase. It involves exploring different ways to address project

requirements while staying within time and budget constraints. Once the best
option is decided on, the team adds a portion of user stories to an iteration
plan and proceeds to their development and testing. The exploration phase
goes in parallel with the fourth adaptation phase since the team considers
customer feedback and learns from the previous experience.

Adaptation phase. This stage is unique to Agile software development. It

enables the team to review the results of previous iterations, assess the
existing situation, gather customer feedback, and check performance against
 the execution plan. Then, you can adapt your plans and approaches
accordingly, introducing all needed changes and new requirements if there
are any.

Closing phase. At the final stage, the team makes sure that the project is
completed and meets all updated requirements. The best practice here is to
discuss mistakes occurred during the project and areas for improvements to
make better decisions in the future.

Agile best practices

Let’s summarize the best practices Agile sticks to.

Flexibility: The scope of work may change according to new requirements.

Work breakdown: The project consists of small cycles.

Value of teamwork: The team members work closely together and have
a clear vision of their responsibilities.

Iterative improvements: There is a frequent reassessment of the work

done within a cycle to make the final product better.

Cooperation with a client: A customer is closely engaged in the

development and can change the requirements or accept the team’s
suggestions.

According to the 16th Annual State of Agile Report, respondents who have
adopted the Agile approach mention the following benefits:
 accelerated time-to-market (52 percent);
 delivery predictability(44 percent); and
 lower risk(31 percent).

Companies also admit that high-performing Agile teams have people-centric

values, clear culture tools, and leadership empowerment that positively
influence the entire organization.
Agile project management frameworks and
methodologies
Agile is an umbrella term for a vast variety of methodologies and techniques,
that share the principles and values described above. Each of them has its
own areas of use and distinctive features. The most popular frameworks and
practices are Scrum, Kanban, Hybrid, Lean, Bimodal, XP, and Crystal. Before
discussing them in more detail, let’s examine their key features.

ow Agile Project Management Works?

Agile is a mindset rather than a rule-book of procedures. Exactly how an Agile software
development project might work in a given context is, therefore, open to considerable
flexibility.

Essentially, Agile does the following:

 De-emphasizes activities that are not directly related to the production of software.
This might include things such as fine detail written contractual agreements,
specifications, and change control negotiations.

 Pulls all required expertise together into one location and under one team.

 Encourages joint integrated development with people communicating side-by-side

rather than in a hierarchical manner. Ideally, this involves the developer and final
customer sharing responsibility for joint development and eventual success.

 Recognizes that change is endemic in a team or a business and software

development must accommodate change as part of a development project rather
than to try and squeeze it out through processes and procedures.

 Delivers smaller, verifiable components to a business rather than an overall, large

scale solution.

 Rather than following the traditional way of sequential methods, Agile works on a
new and improved iterative method that allows the clients to be involved at every
stage of project management.

 Empowers individual software developers to make decisions within a structured

change management environment.
 Attempts to move away from the idea of a vast project plan that becomes set in stone
and which subsequently precludes the realization of opportunities and individual
innovation.

Agile Project Management Versus Other Approaches

Agile principles are relatively revolutionary when examined against other forms of IT
software development. For example, some other methodologies emphasize the need for
rigid change control procedures to be applied to software development and have clear
boundary lines defined for things such as specifications and frozen target design sign-
off. For that reason, Agile has occasionally been portrayed as being “anti-methodology.”
However, that is a common misconception. Agile seeks to achieve a more sensible
balance between risk management, individual initiative, and flexibility, as opposed to
other approaches that may be more constraining and rule-based.

Organizations following Agile methodologies develop products quickly while ensuring

customer satisfaction at the same time. This is largely driven by the realization that the
nature of business today cannot be encapsulated in the current market and when it
comes to software development Agile project teams offer flat organizational structures.

Why Agile Project Management is the Right Choice for

You?

Increasing numbers of organizations are looking for more flexible, iterative, and
interactive software development paradigms. Agile delivers on that requirement. And
here’s why:

 Faster lead times

 A reduction in administrative procedure and its associated overheads

 Improved relationships between the various people and their organizational entities
working alongside each other in a single framework to achieve success

 Regular incremental delivery of product components means improvements in

stakeholder expectation management and confidence levels
 A greater degree of shared participatory risk between contributing entities in the
organization, with an associated reduction in the “not invented here” and “more than
my job’s worth” syndromes

 A reduction in the risk of project failure

 Project progress is easier to measure in terms of deliverables that might be possible

via the interpretation of overly complex project plan progress reports

The growing popularity of Agile increased the demand from employers for Agile
Certified Project Managers and Scrum Masters. An Agile Project Manager in the U.S.
can expect to make an average of $91,000 with more experienced professionals
earning upwards of $125,000. Certified Scrum Masters are commanding an average
salary of around $103,000 with earnings up to $165,000 plus package benefits.

If you are currently operating as a Software Developer, Team Leader, or Non-Agile

Project Manager and are seeking career diversification with advancement, obtaining
your Agile and Scrum Master certification might be an important step on the road to
transforming your future prospects.

n introduction to PMBOK process

groups and knowledge areas
The Project Management Institute (PMI) created the PMBOK (Project
Management Body of Knowledge). It consists of guidelines,
recommended practices, standard principles, and common
terminology for managing projects.

The contents of PMBOK were initially consolidated into a book

called “A Guide to the Project Management Body of
Knowledge” (commonly known as the PMBOK Guide), back in 1996.
The sixth edition of this guide was released in 2017, and
the seventh edition is expected in 2023.
 The PMBOK guide embraces a process-based
approach to project management. It breaks down project
management into 49 processes, which are then grouped under
PMBOK process groups and knowledge areas.

Think of process groups as what you need to do and the knowledge

areas as what you need to know. These come together in a matrix
format to encompass the 49 individual processes. The processes
intersect with each process group so that each of the 49 processes
falls under one knowledge area and one process group.

What are the process groups of

PMBOK?

The five PMBOK process groups are:

1. Initiating Process Group: Processes required to launch a new

project or a new project phase
2. Planning Process Group: Processes related to defining and
planning the extent of the project, as well as planning how it will be
executed
3. Executing Process Group: Processes related to the completion of
project activities and tasks
4. Monitoring & Controlling Process Group: Processes covering
everything related to tracking, monitoring, reporting on, and
controlling project performance and progress
5. Closing Process Group: Processes required to finalize and
complete a project or project phase

Initiating
 The initiating process group is generally when a project is formally
approved and assigned to a project manager. The group includes
two primary processes: developing the project charter and
identifying the project stakeholders.

The two outcomes of this process group are the project charter
document and the stakeholder register. The stakeholder register
lists who the project stakeholders are, what their stake in the project
is, and what they expect regarding frequency and form of
communication.

The project charter should include the business case for the project
(why it should be completed), as well as a high-level overview of the
project’s scope, deliverables, and objectives.

Typically, a project charter will also include:

 Resources required
 Key stakeholders
 A high-level timeline with key milestones
 A high-level cost estimate
 Any known risks, issues, or dependencies

Planning

The planning group is the largest of the five process groups,

consisting of 24 processes in total. This group of processes is
designed to help you plan your entire project in detail, from the
scope, schedule, and budget to how you will manage the key
stakeholders. The primary outcome of this planning stage is
a project management plan (PMP).

For larger projects, the PMP may have sub-plans to further outline
some of the critical areas, such as the project schedule or quality
management. For smaller projects, processes may simply be
covered in separate subsections or fleshed out in an appendix.

The PMP is a “living document” that is updated and revised

throughout the project as changes occur.

Executing

The executing group is where most of the action happens on a

project. It is also where most of the budget is spent and where the
actual project deliverables are produced.

The executing process group includes ten project management

processes. It is primarily focused on managing project activities and
tasks to ensure progress is occurring, communications are
happening, risk responses are being implemented, and stakeholders
are being engaged.

The most significant role for the project manager during this phase
is directing and managing the project work and managing the
project knowledge (requirements documentation, meeting minutes,
lessons learned). Other typical responsibilities of the project
manager include acquiring project resources, developing and
managing the project team, and managing communications.

Controlling and monitoring

The controlling and monitoring process group is the second largest,

containing twelve project processes. These processes happen
throughout the entire project and are in place to ensure there is
sufficient oversight. This will also help identify and mitigate any
potential issues.

Inevitably, something unexpected will come up during the project

life cycle. The processes in this process group are designed to help
you update the plan, modify your team’s activities, and get
everything back on track.

One of the essential processes in this group is monitoring the project

work. This requires the tracking of the overall project and its key
aspects. This process is critical in limiting overages and project
errors. Often, project management software is used to monitor and
report on progress.

Closing

The closing process group only has one primary process: close out
the project or phase. This process involves ensuring the customer
has accepted all final phases or project deliverables. Documentation
should also be completed and stored and any loose ends of the
project or phase should be tied up.
The benefits of PMBOK process groups
The PMBOK process groups are designed to help you plan your
entire project from start to finish, leaving you with a comprehensive
project management plan. The process groups provide a template
that can be reproduced for all kinds of projects, ensuring that
resources are always used effectively.

Experienced project managers understand how the five process

groups interact with each other and use this knowledge to guide
their projects to success. Knowing the intricacies of the processes
within is a hugely valuable project management skill.

Choosing your methodologies with

Wrike
There are many different ways to manage and organize a project.
Traditional methodologies like Waterfall are designed to lay out
every task in sequential order before project execution begins.
Initially, this was the methodology that the PMBOK processes were
designed around, while the five process groups were often treated
as sequential phases.

Over time, people have recognized that the structured approach

does not work well for every project. Sometimes, a more Agile
methodology can work better. Just as methods have grown and
changed over time, so have the PMBOK processes. They have
adapted to work with many mainstream project management
 methodologies. So, no matter what project methodology you select,
you can still successfully incorporate the PMBOK process groups.

Selecting process management software that supports your project

methodology of choice and also aligns with the five PMBOK process
groups is essential for project success.

Fortunately, Wrike project management software is designed to help

you incorporate the PMBOK process groups into your projects,
whether you’re using Waterfall, Agile, or another methodology. Why
not try it out for free today?

What are the Project Management

Knowledge Areas?
Student Success Story

I signed up for The PM PrepCast, bought a copy of the PMBOK®

Guide, and began to study the standards as set forth by PMI. I
quickly understood the terminology, and began to understand
the knowledge area flow and process groups.

Tom C, PMP

First let’s start with the Knowledge Areas. There are ten of them. In the order
that they appear in the PMBOK® Guide they are:

1. Project Integration Management

2. Project Scope Management
3. Project Schedule Management
4. Project Cost Management
5. Project Quality Management
6. Project Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
10. Project Stakeholder Management.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project
Management Institute Inc., 2017, Page 25.

That’s a lot of knowledge! Each Area represents a complete area of

specialization including jargon, tools, concepts and tasks. In other words, you
need to know about each of them in order to be able to successfully manage
a project.

Depending on the project you’ll need to know more or less about each one –
you might not need to procure anything on a small project, for example, so
you can knock off Number 9. However, in order to achieve your PMP®
credential you’ll have to answer questions on each of them.

Knowledge Areas are made up of processes. More on them later.

Why do we have Knowledge Areas?

Tip

Plan on studying one Knowledge Area per week as you

prepare for the exam. Study the same area in all your
study materials in parallel.

Excellent question! Perhaps because trying to memorize all the processes for
the exam is tough and grouping them together helps?

That might be a spin-off benefit but it’s not the real reason. The real reason is
because most projects use most of these areas most of the time. The general
consensus (or we could call it project management best practice) is that you
have to be able to work across these areas in order to get your project done.
The Knowledge Areas are a handy way to group together theory and practical
techniques. They link up the major themes or professional fields that a
project manager has to operate in to get a project done.

Something to remember is that this list of ten is not exclusive. You may have
to draw on any other professional skill in order to complete your project, like
leadership or litigation. However, for most people, being proficient in the
areas covered in the PMBOK® Guide will be enough. The Knowledge Areas give
you a broad base from which to draw.

The 5 PMBOK® Guide Process Groups – 6th

Edition
Every project needs the 5 Process Groups. These are the second large piece of
the backbone of the PMBOK® Guide. The Process Groups are:

Initiating
These processes help you define a new piece of work – either a
complete new project or the phase you are about to begin. They ensure
you have authority to proceed.
Planning
These processes help you define objectives and scope out the work to
be done. They also encompass all the work around planning and
scheduling tasks. Again, they can cover a complete project or just the
phase you are working on right now. Or you might be closing one phase
and planning the next in parallel.
Executing
You do these processes as you carry out your project tasks. This is the
‘delivery’ part of project management, where the main activity
happens and you create the products.
Monitori
ng and
Controlli
ng
 These processes let you track the work that is being done, review and
report on it. They also cover what happens when you find out the
project isn’t following the agreed plan, so change management falls
into this Process Group. You’ll run these processes alongside those in
the Executing Group (mainly, but alongside the other Groups too) so
you monitor as you go.
Closing
Finally, these processes let you finalize all the tasks in the other Groups
when you get to the point to close the project or phase.
Project Management
Management Body of
Edition, Project Mana

It would be nice if your project walked through each of these Groups in a

neat, linear order. That doesn’t happen in real life. As you can see above,
you’ll spend time in each Process Group and then maybe go round again
during the next phase. Monitoring and Controlling happens from Day 1 – it
ramps while the project is in the delivery phases but it goes on throughout.
You can close a particular activity at any point, not just at the end of the
project.

What you can take from that is this:

The Process Groups are not the same thing as a project life cycle. A life
cycle shows how the project moves from start to finish in different
phases. Within one phase you might go through all the Process Groups,
or just some of them, so don’t confuse the two.

You can remember this for the exam by noting that all the Process Group
names finish with ‘–ing’. They are verbs (doing words). Life cycles are
described with nouns: Initiation, Execution, Closure. Watch out for questions
in the PMP exam that ask you to pick terminology because choosing
Initiation, Execution or Closure would be wrong!

What are the Process Groups for?

Process Groups bundle together processes (they’re coming up…promise)
that often operate around the same time on a project or with similar input
and outputs. Once you’ve got comfortable with them they are actually a very
logical way of grouping together the things you have to do.

So what exactly is the difference between

Knowledge Areas and Process Groups?
The easiest way to remember the difference is:

Knowledge Areas

They cover what you need to KNOW.

Process Groups

They cover what you need to DO.

Process Groups help you apply what knowledge you have about the different
professional areas of project management. They let you take your knowledge
and step you and your team through exactly what you have to do at each
point. Clear now?

There’s only one more piece of the PMBOK® Guide backbone to look at.
Finally we’re going to talk processes!

The PMBOK® Guide Processes of Project

Management
Student Success Story
Know all the processes, what sequence they are executed in
and which process group they fall into.

Warwick Kowalczyk, PMP

The PMBOK® Guide defines a process as “a set of interrelated actions and

activities performed to create a pre-specified product, service or result.” It
goes on to say that “project management processes ensure the effective flow
of the project throughout its life cycle.” Processes get things done.

Each process has pre-requisites (known as inputs), tools and techniques you
can use to actually do the process, and then outputs: one of more things that
you get as a result of having done the process. The achievement of those
things lets you know the process is over (at least until the next time you need
to use it).

There are around 50 processes in the Guide. The main part of the book is split
into ten chapters, each of which deals with a PMI Knowledge Area. Each
chapter details which processes apply to that Knowledge Area, and each
process falls into a Process Group.

In his book, Mastering Project, Program, and Portfolio Management: Models

for Structuring and Executing the Project Hierarchy, Gary Lister explains how
the processes are split between the five process groups. It’s not an even split.
He explains that over 50% of the processes fall into the Planning Process
Group. Read the relevant chapter from his book and take a look at the bar
chart yourself: it makes it really clear that planning is essential if you want
your project to be a success, and that you’ve got the most work to do in that
area.

I’m not going to list them all here because there’s a chart in the PMBOK®
Guide which does it perfectly. It’s the one I recommend to students all the
time.
The PMBOK® Guide 6th Edition Matrix Chart –
Process Groups and Knowledge Areas
Mappings
Student Success Story

I used the PMBOK® Guide Appendix to enforce and visualize

the flow and integration of each process area. Doing so showed
me trends in inputs and outputs and showed me how processes
flowed within a process group vs a knowledge area. I also
memorized PMBOK® Guide table 1-4.

Lucas Marino, PMP

Table 1-4 in the PMBOK® Guide shows you the Knowledge Areas down the
side, the Process Groups along the top and then maps the difference
processes in the relevant boxes where those two axes cross. For example, at
the junction of Project Integration Management and the Initiating Process
Group you have the process to ‘Develop Project Charter’. This table explains
the project management process groups and knowledge areas mapping.

You’ll see that some cells in the table are blank. That means that there are no
processes associated with that particular stop along the project journey.
There’s very little in the Initiating Process Group actually, but you’ll see that
each Process Group has at least two processes (otherwise it wouldn’t be a
group, would it? It would just be a single process).

It’s a lot easier to look at the table than for me to describe it. Take a look at it
below or turn to the relevant page in your copy of the Guide. Many students
flick to this page in their Guide and suddenly the interplay between
Knowledge Areas, Process Groups and processes becomes clear. I
recommend using a sticky tab to mark the page in your copy as you’ll be
referring to this table a lot during both your PMP studies and your day-to-day
work as a project manager.
 Process Group / Knowledge Area Mapping

Which processes do I use?

The short answer to this question is that you use the processes that help you
get the job done. Ideally, everyone in your business should use the same
processes for the same activities.

There is huge benefit in everyone using the same processes for the same
activities. PMI’s Pulse of the Profession® study reported that high-performing
organizations are three times more likely to use standard processes across
the organization than low performers. Using project management processes
really does improve project success. This article from PMI gives you some
examples from organizations which have seen the benefits of using standard
processes.

It’s your responsibility to choose the right processes to give you the desired
outcome. There’s no point choosing to carry out all the processes around
procurement if you aren’t buying anything. Pick and choose the processes
that will work for you and your project. You’ll need a degree of professional
judgment to do this so if you are just starting out you might be nervous about
selecting the right processes.

Don’t be. It’s largely common sense. And if you still aren’t confident about
making the right decisions then talk to your manager or mentor. A good rule
of thumb (until you have built your own bank of experience) is that it’s better
to apply the processes and then realize you didn’t need to than leave them
out and regret it later.

However, you’ll need to know about all of them to get through the PMP exam
successfully.

Do I really have to learn them all for the PMP

Exam?
Yes. Let’s look next at how you can prepare, because you do need to know
them all.

Knowledge Areas in the PMP Exam and how

to prepare
Student Success Story

Jot down the Knowledge Area/Domain Matrix and the key

formulas once you get started. They will help you at the height
of your exam.

Ashwin Kumar Chandrasekaran, PMP

If you’ve got this far, you’re probably thinking about taking the PMP exam.
Maybe you’ve already submitted your application (in which case –
congratulations! You’re one step closer to becoming a PMP).

The Knowledge Areas form a significant part of the exam. You’ll also get
questions on individual processes, for example questions covering the
inputs, tools and techniques and the outputs for a process.

A good starting point for preparing for the exam is to memorize the table.
Then take some time after you started your exam session to write down your
own notes – a crib sheet – before answering the first question. Investing a few
minutes of your actual exam time is an excellent way to get this written
down, as it allows you to dump all your revision from your brain onto paper
so it’s there for you to refer to during the exam. It’s also a good way to relieve
stress as you know you’ve got your notes to hand. I call it a brain dump and it
should definitely include this table.

Use your favorite techniques for memorizing it, whichever revision technique
you think will give you the best result based on your learning preferences.
There are some good tips for memorizing the table in Bruce Garrod’s
article on the PMI Community website.
However you choose to remember it, think about the logic behind it. Every
process maps to a Knowledge Area and a Process Group, and there is a strong
rationale for why they fit together in that way. Understanding how you would
use the process on a real project will help you see where it fits on the table
and also in the context of your day job. The more you focus on why the
process features on the table at all, the easier it will be to place it. The added
benefit of this approach is that if you forget where something goes on the
table you’ll still be able to answer the exam questions because you can see
the bigger picture of how the process is used.

Tools for preparing for the exam

The brain dump of Table 1-4 is just one way to get organized for the
Knowledge Area questions in the PMP exam. Arm yourself with other revision
guides and exam prep tools so that you are fully prepared for anything that
might come up relating to processes.

As the Knowledge Areas and Process Groups are such an integral part of
the PMBOK® Guide, you’ll want to make sure you are using a comprehensive
exam prep guide such as the PM PrepCast. With explanations in everyday
English and a complete set of videos covering the entire PMBOK® Guide (and
more – if you didn’t know already, you’ll also face questions about topics that
aren’t covered in the PMBOK® Guide) it’s everything you need to prepare for
success.

How long should I spend revising the Process

Groups and Knowledge Areas?
The amount of time you spend studying the PMI Process Groups and the
Knowledge Areas that correspond to them will depend on how quickly you
pick up the core concepts. Some students get the mapping and the logic
behind it very quickly. Others take longer to feel confident with the ideas and
being able to recall them under exam conditions.
 The best thing to do is to not compare yourself to other PMP aspirants and to
work at your own pace. By all means, set yourself a target for when you want
to be taking the exam but create a study schedule that works for you and that
is achievable. Get the best quality PMP prep tools you can (and they aren’t
necessarily the most expensive the PM PrepCast is very affordable) and use
them to plan your studies.

What is Project Integration Management?

So far we have done an 'executive overview' of the Knowledge Areas and
stayed high-level. But what are some of the details that can be found inside
the Knowledge Areas?

To answer that question, please watch the following video that will give you a
PMP Integration Management overview:

This video is a lesson taken from The PM PrepCast. It's a good representation
of the type of training it offers.

Summary
Now you have read this complete guide to the PMBOK® Guide Knowledge
Areas for project management covering the Process Groups and processes,
you should already feel more equipped to plan for and prepare for the exam.
Plus you’ll have a much better idea of how to make them work for you on a
project.

In summary:

 Project Management Knowledge Areas cover what a project manager needs

to know in order to successfully manage a project.
 Processes cover what a project manager and team have to do to deliver a
project successfully.
 Process Groups are logical groupings of processes.
 It might seem daunting, but with good exam prep guides, a thorough
approach to your revision and a brain dump sheet you can rely on, you’ll
soon find that working with Knowledge Areas, Process Groups and processes
becomes second nature.

Processes, Inputs, and Outputs

Each system has inputs, outputs, processes, constraints and mechanisms. A process is an action that transforms
given inputs into outputs under certain constraints or restrictions and with the aid of some mechanisms. For
example, the process of making coffee by a coffee maker can take inputs such as coffee, filter, water, and
electricity, and result in outputs such as coffee, used filter, used coffee and grounds.

Constraints and Mechanisms

The constraints can be size of the coffee maker and the quantity of coffee and water available, and the mechanism
may be for someone to pour the coffee grounds into a filter and insert into the coffee maker, pour water into the
coffee maker and turn on the coffee maker, and the coffee maker equipment itself. Sometimes outputs can result
in feedback. For example, the quality of the coffee made can indicate which ingredient (water or coffee) should be
controlled next time to produce better coffee. The input-output diagram for the coffee making process is shown in
the figure below.

Identifying inputs, outputs, processes, constraints, and mechanisms of a system will help to understand the system
and manage it better. For example, if one of the environmental goals of the coffee maker system is to reduce
waste or increase efficiency, then the inputs, outputs, process, constraints, and mechanisms can be analyzed to
find the best way to accomplish the goals. The paper filter could be replaced by a reusable metal filter to eliminate
the manufacture and use of paper filters, or a better approach could be devised to discard used coffee grounds.

Sep 27 2020

 Labels: Project Success

Project Inputs, Activities, Outputs, Outcomes, Impact and Results

Many people and organizations seem to have serious trouble separating between the inputs, activities, outputs,
outcomes, impact, and the results of a project.

This leads to lot’s of confusion, bad communication, disappointed project teams, and disappointed stakeholders.

Below you will find my take on these terms and their relevance for your project.

Inputs

Inputs are very often confused to be synonymous with activities. However, these terms are not interchangeable.

Inputs, in simple terms, are those things that we use in the project to implement it.

For example, in any project, inputs would include things like time of internal and/or external employees, finances
in the form of money, hardware and/or software, office space, and so on.

Inputs ensure that it is possible to deliver the intended results of a project.

Activities

Activities on the other hand are actions associated with delivering project goals. In other words, they are what
your people do in order to achieve the aims of the project.

In a software development project, for example, activities would include things such as designing, building,
testing, deploying, etc. And in an upskilling initiative the training of employees would be an activity.

Outputs

These are the first level of results associated with a project. Often confused with “activities”, outputs are the
direct immediate term results associated with a project.

In other words, they are the delivered scope. The tangible and intangible products that result from project
activities. Outputs may include a new product or service, a new ERP system replacing the old one, or employees
being trained as part of a digital upskilling initiative.

Success on this first level of results is what I call “Project Delivery Success”. It is about defining the criteria by
which the process of delivering the project is successful.
Essentially this addresses the classic triangle "scope, time, budget".

It is limited to the duration of the project and success can be measured as soon as the project is officially
completed (with intermediary measures being taken of course as part of project control processes). It is always a
combination of measurements on inputs and outputs.

Outcomes

This is the second level of results associated with a project and refers to the medium term consequences of the
project. Outcomes usually relate to the project goal(s).

For example, the new ERP system is used by all users in scope, uptime is 99.99%, customer satisfaction has
increased by 25%, operational costs have decreased by 15%, and so on.

These criteria need to be measured once the product/service is implemented and over a defined period of time.
This means it cannot be measured immediately at the end of the project itself.

Success on this second level of results is what I often refer to as “Product or Service Success”. It is about
defining the criteria by which the product or service delivered is deemed successful.

Impact

This is the third level of project results, and is the long term consequence of a project. Most often than not, it is
very difficult to ascertain the exclusive impact of a project since several other projects, not similar in nature can
lead to the same impact.

For example, financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share
won, technology advantage).

Success on this third level of results is what I call “Business Success”. Business success is about defining the
criteria by which the product or service delivered brings value to the overall organization, and how it contributes
financially and/or strategically to the business.

Results

Project results are the combination of outputs (level 1), outcomes (level 2), and impact (level 3). These levels
combined will determine your overall project success. You can be successful on one level but not others.

Project success and project failure are NOT absolutes. It may not be possible to be a little bit pregnant, but you
can be a little bit successful.

Every project has multiple success criteria related to business results, product/service results, and project
delivery results (cost, schedule, scope, and quality).

Some criteria are absolute, meaning they must be completed on or before the original planned date, and some
are relative, meaning they must be completed by a date acceptable to the client.

Project success is determined by how many of your success criteria are satisfied, and how well.
25 February 2019 | 9:00
Reinhard Wagner

The interrelations between process and

project management
Project orientation has experienced a similar upswing in recent years as process orientation. Both
concepts are so popular because they promise better fulfilment of customer wishes while
simultaneously improving effectiveness and efficiency. Projects and processes complement each
other. On the one hand, projects can be described by a multitude of processes with the help of which
project results are achieved. On the other hand, higher-level processes can be implemented with the
help of projects. This is perhaps also one of the reasons why the two concepts are often confused or
sometimes even used synonymously. Therefore, in the following a distinction between the two terms
“project” and “process” with the corresponding or complementing disciplines of “process management”
and “project management” is made.

According to ISO 21500, a project “consists of a unique set of processes consisting of coordinated and
controlled activities with start and end dates, performed to achieve project objectives… Although many
projects may be similar, each project is unique”. The latter focuses on the uniqueness of the conditions
and the given deadline. It limits the temporary execution of a set of (processes consisting of
coordinated and controlled) activities necessary for project delivery. This definition already shows how
closely processes and projects are interrelated.

According to ISO 9000, a process is “set of interrelated or interacting activities which transforms inputs
into outputs”. Here, the focus is primarily on permanent activities that are necessary to achieve the
outputs. It does not emphasise the uniqueness of the conditions as a whole, as processes are usually
more standardised activities that are repeated on different occasions, taking advantage of learning
effects and aimed at achieving efficiency.

In both, projects and processes, resources are used to meet client’s requirements and achieve desired
results. Resources should be used as efficiently as possible, in processes due to the overarching
objectives, in projects due to the tight timeframe and financial constraints. In both cases, activities have
to be completed to achieve desired results. The activities interact in many ways, thus a coordination of
the activities towards the goal is necessary.

ISO 21500 defines project management as “the application of methods, tools, techniques and
competencies to a project. Project management includes the integration of the various phases of the
project life cycle… and is performed through processes.” The definition highlights the integrative
character of project management. The International Standard describes that project management is
performed through processes and mentions three types of processes, which overlap and interact
throughout a project:

 project management processes, which are specific to project management and determine how the
activities selected for the project are managed;
 delivery processes, which are not unique to project management, which result in the specification
and provision of a particular product, service or result, and which vary depending on the particular
project deliverable;
 support processes, which are not unique to project management and which provide relevant and
valuable support to product and project management processes in such disciplines as logistics,
finance, accounting and safety.

Process management aims at the development of an organisation. It may encompass the unique
renewal of the entire organisation (“reengineering”) or the establishment of process thinking, a process
organization and process management itself, including the continuous improvement processes.

Process management is therefore primarily understood as development task. The aim is to ensure the
efficiency of the organisation and to enable organisational or individual learning. These tasks can be
realized as (change) projects, but also include continuous tasks such as process controlling and
continuous improvement activities. In contrast to project management, process management is
therefore less oriented to the operative implementation of tasks than to the creation of the necessary
prerequisites (for implementing projects).

Even if the two disciplines are different, they will often complement each other in practice. In this way,
change projects can be triggered from process management, which serve to increase efficiency and
have improved process flows as their goal. In addition, projects provide valuable information on the
efficiency of processes, which can be taken up by process management and used for improvement.
Project management, in turn, can integrate process management into the design of project-specific
processes and thus achieve the most efficient project handling possible.

Project Management Life Cycle vs Project

Management Process
In our previous articles, we have gone over the types of project management life cycle, types of
phase to phase relationships as well as the meaning of process groups and knowledge areas but
in order to completely understand the fundamentals of PMP (check out our
comprehensive YouTube playlist of fundamentals of PMP) we must understand the difference
between Project Management Life Cycle or Project Life Cycle and Project Management Process.

Let’s define both of these for more clarity,

Project Management/Project Life Cycle

This is basically what you need to do ‘to do’ the work

In simpler terms, when you are out to create a software you will have to gather requirements and
complete a system requirements document. This will be followed by a high level design document,
coding, testing and delivery.

But at the same time for a construction project, right after the requirements are signed off, you will
move on to create a CAD drawing.

Consider creating a software but working on partial requirements followed by coding, testing and
delivering them. And then in the next iteration again delivering some more requirements. This is
also a project life cycle which is following the Agile methodology.

The point is, there are different types of Project Management/Project Life Cycles but all of them
essentially deal with the activities that are required to be done in order to deliver the project. These
activities may have different names and characteristics depending upon the type of Life Cycle in
practice

Project Management Process

This is basically what you need to do ‘to manage’ the work

All projects, no matter what industry and no matter what Life Cycle they follow, will always have the
five project management processes viz.
1. Initiation
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing

However, an important point to note here is that each phase/activity of project life cycle may
involve all project management processes. For instance, collecting requirements itself could be
initiated, well planned and executed! And ofcourse it would be monitored and controlled throughout
before the final sign off and closure