BMS 038 Project Management Methodologies Notes

BMS 038 PROJECT MANAGEMENT METHODOLOGIES NOTES
BMS 038: PROJECT MANAGEMENT METHODOLOGIES

Introduction
In order to achieve goals and planned results within a defined schedule and a budget, a manager
uses a project. Regardless of which field or which trade, there are assortments of methodologies
to help managers at every stage of a project from the initiation to implementation to the closure. A
methodology is a model which project managers employ for the design, planning, implementation
and achievement of their project objectives. A project management methodology is a system of
practices, techniques, procedures and rules used by those who are involved in a project. There are
different project management methodologies to benefit different projects.
Project management methodology helps in :-
✓ Work authorization
✓ Project planning
✓ Designing work breakdown structure
✓ Schedule planning
✓ Financial planning
The project management methodologies include:-

1. Traditional methodologies
✓ Critical Path Method (CPM)
✓ Project Evaluation and review program (CPM)
✓ Waterfall
✓ Critical Chain Project Management (CCPM)
2. Project Management Institute – PMBOK Guide Method
3. Agile methodologies
✓ Agile
✓ Scrum
✓ Kanban
✓ Extreme Programming (EP)
✓ Adaptive Project Framework (APF)
4. Change Management methodologies
✓ Event Chain Methodology (ECM)
✓ Extreme Project Management (EPM)
5. Process based methodologies
✓ Lean
✓ Six Sigma
✓ Lean Six Sigma
6. Others
By Gladys Kimutai Page 1 of 62

✓ Prince 2
✓ PRiSM
Programme Evaluation Review Technique (PERT) and Critical Path Method (CPM)
Programme Evaluation Review Technique (PERT) and Critical Path Method (CPM) are two of
the most widely used techniques in project management. Network analysis entails a group of
techniques used for presenting information relating to time and resources so as to assist in the
planning, scheduling and controlling projects. The information usually represented by a network
includes the sequences, interdependencies, interrelationships and criticality of various activities of
the project. The main objectives of project management can be described in terms of a successful
project, which has been finished on time, within the budgeted cost and to technical specifications
that satisfy the end users. Planning, scheduling and controlling are the main tasks for any project
manager. Project planning calls for detailing the project into activities, estimating resources and
time for each activity and describing activity interrelationships. Scheduling requires the details of
starting and completion dates for each activity. Control requires not only current status information
but also insight into possible trade-offs when difficulties arise.
Basic concepts used in PERT and CPM

➢ Network. It is a logical and chronological set of activities and events, graphically illustrating
relationships among the various activities and events of the project.
➢ Project. This is a group of activities and events with a definite start and end as well as both
human and financial resources. Examples include constructing a dam, building a house,
designing a new product among others.
➢ Activity. It is a task or job requiring resources to be accomplished. Examples include
collecting data, answering a question in an examination, painting a wall among others. The
activity is depicted by a single arrow ( ) on the project network. The activity arrows are
called arcs.
i. Predecessor activity: Are activities that must be completed prior to the start of another
activity.
ii. Successor activity: Are activities that cannot be started until one or more of the other
activities are completed.
iii. Concurrent activities: Are activities that can be accomplished together at the same time.
➢ Event. An event represents a specific accomplishment in the project and takes place at a
particular instant of time. It is a time oriented reference point that signifies the end of one
activity and the beginning of another. Events are usually represented by circles ( ). The
event circles are called nodes. All activity arrows must begin and end with event nodes as
shown below: -
Start Finis
Activity h
Eve
nt Even
t

Types of events
i. Merge events: it’s where one or more activities join an event.
ii. Burst event: it’s where more than one activity leaves an event.
iii. Merge and burst event: It’s where more than one activity join and leave an event.
Merge event burst event merge and burst event

➢ A path is a series of adjacent activities leading from one event to another
➢ Critical path. It is the sequence of critical activities that forms a continuous path between the
start of a project and its completion.
➢ Critical activity. It’s an activity that if slightly delayed, will hold up the scheduled completion
date of the entire project.
➢ Dummy activity: it is represented by a dashed arrow on the project network and is inserted in
the network to clarify activity pattern in the following situations:-
i. To make activities with common starting and finishing events distinguishable
ii. To identify and maintain the proper precedence relationship between activities that
are not connected by events.
Guidelines for construction of network diagrams

1. Each activity must be represented by one and only one arrow in the network.
2. No two activities can be identified by the same beginning and end events. In such cases, a
dummy is introduced to resolve the problem.
3. Before an activity can be undertaken, all activities preceding it must be completed.
4. The arrows depicting various activities are indicative of the logical precedence only. The
length and bearing of the arrows are of no significance.
5. The flow of the diagram should be from left to right.
6. Arrows (activities) should be kept straight and should not be crossed.
7. Angle between the arrows should be as large as possible.
8. Dangling must be avoided. This happens when precedence and inter-relationship of the
activities are not properly identified.
9. The general rule (Fulkerson’s rule) for numbering the events is that no event can be
numbered until all preceding events have been numbered. Therefore, the number at the head
of an arrow is always larger than that at its tail.
Example
Draw a network for a project of erection of steel works for a shed. The various elements of the
project are as under:

Activity code Description Prerequisites

A Erect site workshop None
B Fence site None
C Bend reinforcement A
D Dig foundation B
E Fabricate steel works A, C
F Install concrete plant B
G Place reinforcement C, D
H Concrete foundation G, F
I Paint steel works E
J Erect steel work H, I
K Give finishing touch J
Solution
E
I
A C
G H J K
B D
F
TIME ESTIMATES IN NETWORK ANALYSIS.

Activity time is a forecast of the time an activity is expected to take from its starting time to its
completion, under normal circumstances. The basic objective of the time analysis is to get a
planned schedule of the project. The plan should include:-
a. Total completion time for the project
b. Earliest time when each activity can begin
c. Latest time when each activity can be started, without delaying the total project
d. Float for each activity i.e. amount of time by which the completion of an activity can be
delayed without delaying the total project completion
e. Identification of critical activities and critical path.
➢ Slack time of event: It’s the difference between the latest event time and earliest event time

➢ Head Event slack (HES): It is the slack at the head (or terminal point) of an activity. It is the
difference between the latest event time and earliest event time at its head (or terminal point
or node)
➢ Tail Event Slack (TES): It is the slack at the tail (or starting point) of an activity. It is the
difference between the latest event time and the earliest event time at its tail (or starting point
or node).
➢ Earliest Finish Time (EFT): It’s equal to the latest finish time of the activity plus the duration
of that activity.
➢ Latest Start Time (LST): It is equal to the latest finish time of the activity minus the duration
of that activity.
➢ Total float: It represents the amount of time by which an activity can be delayed without
delaying the project completion date:
Total Float = Latest Start Time - Earliest Start Time
Total Float = Latest Finish tim e - Earliest Finish Time
➢ Free float: It is that portion of the total float within which an activity can be manipulated
without affecting the float of subsequent activities.
Free Float = Total Float - Head Event Slack
➢ Independent float: It is that portion of the total float within which an activity can be delayed
for start without affecting the float of preceding activities.
Independent Float = Total Float - Tail Event Slack
➢ In case negative value is obtained, it is taken as zero.
Critical Path Method

CPM emphasizes the relationship between applying more men or other resources to shorten the
duration of given jobs in a project and the increased cost of these additional resources. With CPM,
the amount of time needed to complete various parts of the project is assumed to be known with
certainty. The relation between the amount of resources employed and the time needed to complete
the project is assumed to be known.
The iterative procedure of determining the critical path involves the following steps:
1. Break down the project into various activities systematically. Label all activities. Arrange
all the activities in logical sequence. Construct the arrow diagram.
2. Number all the nodes (events) and activities. Find the time for each activity considering it
to be deterministic. Indicate the activity times on the arrow diagram.
3. Calculate the earliest start time, earliest finish time, latest start time and latest finish time.
Tabulate various items i.e. activity normal times, earliest times and latest times.
4. Determine the total float for each activity by taking difference between the earliest time and
latest time for each node.

5. Identify the critical activities and connect them with the beginning node and the ending
node in the network diagram by double line arrow. This gives the critical path.
6. Calculate the total project duration.
7. If it is intended to reduce the total project duration, crash the critical activities of the
network.
8. Optimize the cost.
9. Update the network and smooth the network resources.
Example
The following table gives the activities in a construction project and other relevant information:
Activity 1-2 1-3 2-3 2-4 3-4 4-5
Duration 20 25 10 12 6 10
Required:
i. Draw the network for the project.
ii. Find the critical path.
iii. Find free, total and independent floats for each activity.
Advantages of CPM
✓ Better scheduling
✓ Process prioritization
✓ Exact estimation of time and cost
✓ Improves team coordination
Disadvantages of CPM
✓ Scheduling needs experience
✓ Inflexible
✓ Difficult to manage
✓ Designing CPM is time consuming
PROGRAMME EVALUATION AND REVIEW TECHNIQUE (PERT)

Steps involved in developing PERT network.
1. Develop a list of activities that make up the project including immediate predecessors.
2. A rough PERT network is drawn on the basis of the three questions for each activity i.e which
activities precede this one? Which activities follow this one? Which activities are concurrent
with this one?
3. The network is then suitably sketched to conform to rules and conventions.

4. Events are numbered in ascending order from left to right.

5. Time estimates for each activity are then obtained. They are
➢ The most likely estimate (m or t m ). It’s the time the activity will take most frequently if
performed a number of times i.e. the modal value.
➢The pessimistic estimate (b or t p ). It is the longest time the activity can conceivably take.
➢The optimistic estimate (a or t o ): it is that time estimate of an activity when everything is
assumed to go well as per plan.
6. Then, upon the assumption of beta distribution for the activity duration, the expected time, t e
t o + 4t m + t p
for each activity is computed from the following formula t e =
6
7. Using the expected activity time estimates, determine the earliest start time and the earliest
finish time for each activity. The earliest finish time for the complete project corresponds to
the earliest finish time for the last activity.
8. After determining the latest start time and the latest finish time for each activity, compute the
float associated with each activity, the critical path activities are the activities with zero float.
Determine the critical path through the given network.
9. Using the values for b and a which were determined in step 5, calculate the variance (2) of
 t p − to 
2
each activity’s time estimates by  = 

2

 6 
10. Use the variability in the activity times to estimates to estimate the variability of the project
completion date. Using this estimate, compute the probability of meeting a specified
completion date by using the standard normal equation:
 = Due date – Expected date of completion
 Project variance
Where Z = number of standard deviations the due date or target date lies from
the mean or expected date.
11. Crashing or compressing the project may have to be undertaken if the critical path duration (as
the project duration) is not acceptable to the management. Resource allocation may have to be
performed if resources are limited.
Example
1. A small project consisting of eight activities has the following characteristics:-
Time estimates in weeks
Activity Preceding Most optimistic Most Most pessimistic (b)
activity (a) likely (m)

A None 2 4 12
B None 10 12 26
C A 8 9 10
D A 10 15 20
E A 7 7.5 11
F B, C 9 9 9
G D 3 3.5 7
H E, F, G 5 5 5
Required;
i. Draw the PERT network for the project.
ii. Determine the critical path
iii. Prepare the activity schedule for the project.
iv. If a 30 weeks deadline is imposed, what is the probability that the project will be finished
within the time limit?
v. If the project manager wants to be 99% sure that the project is completed on the schedule
date, how many weeks before that date should he start the project work?
2. A project has the following activities and other characteristics
Activity Preceding Time estimates in weeks
activity
Most Most likely Most pessimistic
optimistic
A None 4 7 16
B None 1 5 15
C A 6 12 30
D A 2 5 8
E C 5 11 17
F D 3 6 15
G B 3 9 27
H E, F 1 4 7
I G 4 19 28
Required:
i. Draw the PERT network diagram.
ii. Identify the critical path.
iii. Determine the mean project completion time.

iv. Find the probability that the project is completed in 36 weeks.

v. If the project manager wishes to be 99% sure that the project is completed on the
scheduled date, how many weeks before should he start the project?
Advantages of PERT
✓ Better activity analysis
✓ Improved department coordination
✓ Uses what – if -analysis
Disadvantages of PERT
✓ Subjective analysis
✓ Time focussed
✓ Resource intensive
Differences between PERT and CPM

PERT CPM
- It’s a probabilistic model with - It’s a deterministic model with well-

uncertainty in activity duration. known activity (single) times based
upon the past experience.
- It is activity oriented as the results of
- It is event oriented as the results of
calculation are considered in terms of
analysis are expressed in terms of
activities or operations of the project.
events or distinct points in time
indicative of progress.
- The use of dummy activities is - The use of dummy activities is not

required for representing the proper necessary.
sequencing.
- It is used for repetitive jobs.

- It is used for non-repetitive jobs.
- It is applied mainly for planning and

- It is used for construction and business
scheduling research programmes.
problems.

- PERT analysis does not usually - CPM deals with costs of project
consider costs. schedules and their minimization.
WATERFALL
Waterfall is a project management approach where a project is completed in distinct stages and
moved step by step toward ultimate release to consumers. You make a big plan upfront and then
execute in a linear fashion, hoping there won’t be any changes in the plan. When you take
traditional project management and apply it to software development, you get Waterfall. As such,
no one invented waterfall - instead, we gave it name once we realized that there are others ways to
manage projects (like agile project management).
Waterfall was the first software development methodology, inherited from manufacturing and
construction industry where you can't afford to iterate (after you've built a tower or a bridge you
can't go back to "improve" the foundation). But because software is prone to frequent change,
waterfall is not the best solution. Waterfall is often mentioned alongside Agile and stands in
contrast to it. The main difference between them is that waterfall doesn't react well to frequent
changes, which is why it gets a bad reputation in software development community, where
frequent changes are the norm.
Phases in waterfall projects

All tasks on waterfall projects are grouped by type of activity and each projects follows the same
phases:
✓ Requirements - where we analyze business needs and document what software needs to do
✓ Design - where we choose the technology, create diagrams, and plan software architecture
✓ Coding - where we figure out how to solve problems and write code
✓ Testing - where we make sure the code does what it supposed to do without breaking anything
✓ Operations - where we deploy the code to production environment and provide support
Once you put all the activities on a Gantt chart, you get something that looks like slopes of a
waterfall, hence the name. Usually 20–40% of the time is spent on requirements and design, 30–
40% on coding, and the rest on testing and operations. Activities on waterfall projects have to
happen in the exact order and one set of activities can't start before the previous one ends. This is
why planning is the most important thing on waterfall projects: if you don’t plan right, a phase will
be late and will push every other subsequent phase, thus putting the whole project over deadline.
The problem with using waterfall method on software project is that planning is very tricky in
software development. You can never be 100% sure how much time you'll need on something or
how much time you'll spend debugging. As a result, waterfall is risky.

Advantages of waterfall
✓ Extensive documentation: Because you can't go back to a previous activity, you're forced to
create a comprehensive documentation from the start, listing all the requirements you can think
of.
✓ Knowledge stays in the organization: When you have extensive documentation, knowledge
won't get lost if someone leaves. Also, you don’t have to spend time on training new members
as they can familiarize with the project by reading the documentation.
✓ Team members can better plan their time: Because everyone knows in advance on what they'll
work, they can be assigned on multiple projects at the same time.
✓ Easy to understand: Waterfall projects are divided in discrete and easily understandable phases.
As a result, project management is straightforward and the process is easily understandable
even to non-developers.
✓ Client knows what to expect: Clients can know in advance the cost and timeline of the project
so they can plan their business activities and manage cash flow according to the plan.
✓ Client input not required: After requirements phase, client input is minimal (save for occasional
reviews, approvals, and status meetings). This means you don't have coordinate with them and
wait for when they're available.
✓ Easier to measure: Because waterfall projects are simple, it's much easier to measure your
progress by quickly looking at a Gantt chart.
✓ Better design Products have a higher cohesion because during the design phase you know
everything that must be taken into account. There is no one-feature-at-a-time problem that
leads to usability problems down the road.
Disadvantages of waterfall
✓ No going back: Once you're finished with one activity, it's difficult and expensive to go back
and make changes. This puts a huge pressure on the planning.
✓ No room for error during requirements phase: Everything relies heavily on the requirements
phase and if you make an error, the project is doomed.
✓ Deadline creep: Once one activity is late, all the other activities are late too, including the
project deadline.

✓ QA too late to be useful: Testing is done at the end of the project which means that developers
can't improve how they write code based on QA feedback.
✓ Bug ridden software: Because the testing is done at the end, most teams tend to rush the testing
in order to deliver the project on time and hit their incentives. This short-term wins lead to sub-
par quality and long term problems.
✓ Not what the client actually needs: Most of the time, clients can't articulate what they need
until they see what they don't need. If the client realizes they need more than they initially
thought, the project plan will need a major overhaul (as well as the budget).
✓ Unexpected problems: Designers can't foresee all the problems that will arise from their design,
and once those problems surface, it's very difficult to fix them.
On what types of project you should use waterfall

Waterfall is suited for projects where:
✓ budget, requirements, and scope are fixed (eg. you're building a one-off project which doesn't
need further development)
✓ you can accurately estimate the work (you're familiar with technology and you've done the
same work before)
✓ you can't afford to iterate (e.g. you're building a heart rate monitoring software)
✓ project is innately low-risk (you're building a clone of something that already works)
✓ project has a hard ship date (e.g. you have to ship a video game by Christmas)
✓ your users can't or won't update software (doesn't apply to web applications where updates are
seamless)
You shouldn’t use waterfall:

✓ where a working prototype is more important than quality (eg. you first need to test if there’s
a market demand)
✓ when you don't know what the final product should look like
✓ where client doesn't know exactly what they need
✓ when the product is made for an industry with rapidly changing standards
✓ when you know you won't get the product first the right time and have to incorporate user
feedback
✓ when your users are happy with v1.0 and you can ship additional features as time goes on
Whether you'll use agile or waterfall doesn't matter on your preference but type of project and your
customer/client. While strictly speaking agile is better for software development (see the statistics
here), if you can't iterate, you have to use waterfall.
Waterfall is not that different from agile

Waterfall is always mentioned as the antithesis to Agile, which makes sense. After all, waterfall
projects have a hard time dealing with changes while agile projects welcome change. At least in
theory.
The truth is, no matter what methodology you use, change is not a good thing. Change always
means additional scope, delay, and expenses. Agile is better at minimizing the effects of change,
but they still happen. Also, agile teams have the culture where change is OK, which is maybe the
most important benefit of being agile. But once you scratch behind the surface and look both from
purely process perspective, waterfall is very similar to agile.
Once you break down any agile workflow, you'll still get a set of activities that follow one another,
which eerily resembles Waterfall. And if you treat waterfall projects as smaller phases within a
big project, you'll end up with agile. In other words, activities on a project are waterfall and if you
treat the whole project as a series of iterations, it’s agile.

Whether you're agile or waterfall ultimately depends on whether your client expects the first
version to be bad. And waterfall projects are projects where the client decided on zero iterations.
In agile projects, the number of iterations is decided on by the customer. Because things
are all done within an iteration in agile, the logical assumption was that an iteration
equaled a project. But an iteration is more properly referred to as a phase or sub-phase of
the project. - PMI
As you can see, agile still fits in the traditional project management, only the point of view changes.
Instead of treating each iteration as a separate project, iterations are just phases in one big project.
The real difference between the waterfall method and agile is that in waterfall the clients is heavily
engaged at the beginning of the project and then their engagement declines; while in agile, the
client is constantly engaged.

So what this all means in practice? It means no organization is purely agile or waterfall. Agile and
waterfall are more about the culture and type of work the organization does than how they do it.
You’ll find that most organizations divide the project into waterfall milestone but work according
to agile principles between those milestones.
A problem common with comparing agile and waterfall is the labeling. Few, if any,
companies are purely "agile" or "waterfall". They are more mindsets that encompass a
wide variety of practices and approaches to development. Labels are convenient for
helping make an argument, often with cute little straw-man statements to help reinforce
preconceived notions. - Clinton Keith
Critical Chain Project Management (CCPM)

Critical Chain Project Management is a schedule network analysis technique that takes into
account task dependencies, limited resources availability (people, equipment, physical space), and
buffers necessary to successfully complete the project. CCPM allows a project manager to plan
and manage project’s schedule by concentrating on resources used in Critical Path (also known as
the Critical Chain).
The origin of Critical Chain Project Management
Critical Chain Project Management was developed by Dr. Eliyahu M. Goldratt in 1997 as a
response to inability to complete tasks on time and within budget. Dr. Goldratt first introduced the

method in his work on Theory of Constraints (TOC), which focuses on identifying and fixing
bottlenecks in order to improve the entire workflow.
Why we need CCPM
Traditional project management is based on predictable experience and predictable tools. But, as
much as we would like to be able to control every single aspect on a project, we can’t. In traditional
project management, a lot of time is spent on making accurate time estimates and reduce risks,
which delays projects. Critical Path Method isn’t very helpful either because it’s based on the idea
that all the resources will be available at any given time, which is not always the case. Also,
according to Critical Path Method, if any activity is delayed, the delay will pass on to the next
activity and delay the entire project. Unlike other techniques, Critical Chain Optimization (a huge
part of CCPM) helps us determine which time estimates we can shorten and it allows us to evenly
distribute workload thanks to flexible start times. Finally, Critical Chain Optimization ensures we
don’t need safety margin and all tasks are completed ahead of schedule.
What is CCPM
Critical Chain is the longest path in the network diagram that takes into consideration task
dependency and resource availability. It’s a modified form of Critical Path Method where project
activities use aggressive time and have access to unlimited resources. While Critical Path Method
uses Float, CCPM uses buffers as strategic points that eliminate uncertainty around projects.
There are four types of buffers:
1. Project Buffer - protects the project from missing its scheduled end date and keeps the
completion date unchanged. It is inserted at the end of the project network diagram, between
the last task and the completion date. It protects project completion date, which might vary due
to the changes in activity durations in the critical chain. In other words, the size of the project
buffer depends on the activities in the critical chain.
2. Feeding Buffer - is inserted between the last task on a noncritical chain and the critical chain.
These buffers are typically added to a non-critical chain so that any delays on a non-critical
chain don’t affect the critical chain.
3. Resource Buffer - these are set on the Critical Chain to ensure appropriate resources (,
equipment) are available throughout the project when needed. These resources are commonly
known as Critical Resources.
4. Capacity Buffer - it sets on-call resources necessary in case unforeseen budget issues arise.
The specific steps in CCPM
There 9 steps you need to do in the CCPM process:
1. Reduce all time estimates by 50% (the protection that is cut is inserted as a buffer in the project)
2. Level the project plan and remove resource retentions (in this phase, a critical path is
transformed into critical chain).
3. Add a portion of reduced task estimates into the Project Buffer and insert it at the end of the
project
4. Insert Feeding Buffers at points where non-critical chain path meets critical chain path

5. Protect the Critical Chain from unavailable resources by placing Resource Buffers where
appropriate
6. Insert Capacity Buffers where needed
7. Schedule tasks as late as possible (this will help you prevent multitasking)
8. Encourage aggressive task completion time and emphasize the importance of start time to
complete the tasks as quickly as possible
9. Manage buffers and gain information necessary for controlling the plan and taking recovery
actions if needed
Here’s a real world example of CCPM in action. Let’s say you’re building something. You created
a plan and built a schedule based on the critical path. Although you have given enough thought to
each project stage and started working on it, you suddenly realize there isn’t enough equipment
nor people to complete the project on time. To prevent the project from failing, you consider
resource allocation into your project plan and modify the critical path. Essentially, you change the
critical path into a critical chain and this way you create a much more realistic schedule.
What are the benefits of CCPM
Although CCPM is mainly used in multi-project environments that require a lot of resources, you
can apply it on your projects regardless of whether you are running a small company or a big
corporation. CCPM is probably one of the most practical and the most important project
management technique because of a number of benefits it offers:
✓ It allows people to become more focused on their tasks, thus increasing team productivity and
efficiency
✓ It helps your team overcome the Student Syndrome phenomena (when people start working
more as the deadline starts approaching)

✓ It avoids mismanagement of floats

✓ It considers the minimal time needed to complete the project
✓ It accelerates project completion
✓ It makes significant reduction in capital requirements
Agile
Agile is an approach to project management that favors responding to change over careful
planning. Agile is not a methodology but a set of principles (as defined in Agile Manifesto in 2001)
that suggests how we should approach project management. Basically, there are two ways you can
manage software development projects:
✓ Waterfall: plan everything in advance, then build according to the plan for the next whole year
✓ Agile: plan what you'll build in the next few weeks, and see how it goes from there
How to know whether you're agile? Just because you're using Kanban boards or Scrum doesn't
automatically mean you're agile. To really be agile, you have to share the agile values, as defined
in Agile Manifesto.
Agile Manifesto
In 2001, 17 software developers met in Utah to discuss their processes that were different from the
usual waterfall project management approach. Together, they defined the concept of agile software
development in Agile Manifesto. Today, when we say that some methodology is agile, it means it
follow the value and principles from Agile Manifesto. The group recognized that there's no one-
size-fits-all approach, so Agile Manifesto doesn't prescribe how to run projects. Instead, it defines
the mindset on how to best manage software projects. Most important part of Agile Manifesto are
the 4 values. They are the heart of what it means to be agile.

Agile values help you focus on what's important. For example, one of the values is "working
software over comprehensive documentation". It doesn't mean that documentation is bad – it
means that if you have to choose whether to spend your time on writing a detailed user story or
fixing a bug, you should choose the latter.
Individuals and interactions over processes and tools
Knowledge workers prefer autonomy. So in software development it's more important to let people
solve problems by collaborating than forcing them to follow a procedure for the sake of satisfying
some dusty policy.
Every company needs processes (especially after they've grown to a certain size), but you must
know why a rule is in place and when you should break it. For example, when daily stand-ups stop
being useful, don't force them just because some agile methodology says you must have them.
The way you know when process doesn't work is when people can't collaborate efficiently
anymore. People are the engine behind every project. If they can't interact because of hierarchy or
a lengthy/complex protocol, they have to spend more time on managing tools and processes than
doing their job.
Good process serves you so you can serve customers. But if you’re not watchful, the
process can become the thing. The process becomes the proxy for the result you want. You
stop looking at outcomes and just make sure you’re doing the process right. It’s not that

rare to hear a junior leader defend a bad outcome with something like, “Well, we followed
the process.” A more experienced leader will use it as an opportunity to investigate and
improve the process. The process is not the thing. It’s always worth asking, do we own the
process or does the process own us? – JeffBezos
There’s something really wrong with our definition ofwhat a ‘completed project’ is. If it
means ‘Did Chris get all his project tasks done?’ then it was a success. But ifwe wanted
the project in production that fulfilled the business goals, without setting the entire business
on fire, we should call it a total failure. - The Phoenix Project: A Novel About IT, DevOps,
And Helping Your Business Win
Working software over comprehensive documentation

In traditional project management, phases happen in sequence and if you mess up the first phase
(requirement gathering and documentation), every other phase will suffer. That's why waterfall
needs comprehensive documentation. But on agile project we expect things to change.
Do you really want to spend your whole time updating the documentation? What matters the most
is having a working product that real users can test. If you had to choose between fixing a bug and
writing a report on it, fixing it is the best use of your time.
This doesn't mean that you should forsake documentation. Developers fall in this trap often and
write terse one-line user stories, which creates trouble for QA and maintainers because they can't
figure out the proper user acceptance criteria.
The perfect documentation should be "Just Barely Good Enough". Too much and it goes to waste
or can't be trusted because it's out of sync with code; Too little and it's difficult to maintain and get
new team members up to speed.
When writing documentation, you should ask yourself what would you want to know if you joined
the team tomorrow and document based on that. If you have trouble with documentation, grab a
copy of Living Documentation by Cyrille Martraire.
Customer collaboration over contract negotiation

Contracts create the culture where change isn't an option. Agile creates the culture where change
is expected. But how do you manage change? By collaborating with customers.
Agile presupposes that you have unlimited access to your customers and that you can always sit
down with them and talk. Developers are natural problem solvers but they need access to the
customer so they can better understand what the real problem is.
Contracts are useful, but they have a nasty side effect: people tend to care more about delivering
the project within time and budget than fulfilling the real business goal. Further, when the team
falls behind schedule, they are pressured to get things done which results in frustration, panic, and
lower quality.

Also, when you sign a contract early in the lifecycle, you're guesstimating and more often than
not, you're wrong. But you still try to hit the milestone even though they have nothing to do with
real needs.
That's why agile favors customer collaboration and delivering work in small increments. This lets
scope work as you gather more information and discover what you don't know.
Responding to change over following a plan

The more time you spend on planning, the more you resist changes lest your efforts go to waste.
But the goal is not to deliver project according to the plan (within time and budget) - the real goal
is to satisfy some business goal, and if it means completely changing your plan, then so must be
it.
It's more important to build what you really need than to blindly follow an obsolete plan.
Developers may hate it when they their code becomes invalidated, but clients hate it even more
when they don't get the product they need.
That's why agile favors shorter lead time and encourages teams to chop things up in smaller
deliverables so they won't have to redo large chunks of work. This means that you are never done
with requirements gathering and design phases but you continually revisit them throughout the
lifecycle.
Elements of agile
✓ Culture where change is expected: Agile isn't about using Kanban boards, having daily
stand-ups, or anything similar (those are elements of specific agile methodologies). Agile, at
its core, is mindset where everyone, from employees to clients, expects change. You can't
promise your client everything at once or a firm deadline because both you and the client know
that's unrealistic. But you can promise them that you'll give them something they can use and
listen.
✓ Incremental development: Each iteration builds on previous work, making the product better
gradually. Also, you don't wait for completed work to pile up before releasing it all at once -
you release it as soon as it's finished. An iteration might not add enough features to warrant a
marketing campaign, but that doesn't matter because the ultimate goal is to give customers
value.
✓ Frequent release: Because software is developed incrementally, you can have shorter cycles,
where at the end of cycle you ship new features/updates. This way, customers can get value as
soon as possible and validate it. If the work doesn't satisfy their needs, you can learn that before
you spend more time on development.
✓ Short feedback loop: Because releases are more frequent, you can get feedback faster. And
because you can get feedback faster, you can more quickly change the product and give value.
✓ High level of client involvement: In order to reap the full benefits of short feedback loop and
frequent releases, you need a high level of client involvement. You need to talk to your client
after each cycle and see how they use the software and if it they derive value from it.

Sometimes the client is not available to give you feedback. Some agile methodologies (like Scrum)
solve this problem by having a special role on the team called Product Owner. This person serves
as a customer representative and act on behalf of the customer. If a developer has any question,
they ask the product owner instead of the customer. Product owner also reviews progress and
reevaluates priorities at the end of each iteration
Advantages and disadvantages of agile

Today, agile is such a buzzword that teams outside software development try to incorporate it into
their workflow. But agile is not for everyone. For example, a marketing agency can never
implement agile because clients don't want to pay for a half-finished marketing campaign and
iterate. There are revisions, but their number is clearly specified in the contract. Plus, there are no
such thing as a "working increments" - you either have the deliverables or you don't. Agile isn't
the right approach for every software project either. If you don't have access to customers, can't
iterate, or if you have complex organizational structure, it's very difficult to adhere to agile
principles.
Agile works best when

✓ You can't estimate the time you'll need and don't know the full scope of requirements
✓ You don't know whether there's a need on the market for your software
✓ You can't map out the business needs so the design needs to emerge through trial and error
✓ You have unlimited access to your customer who's ready for extensive involvement
✓ You can afford to iterate and don't need to deliver a fully functional software at once
✓ Neither you nor your client have a complex bureaucracy that delays decision

✓ Clients don't have a fixed budget/schedule

✓ You need to capture the market before there's any competition
✓ Your customers don't have trouble updating their software (or don't even notice it, e.g. they
use a web app)
As you can see, agile is more suited for small-to-medium size organizations than corporations. The
reason is simple: the less people there are, the easier it is to make a decision and respond to change.
Also, agile is more suited for product companies over consultancies. Agile is also great for startups,
where "fail fast" is the dominant mantra. Venture capitalists encourage startups to try crazy ideas
and let the markets do the work. Most of the ideas will fail those few that succeed will change the
world.
Advantages of agile
✓ You can deploy software quicker so your customer can get value sooner rather than later
✓ You waste less resources because you always work on upto- date tasks
✓ You can better adapt to change and respond faster
✓ Faster turnaround times
✓ You can detect and fix issues and defects faster
✓ You spend less time on bureaucracy and meaningless work
✓ There's a big community of agile practitioners with whom you can share knowledge
✓ You can get immediate feedback (which also improves team morale)
✓ Developers can improve their coding skills based on QA feedback
✓ You don't have to worry about premature optimization
✓ You can experiment and test ideas because it costs are low
Disadvantages of agile
✓ Documentation tends to get sidetracked, which makes it harder for new members to get up to
speed
✓ It's more difficult to measure progress than in waterfall because progress happens across
several cycles
✓ Agile demands more time and energy from everyone because developers and customers must
constantly interact with each other
✓ When developers run out of work, they can't work on a different project because they'll be
needed soon
✓ Projects can become ever-lasting because there's no clear end
✓ Scope creep and experience rot
✓ Clients who work on a specified budget or schedule can't know how much the project will
actually cost, which makes for a very complicated sales cycle (until iteration ends is not
something clients like to hear)
✓ Product lacks overall design, both from UX and architecture point of view, which leads to
problems the more you work on the product.

✓ Teams can get sidetracked into delivering new functionality at the expense of technical debt,
which increases the amount of unplanned work
✓ Features that are too big to fit into one or even several cycles are avoided because they don't
fit in nicely into the philosophy
✓ You need a long term vision for the product and actively work on communicating it
✓ Products lack cohesion and the user journey is fragmented because the design is fragmented.
The more time passes, the more disjointed software ends up.
✓ Short cycles don't leave enough time for the design thinking process so designers have to
redevelop the experience over and over due to negative feedback.
✓ Check here for some more Scrum sprint planning antipatterns and product backlog and
refinement anti-patterns
Workers in tech don’t usually feel like they have the ability to focus on craft — especially when it
comes to visual design. When you're constantly iterating, constantly pushing new versions out, you
can’t invest time in seemingly unnecessary details that will be lost in tomorrow’s update. - Jessica
Hische
SCRUM
Scrum is a project management framework that helps small, close-knit teams develop complex
products incrementally. Scrum focuses on how people work instead of what they do. Scrum relies
on agile principles and is the most popular agile methodology out there. In Scrum, teams develop
software in sprints and release what they've worked on every two weeks. This way, customers get
bug fixes and new features as soon as they're done, and there's less risk altogether.
What is Scrum
Scrum is the most popular agile project management framework that's used in software
development organizations. Scrum can also be used in schools, agencies, government, and other
types of organizations. Scrum was first introduced in early 1990s by Jeff Sutherland and Ken
Schwaber. Scrum got its name from rugby. In rugby, scrum is when a team huddles around the
ball and tries to move it down the field in order to win. Scrum is a metaphor meant to reflect how
everyone needs to work together to complete the project.
How Scrum works

In Scrum, you deliver to your customer new code and functionality every two weeks. Those two
weeks represent one sprint and the whole workflow is built around them. To better understand how
Scrum works, we'll talk about what happens before the sprint, during, and after.
BEFORE SPRINT
Before you can start coding, you first need to plan what you'll work on. In Scrum, there are no big
master plans like in Waterfall where you lock up your resources months in advance. Instead, Scrum
lets you work on one thing for two weeks and then reflect on what you'll work next. Everything

starts with your users/client. First, you get a wish list from your customers in a special format
called user story, which looks like this:
As a (role), I want (feature) so that (reason
e.g. As a manager, I want custom time reporting so that I can calculate my employees'
exact salary.
Then, you create a task for each user story, put it in a backlog, and estimate each task (together
with the team).
Finally, you decide on what items you will work during the sprint. If some item can't be done in
one sprint, it's called an epic and you have three options: split it across several sprints, leave it for
later, or make a new project and form a separate team to work on it.
DURING SPRINT
You set up a Kanban board to visually track progress, see who works on what, and control
bottlenecks. The board is usually split into several task lists (columns):
✓ Backlog - all feature requests and bugs go here first
✓ Next Sprint - tasks you'll work after the team finishes the current sprint
✓ To-Do - what the team needs to complete during the current sprint
✓ In Progress - tasks that the team is actively working on right now
✓ Testing - finished tasks that need to be tested before marked as complete
✓ Done - finished tasks that are ready to be shipped once the sprint end
Once you've decided on what items to work, the team pulls tasks from the To-Do columns and
moves them to In Progress as they start working on them. Once they're finished, the task goes to
Testing; if the task needs more work, it goes back to In Progress; once the task meets the
Definition-Of-Done criteria, it goes to Done and is ready to be shipped. Each day before work, the

team has a daily stand-up). The meeting doesn't take longer than 15 minutes and everyone shares
a quick status update:
✓ Things I have done since yesterday's meeting
✓ Things I am going to get done today
✓ Obstacles I need someone to remove
To measure progress, the team uses a Burndown Chart, which is a graphical representation of work
left to do versus time. That chart shows how efficient the team is, if they're going to ship on time,
and if they need to optimize the process.
AFTER SPRINT
At the end of the sprint, the team reflects on what they've done. They have two reflection sessions:
✓ Sprint review (2h), where they discuss the work they've done and the planned work they didn't
do
✓ Sprint retrospective (1h), where they talk about the process (what went well and what could be
improved in the next sprint)
After the reflection, the team estimates new user stories and decide on what to work during the
next sprint.
Roles in Scrum
There are 3 roles in Scrum:

Product owner
Product owner is the visionary and represents the voice of the customer/user. If a team member
has any questions regarding functionality of some feature, it's product owner's job to clarify the
purpose of that feature. Product owner focuses on the business side of product development and
spends most of the time talking with stakeholders. Product owner doesn't care about the technical
implementation, only the end result.
Product owner's main job is to:
✓ Gather and write user stories
✓ Refine and prioritize backlog
✓ Handle clients and demo new features
Scrum master
Scrum master's role and responsibilities are similar to project manager's, with an emphasis on team
facilitation and making sure the Scrum framework is followed. Scrum master, as opposed to a
traditional project manager, doesn't manage people because that goes against agile principles.
Scrum master's main job is to:
✓ Remove impediments for team members
✓ Facilitate team events
✓ Track sprint progress
✓ Improve processes
The team
The team does all the actual work, from analysis and design to coding and testing. They are self-
organizing and work without supervision. Scrum teams are cross-functional, meaning they don't
have clear sub-role and everyone can do anything. Most teams compromise by hiring T-shaped
workers so, while everyone can do anything, there is still some specialization and work division.
Scrum work only if the team is small, up to 9 people, max. Any team larger than that changes team
dynamics, thus rendering Scrum ineffective.
How to implement Scrum

Scrum is more about about the mindset than some checklist you need to follow to a T. Once you
have agile mindset, here's the most common way companies implement Scrum:
1. Pick a product owner

2. Pick up to 9 cross functional team members

3. Pick a scrum master
4. Create and prioritize a product backlog
5. Refine and estimate items in the product backlog
6. Put up a Kanban board
7. Plan the sprint
8. Have a daily stand-up
9. Work
10. When finished, do sprint review and sprint retrospective
11. Immediately start the next sprint


KANBAN
Kanban is a Japanese term that translates roughly as “ billboard”, is a method that helps
organizations visualize, plan and organize their work by controlling various logistic elements and
prioritizing tasks on boards. As a result, Kanban helps teams eliminate bottlenecks and achieve
outstanding quality improvements. To put it simply, Kanban offers a project manager and his team
the place where they can manage their tasks, lists and files. This boosts the team’s productivity
and helps them complete their projects more efficiently.
One of the most quoted sayings in Kanban is: “Stop starting and start finishing”. With so many
tasks at hand, this seems like a mission impossible. However, with Kanban’s philosophy, you will
be able to create a perfect scheduling system that will tell you what to produce, when to produce
it, and how much to produce. There’s no doubt that Kanban has entered a variety of business areas
and is becoming all the rage. In today’s business world Kanban is known as one of the clearest,
simplest and the most effective tools for project management.
First implementation of Kanban

Back in 1940’s, a Japanese Toyota engineer Taiichi Ohno was fascinated by the system American
grocery stores used to stock their shelves. They stocked only as many items as that day's customers
needed. This inspired him to apply the method in Toyota production system and deliver the same
level of efficiency on their assembly line. Basically, their goal was to keep their inventory low but
always adequate to meet the demand for the parts. They named it Kanban (Khan - Ban), also known
as “just in time” system.
Although it was initially gaining popularity in manufacturing industries, it has undergone some
changes over the last few years and has been modified by David Anderson. With the rise of IT
world and the digital age we are all part of, Kanban method is usually presented online as visual
panels with virtual sticky notes which you can move around to organize tasks and to-do items.
Six core practices of Kanban

After using Kanban system at Microsoft in the mid-2000s, David J. Anderson was so thrilled about
the positive results that he decided to use the method as the essential ingredient of future
continuous improvement of company’s workflow. In his book Kanban - Successful evolutionary
change for your technology business, he focused on five practices that lead to such positive
outcomes:
1. Visualize your work - use the board to represent your workflow, columns to represent the
steps in this process, and list the relevant tasks of work items.
2. Limit work in Process (WIP) - be more effective and accomplish more by doing less.
Delegate only ideal number of tasks to your team. Don't pull more work until your team
completes something.

3. Manage Flow - start where you are, with the existing process, review where inefficiencies
lie and improve continuously. Learn from your mistakes and prevent bottlenecks from
arising again.
4. Make management policies explicit - define the whole process and make sure everyone
understands how things work and what your goals are. For example, define the criteria that
each step of the process has to meet to called “done”.
5. Improve collaboratively - when your team clearly understands the theories about work,
processes and workflow, they are more likely to exchange their ideas and suggest
improvement actions.
Basic Principles in Kanban

Kanban project management is a philosophy which suggests that you can gradually improve
whatever you are working on and implement continuous, incremental and evolutionary changes.
To achieve this goal, you need to follow the four basic principles that underlie this revolutionary
method:
✓ Start with what you do now: The good thing about Kanban is that you don’t need to make
big changes before you implement this methodology. You can simply overlay Kanban
properties on your existing workflow, address issues and make some important changes over
time.
✓ Pursue evolutionary change: Encourage small but evolutionary changes to processes and run
project management that will meet minimal resistance.
✓ Respect the current roles and responsibilities: While you may be satisfied with how certain
elements and processes are working, you also need to seek out the way how to drive out fear
to be able to make necessary future changes. By agreeing to respect the current roles,
responsibilities, and process, you will gain broader support for Kanban initiative. This will
help you implement Kanban method more easily.
✓ Encourage acts of leadership at all levels: You don’t need to be a team leader or an executive
to encourage continual improvement and reach optimal results. With Kanban, some of the best
leadership comes from everyday acts by common people who are a part of a team.
Kanban board
A Kanban board is a field on which Kanban Cards represent the individual tasks in progress which
are categorized according to priority and delivery. Simply put, Kanban is an excellent way to keep
track of your team’s workflow. Today, Kanban boards are mostly used in Agile or Lean software
development teams in the form of online collaboration tools aimed at boosting team’s productivity
and stimulating inspiring ideas.

The integral part of Kanban board is Kanban cards. Each card represents individual work item or
a task, and each consists of important data for that specific task. Cards are placed on the board in
a visual way in order to show the current stage of the task and they are usually color-coded to show
what type of task they are. Kanban board consists of three sections:
✓ Waiting
✓ Work in progress
✓ Completed work
After the tasks have been delegated, the team will take the cards and move them across the sections
as they complete their tasks. Keep in mind that Kanban board can be used in many forms and that
today teams use it in different ways to share ideas and manage their workflow. The most
straightforward way is the old concept of putting sticky notes on a white board to show the stages
of the project development and its progress.
Essentially, Kanban is based on the pull system. Whether you work in a small business or anywhere
else on the value chain, pull systems will help you minimize inventories and make necessary
changes to the production system as the demand arises. They provide you only with what you need
which consequently reduces costs and waste.
Why should you use Kanban?

✓ Kanban helps you recognize bottlenecks in work processes
✓ Kanban helps you work on continuous improvement and expand your knowledge through the
lessons learned
✓ Kanban limits multitasking which, in turn, increases the quality of the process

✓ Kanban can be the fastest way to deliver positive results which will help you gain competitive
advantage on the market
✓ Kanban allows you to re-prioritize your project plans at any given time based on the new
information and new business climate or increased customer demand
✓ Kanban helps your team visualize all the tasks and have a clear overview of all the stages and
process which further upscales team collaboration
Is Kanban the right choice for you?

As it was mentioned before, Kanban is an approach which will help you make changes to the
management that is designed to meet minimal resistance. Therefore, if you have some processes
that are working well, Kanban will help you improve over time without massive and radical
change.
Kanban is a great solution for projects of different sizes, complexities and urgencies. Although
Kanban works well in most industries, the practice has proven that it works best in product
development environment.
Finally, If you want to build trust within your organization and take productivity to a whole new
level, opt for Kanban and see how it works for your business.
EXTREME PROGRAMMING (XP)

Extreme Programming (XP) is an agile project management framework used in software
development. It prescribes everything, from how to organize projects and develop software, to
how to increase developers' productivity and what's the best way to collaborate on code. Extreme
Programming is an agile framework, which means it advocates frequent releases, iterative
development, and high level of customer involvement. It's similar to Scrum, only XP is a lot more
prescriptive and opinionated. Unlike Scrum, which is primarily concerned with team organization,
XP is primarily concerned with code: its simplicity, how it's written and deployed, how developers
work, etc. This means you can apply XP only if you work in a software development company.
What's at the core of Extreme Programming (XP)

The easiest way to understand XP is to think of it as Scrum with an added layer of coding best
practices. XP takes agile principles, gives you some processes like Scrum, and tells you exactly
how to approach coding.
XP starts with an idea that software development is hard. That's why, according to XP, the 4 most
important things in software development are:
✓ CODING - At the end of the day, if the program doesn't run and make money for the client,
you haven't done anything.
✓ TESTING - You have to know when you're done. The tests tell you this. If you're smart you'll
write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you
maybe might be done, but knowing you're probably not, but you're not sure how close you are.

✓ LISTENING - You have to learn what the problem is in the first place, then you have to learn
what numbers to put in the tests. You probably won't know this yourself, so you have to get
good at listening to clients - users, managers, and business people.
✓ DESIGNING - You have to take what your program tells you about how it wants to be
structured and feed it back into the program. Otherwise, you'll sink under the weight of your
own guesses.
Listening, testing, coding, designing. That's all there is to software. Anyone who tells you
different is selling something. - Kent Beck, the creator of Extreme Programming
Project lifecycle in XP
✓ Small releases - finished work is delivered to the customer at the end of each week, so the
customer gets value sooner rather than later.
✓ Weekly cycle - the team plans what features to deliver at the end of each week, works in one-
week cycles, and reviews progress each Friday. If some feature takes more time, it's broken
down into several cycles.
✓ Quarterly cycle - because work is delivered in small releases, you need some long-term strategy
to make sure stories fit together and software doesn't end up all over the place.

Best practices for code collaboration

✓ Pair Programming - all production code should be written by two developers working on a
single computer. This should increase code quality and lower number of bugs, thus saving you
from future bug fixing.
✓ Collective code ownership - everyone has access to all code and is empowered to fix things on
their own. Also, code that you write will be used by someone else so you should make your
code clean and simple to understand.
✓ Together but alone - there shouldn't be cubicles and walls between developers to encourage
face-to-face communication. But, everyone should have privacy when needed, and shouldn't
be interrupted so they can stay focused.
✓ Cross-functional teams - work is done in small teams so each developer should have multiple
skills and take care of whatever that needs to be done. There are only two mandatory roles on
a team (customer and developer), and two optional (coach and someone who will track results).

✓ Customer always available - only the customer knows how the software should work and only
they can answer questions that constantly pop-up during the development.
✓ Information radiators - work should be transparent and everyone should know who is working
on what. This is solved by using a public Kanban board.
✓ Daily stand-up meeting - it's more efficient to have one short meeting everyone has to attend
than many smaller getting-up-to speed meetings during the day.
Best practices for coding

✓ The planning game - you should treat planning and estimating like a game, with rules to create
emotional distance. This way, both business and development knows what to expect and there's
no conflict.
✓ Simple, incremental design - simply designed software takes less time to write and fix than
complex one. You should never add extra functionality because only 10% of it will be actually
used, thus wasting 90% of your time.
✓ Refactoring - you should always go back and improve code (make it simpler, remove
redundancy, eliminate unused functionality, etc). The goal of refactoring is to make old code
better in order to make work easier in the future.
✓ Coding standard - all code should be consistent so other people can read it easier. This means,
for example, adopting Hungarian notation or camel case, deciding on tabs vs spaces, etc.
Best practices for code deployment

✓ Test-driven development - tests are the cornerstone of XP. Automated testing saves time and
lowers number of defects. To make sure developers really focus on tests, they first need to
write an automated test (which will first fail), and then develop just enough code to pass the
test.
✓ Ten-minute build - you should be able to build the whole system and run all of the tests in 10
minutes. If the process takes longer, it's less likely test will be run on a frequent basis, thus
negating benefits of testing.
✓ Continuous integration & deployment - to be able to pull of a 10- minute build, you need to
automate testing and code deployment. Every time changes are added to the code base, they
are immediately tested and deployed if they pass the test.
When XP doesn't work (and its disadvantages)

XP doesn't work for every software development company. Each company has a different structure
and developers a different type of software, so a one-size-fits-all approach XP advocates doesn't
work everywhere. XP suffers from the same disadvantages as all agile methodologies, plus a few
more of its own:
✓ XP is a complex framework with a lot of rules, rules someone has to enforce and everyone has
to adopt.

✓ Collaboration takes more than putting all developers in one room, and logistically, it's seldom
possible.
✓ XP relies on too many things, so if you don't do one thing right, all others both up and down
the dependency chain will get affected.
✓ XP doesn't offer a clear-cut, foolproof process you can easily adopt and follow
✓ Having an on-site customer so you don't have to write extensive specs is extremely risky
because, if they leave, they take all domain knowledge away with them
✓ Pair programming locks up twice as much resources as solo programming. Pair programming
is useful for solving complex problems, but solving complex problems is very rare in everyday
development in 90% of companies. Plus, not everyone like to work in pair and it's more
difficult to achieve state of flow.
✓ XP de-emphasises good UX design. Walking customers through mock-ups, storyboards, and
use cases until they know what they want is much cheaper than fixing code. This makes XP
especially bad for both large programs and consumer software as good UX design doesn't
happen incrementally.
✓ Refactoring and unit testing is not a substitute for thoughtful design, modeling, and software
architecture.
✓ Constant involvement is a tough sell for your customer/client, as well as absence of knowing
how much all is going to cost.
✓ Refactoring can be a time-waster. Refactoring is only beneficial for code that is used often by
others than the original author, which is not always the case.
✓ Automated testing can only detect "computer" problems, while subtle, "human" usability
problems are pushed aside.
✓ Most software consultancies and contractors don't care for the level of code quality that XP
demands. Their job is to simply make something work in the short term, while maintaining it
is often someone else's job, thus they have no incentive to refactor or do other unbillable work.
However, the biggest problem with XP is that it's based on the assumption that the whole team is
in one place – both development and the customer. In most cases, that's not viable. Most software
development companies today are outsourced, meaning the customer and the development team
work not only in different places but different continents altogether, making XP impossible. Just
to get an answer about some requirement, XP team would have to wait anywhere from a few hours
to a day. This is a deal-breaker for a framework that relies on agility and close collaboration.
ADAPTIVE PROJECT FRAMEWORK (APF)

Adaptive project management is a structured and systematic process that allows you to gradually
improve your decisions and practices, by learning from outcomes of the decisions that you took at

previous stages in the project. As the name suggests, project management process changes and
adapts to the needs of the organization, ultimately boosting business value.
Adaptive Project Framework (APF) has a number of variations, with adjusting scope at each
iteration. Robert K. Wysocki, the author of Adaptive Project Framework, says that APF is more
like creating a recipe than following one. He also explains that project managers are in charge of
the approach, meaning they need to understand the situation and adapt their approach and
techniques.
Main characteristics of Adaptive Framework are:
✓ Thrive on change
✓ Learn from discovery
✓ Client driven
What distinguishes APF from other methodologies is the fact that it places the client as the central
figure who decides on project’s next step. Also, the client has the power to completely change
project direction.
Why do we need Adaptive Project Framework?

Traditional projects have a clear structure and a static strategy where project managers distribute
tasks and keep the entire team under control. But the fast-paced technological advancements and
ever-increasing demands of today’s market have changed project management in three key areas:
✓ Strategy - it became more dynamic and difficult to predict
✓ Work - the development of new technologies speed up the pace of work
✓ People - they work collaboratively and strive towards creating a real team culture
Taking all these changes into the account, it’s obvious that software development projects evolve
as they go and that applying traditional project management would be futile. Wysocki uses the
analogy of a chef and a cook to explain the difference between the traditional and the adaptive
project management: while a cook follows a recipe to the letter, a chef doesn’t only have the
knowledge and experience to create a recipe but also the ability to improvise if something
unexpected happens.
How was the idea of APF born?

During the 1970’s, two ecologists C.S. Holling and Carl J. Walters researched how to predict the
fish stocks, which are dependent on a number of factors that can’t be controlled. As a result, they
came up with adaptive project management, a method whose idea is “learning by doing”. APM
has become an integral part of project management methodologies, and most big corporations and
environmental organizations are using it on their large-scale projects. It has become top
methodology of environmental engineering and is used on some of the biggest projects worldwide
(such as Everglades and Grand Canyon National Park).
How does APF work?
Adaptive project management processes (planning, execution, monitoring, control, and
evaluation) can be:

Passive
Passive Adaptive Management allows you to apply important lessons that you’ve learned during
the process to the current management approach. The information you obtain from one iteration
you can then use on the following one. In this way, you can minimize all the uncertainties related.
Active
Active Adaptive Management enables you to determine the best management strategy by learning
through experiments.
Here are the essential steps you need to take when implementing Active Adaptive Management:
✓ Define a project strategy and make it flexible. This way, you’ll be able to reverse decisions if
necessary.
✓ Break your project plan into multiple iterations (phases).
✓ Create a more detailed plan that will include a schedule and a list of risks for the next phase.
Make sure you don’t make detailed plans for future iterations as you cannot predict all potential
changes to the project.
✓ Perform a quantitative risk analysis, which should help you determine what will happen with
project schedule if a certain risks occur.
✓ Execute one or more project scenarios and measure their results.
✓ Perform quantitative risk analysis again to gain a better insight into which risks actually occur
and which ones don’t.
Traditional project management vs Adaptive Project Framework

Future uncertainty prevents us from relying on traditional management, especially if we are
involved in complex projects (eg. IT projects). Robert K Wysocki claims that traditional project
methods are not applicable in such cases.
By using a traditional project management, you can achieve positive results only if you have a
clearly defined goal and a reasonable solution. However, If your goals are not specific and may
change as project progress, you should consider using adaptive project management.
Agile project management vs Adaptive Project Framework

Agile project management was introduced to reduce complexity by breaking down ambitious and
complex software development processes into smaller segments so you can make product changes
even at later stages.
While Agile project management is mainly focused on the project organization, Adaptive PM takes
it to another lever. Besides helping you organize your project more efficiently, it also gives you
the ability to include quantitative analysis methods, which can help you:
✓ Analyze model and test hypothesis
✓ Measure the actual performance of the project
✓ Analyze project risk

The core values of APF

Since the client is in the center of attention in APF, they are given an opportunity to control the
direction of the entire project.
According to Wysocki, this way of thinking is embodied in six core values of AFP:
✓ Client focused - it helps you stay focused on your client’s needs as long as they are within
the scope of ethical business practices
✓ Client-driven - It allows you to include the client in your project and keep them
meaningfully involved by having project co-managers
✓ Incremental results early and often - ADP enables you to deliver a workable solution to
the client as early as possible and keep them meaningfully engaged in the project
✓ Continuous Questioning and Introspection - refers to an openness and honesty that must
exist between client team and development team in order to make the best decisions
possible and deliver positive results
✓ Change is the progress to a better solution - by working with deliverables from the early
stages of the project, both the client team and the development team will get the big picture
of what else can be done to improve results.
✓ Don’t speculate on the future - APF strips out all non-value added work. Although the
APF team will always be tempted to achieve perfection, they must resist the temptation.
It’s essential that your team doesn’t waste their time and money on guessing but instead
focus on the work your client will benefit from.
CHANGE MANAGEMENT METHODOLOGIES

Event Chain Methodology (ECM)
Event chain methodology is a network analysis technique that is focused on identifying and
managing events and relationship between them (event chains) that affect project schedules. It is
the next advance beyond critical path method and critical chain project management. Event Chain
Methodology is an extension of traditional Monte Carlo Simulations and project risk analysis with
Risk Driver.
Event chain methodology helps to mitigate the effect of motivational and cognitive
biases in estimating and scheduling. It improves accuracy of risk assessment and helps to generate
more realistic risk adjusted project schedules.
It is a more of a statistical method. Event Chain Methodology is based on six main principles
✓ Moment of Risk and State of Activity - In a real life project process, a task or an activity
is not always a continuous procedure. Neither is it a uniform one. A factor that influences
tasks is external events, which in turn transform tasks or activities from one position to
another. During the course of a project, the time or moment when an event occurs is a very
important component of the event. This time or moment is predominantly probabilistic and

can be characterized using statistical distribution. More often than not, these external
events have a negative impact on the project.
✓ Event Chains - An external event can lead to another event and so forth. This creates event
chains. Event chains have a significant impact of the course of a project. For example, any
changed requirements to the materials needed for the project can cause the activity to be
delayed. The project manager then allocates resources from another activity. This leads to
missed deadlines and eventually leads to the failure of the project.
✓ Monte Carlo Simulations - On the clear definition of events and event chains, Monte
Carlo Analysis is utilized in order to quantify the collective consequences of the events.
The probability of the risks occurring and the effects they may have are used as input data
for the Monte Carlo Analysis. This analysis gives a probability curve of the project
schedule.
✓ Critical Event Chains - Critical events or critical chains of events are those with the
potential to impinge on a project the most. By identifying such events at the very beginning,
it is possible to lessen the negative effect they have on projects. These types of events can
be detected by examining the connections between the primary project parameters.
✓ Performance Tracking With Event Chains - It is important for a manager to track the
progress of an activity live. This ensures that updated information is used for the Monte
Carlo Analysis. Hence during the duration of the project, the probability of events can be
calculated more accurately using actual data.
✓ Event Chain Diagrams - Event Chain Diagrams depict the relationships between external
events and tasks and how the two affect each other. These chains are represented by arrows
that are associated with a particular activity or time interval on a Gantt chart.
A different color represents each event and event chain. Global events affect all the tasks in a
project while local events affect just one task or activity in a project. Event Chain Diagrams allow
for the simple modeling and analysis of risks.

Event Chain Methodology Phenomenon
The use of Event Chain Methodology in project management produces some interesting
phenomenon:
• Repeated Activity - Certain external events cause the repetition of activities that have
already been completed.
• Event Chains and Risk Mitigation - When an event occurs during the course of a project,
a mitigation plan, that is an activity that expands the project schedule, is drawn up. The
same mitigation plans may be used for several events.
• Resource Allocation Based on Events - Another phenomenon that occurs with Event
Chain Methodology is the reallocation of resources from one activity to another.
Conclusion
Event chain methodology is an uncertainty modelling and schedule network analysis technique
that is focused on identifying and managing events and event chains that affect project schedules.
It helps to:
• Mitigate effects of motivational and cognitive biases in estimating and scheduling. In many
cases, project managers intentionally or unintentionally create project schedules that are
impossible to implement.
• Simplify the process of defining risks and uncertainties in project schedules, particularly
improve the ability to provide reality checks and visualize multiple events.
• Perform more accurate quantitative analysis while taking to an account such factors as
relationship between different events and actual moment of the events.

EXTREME PROJECT MANAGEMENT (EPM)

"Extreme project management is the art and science of facilitating and managing the flow
of thoughts, emotions, and interactions in a way that produces valued outcomes under
turbulent and complex conditions: those that feature high speed, high change, high
uncertainty, and high stress." - Doug DeCarlo, author of eXtreme Project Management
From development of new technologies and shift in customer needs, to economic conditions or
some new ground breaking ideas, a number of project requirements can change every day due to
a variety of circumstances. This is where extreme project management enters the game. Extreme
projects are carried out in turbulent environments where it’s difficult to estimate the speed of the
project and obstacles you will encounter. On extreme projects, things are unpredictable, planning
is chaotic and just-in-time, and the entire project development is messy. Despite their extreme
nature, extreme projects can still contribute to success and extreme project management allows
you to manage the unknown and unpredictable by self-correcting along the way.
Traditional vs Extreme Project Management

Traditional project management is a perfect solution for managing engineering and construction
projects because they have a specific goal and a well-defined path on how to get there. But today,
many projects don’t have a proven path and a predictable life cycle, and requirements are
constantly changing.
Unlike traditional management, where circumstances are highly predictable, extreme project
management thrives in the chaotic environment where the level of certainty is very low. Also,
traditional approach is more streamlined while extreme one is more flexible.

Doug DeCarlo, the author of Extreme Project Management, points out the basic differences
between the two approaches:
✓ Traditional project management is past oriented. Extreme project management is future
oriented.
✓ Traditional project management makes people the servants of the process. Extreme project
management makes the process the servant of people.
✓ Traditional project management is about centralizing control of people, processes, and tools.
Extreme project management is about distributing control.
✓ Traditional project management tries to take charge of the world (things, people, schedule).
Extreme project management is about taking charge of yourself, your attitudes, and your
approach to the world.
✓ Traditional project management is about managing. Extreme project management is about
leading.
Extreme Project Management characteristics

DeCarlo compares extreme project management to jazz music. Although jazz may sound random
and chaotic, it actually has its own framework which allows jazz musicians to improvise within it
and make outstanding musical pieces.
✓ There is a rough idea about the goal but little idea about how to achieve that goal.
✓ All the standard tools, templates, and processes engineers used to apply in the past don’t
make much contribution to the extreme project management.
✓ Instead of following the safe path, in extreme management project managers discuss the
best alternative with the client, carry out the experiment, learn from what happens, and use
their knowledge for the next project cycle.
The mindset as an important factor

It’s obvious that steps you need to take in extreme approach differ significantly from the steps in
the traditional approach. The extreme approach requires a particular mindset, that is, a set of beliefs
and assumptions of how things function. With this in mind, changing the mindset of your project
team and adapting it to extreme circumstances they have to work in is the imperative.

There are a few ground rules and expectations your project team has to adopt to successfully
implement extreme approach:
✓ Requirements and project activities are chaotic and unpredictable
✓ Team should rely on uncertainty
✓ It’s virtually impossible to fully control this kind of projects
✓ Change is inevitable
✓ Flexibility and openness bring the feeling of security
Five steps of XPM life cycle model

Brian Vernham, the author of Agile Project Management for Government, suggests that there are
five steps every extreme project management team needs to follow to carry out the project
successfully:
✓ Envision - define your vision clearly before embarking on extreme project management.
✓ Speculate - have your team participate in creative thinking process and brainstorm ideas that
will achieve your vision.
✓ Innovate - make your team test their speculations by coming up with innovative solutions.
✓ Re-evaluate - as the cycle approaches its end, your team must re-evaluate their work.
✓ Disseminate - after going through a learning process, it’s essential to spread the knowledge
and apply it to future stages of the project as well as future projects in general.

When to use XPM

Whether your team will employ a straightforward and well-structured traditional project
management or the radical extreme project management approach depends on the project they are
involved in. You should use extreme project management when your projects require:
✓ Fast-paced work
✓ Frequent changes as the project progresses due to the dynamic environment
✓ A trial-and-error approach to see what works
✓ Self-correcting processes when things go wrong
✓ People-driven processes instead of process-driven (when people are in control of processes
rather than the other way around)
Advantages of XPM
Unlike other methodologies that rely on software tools and templates, extreme approach is much
more people-centric:
✓ It’s holistic - although it includes methods, tools, and templates, they only make sense if
they refer to the project as the whole. In other words, it allows you to view the project as a
single system without analyzing its parts
✓ It’s people-centric - it puts emphasis on project dynamics, meaning it allows stakeholders
to communicate and interact. This helps you reach meaningful solutions and meet your
client's needs.
✓ It’s humanistic - one of the principles of this approach is takes into account quality of life
of the stakeholder as they are baked into the project. Because people are an integral part of
the project, their job satisfaction and the team culture they develop can have a profound
effect on the business
✓ It’s business focused - once you have reached the project’s outcome, you can have a clear
insight into how the project can benefit your client. The team is constantly focused on
delivering value early and often.
✓ It’s reality based - it allows you to work in the highly unpredictable environment that is
prone to change and helps you recognize that you cannot change the reality to adapt to your
project.
PROCESS BASED METHODOLOGIES

Lean Project Management
Lean project management is the application of lean manufacturing principles to the practice of
project management. The goal of lean project management is to maximize value while minimizing
waste. Lean manufacturing principles were developed by Toyota in the 1950s and applied in the
1970s to combat the energy crisis. The term “lean” was coined in the late 1980s. The Project
Management Institute sums it up: “To be Lean is to provide what is needed, when it is needed,
with the minimum amount of materials, equipment, labor, and space.” Lean manufacturing
identifies three types of waste: muda, muri, and mura (known collectively as the 3M).

✓ Muda refers to activities that consume resources without providing additional value
✓ Muri refers to the overuse of equipment or employees
✓ Mura is operational “unevenness,” which decreases efficiency and productivity in the long
term
Lean project management aims to reduce the 3M within the project process.
Principles of Lean Project Management

The five principles of lean project management serve as steps for how to reach prime customer
satisfaction. Use these steps if you want the best chance of reducing product waste, staying
within project scope, and meeting critical success factors.
1. Identify value
The first core principle in the lean project management process is to identify your product value.
To do this, you need to know your stakeholder. Sometimes you’ll be creating project
deliverables for internal stakeholders, while other times you’ll have a customer who’s an external
stakeholder.
✓ An internal stakeholder is a shareholder of the project who monitors a product’s development
because they have a stake in its success.
✓ An external stakeholder is a customer who buys the product or service and is affected by its
quality.
Once you know who you’re building your product for, you can better determine how to make it
valuable. For example, product value for an internal stakeholder may mean meeting an internal
operations need. Product value to a customer may mean solving a customer problem or making
the customer’s life easier.

2. Map the value stream

Value stream mapping (VSM) is the next principle in lean project management. VSM is a visual
tool that involves diagramming your current workflow and your ideal workflow from project
initiation to completion. When comparing the two workflows, you can identify waste across
each project management phase to maximize efficiency. Toyota identified types of waste you may
find through VSM in lean manufacturing, but in parentheses, you can see how these items may
translate to other industries:
✓ Overproduction (Unnecessary features): Overproduction and unnecessary software features
can lead to added costs like extra storage, wasted materials, and useless inventory.
✓ Inventory (Mismanaged backlog): Inventory waste, waste from incomplete work, and
mismanaged backlogs all incur unnecessary costs for storing inventory, transportation costs,
and additional costs spent to complete work.
✓ Motion (Task switching): Motion waste is the unnecessary cost of internal motion by people
or machines. This can take the form of redundant processes or an overabundance of business
apps. In fact, the average knowledge worker switches between 10 apps up to 25 times per day,
but 27% of workers say that actions and messages are missed when switching apps.
✓ Defects (Technical debt): Defects can result in costly repairs and a loss of materials. Technical
debt can result in a loss of valuable time.
✓ Over-processing (Expensive tools): Over-processing can lead to unnecessary costs like
upgrading a product that users didn’t ask for or don’t need. Similarly, money spent on
expensive tools can be a waste if the tools aren’t worth it.
✓ Waiting: Waiting waste is the cost resulting from delayed timelines in final product
deliverables.
✓ Transport: Transport waste is similar to motion waste and deals with external movement, like
the unnecessary movement of product and materials.
✓ Fragmented teams: Fragmented teams can result in wasted costs due to miscommunication,
unnecessary meetings, and lack of strong collaboration.
VSM is the most important step in lean project management. Without it, you won’t have the
visualization you need to notice flaws in your project life cycle and improve product quality for
customers.
3. Create flow
In this step, you’ll rework your project management plan to be more efficient by removing the
waste you identified in step two. To do this, break down every stage of product development and
reconfigure steps as needed. Use project milestones as checkpoints to ensure new waste doesn’t
develop as the project progresses. For example, imagine you identified in step two that you have
a mismanaged backlog and delayed timeline due to a bottleneck in team member scheduling. This
is where you’ll determine how to remove those pain points and piece your project plan back
together. Establishing open communication with your team members is the best way to ensure
your VSM was worth the effort. Once you’ve taken time to identify and remove waste, your team
can work together to prevent future inefficiencies and keep waste from building back up.

4. Establish pull
Establishing pull means pulling work from the previous process stage as work is completed. This
concept originated in manufacturing to help factories meet the exact demands of their customers
with a “just-in-time” inventory system. However, a pull system is also helpful in other industries
because it keeps your workflow moving efficiently.
Example of a pull system in software development:

1. The tech designer finishes their task and flags the product for review.
2. The review flag signals the coding stage to begin.
3. Your coder finishes their task and flags the product for review.
4. The review flag signals the testing stage to begin.
5. The product tester finishes their task and flags the product ready for final review.
6. You conduct a final review of the product.
Establishing pull can help teams in various industries because it keeps work moving seamlessly
through the project life cycle. Industries that produce customer-facing products will benefit from
this system if they use pull signals to work backwards. That way, their team only produces
inventory when customers need it.
5. Continuous improvement
Lean project management isn’t a one-time thing—rather, it’s an iterative process. Striving for
perfection is the fifth principle, which involves making continuous improvements to your
workflow. Whether your customer is an internal or external stakeholder, their demands will be
ever changing. This means you’ll need to assess your product value intermittently and regularly
analyze your workflow for waste.
Lean project management tools

You can use the tools below to improve your product development workflow. When striving for
continuous improvement, these tools will help you and your team reduce waste, improve
productivity, and increase customer value.

What are the benefits of lean project management?

Benefits of lean management include:
✓ Improved product value by streamlining processes.
✓ Increased innovation: Improves the project by sparking creativity
✓ Reduced waste: Reduces physical waste and waiting times between production steps, while
also minimizing overproduction and over-processing
✓ Enhanced customer service: Provides what the customer needs—nothing more, nothing
less
✓ Better lead times: Results in faster response times and fewer delays
✓ Higher quality products: Minimizes product defects by adding quality checks
✓ Improved inventory management: Prevents setbacks by monitoring inventory
SIX SIGMA
Six Sigma is a problem-solving methodology aimed at improving business and organizational
performance by using a number of methods and tools. It primarily identifies and corrects errors
and defect in manufacturing and business processes.
History of Six Sigma

Although Six Sigma was originally introduced in the 19th century with the bell curve by Carl
Fredrick Grauss, it turned out to be inadequate and needed some corrections. It was brought back
to life back in the mid-1980’s when Motorola was facing a crisis: their product had poor quality,
which affected their competitive advantage as they were struggling to beat the competition and
secure their place on the market.
Motorola came up with an idea to develop Six Sigma Management System and reduce the
variations in manufacturing processes that were causing defects. The results were stunning. The
level of quality of certain Motorola products experienced a tremendous increase, which
encouraged other big corporations to follow the same path. Since then, many worldwide companies

have adopted the Six Sigma approach with all its tools and techniques, and have saved hundreds
of billions of dollars.
How Six Sigma works

Engineers at Motorola developed a scale that should evaluate the quality of processes based on
their defects. At the top of the scale is Six Sigma, which is 99.9997% defect-free (or in other words,
if you make a million car cylinders, there will only be 3.4 defects). This means that if your
processes run at Six Sigma, they almost have no defects.
Six Sigma scale shows how well an important feature performs compared to its requirements. The
lower the sigma level, the bigger the number of defects. Naturally, most businesses operate at 4 or
5 Sigma, which means that the losses that result from the poor quality cost them 10-15% of their
revenue. The following table shows the universal Six Sigma scale.
Six Sigma concepts

Given its effectiveness and success, Six Sigma methodology is not a precise and narrowly defined
term. Today, Six Sigma represents a number of concepts:
✓ Six Sigma helps you solve the problems effectively and upscale your business and
organization
✓ Six Sigma performance is a statistical term that refers to a process that produces fewer than
3.4 defects (errors) per millions of opportunities for defects.
✓ Six Sigma improvement is when the key outcomes of a business of work processes improve
dramatically, by 70% or more
✓ Six Sigma deployment refers to the application of Six Sigma methodology across
organization with all the assigned practices, roles, and procedures that match accepted
standards

Six Sigma organization uses tools to:

✓ Boost performance
✓ Lower costs
✓ Grow revenue
✓ Improve customer satisfaction
✓ Increase capacity and capability
✓ Reduce complexity
✓ Lower cycle time
✓ Minimize defects and errors
DMAIC methodology
The Six Sigma methodology is defined by 5 DMAIC steps. DMAIC is a problem-solving
technique that can help you handle any problems you meet along the way. It includes five main
steps:
1. Define - you need to define the problem and clearly outlay your objectives. Your definition
should include the exact problem with numeric representation and shouldn’t be vague.
2. Measure - once you define your problem, you need to decide what measurements to use to
quantify the problem. You have to identify what part of the product is damaged, when they
were damaged, and what's the level of the damage.
3. Analyze - after measuring, the next step is to collect and analyze data. At this point, it’s
important to determine whether the error is valid or it happened at random, without any specific
cause. You can use the collected data to compare it against measurements and evaluate its
success.
4. Improve - the next stage includes developing solutions to the problems. Your team should
create a test and launch pilot studies to find the most appropriate solution. After coming up
with a solution, your team can start building a plan and developing a timeline.
5. Control - finally, in order to keep things under control and prevent recurrence, you need to
perform control measurements monthly, daily, or yearly.
Six Sigma tools

To improve the quality of DMAIC model, there are a variety of tools, all of which can be divided
into two categories:
✓ Process optimization tools that allow you and your team to create more efficient workflows.
✓ Statistical analysis tools that allow your team to analyze data more efficiently.
To be able to do calculations, you need to incorporate the tools into Six Sigma software, which
will do the rest of the job for you. Here are some of the essential tools that almost every Six Sigma
Model uses:

✓ Quality Function Deployment: It will help you identify customer requirements and rate them
on a numerical scale. Next, you list various design options and list them based on their ability
to address customer needs. Finally, the designs with the highest scores will become the solution
that you should implement.
✓ Fishbone Diagrams: It helps you identify which variables you should study further. First, you
start with the specific problem and list all the variables in their respective categories that are
affecting the problem. After listing all the variables, the expert team should determine which
variables are most likely to be causing the problem. The diagram looks like a fish skeleton,
hence the name of the diagram.
✓ Cause-and-effect Matrix: It helps your team identify, explore, and display all the possible
causes and finally find the root cause to the problem.
✓ Failure Modes and Effects Analysis: This tool allows you to focus on other processes and
activities other than the issues that arise during the project development. This lets you list all
possible failure scenarios, come up with solutions, and rank them according to how well they
address your concerns. Finally, your team can prioritize things that could go wrong and
develop necessary preventive measures.
✓ Six Sigma belts : Since most large corporations and big industries incorporate Six Sigma into
their business, the incorporation process requires not only ample time and energy but also huge
financial resources.
At its core, we can incorporate Six Sigma in two ways:
✓ Through a separate organization that provides services to the main business
✓ By making it an integral part of every employee’s job
No matter what approach you choose, you need to keep in mind that Six Sigma focuses on the
team and not on the individual. Each team has a certain level of certification that depends on the
degree of their expertise and responsibilities.
Teams are categorized as follows:

✓ Black Belt - represents professionals and experts who need to have a high degree of expertise
and a wide knowledge of all Six Sigma tools and methods
✓ Green Belt - represents people who are in charge of solving a number of issues that arise in the
manufacturing environment (if some issues become more complex, they can always consult
the Black Belt). They usually handle administration and organization
✓ Yellow Belt - everyone else on the team. These employees don’t know every project detail and
therefore don’t need to have extensive knowledge of Six Sigma. However, they are essential
to the success as they help Green Belt people achieve their goals.

Who uses Six Sigma

After the big Motorola success, many companies from manufacturing and transactional industries
(banks and hospitals) to oil industry and even entertainment industry have incorporated six sigma
methodology in their framework. For example, while General Electric profited from $7 to $10
billion in 5 years, Bank of America saved hundreds of millions of dollars within the first 33 years
of launching Six Sigma. Six Sigma is inevitably a path to a dramatic improvement and brings
immense value not only to the company but customers as well.
LEAN SIX SIGMA IN PROJECT MANAGEMENT

Lean Six Sigma is a hybrid methodology that combines two popular approaches to process
improvement: Lean and Six Sigma. Understanding each of those will help you better grasp how
Lean Six Sigma actually works.
Lean project management is all about reducing waste. The goal is to do more with less. Teams
identify waste areas so that they can avoid any project activities that offer little or no value. The
result is more efficient processes that require less time, money, and effort.
Six Sigma methodology focuses on using statistics to improve the quality of a team’s processes. It
takes a magnifying glass to processes to identify any production defects and variations. Some
people even get a Six Sigma certification to prove their knowledge in identifying and removing
defects.
When you put the two together, you get Lean Six Sigma. With this approach, Lean first calls
attention to any unwanted process variations, while Six Sigma steps in and uses a series of

improvements to reduce those variations. How? Six Sigma uses the DMAIC acronym, which
stands for: Define, Measure, Analyze, Improve, Control
To put this all in even simpler terms, Lean highlights the holes in the bucket, and Six Sigma patches
them.
Is Lean Six Sigma right for your team?
Lean Six Sigma got its start in manufacturing, but it has since expanded to virtually every other
industry. Despite its popularity, it’s not the default right choice to help your project team work
more effectively and efficiently. To determine whether you and your team could benefit from Lean
Six Sigma, consider the potential benefits and drawbacks.
Advantages of Lean Six Sigma:
✓ Lower costs: Because there’s less waste and defect-free products, teams can save money.
✓ Improved processes: With more control and fewer variations, processes are far more
streamlined and consistent.
✓ Better employee engagement: With Lean Six Sigma, teams are accountable for solving
problems. Project managers trust them to carry out any process improvements, and that level
of autonomy can boost their enthusiasm and engagement.
Disadvantages of Lean Six Sigma:
✓ Complexity: To do it well, it requires prior knowledge of two different project methodologies.
So, it can feel a little daunting and is not as easily adopted as other approaches.
✓ Resource-intensive: It’s not a fast-moving approach and it takes a lot of time to follow the
principles. Teams will likely also have increased workloads as they move through the process.
✓ Potential customer loss: To reduce defects, you might have to opt for more expensive resources
and materials. That can raise the price of your end product and even lead to customer churn.
To sum it up, Lean Six Sigma combines the zero-waste ideology of Lean and the zero-defects
ideology of Six Sigma to create a new, hybrid approach that ultimately helps teams get better work
across the finish line in less time.
PRojects IN Controlled Environments (PRINCE2)

PRINCE2, which stands for PRojects IN Controlled Environments, is a flexible process-based
method that can help you wrap up projects more effectively and efficiently. Ever since it was first
introduced by UK government as the methodology for executing government projects, it has been
gaining massive appeal worldwide. PRINCE2 has become an integral part of every project

development in both private and public sectors especially in countries like Germany, Spain, South
Africa, Belgium and the United States.
The importance of PRINCE2

In the sea of project management methodologies, you might ask yourself: What can I achieve with
PRINCE2? What makes it stand out from other methodologies? How can it help my business
grow? In its core, every project development, especially in IT world, is highly unpredictable in
nature. PRINCE2 will help you address the common cause of the project failure, and order your
project into defined steps to make it more organized, logical and easy to handle. In other words, it
allows you to structure each stage of the project in details and tie up all the loose ends once the
project finishes.
PRINCE2 framework
We all know that poorly organized schedule and or lack of knowledge necessary to control all of
the stages of project development can lead to irreversible consequences. For example, FBI’s
ambitious project to replace paper based reporting of crimes with an online system fell flat due to
lack of sound communication and thorough planning. The project was scrapped in 2005 and it cost
$170 M.
According to PRINCE2 framework, a project should have:
✓ an organized and controlled start
✓ an organized and controlled middle
✓ an organized and controlled end
Basic principles of PRINCE2 methodology

To better understand how PRINCE2 works, you need to become familiar with the 7 basic
principles, the building blocks of this widely popular methodology:
1. Continued justification of your business - unless there is a justifiable reason to run and
manage the project (a defined customer and realistic benefits) the project should be closed.
2. Learning from experience - PRINCE2 will allow your team to take part in the learning
process, and continually upgrade their knowledge
3. Clearly defined roles and responsibilities - each member of the team should have a clear
insight into what they should be focusing on and what their teams are responsible for.
4. Running the management in stages - the project is divided into separate stages and which
are planned, monitored and controlled with the aim to record lessons learned and confirm
is on the right track.
5. Manage by exception - people on the team have the right amount of authority to manage
and coordinate the project within the controlled environment. A project manager is in
charge of delegating tasks and controlling the budget, the cost and the deadlines. In case
certain, detrimental issues arise, project board enters the game and decides what the next
step should be.

6. Maintaining focus on the quality of products – teams continually check the product
delivery, definition and the quality requirements
7. The approach is adjusted for each project - PRINCE2 method is tailored to suit the
requirements of each project (environment, size, complexity, importance, capability, and
risk)
Basic themes of PRINCE2

To run the project management sufficiently, managing all of its stages is not enough. If you want
to be able to control your project, you need to have a deep insight into all of its aspects and address
them accordingly. When it comes to PRINCE2 method, there are seven themes every project
manager needs to tackle to run the project smoothly:
1. Business case: create and maintain a record of business justification for the project
2. Organization: define the roles and responsibilities of each member of your team
3. Quality: what quality requirements and measures do you need to focus on and what steps
do you need to take to deliver them
4. Plan: what steps you need to take and what techniques you need to use to develop the plan
of the project
5. Risk: clearly identify the risks and opportunities that could affect the project
6. Change: how you as a project manager will evaluate and tackle the changes on the project
7. Progress: measure how fruitful the project performance is and whether the project is
making any progress
Processes of PRINCE2 methodology

Finally, “projects in controlled environments” is a process-driven project management method.
There are seven processes you need to go through when managing the project:

1. Starting up the project - assembling the project team, creating the project brief, agreeing upon
project approach and approving the next phase of the project
2. Starting-Initiating the project - documenting the project plan, risks, project controls and the
plan for the next stage
3. Starting-Directing a project - controlling the project, giving ad-hoc direction and confirming
the end of the project
4. Starting-Controlling a stage - controlling each stage separately by assessing the progress,
managing issues, reviewing status and taking corrective actions
5. Starting-Managing stage boundaries - updating the project plan and deciding what to do with
stages once they have exceeded the tolerance level
6. Starting-Managing product delivery - managing the execution of the project work, while
making sure that the deliverables live up to the expectations
7. Starting-Closing a project - project wrap up including documentation and outcomes
The advantages of PRINCE2

✓ Easy to manage because it can be broken into several stages. This keeps your team's focus on
delivering the positive outcome
✓ Improves the communication not only between team members but also between the team and
other stakeholders which gives the team more control over the project
✓ It allows the team to save a lot of their time and become more economical when it comes to
using other resources and cutting down on some major costs along the way
✓ The flexibility of this approach allows your team to make decisions and changes as the project
develops, thus minimizing the impact of possible issues that may arise
✓ It allows your team to recognize the deviations and possible problems at early stages and have
a clear view of the lessons learned which they can use on future projects
The disadvantage of PRINCE2

✓ PRINCE2 may not be tailored for some modern project management methodologies (such as
projects in the software industry) because it does not offer the level of flexibility these
methodologies usually offer.
PRoject Integrating Sustainability Measures (PRiSM)
PRiSM is an abbreviation of PRoject Integrating Sustainability Measures. It is a principle-based

methodology that applies a value-maximisation approach that focuses on integrating sustainability
into the entirety of the project lifecycle. It predominantly leverages existing organisational systems
to achieve unilateral sustainable benefits realisation with a clear focus on process and the final
product sustainability.
PRiSM is built upon Green Project Management’s P5 Standards for Sustainability in Project
Management. The P5 standards expand on the traditional sustainable project management focus

on the triple bottom line, also known as the 3Ps (people, planet, profits), to consider five elements
– Project, Process, People, Planet and Prosperity. These standards aim to combine project
management goals with the UN Sustainable Development Goals and accurately capture the
holistic impact of projects and/or products throughout their entire lifespan, along with service
activities.
The PRiSM methodology thus lays out a comprehensive model of tools and processes to enable
holistic sustainability tracking, management and optimisation in projects by hitting the five
aforementioned elements. The graph below helps break down the extended factors and
responsibilities required to excel at all five core elements.
(Image reference: Green Project Management)
Key Characteristics of PRiSM Project Management Methodology
For some organisations, adapting the P5 standards to their own pre-existing project management
processes may suffice. But what makes PRiSM different from traditional sustainable project
management processes? There are four key characteristics that make PRiSM stand out:
✓ Ingrained social and environmental project objectives: Often, sustainability measures are
added onto projects for overarching accountability and reporting purposes, typically to hit
general sustainability strategic goals or compliances. However, these overarching
sustainability measures often fail to accurately capture the everyday impacts of everyday
project management activities and only provide organisations with generalised understandings

of their sustainability impacts. By incorporating social and environmental objectives into each
project, organisations can better track and monitor their sustainability activities on a project
level which helps easily identify areas for improvements. This also allows organisations to
provide greater levels of accountability and transparency than portfolio-wide sustainability
goals.
✓ Defined Sustainability Management Plan: Taking this a step further, the PRiSM methodology
not only makes sure that every project has clear sustainability objectives, but every project
must also have a robust Sustainability Management Plan (SMP) that outlines how those
objectives will be realistically met. The SMP helps define the plan, monitor benefits and ensure
the strategic alignment of all project activities. Typically, the SMP consists of an executive
summary, the project’s sustainable objectives, qualitative and quantitative performance
indicators, and an environmental impact assessment. It can also include sustainability risk
management and an outline of review methodologies and sustainability metrics templates. The
SMP helps give organisations clarity on the specific responsibilities, accountability and
objectives of all project activities.
✓ Undertaking Impact Analysis: This is where a lot of traditional sustainable project
management approaches find themselves limited. Projects that use the PRiSM methodology
must conduct an impact analysis that measures and maps out the impact of the project’s
deliverables on the P5 elements. It takes it a step further from its traditional counterparts by
not only analysing the final deliverables of the project but also analysing the entire project
process as well as all ensuing maintenance and updating activities that might be required. With
its holistic analysis of both the final product and process, the PRiSM method is able to give
organisations the ability to assess, evaluate and improve their activities across many different
dimensions ranging from equality, diversity, environmental sustainability and much more, to
ensure best practices are in place. This approach also helps prevent long-term unforeseen cost
overruns as future potentialities are accounted for and mitigation plans are put in place.
✓ Using Green Vendor Scorecards : Reaching sustainability goals is not only about managing
internal processes, but also making sure all your external contracts and suppliers are aligned
with your sustainability strategy. The Green Vendor Scorecard helps assess and evaluate the
sustainability activities of a company through defined criteria.
Evaluation criteria can be adapted to suit your organisation’s specific requirements. They typically
include a combination of quantitative and qualitative criteria that can evaluate factors such as
internal environmental policies, product production process, potential pollutants, environmental
competencies or even the companies ‘green image’.
The key benefits of applying Green Vendor Scorecards is the ability to gain a greater understanding
of supplier capabilities and enable more transparent and objective decision making. It gives
organisations a bigger picture understanding of their environmental and social impact as well as
helps identify potential opportunities to reduce costs and risks.

PRiSM Principles
The PRiSM methodology is built of six core principles:
1. Commitment and Responsibility: The recognition of the essential rights of all to a clean,
healthy and safe environment, equal opportunities, fair remuneration, ethical supplies and
adherence to rule of law.
2. Ethics and Decision Making: Supporting organisational ethics with decision-making made in
respect to universal principles through identification, mitigation and prevention of adverse
short and long-term impacts on society and the environment.
3. Integration and Transparency: Promoting the interdependence of economic development,
social integrity and environmental protection across all aspects of governance, practice and
reporting.
4. Principals and Values-Based: Preserving and enhancing natural resources by improving the
way technologies and resources are developed and used.
5. Social and Ecological Equity: Assessing human vulnerability in ecologically sensitive areas
through demographic research
6. Economic Prosperity: Establishing financial strategies and objectives that balance stakeholder
needs with the immediate and long-term needs of future generations.
PRiSM Project Management Methodology Pros and Cons
PRiSM Pros
There is no doubt that a project management methodology that has sustainability ingrained in every
facet has its benefits in a world moving towards sustainability. Some benefits of the PRISM
methodology include:
✓ Reducing the environmental impact of projects. In a time where sustainability compliances are
becoming more and more common, applying a methodology that accurately tracks and
monitors the impact of all activities plays a critical role in reducing the environmental and
social footprints on projects as well as organisations.
✓ Ensuring sustainability objectives are met. PRiSM helps make sure that your sustainability
goals don’t just stay as goals. With clear plans and breakdowns, it helps companies make sure
their sustainability objectives can be realistically met and is in line with the organisation’s
overall strategy.
✓ Greater accountability and transparency to stakeholders. PRiSM helps lay down the
foundations for greater accountability and transparency as it applies a holistic and
comprehensive breakdown of all activities across the project and organisations. Down to the
specific measures of energy use and CO2 emissions, organisations that use PRiSM can
accurately report to their stakeholders and keep up with any necessary compliances.

PRiSM Cons
✓ Requires extensive collaboration across the entire organization: As a holistic methodology,

PRiSM requires the participation of all levels of an organisation and will fall flat if used only
within a departmental context. It depends on intra-departmental collaboration, transparency
and support to truly bring out the best results
✓ PRiSM success depends heavily on the organisation’s strategic alignment. The success of the
PRiSM approach depends on how much an organisation and its executive believe in the overall
benefits and values of sustainability efforts. If organisations do not have sustainability as a
critical focus on their strategy, top executives would not be interested in spending resources to
carry out the in-depth and detailed level of tracking and monitoring applied through the PRiSM
methodology.
Is PRiSM the right fit for your organisation?
With sustainability and socially responsible behaviours becoming more valuable to stakeholders,
organisations will be keen to tap into the power of sustainable project management. However, we
always remind people that there is no one-size-fits-all methodology or ‘silver bullet’ project
management methodology.
If your organisation requires extensive sustainability monitoring and reporting, PRiSM may be the
right fit for you. But make sure to adapt it to fit your organisation’s unique context and needs.
There is no use in overkilling on reports that will only bog down your team members if they are
not necessary to your organisation’s strategic objectives.
Whether you decide to adopt PRiSM or build your own methodology, pmo365 is always ready to
help you out. Make sure to check out our guide to becoming a sustainable project manager or chat
directly with our PPM experts to see how our services can help you get a head start on your
sustainable project management journey!

BMS 038 Project Management Methodologies Notes

Uploaded by

Copyright:

Available Formats

BMS 038 Project Management Methodologies Notes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMS 038 Project Management Methodologies Notes

Uploaded by

Copyright:

Available Formats

BMS 038 PROJECT MANAGEMENT METHODOLOGIES NOTES

BMS 038: PROJECT MANAGEMENT METHODOLOGIES

The project management methodologies include:-

By Gladys Kimutai Page 1 of 62

Basic concepts used in PERT and CPM

By Gladys Kimutai Page 2 of 62

Merge event burst event merge and burst event

Guidelines for construction of network diagrams

By Gladys Kimutai Page 3 of 62

Activity code Description Prerequisites

TIME ESTIMATES IN NETWORK ANALYSIS.

By Gladys Kimutai Page 4 of 62

Critical Path Method

By Gladys Kimutai Page 5 of 62

Activity 1-2 1-3 2-3 2-4 3-4 4-5

PROGRAMME EVALUATION AND REVIEW TECHNIQUE (PERT)

By Gladys Kimutai Page 6 of 62

4. Events are numbered in ascending order from left to right.

each activity’s time estimates by  = 

By Gladys Kimutai Page 7 of 62

By Gladys Kimutai Page 8 of 62

iv. Find the probability that the project is completed in 36 weeks.

Differences between PERT and CPM

- It’s a probabilistic model with - It’s a deterministic model with well-

- The use of dummy activities is - The use of dummy activities is not

- It is used for repetitive jobs.

- It is applied mainly for planning and

By Gladys Kimutai Page 9 of 62

Phases in waterfall projects

By Gladys Kimutai Page 10 of 62

By Gladys Kimutai Page 11 of 62

On what types of project you should use waterfall

You shouldn’t use waterfall:

Waterfall is not that different from agile

By Gladys Kimutai Page 12 of 62

By Gladys Kimutai Page 13 of 62

By Gladys Kimutai Page 14 of 62

Critical Chain Project Management (CCPM)

By Gladys Kimutai Page 15 of 62

By Gladys Kimutai Page 16 of 62

By Gladys Kimutai Page 17 of 62

✓ It avoids mismanagement of floats

By Gladys Kimutai Page 18 of 62

By Gladys Kimutai Page 19 of 62

Working software over comprehensive documentation

Customer collaboration over contract negotiation

By Gladys Kimutai Page 20 of 62

Responding to change over following a plan

By Gladys Kimutai Page 21 of 62

Advantages and disadvantages of agile

Agile works best when

By Gladys Kimutai Page 22 of 62

✓ Clients don't have a fixed budget/schedule

By Gladys Kimutai Page 23 of 62

How Scrum works

By Gladys Kimutai Page 24 of 62

By Gladys Kimutai Page 25 of 62

By Gladys Kimutai Page 26 of 62

How to implement Scrum