Project Management Methodologies Senior Managers Need

Methodologies Senior Project
Managers Need in 2020
Grow Your Career

in 2020 with these
Project
Management Projex Academy
Grow Your Career
Methodologies
Methodologies Senior Project Managers Need in 2020 Projex Academy
Senior Managers Project Management Overview
With the pace of change rapidly increasing, senior managers need a firm grasp on
the methods used to implement those changes. I am talking of course, of the
application of projects to deliver those changes.
But it’s not as simple as that as today, business leaders need to call on a vast array
of project management methodologies. Indeed, such senior managers may be
acting as the sponsors or providing governance to the projects rather than acting as
the project manager.
Since projects are used for and almost unlimited variety of project types, industries,
and deliverables, it will come as no surprise that there are many methods and
frameworks for the delivery of products and services.
Instead of getting overwhelmed by this wealth of options, it makes good sense to
gain familiarity with the key elements of each method or framework to ensure the
manager can make an informed choice for their business.
It is also helpful to grasp a working understanding of the vocabulary used, the
methods and techniques applied, and knowledge of how these methods can be
blended.
Enjoy!
Dave Litten
Check out our range of project management related online

training https://www.projex.com/courses HERE!
P a g e 2 | 54
Predictive (Waterfall) Project Management
The waterfall or predictive method is the traditional way to manage projects for
lead parts several decades. The waterfall method is very straightforward in its
concept as the project tasks are carried out in strict sequential order.
As part of planning, the project timeframe is split into a series of stages or phrases,
with each one having a gate revue at the end. This review is to check progress and
agree the plan for the next stage. Once approved, there is no going back! Just
like a waterfall flowing down the hill.
These distinct endpoints or goals are set for each phase of development and cannot
be revisited after completion.
In this basic system, a team must complete one step before starting the next.
Managers find this system very straightforward and easy-to-implement. The
waterfall model emphasizes a logical progression of steps.
Just make a list of the task steps you need to accomplish a deliverable item and get
to work! Team members can quickly understand waterfall processes, saving project
managers valuable communication time.
The waterfall method is commonly used for projects of an industrial nature. Here,
the task work is visible and stable. Once the plan has been approved, the project
manager, using a “command and control” management approach, will issue
packages of work to the specialist team who are creating the products.
The construction industry is a good example of using the waterfall method. An
architect’s plan is created and agreed, and the project manager is there to oversee
the construction.
Here is an example of typical phases of the waterfall project:
P a g e 3 | 54
The Waterfall Process

More managers use the Waterfall system than any other, and the process sequence
usually follows the following stages or phases:
Specification of Consumer Requirements
Concept, Design, and Planning
Creation of a Physical Product (Construction, Coding, etc.)
Integration into Current Systems
Validation (Testing, Debugging, etc.)
Product Installation
Ongoing Maintenance
The Waterfall method best suits teams in manufacturing and construction that create
physical products and follow precise assembly orders, and these plans from
previous projects can be used as a template and applied to their current work with
little or no adjustment.
P a g e 4 | 54
The waterfall model is a linear, sequential approach to the software development

life cycle that has been popular in software engineering and product development.
Before moving to the next stage or phase, there is usually a review and sign off
process to ensure that all defined goals (products/deliverables) have been met.
The waterfall approach is ideal for projects that have specific documentation, fixed
requirements, ample resources, an established timeline and well-understood
technology.
The waterfall method is composed of seven non-overlapping stages:
Requirements: Potential requirements, deadlines and guidelines for the project are
analyzed and placed into a functional specification. This stage handles the defining
and planning of the project without mentioning specific processes.
Analysis: The system specifications are analyzed to generate product models and
business logic that will guide production. This is also when financial and technical
resources are audited for feasibility.
Design: A design specification document is created to outline technical design
requirements such as programming language, hardware, data sources, architecture
and services.
Coding/Implementation: The source code is developed using the models, logic and
requirements designated in the prior stages. Typically, the system is designed in
smaller components, or units, before being implemented together.
Testing: This is when quality assurance, unit, system and beta tests take place to
report issues that may need to be resolved. This may cause a forced repeat of the
coding stage for debugging. If the system passes the tests, the waterfall continues
forward.
Operation/Deployment: The product or application is deemed fully functional and
is deployed to a live environment.
Maintenance/Support: Corrective, adaptive and perfective maintenance is carried
out indefinitely to improve, update and enhance the final product. This could include
releasing patch updates or releasing new versions.
P a g e 5 | 54
However, there is a move toward using the Agile method (see later) for the
development of software.
Alternatives to the waterfall model include joint application development (JAD),
rapid application development (RAD), sync-and-stabilize, Agile project
management (APM) and the spiral model.
Waterfall model Advantages

While agile or dynamic methods often replace the waterfall model, there are some
advantages:
Upfront documentation and planning stages allow for large or shifting teams
to remain informed and move towards a common goal
It forces a structured and disciplined organization
It is simple to understand, follow and sequence tasks
Waterfall facilitates departmentalization and managerial control based on

schedule or deadlines
It reinforces good coding habits to define before design and then code
Waterfall allows for early design or specification changes to be made easily
Waterfall clearly defines milestones and deadlines.
Disadvantages of the waterfall model

These typically are associated with risk associated with a lack of revision, including:
Design is not adaptive; often when a flaw is found, the entire process needs
to start over
It ignores the potential to receive mid-process user or client feedback and

make changes based on results
P a g e 6 | 54
Teams that need to change their plans as their projects progress, however,
will find this method quite limiting
Delays testing until the end of the development life cycle
Does not consider error correction
Does not handle requests for changes, scope adjustments or updates well
Reduces efficiency by not allowing processes to overlap
No working product is available until the later stages of the life cycle
The whenever do dollars away the answer project on your walk along
Not ideal for complex, high risk, ongoing or object-oriented projects.
P a g e 7 | 54
Critical Path Method (CPM)

This technique directly follows on from the waterfall method. Because the entire
project plan is done in detail at the start of the project, then the sequence of tasks
or activities plus their dependencies is known.
And who follow the links through from the very first activity to the last, then a series
of parallel paths will naturally occur. Since projects need to know end dates, and
since these are set by the longest path from start to finish, it makes sense to be able
to calculate these various paths.
The longest path (calculated by the sum of durations for all the tasks within that
path), is known as the critical path. The word critical here, means time critical.
Management experts created the CPM project management methodology over a
half-century ago to highlight tasks that teams can’t begin until finishing others.
For example, construction workers find it best to install toilets and light fixtures only
after plumbers and electricians have run pipes and wires through the walls. And, of
course, they save drywall and painting for last.
CPM managers make strings of tasks that each depend on the other. These
sequential items form a team’s critical path. For example, once workers have laid a
foundation and raised the frame of a house, they can conduct several non-
dependent tasks: plumbing, electric, cabinetry, etc. However, carpet installers should
wait until everyone else has finished their tasks and left the house clean and dust-
free.
By determining a critical path and focusing on these important tasks above all
others, managers can avoid frustrating bottlenecks. They can allocate more
resources to any items on a critical path that lag and threaten delays.
With the CPM, managers can pull workers from non-essential tasks when they need
to “unkink” the chain of events in their critical path. Because workers can complete
non-essential tasks at any time, the company can continue working at a normal
pace, despite changes in worker allocation.
Let’s now dive a little deeper into the technique that is called critical path method
(CPM), or sometimes, critical path analysis (CPA) …
P a g e 8 | 54
Critical path method (CPM) is a resource-utilization algorithm for scheduling a set of

project activities. The essential technique for using CPM is to construct a model of
the project that includes the following:
A list of all tasks required to complete the project
The dependencies between the tasks
The estimate of time (duration) that each activity will take to complete
With this information, you can determine the critical path by identifying the longest
stretch of dependent activities and measuring them from start to finish.
Once you’ve identified which activities are on the longest, or critical path, you can
more easily discern which have total float, or can be delayed without making the
project longer.
Using the Critical Path Method in a Project

Now we’ll try to demonstrate the concept of the critical path method with a simple,
real-life example: planning a party. How should you plan and execute on this
project?
1. Define the project scope

First, we need to define all the tasks that must be finished to complete the project.
For our party example, it might look like this:
Choose a date and venue
Make the ultimate playlist
Set up the sound system
Invite your friends
Buy the food and drinks
Cook your famous casserole
Host the party
P a g e 9 | 54
When we look at these tasks individually, we realize that some of them cannot be
started before the others are completed. That is, some tasks are dependent on
others.
We’ve designated these relationships in the table below:
TASK NAME Dependent on

Choose a date and venue -
Make the ultimate playlist -
Set up your sound system -
Invite your friends Choose the date and venue
Buy the food and drinks Invite your friends
Cook your famous casserole Buy the food and drinks
Host the party Casserole & sound system
The actions “invite your friends,” “buy the food and drinks,” “cook your casserole,”
and “host the party” form a sequence of tasks that must be performed in a specific
order, one right after the other, to ensure a successful result. Such tasks are called
sequential activities.
These tasks, together with the start of our project (“choose a date and venue”) are
the most critical steps in completing our project. Thus, these actions will be placed on
the critical path.
2. Critical path analysis and identification
The essential concept behind critical path analysis is that you can’t start certain tasks
until others are finished. These tasks need to be completed in a sequence, with each
stage being completed before the next stage can begin:
P a g e 10 | 54
The critical path consists of the longest sequence of activities from project start to
finish that must be completed to ensure the project is finished by a certain time. The
activities on the critical path must be very closely managed.
If jobs on the critical path slip, take immediate action to get the project back on
schedule. Otherwise, the whole project can be delayed.
Imagine that you have a project that will take 30 days to complete. If the first
activity on the critical path is 1 day late, the project will take 31 days to complete,
unless another activity on the critical path can be completed 1 day earlier. The
critical path essentially determines the end date in your project schedule.
3. Different project paths
You can have more than one critical path in a project, so that several paths run
concurrently. This can be the result of multiple dependencies between tasks, or
separate sequences that run for the same duration.
The critical path in project management may contain all the important activities
associated with a project, or it may not. In fact, the activities on the critical path are
not always the most important parts of the project. At the same time, there will be
tasks that are not on the critical path, but that still determine your project’s success.
Understanding the critical path method involves determining which activities are
critical to complete on time. But other activities that lie outside of the critical path
may also be very important and require additional attention.
What Are Resource Constraints and Why Do They Matter?

Traditional critical path schedules in project management are based only on causal
dependencies. We’ve already marked these dependencies in our plan. (e.g., it’s
impossible to cook the casserole without buying the ingredients).
However, a project may have limited resources that need to be taken into
consideration. These limitations will create more dependencies, often referred to as
resource constraints.
P a g e 11 | 54
If you work on a team, you may split the project work between team members. In
our example, while you’re choosing a date and venue and inviting people, one of
your friends can make a playlist, and another can get the food and drinks.
The tasks can be done in parallel, as on the chart above.
However, if you’re the only person responsible for the project, you have a resource
constraint because you can’t be in two places at the same time. In this case, your
critical path will look different:
On the chart above, we assume that you first need to choose the date and venue,
and only later can you make a playlist. However, depending on the project
conditions, these tasks can be performed in a different order.
This kind of critical path is called a resource critical path.
This method was proposed as an extension to the traditional critical path analysis to
allow for the inclusion of resources related to each activity.
A resource-leveled schedule may include delays due to resource bottlenecks (i.e.,
unavailability of a resource at the required time), and it may cause a previously
shorter critical path to lengthen.
Calculating the Length of Your Project
In project management, a critical path is the sequence of dependent tasks that form
the longest duration, allowing you to determine the most efficient timeline possible
to complete a project.
Here's a rundown on how to calculate critical path in your project.
Getting back to our party example, let’s assume that you must do everything by
yourself. We estimated the length of time each activity will take.
P a g e 12 | 54
Also, we determined the approximate start time for each task on the critical path.
Here’s what we came up with:
Task Duration Start

Choose a date and venue 2 hours Monday
Make the ultimate playlist 3 hours Monday
Set up your sound system 1 hour Monday
Invite your friends 2 days Monday
Buy the food and drinks 1 day Tuesday
Cook your famous casserole 2 hours Wednesday
Host the party 2 hours Wednesday
Now if we add up all our critical tasks’ duration, we’ll get the approximate time
that we need to complete the whole project. In our case, 3 days and 6 hours, since
“make the ultimate playlist” and “set up the sound system” are not on the critical
path.
If we add the duration to the start time, we can calculate the earliest project
completion time. Understanding the CPM allows us to make this calculation quickly
and accurately.
Flexibility in the Critical Path Method

The critical path method was developed for complex, but predictable, projects.
However, in real life, we rarely get to manage such projects. A schedule generated
using critical path method techniques is often not followed precisely.
As we already mentioned, any delay of an activity on the critical path directly
impacts the completion date. New technical requirements may pop up, and new
resource constraints may emerge.
Let’s say you’re planning to redecorate your living room with a friend. Your task list
may look like this:
1. Get rid of the old furniture
2. Paint the walls
P a g e 13 | 54
3. Fix the ceiling

4. Install the new furniture
Your friend’s responsibilities are to:
1. Choose the new curtains
2. Hang the new curtains
Parallel Tasks in the Critical Path

In our example, the curtain tasks form a sub-project and can be treated as a non-
critical path. Your friend can “choose the new curtains” and “hang the new curtains”
any time before the end of your project.
The curtain tasks have flexibility in the start and end date, what is considered
“float.” These tasks are parallel and will not be placed on the critical path. Here’s
how this project would look on a Gantt chart:
If any of the parallel tasks were to be significantly delayed, it would prevent our
whole project from being completed on time. Therefore, you should always keep an
eye on parallel tasks.
Changes in the Critical Path

Now, let’s assume that choosing the curtains took our friend longer than we initially
expected. This will delay the end of the project:
P a g e 14 | 54
Our redecoration is incomplete without the new curtains, so the path that previously
was non-critical becomes critical. The initial critical path changes.
To keep an eye on your non-critical tasks, keep your project schedule up to date.
That’s the only way you’ll know exactly where your project is at any given moment
and whether it will be delivered as initially planned.
P a g e 15 | 54
Critical Chain Project Management (CCPM)

Managers use the CCPM methodology (an extension of CPM) to prioritize critical
resources. Though contractors on projects like home-building often run the risk of
certain teams waiting for others to finish, they must also time out the delivery of
critical supplies.
For example, a team leader might delay an order with a concrete company if they
experience delays while digging a foundation. If the cement workers were to arrive
and there was no place to pour concrete, they would have to dump their loads or
risk its setting inside their trucks!
To avoid bottlenecks and disruptions in the ordering of resources, managers put
time buffers around critical tasks. Though this slows down project completion slightly,
it dramatically reduces their risks of expensive resource re-orders.
These buffered tasks form a “critical chain” of the most sensitive tasks on a critical
path.
Critical Chain Project Management was developed and publicized by Dr. Eliyahu
M. Goldratt in 1997. I will provide a brief overview of the principles of Critical
Chain Project Management and its applicability to managing projects across all
organizations and industries.
The Critical Chain Method has its roots in another one of Dr. Goldratt’s inventions:
The Theory of Constraints (TOC).
This project management method gets applied after the initial project schedule is
prepared, which includes establishing task dependencies. The evolved critical path
is reworked based on the Critical Chain Method. To do so, the methodology
assumes constraints related to each task.
A Few of These Constraints Include
There is a certain amount of uncertainty in each task
Task durations are often overestimated by team members or task owners.

This is typically done to add a safety margin to the task to be certain of its
completion in the decided duration
P a g e 16 | 54
In most cases, the tasks should not take the time estimated, which includes the
safety margin, and should be completed earlier
If the safety margin assumed is not needed, it is wasted.
If the task is finished sooner, it may not necessarily mean that the successor
task can start earlier as the resources required for the successor task may not
be available until their scheduled time.
In other words, the saved time cannot be passed on to finish the project early.
On the other hand, if there are delays over and above the estimated
schedules, these delays will most definitely get passed on, and, in most cases,
will exponentially increase the project schedule.
With the above assumptions, the Critical Path Methodology of project management
recommends pooling of the task buffers and adding them at the end of the critical
path:
P a g e 17 | 54
Critical Chain Project Management Defines Three Types of Buffers

1. Project Buffer
The total pooled buffer depicted in the image above is referred to as the project
buffer.
2. Feeding Buffer
In a project network, there are path/s which feed into the critical path. The pooled
buffer on each such path represents the feeding buffer to the critical path (depicted
in the image below), resulting in providing some slack to the critical path.
3. Resource Buffer
This is a virtual task inserted just before critical chain tasks that require critical
resources. This acts as a trigger point for the resource, indicating when the critical
path is about to begin.
As the progress of the project is reported, the critical chain is recalculated. In fact,
monitoring and controlling of the project primarily focused on the utilization of the
buffers.
As you can see, the critical chain method considers the basic critical path based
project network and schedule to derive a completely new schedule.
The critical path project management methodology is very effective in
organizations which do not have evolved project management practices.
However, the methodology does not advocate multi-tasking, and in projects with
complex schedule networks, the results of implementing the critical path
methodology have proven to be a deterrent to the overall project schedule.
In addition, there is no standard method for calculating and optimizing the project
buffers. The critical path project management methodology has had a fair amount
of success in manufacturing; however, it has not achieved any noteworthy success in
the IT industry.
Along similar lines, the event chain methodology of project management focuses on
determining the uncertain events and the chain reactions they propagate.
P a g e 18 | 54
It is a method of modeling uncertainties and is based on Monte Carlo analysis,

Bayesian Belief Network, and other established simulation methodologies.
When they occur, events can cause other events, triggering an event chain, which
will effectively alter the course of the project.
Events and event chains are identified, and quantitative analysis is performed to
determine the extent of the uncertainty and the probable impact of the same on the
project.
From this exercise, critical event chains are derived, which have the potential to
impact the project significantly. Event chain diagrams are visual representations of
events, event chains, and their impact.
Neither the critical path project management methodology nor the event chain
methodology can be considered alternatives to the standard methodology for
project management as advocated by PMBOK.
While the critical path project management methodology can be at best used as a
tool for deriving project schedule networks, the event chain methodology for project
management can be used as a tool for quantitative risk analysis.
P a g e 19 | 54
Agile Project Management

What is Agile?
Agile is the ability to create and respond to change. It is a way of dealing with,
and ultimately succeeding in, an uncertain and turbulent environment.
The authors of the Agile Manifesto chose “Agile” as the label for this whole idea
because that word represented the adaptiveness and response to change which
was so important to their approach.
It’s about thinking through how you can understand what’s going on in the
environment that you’re in today, identify what uncertainty you’re facing, and
figure out how you can adapt to that as you go along.
A Short History of Agile

Here is a look at how Agile emerged, how it acquired the label Agile, and where it
went from there. It’s important to look at where Agile software development came
from to get an understanding of where things are at today.
Agile is a Mindset
Ultimately, Agile is a mindset informed by the values contained in the Agile
Manifesto and the 12 Principles behind the Agile Manifesto. Those values and
principles provide guidance on how to create and respond to change and how to
deal with uncertainty.
You could say that the first sentence of the Agile Manifesto encapsulates the whole
idea: “We are uncovering better ways of developing software by doing it and
helping others do it.”
When you face uncertainty, try something you think might work, get feedback, and
adjust accordingly.
Keep the values and principles in mind when you do this. Let your context guide
which frameworks, practices, and techniques you use to collaborate with your team
and deliver value to your customers.
P a g e 20 | 54
As Agile Software Development became more popular, people that were involved
with software development activities but who didn’t personally develop software
looked for some way to figure out how these Agile ideas applied in their line of
work.
The Agile Manifesto and the 12 Principles were written by a group of software
developers (and a tester) to address issues that software developers faced. When
you think of Agile as a mindset, that mindset can be applied to other activities.
When you do that, Agile becomes an adjective. It describes the way in which you
perform some activity. It does not create a new methodology for the reasons
explained above.
Agile project management answers the question “How might we perform project
management in a way that allows us to create and respond to change and deal
with uncertainty?”
Agile software development is an umbrella term for a set of frameworks and
practices based on the values and principles expressed in the Manifesto for Agile
Software Development and the 12 Principles behind it.
When you approach software development in a particular manner, it’s generally
good to live by these values and principles and use them to help figure out the right
things to do given your context.
What are Agile Methodologies?
If Agile is a mindset, then what does that say about the idea of Agile
methodologies? To answer this question, you may find it helpful to have a clear
definition of methodology.
Alistair Cockburn suggested that a methodology is the set of conventions that a
team agrees to follow.
That means that each team is going to have its own methodology, which will be
different in either small or large ways from every other team’s methodology.
So Agile methodologies are the conventions that a team chooses to follow in a way
that follows Agile values and principles.
P a g e 21 | 54
A group of software development experts developed the basics of the Agile

System just over 15 years ago. They created a new way to deliver value to and
interact with consumers that featured four key aspects:
Project managers must value individual interactions over systems and tools
Software should work well and not require extensive documentation
Teams and customers should collaborate, not haggle over contracts
Companies must prioritize responsiveness over rigid adherence to plans.

What is Agile Software Development?
Agile software development is more than frameworks such as Scrum, Extreme
Programming or Feature-Driven Development (FDD).
Agile software development is more than practices such as pair programming, test-
driven development, stand-ups, planning sessions and sprints.
Maybe you thought Scrum and XP were Agile methodologies?
Alistair applied the term framework to those concepts. They certainly were born
from a single team’s methodology, but they became frameworks when they were
generalized to be used by other teams.
Those frameworks help to inform where a team starts with their methodology, but
they shouldn’t be the team’s methodology. The team will always need to adapt its
use of a framework to fit properly in its context.
In just a short time, PM experts have expanded these concepts into many
implementation frameworks, including:
Scrum Project Management
Kanban Project Management
Extreme Programming
Adaptive Project Framework (APF)

P a g e 22 | 54
Though the linear Waterfall PM strategy suits many organizations, managers in

certain fields find it quite limiting. By planning only at the beginning of a project,
they lose the benefit of the knowledge and experience they gain while completing
it.
Instead of creating detailed specifications for end products at the beginning of an
endeavor, Agile managers only identify priorities.
As their teams work towards their goals, these managers remain flexible,
communicate with all stakeholders, and change product requirements whenever
necessary.
One thing that separates Agile from other approaches to software development is
the focus on the people doing the work and how they work together. Solutions
evolve through collaboration between self-organizing cross-functional teams
utilizing the appropriate practices for their context.
There’s a big focus in the Agile software development community on collaboration
and the self-organizing team.
That doesn’t mean that there aren’t managers. It means that teams can figure out
how they’re going to approach things on their own.
It means that those teams are cross-functional. Those teams don’t have to have
specific roles involved so much as that when you get the team together, you make
sure that you have all the right skill sets on the team.
The Project Manager

There still is a place for managers. Managers make sure team members have, or
obtain, the right skill sets. Managers provide the environment that allows the team
to be successful.
Managers mostly step back and let their team figure out how they are going to
deliver products, but they step in when the teams try but are unable to resolve
issues.
When most teams and organizations start doing Agile software development, they
focus on the practices that help with collaboration and organizing the work, which is
great.
P a g e 23 | 54
However, another key set of practices that are not as frequently followed but
should be specific technical practices that directly deal with developing software in
a way that help your team deal with uncertainty. Those technical practices are
essential and something you shouldn’t overlook.
The Agile PM methodology suits businesses that seek to quickly and consistently
provide products to consumers. Software development companies prefer this “light-
touch” management style which facilitates rapid production cycles.
With this system, team leaders can create responsive and transparent workplace
cultures. By sharing responsibility with their team members, they can optimize their
awareness of and reactivity to market trends and changes in demand.
Agile teams work in short “sprints” or burst of work. Team leaders quantify each of
these sprints as small, deliverable units. Teams stay motivated by working on series
of small, fast projects (such as software updates) and tracking their progress.
Companies increase their responsiveness to customer demands and changes in the
marketplace. Software companies, for example, create Agile teams to rapidly
adjust their offerings to new challenges like emerging platforms and operating
system updates.
What about Business Agility?

The two concepts noted above are examples of an attempt to move Agile “outside
of software.” Those efforts have resulted recently in the Business Agility movement.
If you extend the idea of Agile as a mindset, then people seeking Business Agility
ask themselves, “How might we structure and operate our organization in a way
that allows us to create and respond to change and deal with uncertainty?”
You might say that business agility is a recognition that for people in an
organization to operate with an Agile mindset, the entire organization needs to
support that mindset.
Agile software development was never truly Agile until the organization changed its
structure and operations to work in an uncertain environment.
P a g e 24 | 54
Agile Project Management: Scrum

For those of you not raving rugby fans, a scrum is a tangle of heavy people who
strain against each other to acquire a small, oblong, whitish ball. As business
managers find such behavior undesirable in production teams, they employ the
Scrum method of project management.
Scrum teams meet for monthly Scrum sessions in which they break down their
projects and deliverables into 15- or 30-day chunks, called “sprints.”
By working toward these small increments, teams avoid the process overwhelm
typical of other PM methodologies.
By re-prioritizing their efforts each month to meet consumer demand, they can stay
flexible and motivated – increasing both productivity and customer satisfaction!
What is Scrum Project Management?

You will use Scrum Project Management to Deliver Working Products with More
Business Value
Scrum project management is a methodology for managing software delivery that
comes under the broader umbrella of agile project management.
It provides a lightweight process framework that embraces iterative and
incremental practices, helping organizations deliver working software more
frequently.
Projects progress via a series of iterations called sprints; at the end of each sprint
the team produces a potentially deliverable product increment.
Understanding the Value of Scrum Project Management

Scrum is a proven and widely adopted method for achieving software agility. By
working in short sprints, this iterative cycle can be repeated until enough work items
have been completed, the budget is depleted, or a deadline arrives. Project
impetus is maintained, and when the project ends Scrum ensures that the most
valuable work has been completed.
P a g e 25 | 54
This contrasts sharply to the more traditional waterfall style approach that fixes the
project scope upfront, requiring the extensive creation of requirements, analysis and
design documentation before development can get started.
Delays and budget overruns are common, and the failure to prioritize the feature
set often results in low quality products that are overloaded with features that the
customer/user does not actually require
Development teams often apply the popular Scrum variation of Agile Project
Management. Managers find Scrum easy to implement and very effective in
addressing issues affecting software development teams.
Team members enjoy the way Scrum helps them untangle complex development
cycles, redefine end goals during a project cycle, and get quality products to
market very quickly.
In this system, no one holds the title of “project manager.” Instead, they split up their
responsibilities by taking on certain roles: ScrumMaster, product owner, and team
member:
P a g e 26 | 54
Scrum Master
The ScrumMaster (despite their impressive-sounding title) does not take on the title
of manager or team leader. This person oversees the Scrum process, not the job
itself. They ensure everyone on the team communicates well on daily projects,
eliminates distractions, and clears obstacles in the group’s path.
The ScrumMaster is responsible for implementing the Scrum. A ScrumMaster differs
from a traditional project manager in that the ScrumMaster does not provide day-
to-day direction to the team and does not assign tasks to individuals.
A key part of this role is to remove impediments or issues that might slow the team
down or stop activity that moves the project forward.
Product Owner
This person, either a key user or a marketing expert, gives the team a consistent
vision of their initial goal: to meet customer needs. Because a team’s concept of their
end-product can change as they work, the Product Owner performs a vital
“grounding” function.
The Product Owner serves as the customer proxy and is responsible for representing
the interests of the stakeholders and ensuring that the product backlog remains
prioritized.
Specialist Team Member

Teams meet daily to discuss their completed work and identify any roadblocks to
further progress. The Scrum Master agrees to deal with these roadblocks; the
Product Owner collaborates with the team to optimize product targeting.
The Scrum Method works best for small teams that work together in one environment
and focus on only one project at a time. It facilitates open communication and
creativity, as well as rapid development/testing cycles.
Scrum works especially well when teams have substantial support from upper
management, in the form of open financial and time budgets.
P a g e 27 | 54
The Team is made up of a cross-functional group of 5-9 members who are

responsible for developing the product. Scrum teams are self-organized will all
members collectively responsible for getting the work done.
How Does Scrum Project Management Work?

The Scrum approach to project management enables software development
organizations to prioritize the work that matters most and break it down into
manageable chunks.
Scrum is about collaborating and communicating both with the people who are
doing the work and the people who need the work done. It’s about delivering often
and responding to feedback, increasing business value by ensuring that customers
get what they want.
Shifting from traditional project management approaches to Scrum project
management requires an adjustment in terms of the activities that are carried out,
the artifacts that are created and the roles within the project team:
Activities in Scrum Project Management

The main activity in Scrum project management is the Sprint, a time boxed iteration
that usually lasts between 1-4 weeks, with the most common sprint length being 2
weeks.
P a g e 28 | 54
Sprint Planning Meeting: at the start of each sprint a planning meeting is held
to discuss the work that is to be done. The product owner and the team meet
to discuss the highest-priority items on the product backlog.
Team members figure out how many items they can commit to and then
create a sprint backlog, which is a list of the tasks to complete during the
sprint
Daily scrum or daily standup: each day during the sprint team members
share what they worked on the prior day, will work on today, and identify
any impediments.
Daily scrums serve to synchronize the work of team members as they discuss
the work of the sprint. These meetings are time boxed to no more than 15
minutes.
Sprint Review: at the end of a sprint the team demonstrates the functionality
added during the sprint. The goal of this meeting is to get feedback from the
product owner and any users or other stakeholders who have been invited to
the review.
Sprint Retrospective: at the end of each sprint the team participates in a

retrospective meeting to reflect on the sprint that is ending and identify
opportunities to improve in the new sprint.
Artifacts in Scrum Project Management

Scrum Project Management requires very few artifacts, concentrating instead on
delivering software that produces business value. The main artifacts in Scrum are:
Product Backlog: this is a complete list of the functionality that remains to be
added to the product. The product backlog is prioritized by the product
owner so that the team always works on the most valuable features first
Sprint Backlog: this is a prioritized list of tasks the team needs to complete
during the sprint
P a g e 29 | 54
Burndown charts: these are used to show the amount of work remaining in a
sprint and provide an effective way to determine at a glance whether a
sprint is on schedule to have all planned work finished.
What You Need to Manage a Scrum Project

Many teams start out using spreadsheets to manage the product backlog and task
boards to see and change the state of tasks during the current sprint, often with a
whiteboard and sticky notes.
This approach tends to work well for small, co-located teams. However, as the
backlog increases, and remote members require project visibility many
organizations implement a more sophisticated tool to centrally manage projects and
enable cross-team collaboration.
P a g e 30 | 54
Blending Agile and Kanban:

Originally developed by Toyota in the 1940s, Kanban means “signal card” in
Japanese. This method relied on Kanban cards, which indicate the need to reorder
certain supplies.
Many managers consider Kanban a Lean Manufacturing system because it
eliminates wasted time and resources. In short, Kanban makes companies “lean and
mean.”
Many project managers use Kanban concepts in conjunction with Agile methods. The
genius of Kanban is “on-demand” production, in which customer orders “pull” items
through a production facility.
This idea replaces the traditional method of producing large amounts of products
and warehousing them in anticipation of an estimated demand. In a software
development setting, this idea of customer demand powering a system fits hand in
glove with Agile.
In the workplace, Kanban teams originally visualized their workflow as cards
moving from left to right across a Kanban board. They grouped tasks and projects
into broad categories:
• In Queue (To Do)
• In Progress
• Recently Completed
Modern Agile/Kanban managers use virtual “cards’ to represent units of work
flowing through their systems. By engaging visually with their workflow, team
members and managers can easily estimate and prioritize upcoming tasks.
P a g e 31 | 54
When assigning new tasks (inspired by customer demand), executives use Kanban
boards to assess a team’s current workload. They can easily estimate the effects
additional tasks would have on a team’s current productivity.
The Agile/Kanban hybrid project management methodology works best for small
teams that work in a single, shared location. Even people who work independently
find this PM method useful.
P a g e 32 | 54
Extreme Programming (XP)

Like all Agile systems, Extreme Programming focuses on teamwork and customer
satisfaction. It features five basic tenets:
Communication
Simplicity
Feedback
Respect
Courage
Extreme Programming teams work in shorter sprints typical for Agile/Scrum

companies. These shorter cycles allow them to maintain rigid task structures. EP
teams don’t embrace as much flexibility as other Agile teams, undertaking tasks in a
strict priority order.
The EP methodology mandates specific engineering practices such as test-driven

product development, automated testing, simple and elegant design, refactoring,
etc.
Experts recommend teams begin with Scrum and adopt EP slowly as they determine
their own best practices and engineering protocols.
The first Extreme Programming project was started March 6, 1996.
P a g e 33 | 54
Extreme Programming is one of several popular Agile Processes. It has already

been proven to be very successful at many companies of all different sizes and
industries worldwide.
Extreme Programming is successful because it stresses customer satisfaction. Instead
of delivering everything you could possibly want on some date far in the future this
process delivers the software you need as you need it.
Extreme Programming empowers your developers to confidently respond to
changing customer requirements, even late in the life cycle.
Extreme Programming emphasizes teamwork - managers, customers, and
developers are all equal partners in a collaborative team.
Extreme Programming implements a simple, yet effective environment enabling
teams to become highly productive. The team self-organizes around the problem to
solve it as efficiently as possible.
Extreme Programmers constantly communicate with their customers and fellow
programmers. They keep their design simple and clean. They get feedback by
testing their software starting on day one.
They deliver the system to the customers as early as possible and implement
changes as suggested.
Every small success deepens their respect for the unique contributions of every team
member. With this foundation Extreme Programmers can courageously respond to
changing requirements and technology.
The most surprising aspect of Extreme Programming is its simple rules. Extreme
Programming is a lot like a jigsaw puzzle. There are many small pieces.
The rules may seem awkward and perhaps even naive at first, but are based on
sound values and principles and when combined together forms the complete
picture.
The rules set expectations between team members but are not the end goal
themselves. You will come to realize these rules define an environment that
promotes team collaboration and empowerment, that is your goal.
P a g e 34 | 54
Once achieved productive teamwork will continue even as rules are changed to fit
your company's specific needs.
This flow chart shows how Extreme Programming's rules work together:
Customers enjoy being partners in the software process, developers actively

contribute regardless of experience level, and managers concentrate on
communication and relationships.
Unproductive activities have been trimmed to reduce costs and frustration of
everyone involved.
P a g e 35 | 54
Agile Project Management: Adaptive Project Framework (APF)

The Adaptive Project Framework allows Agile teams to work with optimal flexibility
and epitomize the idea of “agility.” Sometimes teams must improvise their systems
and protocols as they work, due to high-level goals and outcomes.
The APF framework best suits unique challenges which don’t call for one size fits all
solutions. This approach empowers teams because they aren’t expected to blindly
follow pre-ordained scripts.
In this model, clients work directly with Agile teams and select the exact features
they need in finished products. Consumers appreciate not having to accept products
that meet some, but not all, of their needs.
The Benefits of APF

Here are the 15 most important reasons for using APF. If these reasons resonate
with you, it's time to switch to APF:
The approach thrives on change rather than avoiding it
APF is used on projects whose solution isn't known but must be discovered. Through
successive iterations, the project manager and the business analyst collaborate to
learn and discover the complete solution and deliver expected business value.
The approach is not a "one size fits all" approach
Projects are unique. No one would argue that. So why isn't the approach to
managing them unique? APF adapts to the project's characteristics.
The approach utilizes just-in-time planning
Developing a complete plan when change is a certainty makes no sense. When in
doubt, leave it out, and only plan what you know to be part of the final
deliverable.
The approach is based on the principle that you learn by doing
The solution must be learned and discovered, and that's where the real value of
APF is found. It utilizes concurrent probative and integrative swim lanes to learn and
discover the solution.
P a g e 36 | 54
The approach guarantees "If we build it, they will come."

At the completion of each iteration, APF delivers the best solution possible given the
time and money invested to that point. The solution is continuously aligned to true
client needs.
The approach seeks to get it right every time
Once the client is certain that a function or feature will be part of the final solution,
that function or feature is integrated into the then-solution. At the completion of
each iteration, the then-solution, even though it's still incomplete, can be
implemented because it has been vetted by the client as aligned to the client's
needs.
The approach adjusts immediately to changing business conditions
Between iterations, the business analyst and the project manager review what has
been done and how the business situation may have changed to require an
adjustment in the future iterations.
The approach is client-focused and client-driven
Meaningful client involvement is essential for any Agile project to succeed. The client
(perhaps through its BA) is the co-PM along with the PM. This design creates client
ownership and a vested interest in the success of the project.
The approach is grounded in a set of immutable core values:
Client-focused
Client-driven
Incremental results early and often
Continuous questioning and introspection
Change is progress to a better solution
Don't speculate on the future
The approach assures maximum business value
P a g e 37 | 54
The client (or its BA) is empowered to choose what goes into the solution and what
doesn't, using any desired criteria. Presumably the criterion is to do whatever
maximizes expected business value.
The approach squeezes out all the non-value-added work
APF doesn't waste time by speculating on the future. If there is any doubt about a
specific function or feature being part of the final solution, it's not integrated into
the solution until that doubt is removed.
The approach fully engages the client as the primary decision maker
The client is responsible for successful project completion. The role of the PM is to
keep the client pointed in feasible directions. The PM does this by presenting the
client with only feasible alternatives and letting the client choose.
The approach creates a shared partnership with shared responsibility
Attaining and maintaining client involvement and ownership of the project and its
deliverables is the key determinant of the success of an APF effort.
The approach empowers the team
The team may start out much like a herd of cats, but through the active participation
of the client and the BA it quickly forms into a "lean, mean fighting machine." The
motivation to succeed where others may have failed is the kind of challenge to
which technical professionals respond.
The approach works 100% of the time - no exceptions!
The APF project is either terminated early because the direction chosen by the client
or BA is not converging on an acceptable solution, or a different approach is
discovered during iteration. That arrangement frees the project resources (time,
money, and people) to redirect the project toward a more likely solution.
P a g e 38 | 54
Rapid Applications Development (RAD)

Another project management methodology preferred by software development
teams; the Rapid Application Development model facilitates interaction via certain,
structured techniques.
The term was inspired by James Martin, who worked with colleagues to develop a
new method called Rapid Iterative Production Prototyping (RIPP). In 1991, this
approach became the premise of the book Rapid Application Development.
Martin's development philosophy focused on speed and used strategies such as
prototyping, iterative development and time boxing. He believed that software
products can be developed faster and of higher quality through:
Gathering requirements using workshops or focus groups
Prototyping and early, reiterative user testing of designs
The re-use of software components
A rigidly paced schedule that defers design improvements to the next

product version
Less formality in reviews and other team communication

RAD teams create prototypes to determine user needs and redefine their designs.
They repeat this cycle many times throughout the development process to optimize
product quality and user experience.
RAD teams move quickly, putting off large design improvements to future
production/software update cycles. These nimble organizations often re-use
components of other software systems to focus on immediate customer demands.
RAD managers focus on consumer data gathered from focus groups and workshops
to rapidly deliver desirable products.
The RAD method works best for teams that don’t require long interactions and deep
development of complex functions.
P a g e 39 | 54
In software development, rapid application development (RAD) is a concept which

emphasizes working on software and being more adaptive than older development
methods.
RAD was born out of frustration with the waterfall software design approach which
too often resulted in products that were out of date or inefficient by the time they
were released.
RAD usually embraces object-oriented programming methodology, which inherently
fosters software re-use.
The most popular object-oriented programming languages, C++ and Java, are
offered in visual programming packages often described as providing rapid
application development.
Rapid application development is still in use today and some companies offer
products that provide some or all of the tools for RAD software development. (The
concept can be applied to hardware development as well.)
These products include requirements gathering tools, prototyping tools, computer-
aided software engineering tools, language development environments such as
those for the Java platform, groupware for communication among development
members, and testing tools.
P a g e 40 | 54
New Product Introduction (NPI)

Business leaders use the NPI methodology to focus on certain steps of a task, not the
management of entire projects. For example, NPI teams don’t spend time creating
Work Breakdown Structures (WBS) and mapping out tasks and budget allocations
across vast, complicated projects.
Instead, they focus on communication with all stakeholders in a project – both inside
and outside of an organization.
The NPI project management strategy works best for product-based teams because
NPI managers shepherd single products through their entire development process.
These managers create teams from all sectors of an organization involved in
creating a new product. With their teams, they guide and shape a product all the
way through to its launch.
P a g e 41 | 54
Packaged Enabled Reengineering (PER)

Project leaders use the PER project management methodology to redesign a
product or system from the ground up.
By taking a fresh look at a company’s offerings and redesigning them completely,
PER teams can shed outdated assumptions and organizational habits.
PER managers help organizations stay true to their commitment to growth with
regular reviews of the modification process.
They create and maintain corporate cultures of innovation and help their colleagues
let go of old ways of doing things.
With the potent PER method, companies can change rapidly to address changes in
consumer demand and maximize their returns on investment.
In the software industry, package-enabled design project management focuses on a
software package original functionality as the framework to rethink the design. It
relies on challenging current practices to identify new systems for processing.
Package enabled design requires analysis of current processes, design, structure,
and management and aims to replace inefficiencies wherever identified.
PER Advantages
Optimize Existing Processes: Package Enable Design provides a framework for
reengineering current processes and reconfiguring products into a new design.
PER Disadvantages
Focused on inefficient processes: This process is best used in project management
that needs to rethink current processes. It is not best for business environments that
are already operating efficiently.
Who and When should use it?
Project managers looking to redesign a current product or process could benefit
from Package Enabled Design. When the need for reengineering or rethinking
business processes identify themselves, Package Enabled Design may be used.
P a g e 42 | 54
PRINCE2
Not to be confused with the PMBOK, the Project Management Institute’s Project
Management Body of Knowledge (a best-practices resource), PRINCE2 is a
complete project methodology system.
PRINCE2 is a framework for delivering successful projects and is not a ‘how to
become a project manager’ type of method (even thought it lays out clear advice
for the role of project manager)
Used by the U.K. government and many private-sector organizations across the
globe, PRINCE2 has much to offer U.S. organizations:
Greater Resource Control
Increased Project Risk Management
Clear and Structures Responsibility Allocation
A focus on End-User “Who, When, and Why”
Consistent, Organized Planning and Execution
Regular Review Justification Cycles
Most of the people involved in the project management world certainly know what
Prince2 means. The methodology is widely used in many industries.
Perhaps there are those for whom there will be a discovery that a structured project
management methodology PRINCE2 literally means PRojects IN Controlled
Environments. This is a well-known process-based method for effective project
management.
The methodology is free for using that is why PRINCE2 is so popular nowadays.
Then the approach was renamed and the acronym for “PRojects IN Controlled
Environments” started to be official. The method became regularly applied outside
the IT environment all over the world.
P a g e 43 | 54
PRINCE2 roles
To deliver the project according to the Prince2 you will need the following roles in
your team:
• A Project Manager who is responsible for allocating work, planning, ensuring

the work is done, ensuring all the processes are completed on-time, etc.
The project manager that manages a PRINCE2 project has quite similar
responsibilities as a PM in other project management methodologies. The main
difference is that the Prince2 PM reports on project status to a Project Board. The
Project Board includes the Customer, User, and Supplier.
Customer is a person or a company that pays for the project
User is a person or a company that uses the project’s outcome
Supplier (specialist) who is responsible for creating the project outcome
P a g e 44 | 54
7 Principles provided by PRINCE2
There are 7 key principles that form the basis of PRINCE2. They cannot be tailored.
If a project doesn’t adhere to these principles, we cannot say about managing it
according to PRINCE2:
Continued business justification. This critical document is being updated at

every project stage It ensures that the project is still viable
Learn from experience. The main thing here is to avoid reinventing wheels
that’s why every project maintains a lessons log. Projects should continually
refer to their own and to previous and concurrent projects’ lesson logs
Defined roles that are structured in PRINCE2 methodology in 4 levels:

corporate or program management, project board, project manager level,
and team level
Managing by stages. In PRINCE2 projects are planned and controlled stage

by stage
Managing by exception. If a management level forecasts that 6 tolerances

(scope, timescale, risk, quality, benefits, cost) are exceeded, it is escalated to
the next level for a decision how to proceed
Focus on products, on their delivery, and their quality
Tailor to suit project environment. The methodology is adapted to suit the

project environment, its complexity, importance, size, time capability, and
risks.
P a g e 45 | 54
However, not all methodology’s aspects can be applicable to any project. Every
single project has own notes on scalability.
The SEVEN processes in the PRINCE2 methodology
The following processes are applied in the PRINCE2 methodology:
Directing a project that includes the procedures, which enable the Project
Board to be sure, that projects proceed as planned
Starting a project with all procedures that initiate a project process (including
developing the Initiation Stage Plan)
Initiating a project with all corresponding procedures resulting in assembling

The Project Initiation Documentation (PID)
Managing stage boundaries. This process allows the Project Board to make
key decisions
Controlling a stage includes procedures for tracking and controlling projects
Managing product delivery with the procedures that ensure the planned
products are created as planned
Closing a project. How to perform a controlled shut down of your project.
What are the benefits?
The big family of project management methodologies consists of many different

members and each method has its own advantages and benefits.
P a g e 46 | 54
You may be a real fan of Scrum or Kanban, apply Extreme Programming or

Waterfall, or be fond of any other PM approach. PRINCE2 provides a systematic
way to execute a project, it ensures that you meet the project goals in a logical and
systematic way.
Besides its relative simplicity, PRINCE2 has the following benefits:
It is product-based and divides projects into different stages making it easy

to manage
It improves communication between all team members and with external

stakeholders
It gives stakeholder a chance to have a say when it comes to decision making
PRINCE2 provides a consistent approach
It focuses on business justification
It provides the greater control on the plan by regular reviews of project

progress
It implicates detailed competencies according to the role being played in the

project
PRINCE2 is adaptable and can be tailored for all project types no matter what
industry and marketplace you represent. And it looks like the most significant key to
success and explains the popularity of this project management methodology.
P a g e 47 | 54
Choosing and implementing the method is more than training staff. Applying
PRINCE2 is about setting project management best practice and getting all its
benefits through the improved project management.
P a g e 48 | 54
Six Sigma
The Motorola company originally developed the highly disciplined Six Sigma
system to eliminate defects. They wanted their products and services to conform
completely to their original specifications throughout the entire design, production,
and delivery process.
Some experts consider Six Sigma more of a quality-control and apparatus than a
true project management methodology, due to its focus on gathering data and
improving processes. Companies typically use this method to increase efficiency,
raise productivity, and deliver uniform products to consumers.
Six Sigma Managers use 5 process steps, collectively called DMAIC-S:

Define customer needs. By identifying and profiling ideal customers and
understanding how to serve them, managers can shape the scope and
purpose of a project
Measure the performance of a process. By creating appropriate metrics for

gathering data on productivity, managers can determine how well a system
meets consumer needs
P a g e 49 | 54
Analyze common problems. Six Sigma managers examine performance gaps

to determine their root causes and back up their observations with hard data
Improve systems. Managers design, test, and execute new systems to address
the root causes of systemic problems. They continue to rely on data in their
evaluations of these solutions (and the implementation of these fixes)
Synergize these results throughout the company. Six Sigma managers know
that changes to one area of operations affect all other parts of a business, to
some degree. They share the experience and knowledge they have gained
from an optimization cycle with their colleagues and supervisors.
Some managers follow the DMAIC method without employing the entire Six Sigma
management strategy. They use this data-driven method to improve, optimize, and
stabilize their designs, processes, and systems.
Six Sigma – what does it mean?

“Six Sigma is a quality program that, when all is said and done, improves your
customer’s experience, lowers your costs, and builds better leaders. — Jack Welch
Six Sigma at many organizations simply means a measure of quality that strives for
near perfection. It can be called “Six Sigma,” or it may have a generic or
customized name for the organization like “Operational Excellence,” “Zero
Defects,” or “Customer Perfection.”
Six Sigma is a disciplined, data-driven approach and methodology for eliminating
defects (driving toward six standard deviations between the mean and the nearest
specification limit) in any process – from manufacturing to transactional and from
product to service.
The statistical representation of Six Sigma describes quantitatively how a process is
performing. To achieve Six Sigma — statistically — a process must not produce
more than 3.4 defects per million opportunities.
A Six Sigma defect is defined as anything outside of customer specifications. A Six
Sigma opportunity is then the total quantity of chances for a defect. Process sigma
can easily be calculated using a Six Sigma calculator.
P a g e 50 | 54
The fundamental objective of the Six Sigma methodology is the implementation of a

measurement-based strategy that focuses on process improvement and variation
reduction through the application of Six Sigma improvement projects.
This is accomplished using two Six Sigma sub-methodologies: DMAIC and DMADV.
The Six Sigma DMAIC process (define, measure, analyze, improve, control) is an
improvement system for existing processes falling below specification and looking
for incremental improvement.
The Six Sigma DMADV process (define, measure, analyze, design, verify) is an
improvement system used to develop new processes or products at Six Sigma
quality levels. It can also be employed if a current process requires more than just
incremental improvement.
Both Six Sigma processes are executed by Six Sigma Green Belts and Six Sigma
Black Belts and are overseen by Six Sigma Master Black Belts.
According to the Six Sigma Academy, Black Belts save companies approximately
$230,000 per project and can complete four to six projects per year.
(Given that the average Black Belt salary is $80,000 in the United States, that is a
fantastic return on investment.)
General Electric, one of the most successful companies implementing Six Sigma, has
estimated benefits on the order of $10 billion during the first five years of
implementation.
GE first began Six Sigma in 1995 after Motorola and Allied Signal blazed the Six
Sigma trail. Since then, thousands of companies around the world have discovered
the far-reaching benefits of Six Sigma.
Many frameworks exist for implementing the Six Sigma methodology. Six Sigma
Consultants all over the world have developed proprietary methodologies for
implementing Six Sigma quality, based on the similar change management
philosophies and applications of tools.
P a g e 51 | 54
Lean Six Sigma

Lean focusses Focus on visual management a prescriptive approach, whereas Six
sigma focusses on process centricity and an analytic approach
A combined management approach, LSS (Lean Six Sigma) amplifies the strengths
and minimizes the weaknesses of both approaches when used alone:
Customer Satisfaction
Employee growth
Profitability
Increased Revenues
P a g e 52 | 54
Outcome Mapping
The International Development Research Center (IDRC) developed the outcome
mapping project management methodology. Many charitable organizations which
bundle large donations into grants for developing countries use this system.
With the Outcome Mapping PM methodology, charities can measure the effects of
their efforts on secondary beneficiaries.
They take care to ensure that the recipients of large grants create benefits for
large groups of people and facilitate positive behavior changes.
Organizations that use this PM methodology divide their tasks into two distinct
phases:
Design– Project leaders write essays in which they identify their direct
partners (governments and local organizations who receive funds) and
indirect partners (people in need who receive benefits).
They determine progress markers, appropriate actions for partners to take,

and suitable metrics for later record-keeping
Record-Keeping – Outcome mapping organizations keep three types of

journals: performance (meeting minutes and organizational progress),
strategy (tasks completed in the overall plan), and outcomes (realization of
stated goals and desired results).
Outcome mapping works best for groups that contribute to others instead of
creating products and services. Organizations outside the philanthropy sector rarely
use this PM methodology.
P a g e 53 | 54
Project Management Professional (PMP)

The Project Management Professional (PMP) is the most important industry-
recognized certification for project managers.
You can find PMPs leading projects in nearly every country and, unlike other
certifications that focus on a geography or domain, the PMP is truly global. As a
PMP, you can work in virtually any industry, with any methodology and in any
location.
Among survey respondents to PMI’s Earning Power Salary Survey, those with a PMP
certification garner a higher salary (20% higher on average) than those without a
PMP certification.
Employers benefit as well. When more than one-third of their project managers are
PMP-certified, organizations complete more of their projects on time, on budget
and meeting original goals.
The PMP signifies that you speak and understand the global language of project
management and connects you to a community of professionals, organizations and
experts worldwide. Become a PMP and become a project hero.
In an increasingly projectized world, PMI professional certification ensures that
you’re ready to meet the demands of projects and employers across the globe.
Developed by practitioners for practitioners, our certifications are based on
rigorous standards and ongoing research to meet the real-world needs of
organizations.
With a PMI certification behind your name, you can work in virtually any industry,
anywhere in the world, and with any project management methodology.
The PMP is the gold standard of project management certification. Recognized and
demanded by organizations worldwide, the PMP validates your competence to
perform in the role of a project manager, leading and directing projects and teams.
Check out our range of project management related online

training https://www.projex.com/courses HERE!
P a g e 54 | 54

Project Management Methodologies Senior Managers Need

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management Methodologies Senior Managers Need

Uploaded by

Copyright:

Available Formats

Methodologies Senior Project

Managers Need in 2020

Grow Your Career

Senior Managers Project Management Overview

Check out our range of project management related online

Predictive (Waterfall) Project Management

The Waterfall Process

The waterfall model is a linear, sequential approach to the software development

Waterfall model Advantages

It forces a structured and disciplined organization

It is simple to understand, follow and sequence tasks

Waterfall facilitates departmentalization and managerial control based on

Waterfall allows for early design or specification changes to be made easily

Waterfall clearly defines milestones and deadlines.

Disadvantages of the waterfall model

It ignores the potential to receive mid-process user or client feedback and

Delays testing until the end of the development life cycle

Does not consider error correction

Reduces efficiency by not allowing processes to overlap

Critical Path Method (CPM)

Critical path method (CPM) is a resource-utilization algorithm for scheduling a set of

Using the Critical Path Method in a Project

1. Define the project scope

TASK NAME Dependent on

What Are Resource Constraints and Why Do They Matter?

Task Duration Start

Flexibility in the Critical Path Method

3. Fix the ceiling

Parallel Tasks in the Critical Path

Changes in the Critical Path

Critical Chain Project Management (CCPM)

Task durations are often overestimated by team members or task owners.

If the safety margin assumed is not needed, it is wasted.

Critical Chain Project Management Defines Three Types of Buffers

It is a method of modeling uncertainties and is based on Monte Carlo analysis,

Agile Project Management

A Short History of Agile

A group of software development experts developed the basics of the Agile

Software should work well and not require extensive documentation

Teams and customers should collaborate, not haggle over contracts

Companies must prioritize responsiveness over rigid adherence to plans.

Kanban Project Management

Adaptive Project Framework (APF)

Though the linear Waterfall PM strategy suits many organizations, managers in

The Project Manager

What about Business Agility?

Agile Project Management: Scrum

What is Scrum Project Management?

Understanding the Value of Scrum Project Management

Specialist Team Member

The Team is made up of a cross-functional group of 5-9 members who are

How Does Scrum Project Management Work?

Activities in Scrum Project Management

Sprint Retrospective: at the end of each sprint the team participates in a

Artifacts in Scrum Project Management

What You Need to Manage a Scrum Project

Blending Agile and Kanban:

Extreme Programming (XP)

Extreme Programming teams work in shorter sprints typical for Agile/Scrum

The EP methodology mandates specific engineering practices such as test-driven

Extreme Programming is one of several popular Agile Processes. It has already

Customers enjoy being partners in the software process, developers actively