Methodologies Senior Project Managers Need

Methodologies Senior Project
Managers Need
Grow Your Career

with these Project
Management Projex Academy
Grow Your Career
Methodologies
Methodologies Senior Project Managers Need in 2023 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
P a g e 2 | 65
The Best Project Management Methodologies for 2023
Projects are simply a method for managing and delivering change, so

selecting the project management methodology that is right for you
(for a specific project of course), will ensure you deliver your project
to a successful conclusion and outcome.
Traditional methodologies tend to be plan-driven, that is, where

requirements need to be defined up front and a detailed plan created
to deliver against. Such a method is delivered against the series of
management stages and gate reviews.
As each gate review is passed, the project cannot return to the

previous stage or phase. And like the fact that water cannot flow
uphill, only down, this is also known as the waterfall project method.
Back in the 1990s a different approach was envisaged and techniques

such as rapid application development (RAD), and just in time (JIT),
evolved into what is known today as agile and lean methods.
Methodologies can also be known as frameworks since they support

the processes and tools used.
Traditional waterfall methods are more suited to projects that need

firm foundation and strict change control, they are typically used in
industries such as construction.
Whereas agile methods are more suited for when the project product
or service is based on knowledge work, where the solution would
normally be arrived at by iterative and incremental approaches. It
would be helpful to consider the way in which an artist paints a
picture as being agile.
The artist would first sketch and pencil the main outline of the
intended painting, start to fill in some detail, modify as they
proceeded, and gradually the finished painting would evolve.
P a g e 3 | 65
While it can be daunting at first to understand how to apply a
methodology, it will result in a far more successful project. Projects
can come in all shapes and sizes and across many different industries.
Some are simple, some are complex, some are business critical, some
are high or low risk and so on.
No matter which types you are dealing with, projects which are
successful have been found to use a common and consistent project
management approach.
For the rest of this blog, I will provide you with a clear distinction
between the different types of project management methodologies
and their frameworks.
Are you a practising project manager or are you moving into the
profession? No matter which, it should be an easy logical choice of the
methodology to use.
So, I have pulled together a list of different project management

methodologies so you can determine which methods, tools,
techniques, and approaches are best for your specific project.
Let's make a start!
How do you choose the right management methodology?
I'm glad you asked! It is a set of principles, approaches, and practises

designed to guide you and your project to a successful and optimum
conclusion.
It should also be chosen for the most efficient and effective

performance of the project and the team. The project management
methodology chosen should also be consistent with your organisation,
its culture, and goals.
Why are there so many different project management methodologies?
P a g e 4 | 65
For a start, every project is unique undertaking, no two are the same,
often in different industries, so having a single method for all is
unrealistic.
As a standard guideline, a project management framework provides

an environment for the project to take place, but lets you decide how
the work gets done. By way of contrast, a methodology is more
prescriptive and precise as it specifies why you should do it, what to
do, when to do it and how to do it.
How a project management methodology helps
There are several important reasons why you would want to harness
the power of a project management methodology.
It helps you to define roles and responsibilities, decision making and

accountability. It clarifies what each member of the project team
should be doing while avoiding conflicts of interest.
A project management methodology describes a set of processes for

planning, monitoring controlling the project. It provides templates and
project controls to ensure the project is delivered on time and to
budget.
By following a project management methodology, you will create

more robust plans and better estimates.
A typical project management lifecycle
Different names for the steps may be used, but here is a popular one
used by the Project Management Institute:
The Initiation process. Here, key stakeholders are identified, and

the project charter is developed. The project business case is formed
here including establishing the project scope (what is included within
the project boundaries, and what is not).
P a g e 5 | 65
The Planning process. Here, the project management plan is
assembled and signed off. Project deliverables are agreed along with
resources/costs and key milestone dates
The Executing Process. This is where the project products and the
work to create them are performed as laid down in the project
schedule.
The Monitoring and Controlling process. The actual progress is

captured and compared to the plan. It is where corrective actions are
taken. Scope creep is closely watched, and a formal change control
procedure is documented and used
The Closing process. This is where the customer accepts the final
product where it is handed over to the business, and the project is
shutdown in a controlled manner.
Choosing the most appropriate method will be driven by the type of

project and its environment. Take for example:
P a g e 6 | 65
Predictive (Waterfall) Project Management
The waterfall or predictive method is the traditional way to manage

projects for the last several decades. The waterfall method is very
straightforward in its concept as the project tasks are carried out in
strict sequential order.
This is a generic term for a traditional new product development

process in which there are discrete steps and milestones. It is called
waterfall product development because here, teams continue on to
the next stages only after milestones are met.
Agile product development processes are more common because they

can create new products that delight customers while economizing on
resources.
The Agile approach relies on sprints, cycles that combine development

with customer testing. Almost all organizations that say they are Agile
are really using it between major milestones, to develop their
products. This is a hybrid approach that offers the best of both worlds.
The term refers to the graphical depiction of a development process in

which the sequential phases of work are shown flowing steadily
downwards like a cascading waterfall.
This is also known as a plan-driven process. This is a style of

development that attempts to plan for and anticipate upfront all the
features a user might want in the end-product and to determine how
best to build those features.
The work plan is based on execution of a sequential and linear set of

work-specific phases where each step or stage in the project waits for
the previous one to finish before the next can start, so progress
cascades down from one stage to the next.
P a g e 7 | 65
Here is one example:
Waterfall is a rigid approach to project management and assumes you

have, or can get, all the requirements upfront and assumes changes
will not cause you to deviate from the plan.
For most project endeavours this is not realistic or highly optimistic

and so causes budgets to be overdrawn and adds delay to project
completion.
Waterfall or plan driven processes are so named because they

attempt to plan for and anticipate up front all the features a user
might want in the project end-product, and to determine how best to
build those features.
The idea here is that the better the planning, the better the
understanding, and therefore the better the execution.
P a g e 8 | 65
Plan-driven processes are often called sequential processes because

practitioners perform, in sequence, a complete requirements analysis
followed by a complete design followed in turn by building, and then
testing.
Waterfall is best used when:
▪ Your project end deliverable is clearly defined, and changes

are highly unlikely
▪ The project stakeholders have made clear the project

requirements and features, and changes to those are highly
unlikely
▪ This approach works well when applied to problems that are

well defined, predictable, unlikely to undergo any significant
change, and your project delivery approach is consistent
▪ It works well if your project will be delivered within a

regulated industry sector demanding extensive project tracking
and documentation
▪ It is suitable when your project change control process is

agreed and supported by senior management, and they in turn,
understand that extra funding or resources may be needed by
such changes
▪ Waterfall is good when your project is not taking place in a

volatile environment and project risk is understood from the start
so that mitigation responses can be put in place
▪ It works when roles and responsibilities clearly understood

from the outset
P a g e 9 | 65
▪ Waterfall projects normally require full funding from the start

and business benefits are not realized until at some point after
project completion.
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.
P a g e 10 | 65
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
Here is an example of typical phases of the waterfall project:
P a g e 11 | 65
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.
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.
P a g e 12 | 65
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 version.
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
P a g e 13 | 65
▪ 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
▪ 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
▪ Not ideal for complex, high risk, ongoing or object-oriented

projects
P a g e 14 | 65
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.
P a g e 15 | 65
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) …
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 I will 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?
P a g e 16 | 65
1. Define the project scope
First, you need to define all the tasks that must be finished to
complete the project. For a 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
When you look at these tasks individually, you realize that some of
them cannot be started before the others are completed. That is,
some tasks are dependent on others.
Here, I have 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.
P a g e 17 | 65
These tasks, together with the start of the 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:
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.
P a g e 18 | 65
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. I have 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 19 | 65
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.
P a g e 20 | 65
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 the party example, first assume that you must do
everything by yourself. I have estimated the length of time each
activity will take.
Also, I determined the approximate start time for each task on the
critical path.
Here’s what I came up with:
Task Duration Start

Choose a date and 2 hours Monday
venue
Make the ultimate 3 hours Monday
playlist
Set up your sound 1 hour Monday
system
Invite your friends 2 days Monday
Buy the food and drinks 1 day Tuesday
Cook your famous 2 hours Wednesday
casserole
Host the party 2 hours Wednesday
Now if you add up all our critical tasks’ duration, you’ll get the
approximate time needed to complete the whole project. In this case,
3 days and 6 hours, since “make the ultimate playlist” and “set up the
sound system” are not on the critical path.
P a g e 21 | 65
If you add the duration to the start time, you 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, you rarely get to manage such projects. A
schedule generated using critical path method techniques is often not
followed precisely.
As 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
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
P a g e 22 | 65
Parallel Tasks in the Critical Path

In the 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 your whole project from being completed on time. Therefore,
you should always keep an eye on parallel tasks.
Changes in the Critical Path

Now, assume that choosing the curtains took our friend longer than
we initially expected. This will delay the end of the project:
The redecoration is incomplete without the new curtains, so the path that
previously was non-critical becomes critical.
P a g e 23 | 65
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.
For more training on Critical Path Management – Go HERE!
P a g e 24 | 65
Critical Chain Project Management (CCPM)
You might see this as a technique, but you would be wrong since it is
a new approach to project management planning and control.
Critical chain project management (or CCPM) takes the critical path
method (CPM) and includes the recognition of resource limitations.
You probably know the critical path method calculates which activities
are time-critical and which are not. Since the addition of such critical
activities determine the earliest finish date of the project – you focus
on them.
But putting that concept into practice is often unrealistic, leading to

uncontrolled slippage and cost over-runs.
Critical chain project management resolves such issues by using

aggressive resource and work estimating yet building in “buffers” at
key schedule points plus at the end of the project.
P a g e 25 | 65
In this way, delays and unexpected resourcing issues are neatly side-
stepped and keep your project on track.
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.
P a g e 26 | 65
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
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.
P a g e 27 | 65
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 28 | 65
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.
P a g e 29 | 65
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.
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.
Go HERE for more tuition on Critical Chain!

P a g e 30 | 65
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.
P a g e 31 | 65
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.
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.
P a g e 32 | 65
The Agile methodology model
Agile is a specific set of values and principles as expressed in the
agile manifesto. It is an umbrella term used for a group of related
approaches to software and hardware development based on
iterative and incremental development.
Key characteristics of agile project management methodologies

are they are collaborative, quick, and open to data-driven change.
The frustrating limitations of waterfall methods that couldn’t adapt

with a project as they progressed, caused a shift to more iterative
models, allowing teams to revise their project if needed during the
process instead of waiting until project end to review and amend.
P a g e 33 | 65
Work is completed in planned increments and each increment

brings greater clarity as to what the outcome will be, and the agile
approach is based on both iterative and incremental development.
Iterative development acknowledges that we will probably get

things wrong before we get them right and that we will do things
poorly before we do them well.
So iterative development is a planned rework strategy using

multiple passes to improve what is being built so we can converge
on a good solution.
Iterative development is an excellent way to improve the product

as it is being developed however due to uncertainty it can be
difficult at the start to plan how many improvement passes will be
necessary.
Incremental development is based all new building some of it

before you build all of it, and in doing so avoid a Big Bang style
event at the end of development. Instead, we break the product
into smaller pieces so that we can build some of it, learn how each
piece is to survive in the environment in which it must exist, adapt
based on what we learn and then build more of it.
Incremental development gives important information allowing us

to adapt our development efforts and to change how we proceed.
P a g e 34 | 65
In an Agile framework, the planning phase is shorter and
combined with the project execution phase.
Within the executing stage, agile timeboxes (also called sprints),

helps inform what the next sprint will deliver homing in on the
project goals.
In an Agile project, sprints start in the executing stage. Each

sprint informs what will be delivered next, edging the project
closer to the end goal.
The specialist team are self-empowered, with daily updates (sprint

review) to address progress and issues, and a sprint-end
retrospective to review lessons and apply those learnings to the
up-coming sprints.
Agile project management methodologies involve short sprints

with frequent testing, reassessment, and adaptation throughout.
In an agile project the requirements are captured as user stories

(what a requirement feels like from the perspective of a user) and
prioritized into a Product Backlog. Stories that are most important
to the customer are ordered at the top, with less important and
less understood storied at the bottom.
The Product Owner role prioritises the user stories and the team
select how many (from the top) they can do in the upcoming
sprint.
At sprint (timebox) start, the team plan determines the sprint

tasks and activities to be carried out – and then work starts.
Sprints are fixed duration (up to four weeks) with a constant team
size, so by sprint end, the only variable is scope in terms of whole
products created.
If any sprint products did not have time to complete a product it is

placed back on the Product Backlog to be prioritized by the
Product Owner.
P a g e 35 | 65
Agile projects value self-organising teams with no formal project
manager this means the work is distributed by team consensus
rather than by an authority. Minecraft when problems arise the
team works to resolve them internally because of the high degree
of communication, visibility, and transparency.
Agile projects welcome change and are embraced by the team.

Such changes almost always lead to improvement in the product.
Customer involvement is a key part of any agile methodology

meaning that the customer participates in project meetings and
has complete visibility into the team’s progress.
Work is delivered to the customer and users in small frequent

releases keeping the teams focus sharp with immediate priority
giving functionality into the hands of the customer quickly allowing
it to be used, tested, and providing a rapid feedback loop.
Agile works well in projects where there is a need for complex

decision making and your stakeholders or client needs is frequent
and collaborative.
Learning occurs throughout the project so processes and

approaches can be continuously improved. Benefits are realised
throughout project delivery rather than waiting until project
closure, and agile is best when all key stakeholders are collocated
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.
P a g e 36 | 65
So Agile methodologies are the conventions that a team chooses
to follow in a way that follows Agile values and principles.
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.
P a g e 37 | 65
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)
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.
P a g e 38 | 65
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.
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 provide

products quickly and consistently to consumers. Software
development companies prefer this “light- touch” management
style which facilitates rapid production cycles.
P a g e 39 | 65
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 40 | 65
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.
For more training on Agile Project Management – Go HERE!
P a g e 41 | 65
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!
Scrum is the Agile project management framework of choice of most

product development teams today and is a form of agile project
management
Scrum has its own techniques and tools such as “sprints,” “scrums,”
“backlogs,” and “burnup/downs.”
Scrum does not focus on projects but instead focus on time: what can
you achieve as a team in the next two weeks or a month?
Scrum uses story points to both estimate and manage the work within
each sprint.
P a g e 42 | 65
Scrum is a framework for organising and managing work and is based

on a set of values, principles, and practises.
The development team self-organises to determine the best way to

accomplish the goal set out by the product owner.
The product owner is the single authority responsible for deciding

which features and functionality to build and the order in which to
build them.
They are responsible for the overall success of the solution being
developed or maintained
P a g e 43 | 65
Small teams (no more than nine people) divide work into two-week
milestones known as “sprints” or “iterations.” They meet for daily 15-
minute “stand-ups” led by a Scrum Master to discuss where things
stand.
The Scrum Master acts as a facilitator whose job is to clear away

obstacles and help the team work more efficiently. This Agile
approach is great for creative projects (the creation of “knowledge
work”), where you can modify goals midway without derailing the
entire project.
Small teams are led by a Scrum Master (who is not the same as
the project manager) for the duration of the sprint, after which they
review their performance in a “sprint retrospective” and make any
necessary changes before starting the next sprint.
P a g e 44 | 65
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 45 | 65
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.
P a g e 46 | 65
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:
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.
P a g e 47 | 65
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.
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 conducted, the artifacts that are created and the roles within
the project team:
P a g e 48 | 65
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.
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.
P a g e 49 | 65
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
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.
P a g e 50 | 65
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.
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.
For more training on SCRUM Go HERE!
P a g e 51 | 65
If neither Agile nor Waterfall seem like the perfect fit for your project,
there’s another solution:
The Hybrid methodology
This approach combines the best of both Agile and Waterfall project
management methodologies, but it can be challenging causing teams
to work in ways they are comfortable with.
Senior management and stakeholders may need help gathering the

metrics they need, possibly causing longer decision times, duplicating
of data and unclear responsibilities.
However, if such challenges are known, the hybrid approach may be

worth these extra challenges.
P a g e 52 | 65
Blending Agile and Kanban:

Originally developed by Toyota in the 1940s, Kanban means
“signboard” 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.
Kanban is an agile approach overlaid on an existing process that

advocates visualising how work flows through a system, limiting
the work in process, and measuring and optimising the flow of
work.
The term Kanban has evolved using a framework in which tasks are
visually represented as they progress through columns on
a Kanban board.
P a g e 53 | 65
Work is pulled from the predefined product backlog on a continuous

basis as the team has capacity and moved through the columns on
the board, with each column representing a stage of the process.
The Kanban board visually manages processes with several

different columns that represent stages in your workflow.
P a g e 54 | 65
The stages could be as simple as “To-do,” “Working on it,” and
“Done” or far more complex, as tailored to your process.
Work is visualized by cards or sticky notes, moving them from left

to right as they progress through your workflow—this way you can
easily evaluate points of inefficiency by noting where the sticky
notes are building up by helping you to see where bottlenecks are
at risk of forming
Kanban can be applied to basically any workflow that follows a

predictable process – including software.
Kanban is simple and flexible for when you need to focus on the
present day - however, you may need to focus on what is
important rather than urgent!
Kanban provides everyone an immediate visual overview of where

each piece of work stands at any given time.
Work in progress limits restrict the number of tasks in play at any

given time, meaning that you can only have a certain number of
tasks in each column (or on the board overall).
This will prevent the team from spreading their energy and effort
across too many tasks, and so help them work more productively
by focusing on each task individually.
Kanban and the Kanban board works great if you are looking for a
visual representation of your project’s progress and want at-a-
glance status updates.
By encouraging the use of WIP limits so your team can stay

focused, where work is bought in on a continuous “pull” basis.
In the workplace, Kanban teams originally visualized their workflow

as cards moving from left to right across a Kanban board.
P a g e 55 | 65
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.
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.
Kanban development operates on five core principles:
Visualize the workflow. Knowledge work projects, by definition,

manipulate knowledge which is intangible and invisible. Therefore,
having some way to Visualize the workflow it is very important for
organizing, for optimizing, and tracking it
Limit WIP (work-in-progress). Restricting the amount of work in

progress improves productivity, increases the visibility of issues and
bottlenecks, and facilitates continuous improvement. This makes it
easier for routine to identify issues and to minimize waste and cost
associated with changes.
It also results in a steady “pull” of work through the development

effort, since new work can only be moved forward as existing work is
completed.
P a g e 56 | 65
Manage the flow. By tracking the flow of work to a system, issues
can be identified, and changes can be prepared for effectiveness.
Make process policies explicit. It is important to clearly explains how

things work so the team can have open discussions about
improvements in an objective, rather than emotional or subjective
way.
Improve collaboratively. Through scientific measurement and

experimentation, the team should collectively own and improve the
processes it uses.
Kanban’s Pull System.

Kanban has some distinct features that differentiate it from Scrum,
XP, and generic agile.
The main difference is that Kanban employs a “Pull System” to

move worked through the development process, rather than
planning their work in timeboxed iterations.
Each time a Kanban team completes an item of work, it triggers

a “pull” to bring into the next item they will work on.
Only a certain number of slots are available for each column on

the Kanban Board and whenever there is an empty slot on the
board, and that’s a signal for the team to pull work from the
previous stage is, if there are any items available.
So work is continuously being called from the left side of the

board to the right side.
On a Kanban Board, capacity is what signals the team to pull

work items into the next stage of the process.
As the project progresses, the team simply moves the work items
from left to right to show their status in the process.
P a g e 57 | 65
WIP Limits in Kanban
This refers to capping the number of items that can be in a given
state of progress, as defined by the columns on the team’s
Kanban Board.
The reason that limiting WIP is important, is that lowering the

WIP increases a team’s productivity – its features: and the rate
at which the work is completed
For more training on Scrum Kanban Go HERE!
P a g e 58 | 65
Scrumban methodology
Scrumban is a hybrid agile project management methodology that has

the nose of scrum and the eyes of Kanban.
The benefits of Scrumban are that instead of deciding which task from
the Product Backlog to work on in each sprint (as you do in a
“traditional” scrum framework).
Scrumban allows teams to continuously “pull” from the product

backlog based on their capacity (as in a Kanban framework).
By using work in progress limits from Kanban during your sprint cycle
from scrum, you can keep a continuous flow while retaining project
planning, reviews and retrospectives as required.
P a g e 59 | 65
Extreme Programming (XP) Methodology
The eXtreme Programming (XP) methodology is another form of agile

project management that was designed for software development.
It emphasizes teamwork and collaboration across managers,

customers, and developers, with teams self-organizing.
It has a defined set of rules that teams should follow, which are based
on its five values: simplicity, communication (face to face is
preferred), feedback, respect, and courage.
P a g e 60 | 65
eXtreme programming works best if you need to foster teamwork and

collaboration and have a small co-located team.
P a g e 61 | 65
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.
P a g e 62 | 65
The first Extreme Programming project was started March 6, 1996.
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.
P a g e 63 | 65
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,
which is your goal.
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 64 | 65
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.
APF is a type of agile project management framework that adapts to the

changing situations and requirements of your client
Businesses often avoid change because traditional project management

methods rely on adapting goals and outcomes to the process, rather than
adapting the process to the goals.
Today’s fast-paced businesses have moving targets, goals and outcomes

and so must be flexible, so rather than react, you should be responsive to
change.
It prepares teams to anticipate the unexpected and respond with a core

principle of "learning by doing." This requires regular communication with
stakeholders at every level for the team to effectively adapt.
P a g e 65 | 65
The problem with this is project plans have little room to adapt when the
needs or solutions evolve.
APF allows you to create new plans and find better solutions whenever a
change occurs and adapts should unanticipated factors crop up during a
project.
APF is helpful when your ultimate goals are known when you do not need
predictability, scope may creep, and you have sufficient resources to
adapt as needed.
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.
P a g e 66 | 65
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.
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.
P a g e 67 | 65
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
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.
P a g e 68 | 65
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.
P a g e 69 | 65
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 70 | 65
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
Rapid Application Development (RAD) is a development model that

prioritizes rapid prototyping and quick feedback over long-drawn-out
development and testing cycles.
With rapid application development, developers can make multiple

iterations and updates to a software quickly without starting from scratch
each time. This helps ensure that the outcome is more quality-focused
and is in alignment with the end-users’ requirements.
One of the major advantages of rapid application development is that you

can change the design, add functionality, and keep reiterating as
frequently as possible without having to start from scratch each time.
P a g e 71 | 65
A major challenge with the waterfall model is that once the product moves
into the testing phase, the tester cannot go back to reiterate and make
changes to the core functions and features.
This essentially leaves teams with a software that may or may not fit the
end-users’ evolving requirements.
Rapid application development (RAD) is an agile project management

methodology used for faster software development.
RAD uses rapid prototype releases and iterations to gather feedback in a

short period of time, and values user feedback over strict planning and
requirements recording.
RAD is great for when you want to give customers a reasonable/not

perfect working model much sooner, speed is of the essence, and
making/choosing multiple working prototypes.
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.
P a g e 72 | 65
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 do not require long interactions
and deep development of complex functions.
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 73 | 65
Crystal methodology
Crystal is a family of methodologies. Crystal methodologies are designed to
scale and provide a selection of methodology rigor based on project size
(number of people involved in the project) and the criticality of the project
Crystal is an agile framework focusing on individuals and their interactions,

as opposed to processes and tools
Crystal is a direct outgrowth of one of the core values articulated in
the Agile Manifesto
Crystal is a family of methodologies.
P a g e 74 | 65
Crystal methodologies are designed to scale and provide a selection of

methodology rigor based on project size (number of people involved in the
project) and the criticality of the project
Crystal is an agile framework focusing on individuals and their interactions,
as opposed to processes and tools
Crystal is a more flexible agile framework, because it is designed around a
project’s people and is not dependent on any single set of processes or tools
The Crystal agile framework is built on two core beliefs:
▪ Teams can find ways on their own to improve and optimize their
workflows
▪ Every project is unique and always changing, which is why that
project’s team is best suited to determine how it will tackle the work
P a g e 75 | 65
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.
New product introduction is a project management methodology for when

you want to introduce a new product.
Introduction of new products that consumers want requires correct and

thorough information, time, and resources from your organization, so it is
important follow an organized and well-planned process.
In today’s competitive marketplace successful organizations realize the

importance of developing the right product, at the right time and the right
cost.
P a g e 76 | 65
The New Product Introduction (NPI) method is designed to bring the right
resources together at the right time. It is also known as new product
development (NPD), covering all you need to define, develop and launch a
new (or improved) product:
A New Product Introduction process consists of various phases or gates,

and these keep management apprised of the project progress and assures
all activities are completed on time:
▪ Define
▪ Feasibility
▪ Develop
▪ Validate
▪ Implement
▪ Evaluate
Each NPI phase feeds into the next. The NPI process is not a straight line,
but rather, an endless circle or loop.
For each phase of an NPI project, there are inputs and outputs, including
various requirements, tools, documentation, and processes within each
phase.
P a g e 77 | 65
The requirements for a successful new product introduction require a lot
of cross-functional collaboration and communication.
A typical NPI project will include:
1. Defining the product specification and the scope of the project

2. Evaluating the product feasibility and developing a prototype
3. Validating the prototype via testing and analysis
4. Manufacture the product on a larger scale
5. Evaluate the product’s business benefits/success in the market after
launch
There is a manufacturing focusses version of NPI, so I will briefly explain

that too:
New Product Introduction Method is the step-by-step process to create an

idea and carries it through to commercialization.
It is the new product introduction process, rather than the new product
development process, because NPI looks at the product from the
viewpoint of manufacturing.
P a g e 78 | 65
Although cross functional processes differ depending on these factors, a
new product idea is put through a series of steps.
At the end of each of the six steps, the Senior Management team makes
an up-or-down decision in a formal review (often called a “gate”). A
typical NPI approach has six steps with five gates:
Step 1: Ideation (Initial Idea)
Step 2: Product Definition/Discovery/Scoping
Step 3: Prototyping/Feasibility
Step 4: Detailed Design
Step 5: Pre-Production (Validation/Testing)
Step 6: Manufacturing
The NPI project management strategy works best for product-based

teams because NPI managers shepherd single products through their
entire development process.
P a g e 79 | 65
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 80 | 65
Dynamic Systems Development Method (DSDM)
Dynamic systems development method (DSDM) is an agile project

delivery framework developed in 1994 and first used for software
development as an improvement on Rapid Application Development
(RAD), which prioritized rapid prototyping and iteration based on user
feedback.
Today, DSDM Agile Project Framework has evolved to a more general

project management tool.
The DSDM Foundation Phase of the project is where the definition of work
and finished work is agreed, but because this is early on, it can lead to
assumptions being made in planning. The DSDM eight agile principles are
the guiding force behind every project:
▪ Focus on the business need
▪ Deliver on time
▪ Collaborate
P a g e 81 | 65
▪ Never compromise quality
▪ Build incrementally from firm foundations
▪ Develop iteratively
▪ Communicate continuously and clearly
▪ Demonstrate control
What makes DSDM stand out amongst other system development

methods are several techniques and practices:
▪ Timeboxing
▪ MoSCoW
▪ Modelling and Iterative Development
▪ Prototyping
▪ Workshops
P a g e 82 | 65
Packaged Enabled Reengineering (PER)
Package enabled Reengineering (PER) is a project management technique
used by the business to redesign new products, services, or processes.
The focus of PER is on swift business transitions efficiently and

strategically, whether by redesigning systems or reorienting people. It
provides a fresh look on your products, services, or processes.
Innovation-driven organizations who are committed to growth follow this

approach, making it easier and more productive for the organization to
adapt and respond to evolving market conditions and customer needs
thereby increasing their sales and return on investment.
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.
P a g e 83 | 65
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 identifies themselves, Package Enabled
Design may be used.
P a g e 84 | 65
The Scaled Agile Framework (SAFe)
SAFe is a way to take the agile principles and scale them beyond a single
project team. Used by larger businesses, it applies agility across your
entire business enterprise.
Project management in an organization using SAFe happens at three

levels.
At the individual team level, it’s basically Scrum business as usual.
SAFe has ten principles:
▪ Take an economic view
▪ Apply systems thinking
▪ Assume variability: preserve options
▪ Build incrementally with fast, integrated learning cycles
▪ Base milestones on objective evaluation of working systems
▪ Visualize and limit WIP (work in progress), reduce batch sizes, and
manage queue lengths
▪ Apply cadence, synchronize with cross-domain planning
▪ Unlock the intrinsic motivation or knowledge workers
▪ Decentralize decision-making
▪ Organize around value
Small teams have specific goals and areas of responsibility, so they

release iterations after each Sprint lead by the Scrum Master.
P a g e 85 | 65
The only significant change is that these small teams now roll up into
programs.
The program level is where SAFe’s benefits are realised as each team’s
output must stitch together with everyone else’s into something
complementary, cohesive, and consistent.
P a g e 86 | 65
Disciplined Agile (DA)
Disciplined Agile is a tool kit that brings together hundreds of Agile
practices - guiding your team or organization to the best way of working.
The DA tool kit provides guidance helping organizations streamline their

processes thus laying the ground for business agility.
Since business agility comes from freedom, not frameworks, Disciplined

Agile shows you your options and guides you to your best next step.
DA is a people-first agile framework and is a hybrid of various

disciplined agile delivery methodologies like XP, Scrum, Kanban, and so
on.
P a g e 87 | 65
DA guides persons, teams, and organizations to optimize their processes,

leading to business enhancement by collaborating and drawing together
various activities such as:
▪ software development
▪ IT Operations
▪ Finance
▪ Procurement
▪ Portfolio Management
▪ Enterprise
DA provides a wide range of customized, context-sensitive ideas and

helps make better decisions.
P a g e 88 | 65
Large Scale Scrum (LeSS)
LeSS is like a one team Scrum, only extended.
Using LeSS there is one Product Backlog, one Product Owner, one
Definition of Done, one common sprint, and one PSP (Potentially
Shippable Product) increment at the end of the sprint.
All the cross-functional teams work on implementing the same product to

deliver a common, shippable product each sprint.
When scaling up occurs there is a risk to add more of everything which

increases overhead and costs, so the LeSS goals for scaled agile projects
do the opposite.
LeSS does not just stand for Large Scale Scrum, it also stands for “less”,
so the goal is to solve things as simply as possible with “less roles, less
management, less organizational structures”.
P a g e 89 | 65
The PRINCE2 Methodology
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 though 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.
PRINCE2 (PRojects IN Controlled Environments) is a project management

methodology and certification that aims to equip project managers with
knowledge of best practices and processes, clear steps, and well-defined
responsibilities.
It doesn’t require several prerequisites, making it a good choice for

project managers looking to get both a methodological grounding and a
qualification.
PRINCE2 is guided by seven principles, which in turn dictate the seven

processes (the chronological flow of the project) a project manager needs
to use in each project when using PRINCE2.
P a g e 90 | 65
PRINCE2 also has seven Themes which are the logical thread of key
elements such as risk management used within each process.
The PRINCE2 Method is intended to be tailored to each project and it can

be applied in any industry or project approach. For example, PRINCE2 can
be tailored for both waterfall and agile project frameworks.
P a g e 91 | 65
PRINCE2 places heavy emphasis on planning, business justification, cost

analysis, and risk mitigation, and is an incredibly thorough framework for
running large and predictable enterprise projects as well as being tailored
for small, simple, and low risk projects.
The methodology is free for use 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.
PRINCE2 roles
To deliver the project according to 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.
▪ The Customer is a person or a company that pays for the project
▪ The User is a person or a company that uses the project’s outcome
▪ The Supplier (specialist) who is responsible for creating the project

outcome
P a g e 92 | 65
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
P a g e 93 | 65
▪ 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.
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 up 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
P a g e 94 | 65
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.
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
P a g e 95 | 65
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.
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.
PRINCE2 is a framework for project success and can be tailored/blended

to suit any project in any industry.
For more training on becoming a PRINCE2 Practitioner – Go

HERE!
P a g e 96 | 65
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
P a g e 97 | 65
▪ 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
▪ 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.”
P a g e 98 | 65
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.
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.
P a g e 99 | 65
(Given that the average Black Belt salary is $80,000 in the United States,
which 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 100 |
65
Design for Six Sigma (DfSS)
DfSS uses the DMADV Method – Define, Measure, Analyse, Design, and
Verify. DMAIC Is used to improve existing processes, but sometimes the
process does not exist and you need to create one, perhaps for new
services or products
P a g e 101 |
65
It may be that your current process is so poor that scrapping it and
starting again makes more sense! DMADV Will help introduce new
products and services quickly and to a consistently high standard
When redesigning a process we focus on the customer, when designing a

new service or product there may not be a customer yet, so we focus on
the demands of the (potential) marketplace
Where the customer is involved, this means both end-user customers and
internal business stakeholders and users.
Customer requirements and the resulting CTQ’ s are established early on

and the DMADV framework ensures that these requirements are satisfied
in the final product, service, or process
As with DMAIC, we managed by facts and not speculation to ensure that

new designs reflect customer CTQs and provide real value to the
customers
DMADV Projects are normally used to introduce radical change within an

organization.
P a g e 102 |
65
It is important that you have a change management framework in place
to address and manage the various people issues that are so important
for the successful completion of the project
The DMADV Define Phase
This is where scoping, organizing, and planning the journey for your
project occurs
It’s where you understand the purpose, rationale, and business case, as
well as define what resources you need to help you and how you will
manage the project
Here you will understand the boundaries of the project, including the
processes, markets, customers, and stakeholders.
It is vital that everyone understand why the project is being undertaken.
Using the affinity and inter-relationship diagrams can be helpful when

starting a DfSS project
P a g e 103 |
65
These also identify the key areas for the project’s success, bringing the
team together, while creating involvement and ownership for the team
members within the project
The DMADV Measure Phase
The measure phase provides the framework around which the design can
be built and is used to make design decisions needed in further phases
Here, the focus is on defining and understanding customer needs, and the
different customer segments
DfSS projects seek to optimize the design of products or processes across
multiple customer requirements, so a detailed understanding of these is
essential
Project needs are translated into measurable characteristics (CTQ’s) that

provides the requirements for the product, define the measures, and set
targets, and CTQ specification limits service or process
For new products or services, you must make sure the design can be
produced with existing processes or designing new processes to
accommodate such new designs
Process capability is considered in the measure phase rather than after
the design is complete (as in DMAIC)
The DMADV Analyze Phase

Here is where the functional specification and high-level designs are
developed, going on to create and test the detailed design
The Analysis phase moves from the ‘what the customer needs’ to the ‘how
we might achieve it’ Mapping the CTQs onto internal functions and looking
at alternative design concepts
The sub-system characteristics are developed next followed by the

components (parts) of the sub-system
P a g e 104 |
65
Functions are what the product, service or process has to do to meet the
CTQs identified and specified in the design process
For a service, functions are key high-level processes to be considered. You

will carry out an analysis of the functions to understand their performance
capability to ensure they are fit for the purpose
The DfSS project emphasis is on alternative design concepts and the

generation, analysis, and assessment of a high-level design. Analysis
analyses and selects the best design concept and starts to add more detail
to it
Each design element is considered in turn with high-level design

requirements for each. Consideration needs to be given to how each
component fits and interacts with each other
The analysis phase usually creates several high-level designs, assessing

their suitability and selecting the best fit
You need to assess performance and develop design scorecards to help

analyze how capable the design is to deliver the CTQs.
Such assessments may be carried out through simulations, field tests, or

pilots involving the customer to capture their feedback
The Design Scorecard method deploys the requirements into the design
and predicts the capability of the new design.
The Design Scorecard captures the critical performance measures at each

level and visibly tracks the measured performance as the design evolves
Failure Mode Effects Analysis (FMEA)
Based on the outputs of the review, the high-level design requirements

can be finalized and a thorough risk assessment undertaken using FMEA.
For each of these potential events (failure modes), you assign a value,
usually on a scale of 1 to 10, to reflect the risk
P a g e 105 |
65
A failure mode is a mechanism by which the system fails, or the process
fails. A failure mode usually impacts the customer or business
The DMADV Design Phase
The design phase starts by developing the ‘how’ thinking in more detail
Adding this to the various elements of the high-level design.
The emphasis is on developing designs that will satisfy the CTQ

requirements of the process outputs.
The lowest level specification limits, control points, and measures are
determined to form the basis of the control plan that must be in place
following the implementation
The design is specified at a detailed enough level to develop a pilot and

test it because, before implementation, you need to pilot the design.
Enough detail should now be available to test and evaluate the capability
of the design by preparing an effective and realistic pilot in this design
phase
P a g e 106 |
65
Lean Six Sigma
Six Sigma is a highly disciplined management approach to attain near

perfection. Sigma (Ꝺ) is used to represent ‘Standard Deviation’.
Sigma (standard deviation) was defined by Gauss, and popularized by

Motorola who coined the term Six Sigma
Standard Deviation is a measure of variation that exists in any process.
Five Key Principles of Lean
Involve people in the process to use their creative potential, equip them
to be able, and feel able, to challenge and improve their processes and
the way those processes work:
▪ Enable the value to flow
▪ Identify and understand the value stream for each process and the
waste within it
▪ Continuously pursue perfection

(continuous improvement)
▪ Let the customer pull the value through the process, according to
their needs
▪ Understand the customer and their perception of value
P a g e 107 |
65
Six Sigma is a method for improving processes with an emphasis on

ensuring consistency in output and impeccable quality.
There are several variants, such as Lean Six Sigma and Agile Sigma, but
ultimately Six Sigma is a business methodology that aims to eliminate
defects and reduce variation by using its defined methodologies.
Six Sigma methods can be used to optimize and improve existing

processes or create new ones.
To improve business processes, use the Six Sigma DMAIC process, which
stands for the phases in the project methodology: Define, Measure,
Analyze, Improve, Control.
To create new processes or products, you can use the Six Sigma DMADV
process: Define, Measure, Analyze, Design, Verify.
As a set of principles and techniques Six Sigma methods can be blended

with many other project management methodologies, like Lean and Agile.
P a g e 108 |
65
P a g e 109 |
65
P a g e 110 |
65
The Lean Startup Method (LSM)
The Lean Startup Method provides a scientific approach to creating and
managing start-up’s and get a desired product to customers' hands faster.
The Lean Startup Methodology shows how constant innovation creates

radically successful businesses.
The method teaches you how to drive a Startup-how to steer, when to

turn, and when to persevere-and grow a business with maximum
acceleration
Entrepreneurship is management
A Startup is an institution, not just a product, so it requires management,

a new kind of management specifically geared to its context.
A core component of Lean Startup methodology is the build-measure-

learn feedback loop.
The first step is figuring out the problem that needs to be solved and then
developing a minimum viable product (MVP) to begin the process of
learning as quickly as possible.
Once the MVP is established, a Startup can work on tuning the engine.
This will involve measurement and learning and must include actionable
metrics that can demonstrate cause and effect question.
Lean Startup is a new approach to business that’s being adopted across

the globe – it’s a movement that is transforming not just the way
companies are built, but also how new products are launched.
LSM describes how to learn what your customers really want by testing
your vision continuously, then adapting and adjusting.
P a g e 111 |
65
The five principles of The Lean Startup Method are:
Entrepreneurs are everywhere. the concept of entrepreneurship

includes anyone who works within a start up: a human institution
designed to create new products and services under conditions of extreme
uncertainty.
That means entrepreneurs are everywhere and the Lean Startup Method
can work in any size company, even a very large enterprise, in any sector
or industry
Entrepreneurship is management. A start up is an institution not just

the product, and so it requires a new kind of management specifically
geared to its context of extreme uncertainty.
P a g e 112 |
65
Validated learning. Start-ups exist not just to make stuff, make money,
or even serve customers. They exist to learn how to build a sustainable
business. This learning can be validated scientifically by running frequent
experiments that allow entrepreneurs to test each element of their vision.
Build-measure-learn. The fundamental activity of a Startup is to turn

ideas into products, measure how customers respond, and then learn
whether to pivot or persevere. All successful Startup processes should be
geared to accelerate that feedback loop.
Innovation accounting. To improve entrepreneurial outcomes and hold

innovators accountable, we need to focus on the boring stuff how to
measure progress, how to set up milestones, and how to prioritise work.
This requires a new kind of accounting designed for start ups - and the
people who hold them accountable.
P a g e 113 |
65
Technical Debt
Not many organizations know of this business approach.
Although it is a ‘method’ it is not a structure of management in the pure

sense – yet a framework for technical debt management should be set up
in your organization … and a change management project is the prefect
way of doing this.
Rescuing Profit and Customer Satisfaction from The Silent
Company Killer
Technical Debt Rot is damaging your company business agility and

competitiveness - RIGHT NOW!
Technical Debt has become more evident in the last decade as the pace
and horizon of change continues to expand.
Today’s developers focus on delivering products and services to quickly to

solve a market need. Developers who over-architect only delay launch
and waste money.
P a g e 114 |
65
To do well, you need to stay on top of new technologies as well as full
understanding of your internal systems, your teams, as well as strategic
initiatives and business goals.
Technical debt will paralyze products and decimate maintenance and

support - making changes or upgrades a nightmare ordeal ...
So, while shortcuts and assumptions help developers iterate quickly, they
also cause products, hardware, systems, or software to accrue technical
debt.
Left unaddressed, this debt bogs down systems, crashes software,

causing months of delay in product and service releases or upgrades.
This was first described as a technical debt concept, where the example
given was “ shipping first time code is like going into debt.
A little debt speeds development so long as it is paid back promptly with a

rewrite … the danger occurs when the debt is not repaid. Every minute
spent on not quite right code counts as interest on that debt.
P a g e 115 |
65
Entire engineering organisations can be brought to a standstill under the
debt load of an unconsolidated implementation”
So, creating software fast to get early feedback is a good thing.
The team and organisation need to be vigilant about repayment of debt as

their understanding of the business domain improves, and the design and
implementation of the system need to evolve to better embrace that
understanding.
But don’t run away with the idea that technical debt can only occur in
software – it occurs in ANY product or service your organization supplies
or creates.
There are three types of technical debt, the first being naive technical
debt. This can often be due to business immaturity, process deficiencies,
poor engineering design, and lack of testing.
Put simply, this type of technical debt often occurs due to accidental or
irresponsible activities within your organization.
The second type is unavoidable technical debt. This is unpredictable

and unpreventable – often due to products and services needing to evolve
over time – yet such actions were never taken.
The third type is strategic technical debt. Here, managing such debt is
the need for organizations to quantify and leverage the economics of
important, often time-sensitive, decisions.
Two such examples are to take a strategic decision to take development

shortcuts to achieve short-term goals such as getting product or service
to market swiftly.
Another might be getting a technical debt-ridden product to market to

slash development costs.
P a g e 116 |
65
The Lean Method
Lean focuses on achieving more by working with less and was created by
the Toyota Production System (TPS) who defined three broad types of
waste: muda, mura, muri.
Muda (wastefulness) consumes resources without adding value for the

customer.
Mura (unevenness) occurs when you have overproduction in one area

leaving you with too much inventory (wasteful!) or inefficient processes
(also wasteful!).
Muri (overburden) occurs when there is too much strain on resources

such as equipment and people, which can often lead to breakdowns — in
both machines and humans.
P a g e 117 |
65
Using the key principles of lean, a project manager can reduce these
types of waste to create more efficient workflows.
P a g e 118 |
65
Lean will help when you want a set of principles that will help you cut the
fat and optimize your flow, while striving to improve and add value for the
customer and decreasing costs
You apply lean principles to your project management methods to

maximize value, minimize waste and work as efficiently as possible. It
encourages you to strip away all the padding of your day-to-day, so
you’re only left with the essentials that deliver real value.
Lean Product Development
Lean is not an agile methodology, but they are closely aligned. Lean
began as a manufacturing approach which was then applied to software
development, and eventually adapted for all kinds of knowledge work.
Within an agile context, Lean refers to “lean product development” as

these deals with developing new and better products.
The high-level principles of the new product development include:
▪ Using visual management tools

▪ Identifying customer defined value
▪ Building in the learning and continuous improvement
Lean core concepts
P a g e 119 |
65
Eliminate waste. To maximize value, we must minimize waste. In

knowledge work, waste can take the form of partially done work, delays,
handoffs, unnecessary features, etc.
Therefore, to increase the value we are getting from projects, we must
develop ways to identify and then remove, waste.
Empower the team. Rather than taking a micro-management
approach, we should respect the team members superior knowledge of
the specialist steps required on the project and let them make local
decisions so they can be productive and successful.
Deliver fast. We can maximize the project’s return on investment (ROI)
by quickly producing valuable deliverables and into writing through
designs. We will find the best solution through the rapid evolution of
options.
Optimize the whole. We aim to see the system as more than the
sum of its parts. We go beyond the pieces of the project and look for
how it aligns with the organization. As part of optimizing the whole, we
also focus on forming better intergroup relations.
Build quality in. Lean development does not try to “test in” quality
at the end. Rather, we build quality into the product and continually is
sure quality throughout the development process, using techniques like
refactoring, continuous integration, and unit testing.
Defer decisions. We balance early planning with making decisions

and commitments as late as possible. As an example, we could
reprioritize the backlog right up until it is time to do the work, to avoid
being tied to an early technology- bounded solution.
Amplify learning. This concept involves facilitating communication

early and often, getting feedback as soon as possible, and building on
what we learn. Since knowledge work projects are business and
technology learning experiences, we should start early and keep
learning.
P a g e 120 |
65
The Seven Wastes of Lean

The primary driver of the leaner approach is to eliminate waste.
Lean uses the Japanese term muda to refer to the seven kinds of
wastes that should be eliminated.
The following diagram summarizes these wastes as they would apply

to any type of knowledge work:
P a g e 121 |
65
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 122 |
65
P a g e 123 |
65
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.
Outcome mapping (OM) is a project management methodology for

planning, monitoring, and evaluating development initiatives to bring
sustainable social change.
It does not focus on measurable deliverables, instead, it measures

influence on creating lasting behavioural change within a community.
P a g e 124 |
65
OM is a common project management methodology often used in
charitable projects in developing countries.
During the planning stage, outcome mapping helps a project team be

specific about the stakeholders it intends to target, the changes it
hopes to see and the strategies appropriate to achieve these.
During ongoing monitoring, OM gathers information on the results of

the change process, and these are measured in terms of the changes
in behaviour, actions or relationships that can be influenced by the
team.
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).
P a g e 125 |
65
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 126 |
65
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.
P a g e 127 |
65
Project Management Body of Knowledge (PMBOK)

methodology
Created by the Project Management Institute (PMI), PMBOK (Project
Management Body of Knowledge), breaks down project management
into five phases: conception and initiation, planning, execution,
performance, and monitoring, and closing.
PMI’s Project Management Professional (PMP) certification is

one of the leading project management qualifications. This is not a
methodology, but rather a set of best practices for managing projects.
PMBOK is an industry-standard set of guiding principles used to

ensure you meet the PMI’s high standards and comply with best
practices for your projects across multiple types of teams and
organizations
P a g e 128 |
65
Although traditionally used for waterfall type projects it now includes

agile concepts and is probably the most sought-after project
management accreditation in the world.
PMBOK consists of 10 knowledge areas and five process groups. there

are several processes within each process group numbering 49
process is in total. The process groups are mostly sequential and can
be used to represent the project as a whole ought to be used once for
each stage or phase of a project.
P a g e 129 |
65
Feature-Driven Development (FDD)

This is a simple to understand yet powerful approach and building
products or solutions. A project team following the FDD method,
will first develop an overall model for the product, building a
feature list, and plan the work.
Feature-Driven Development (FDD) was developed to meet the

specific needs of a large software development project, where
features relate to a small business value capability
FDD is an agile framework that organizes software development

around making progress on features, where these in the FDD context
are like user stories in Scrum.
Feature-Driven development is the agile methodology that popularized

if you were to follow diagrams as are used for tracking and diagnostic
tool now used by other agile approaches.
A feature is a small, client-valued function expressed in the form

<action><result><object> Examples are:
P a g e 130 |
65
“Complete the login process”
"Calculate the total of a sale"
"Authorize the sales transaction of a customer"
FDD recommends the set of good practices derived from the Software
Engineering:
Domain object modeling. In this practice, teams explore and

explain the domain or business environment of the problem to be
solved
Developing by feature. This involves breaking functions down into two

week or shorter chunks of work and calling these features
Individual class (code) ownership. With this practice, areas

of code have a single owner for consistency, performance, and
conceptual integrity.
Feature teams. These are small dynamically fault teams that vet
designs and allow multiple design options to be evaluated first before
a design is chosen. Features help teams mitigate (reduce or remove)
risks associated with individual ownership
Inspections. These are reviews that help ensure good quality and
development
Configuration management. This involves label income, tracking

changes, and managing the source code. This also applies to physical
(non-software) products such as documentation
P a g e 131 |
65
Regular builds. Through regular bills, the team makes sure the
new code integrates with the existing code (this also applies to
physical products in which case the integration may refer to physical
or electrical interfaces)
Visibility of progress and results. This practice tracks progress based

on completed work
P a g e 132 |
65
Cumulative flow diagrams (CFD’s)

These are valuable tools for tracking and forecasting by delivery of
value, helping us gain insight into projects issues, cycle times, and
likely completion dates.
CFD’s are stacked area graphs that depict the features that are in
progress, those remaining, and those completed over time:
The above diagram shows the features completed verses the features
remaining for a project that is still in progress. The green area
represents all the planned features to be built.
This number rose from 400 to 450 in June and then to a 500 in
August as additional features were added to the project. The yellow
section clocks the work in progress, and the grey section shows the
number of features completed on the project.
P a g e 133 |
65
Limiting WIP helps identify bottlenecks and maximize throughput on a

project - just like limiting the number of cars on a busy freeway
helps traffic flow faster. On software projects, WIP limits equate to
the number of features that are being worked on but are not yet
accepted by the business.
Earned Value Management

This is a technique used to measure the scope, schedule and cost
performance compared with plans, by comparing be completed
products and the actual costs and time taken against their
schedule and cost estimates.
Imagine you are 50% through the schedule of a project, and that you
have spent 50% of your project. Are you going to complete on time
and on budget? The answer is you don’t know.
You see, it all depends on your actual progress in terms of completed

products. Put another way, how much is your earned value?
P a g e 134 |
65
Earned value removes the ambiguity by adding a third metric called
percentage complete.
By using several simple formulas, you can track schedule and cost
variances, plus schedule and costs performance indices. Using these,
you can predict future progress and to implement corrective actions
to stay on track.
Find out more HERE!
P a g e 135 |
65
Earned Schedule Management

Walter Lipke is the pioneer who created and evolved the Earned
Schedule technique and tool to overcome the disadvantages of the
regular Earned Value Management (EVM) technique.
There are FOUR main drivers at play here – Critical Path Analysis, The
Critical Chain Method, Earned Value Analysis and Earned Schedule
Analysis, with ALL four providing a powerful set of tools for the project
manager.
I will assume that you are already familiar with the critical path and
its use of the critical tasks forming the critical path itself, along with the
non-critical tasks and their associated float or slack.
This technique is used in the planning, execution, monitoring and control

of the project.
Earned Value Management (EVM) on the other hand, is used in the

delivery phases of the project, and here I am referring to the
Monitoring and Controlling of the project.
While monitoring is all about collecting data to determine the current

status and progress, then going on to determine the forecast future,
Controlling is all about taking any required corrective actions to
ensure the project continues to plan.
Earned Value Management comes into its own here.
This is a well-established technique with a set of formulas to gather vital

information to establish the current progress thus far, and to forecast
the remaining project future.
Earned Value Management must continue to be used, but it has an

Achilles Heel hiding in plain sight.
You see, once a project is about two thirds complete, the EVM variance
and Index formulae start to provide skewed results.
P a g e 136 |
65
These EVM shortcomings are exactly what lead Walter Lipke (and
others) to develop the Earned Schedule Methodology.
So, let me be clear. You need a blending of both Critical Path
Analysis, Critical Chain, EVM, and Earned Schedule.
Much like EVM, Earned Schedule Management has its own set of formula
and acronyms that need to be understood and applied.
It is vital that you have a firm understanding of EVM first and use that as
a basis for learning Earned Schedule.
The results for YOU, will be far better control of your projects
and precise prediction of future progress.
In short, your projects will perform better than others while consistently
coming on time and schedule.
Learn more about Earned Schedule HERE!
P a g e 137 |
65
Technical Debt
Technical Debt has gained momentum with the core concept identifying a
serious problem that many project teams are struggling to manage.
People under deadline pressure take shortcuts, which is one of

several ways in which project management is a key determinant of
technical debt. A realistic plan needs to set aside time to address
technical debt.
You will also find Technical Debt lurking inside legacy systems – of the
software type and other disciplines. You need a practical guide to
manage and attempt to banish the business harm that technical debt
can bring both in agile and traditional predictive project methods as
well as other industries such as process control and multi-discipline
projects.
Find out more HERE!
Check out our complete range of project management

related online training HERE:
https://www.projex.com/courses
P a g e 138 |
65

Methodologies Senior Project Managers Need

Uploaded by

Copyright:

Available Formats

You might also like

Methodologies Senior Project Managers Need

Uploaded by

Document Information

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

Methodologies Senior Project Managers Need

Uploaded by

Copyright:

Available Formats

Methodologies Senior Project

Grow Your Career

Senior Managers Project Management Overview

Instead of getting overwhelmed by this wealth of options, it makes

It is also helpful to grasp a working understanding of the vocabulary

Check out our range of project management related online training

The Best Project Management Methodologies for 2023

Projects are simply a method for managing and delivering change, so

Traditional methodologies tend to be plan-driven, that is, where

As each gate review is passed, the project cannot return to the

Back in the 1990s a different approach was envisaged and techniques

Methodologies can also be known as frameworks since they support

Traditional waterfall methods are more suited to projects that need

So, I have pulled together a list of different project management

Let's make a start!

How do you choose the right management methodology?

I'm glad you asked! It is a set of principles, approaches, and practises

It should also be chosen for the most efficient and effective

Why are there so many different project management methodologies?

As a standard guideline, a project management framework provides

How a project management methodology helps

It helps you to define roles and responsibilities, decision making and

A project management methodology describes a set of processes for

By following a project management methodology, you will create

A typical project management lifecycle

The Initiation process. Here, key stakeholders are identified, and

The Monitoring and Controlling process. The actual progress is

Choosing the most appropriate method will be driven by the type of

The waterfall or predictive method is the traditional way to manage

This is a generic term for a traditional new product development

Agile product development processes are more common because they

The Agile approach relies on sprints, cycles that combine development

The term refers to the graphical depiction of a development process in

This is also known as a plan-driven process. This is a style of

The work plan is based on execution of a sequential and linear set of

Waterfall is a rigid approach to project management and assumes you

For most project endeavours this is not realistic or highly optimistic

Waterfall or plan driven processes are so named because they

Plan-driven processes are often called sequential processes because

Waterfall is best used when:

▪ Your project end deliverable is clearly defined, and changes

▪ The project stakeholders have made clear the project

▪ This approach works well when applied to problems that are

▪ It works well if your project will be delivered within a

▪ It is suitable when your project change control process is

▪ Waterfall is good when your project is not taking place in a

▪ It works when roles and responsibilities clearly understood

▪ Waterfall projects normally require full funding from the start

As part of planning, the project timeframe is split into a series of stages

Once approved, there is no going back! Just like a waterfall flowing

In this basic system, a team must complete one step before

Managers find this system very straightforward and easy-to-

The waterfall method is commonly used for projects of an industrial

The construction industry is a good example of using the waterfall

Here is an example of typical phases of the waterfall project:

The Waterfall method best suits teams in manufacturing and construction

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

Before moving to the next stage or phase, there is usually a review

The waterfall approach is ideal for projects that have specific