PROJECT MANAGEMENT

A Project is a temporary, unique and progressive attempt or endeavor made

to produce some kind of a tangible or intangible result (a unique product,
service, benefit, competitive advantage, etc.). It usually includes a series of
interrelated tasks that are planned for execution over a fixed period of time
and within certain requirements and limitations such as cost, quality,
performance, others.

Key Characteristics
As follows from the given definition, any project can be characterized by these
characteristics:

 Temporary. This key characteristic means that every project has a finite
start and a finite end. The start is the time when the project is initiated and
its concept is developed. The end is reached when all objectives of the
project have been met (or unmet if it’s obvious that the project cannot be
completed – then it’s terminated).
 Unique Deliverable(s). Any project aims to produce some deliverable(s)
which can be a product, service, or some another result. Deliverables
should address a problem or need analyzed before project start.

 Progressive Elaboration. With the progress of a project, continuous

investigation and improvement become available, and all this allows
producing more accurate and comprehensive plans. This key
characteristic means that the successive iterations of planning processes
result in developing more effective solutions to progress and develop
projects.
In addition to the listed characteristics, a conventional project is:
 Purposeful as it has a rational and measurable purchase
 Logical as it has a certain life-cycle
 Structured as it has interdependencies between its tasks and activities
 Conflict as it tries to solve a problem that creates some kind of conflict
 Limited by available resources
 Risk as it involves an element of risk
Some examples of a project are:
 Developing a new product or service
 Constructing a building or facility
 Renovating the kitchen
 Designing a new transportation vehicle
 Acquiring a new or modified data system
 Organizing a meeting
 Implementing a new business process
Work Breakdown
In organizations, a project is defined as a piece of work that is planned for
implementation within current business environment. This definition lets make
a distinction between other pieces of work, such as:

 Program – a broad, long-term objective that is often decomposed into a

series of projects and sub-projects
 Task – an identifiable and measurable activity that create a small unit of
work for a related project
 Work package – division of a project task
 Work unit – division of work packages
Projects along with programs, tasks, work packages and work units are the
elements of work breakdown structure or WBS. Often WBS is used to
determine an activity-based hierarchy of projects, with reference to their
deliverables and objectives.
A program includes several or more larger projects. A larger project can be
broken down into smaller interrelated sub-projects. Each one can be divided
into tasks which in term are decomposed into interrelated activities or sub-
tasks. A task includes a series of smaller goals which are monitored against
milestones.
Managing Projects
Project management is the art of planning, controlling and executing a project
in a way that ensures successful delivery of the desired outcome. It is widely
used in organizations as a complex of tools for delivering strategic goals and
objectives.

The key advantages of using project management within a company’s business

environment can be described as:
 Accelerating improvement and strengthening of the company’s
management through implementing the ideas of participatory
management. Projects help involve employees in decision making
 Adopting systems engineering approach that helps deal with risks
effectively
 Accomplishing specific changes that are linked to the company’s
strategies

A project life cycle is the sequence of phases that a project goes through from its
initiation to its closure. The number and sequence of the cycle are determined by the
management and various other factors like needs of the organization involved in the
project, the nature of the project, and its area of application. The phases have a definite
start, end, and control point and are constrained by time. The project lifecycle can be
defined and modified as per the needs and aspects of the organization. Even though every
project has a definite start and end, the particular objectives, deliverables, and activities
vary widely. The lifecycle provides the basic foundation of the actions that has to be
performed in the project, irrespective of the specific work involved.

Project life cycles can range from predictive or plan-driven approaches to adaptive or
change-driven approaches. In a predictive life cycle, the specifics are defined at the start
of the project, and any alterations to scope are carefully addressed. In an adaptive life
cycle, the product is developed over multiple iterations, and detailed scope is defined for
iteration only as the iteration begins.

Characteristics of the Project Life Cycle

Although projects are unique and highly unpredictable, their standard framework consists
of same generic lifecycle structure, consisting of following phases:

1. The Initiation Phase: Starting of the project

2. The Planning Phase: Organizing and Preparing

3. The Execution Phase: Carrying out the project

4. The Termination Phase: Closing the project

1. The Initiation Phase: The initiation phase aims to define and authorize the
project. The project manager takes the given information and creates a Project
Charter. The Project Charter authorizes the project and documents the primary
requirements for the project. It includes information such as:

 Project’s purpose, vision, and mission

 Measurable objectives and success criteria

 Elaborated project description, conditions, and risks

 Name and authority of the project sponsor

 Concerned stakeholders

2. The Planning Phase: The purpose of this phase is to lay down a detailed strategy
of how the project has to be performed and how to make it a success.

Project Planning consists of two parts:

  Strategic Planning

 Implementation Planning

In strategic planning, the overall approach to the project is developed. In

implementation planning, the ways to apply those decisions are sought.

3. The Execution Phase: In this phase, the decisions and activities defined during
the planning phase are implemented. During this phase, the project manager has to
supervise the project and prevent any errors from taking place. This process is also
termed as monitoring and controlling. After satisfaction from the customer,
sponsor, and stakeholder’s end, he takes the process to the next step.

4. The Termination Phase: This is the last phase of any project, and it marks the
official closure of the project.

This general lifecycle structure is used when dealing with upper management or other
people less familiar with the project. Some people might confuse it with the project
management process groups, but the latter contains activities specific to the project. The
project lifecycle, on the other hand, is independent of the life cycle of the particular
outcome of the project. However, it is beneficial to take the current life-cycle phase of the
product into account. It can provide a common frame of reference for comparing different
projects

The generic life cycle structure commonly exhibits the following characteristics:

 At the start, cost and staffing levels are low and reach a peak when the work is in
progress. It again starts to drop rapidly as the project begins to halt.

 The typical cost and staffing curve does not apply to all projects. Considerable
expenses are required to secure essential resources early in its life cycle.

 Risk and uncertainty are at their peak at the beginning of the project. These factors
drop over the lifecycle of the project as decisions are reached, and deliverables are
accepted.

 The ability to affect the final product of the project without impacting the cost
drastically is highest at the start of the project and decreases as the project advances
towards completion. It is clear from the figure 2 that the cost of making new changes and
rectifying errors increases as the project approaches completion.
 These features are present almost in all kinds of project lifecycles but in different ways or
to different degrees. Adaptive life cycles are developed particularly with the intent of
keeping stakeholder influences higher and the costs of changes lower all through the life
cycle than in predictive life cycles.
 

Let’s take a look at how knowledge on project lifecycle benefits an organization:

 It helps professional services teams to be more proficient and profitable.

 It helps the organization.

 It makes the flow of communication easier.

 It emphasizes on reporting and examining previous projects.

he Project Life Cycle consists of four main phases through which the Project
Manager and his team try to achieve the objectives that the project itself sets.
The four phases that mark the life of the project are: conception / start, planning,
execution / implementation and closure.
Each project therefore has a beginning, a central period, a completion and a final
phase (successful or not). All phases that we will analyze in this article constitute the
so-called Project Life Cycle .
Obviously, those mentioned are only the main phases of the project, which means the
starting point for a further subdivision in sub-phases, activities and tasks,
increasingly basic and detailed, necessary for the development and allocation of
work among the resources.
For each phase or lifecycle activity, the project manager must have two clear things
in mind:

 The objectives of each project phase: based on company constraints ranging

from quality to timing and costs;
 Products (derivable): every activity must lead to results that can be tangible
goods or a documentation or specific services, etc.
But now we specifically enter the four main phases of the project life cycle.
CONTENT INDEX
 The start-up phase
 The planning phase
 The execution phase
 The closing phase

Project Life Cycle: The initiation phase

During this first phase, the objective or “need” of the project is identified.
This can be, for example, the resolution of a business problem or the analysis and
creation of a concrete opportunity.

An appropriate responce to the need can be documented in a business case with the

recommended solution options.
A feasibility study is then conducted to verify if each option is in line with the
objective and a final solution is determined.

The feasibility study asks questions about the feasibility of the project. Questions

such as “can we do the project? Do we have the resources to do it?”.
Furthermore, a justification study phase of the project is also carried out, for example
by answering the question “is the project necessary for this objective?”.
Once these analyzes have been carried out and the project is considered feasible
and necessary, this is officially started and, in case it has not already been identified,
a project manager is appointed.

The project team is thenidentified and involved, thus starting to take shape.

At this point we can then move on to the detailed planning phase.
Project Life Cycle: The planning phase
In this phase we start from the objective of the project and move on to develop it in
as much detail as possible, planning the steps necessary to reach the final solution.
The individual tasks of the project are then identified, as well as the requirements
that the resources must have and the strategy to follow.
A project plan is created that illustrates the activities, tasks and timelines.
The project manager coordinates the preparation of a project budget by providing
cost estimates for labor, equipment and materials, if needed.
The budget is used to monitor and control the expenses incurred during the entire
project phase.
Once the Project Manager has identified the work, prepared the strategy and the
performance and estimated costs, the basic components of the planning process are
complete.
It comes then the right time to identify and address any factor that may pose a threat
to the success of the project. This part is called risk management.
Potential problems are identified, as well as the action that must be taken to avoid
them, solve them or at least reduce their impact.

This is also a good time to identify all stakeholders and establish a communication

plan that sets out the information needed to keep all the parties involved in the
project informed.
Finally, the project manager will draw up a quality plan that includes the quality
objectives, the control measures, also listing the criteria to be met  obtain the
acceptance of the client – customer that can be the company itself.
Arrived here, the project has been discussed and planned in detail, and is ready to
run and move on to the next stage.
Project Life Cycle: The execution phase
During the third phase, that of the implementation, the project plan is put into motion
and the work is performed in concrete, following the steps structured in the planning
phase.
It is important and fundamental to maintain control and communicate how – and
when – necessary during this whole phase.

Progress is continuously monitored and appropriate  changes are made and

documented as variations with respect to the original plan.

Whatever project  it is, a project manager usually spends most of the time at this
stage.

During the execution of the project, people perform their tasks and progress
information is exchanged through regular team meetings, so-called progress status
meetings .
The project manager uses this information to maintain control over the project
direction by comparing progress reports with the project plan, to measure the
performance of activities and take corrective actions if necessary.
The main strategy should always be to bring the project back to its original
course,that of the project plan drawn up in the previous phase. If this is not possible,
the changes from the original plan must be recorded and the modified plan must be
formalized.

During this step, project sponsors and all other stakeholders should be regularly

informed about the progress of the work.
Each product result should be analyzed and accepted.

Once the results of the various steps have been produced and the client has
accepted the final solution, the project is ready for closure.
Project Life Cycle: The closing phase
During this closing phase, the emphasis is placed on:
 the final results;
 the delivery of project documentation;
 the termination of supplier contracts;
 the release of project resources;
 the communication of the closure of the project to all the stakeholders.
The last remaining step is to conduct an analysis of what went well and what did not.

Through this type of analysis you gain experience and knowledge, are gained,
factors that will help the project manager, and the team in general, for future
projects.

Unfortunately, the closing phase is often underestimated and in many companies

the project is delivered without further evaluation; it only matters if the project was a
success or not.

In reality, it isn’t only important to conclude a project successfully, but also to be able
to execute it in the way that was set in the original project plan.
There is no shortage of cases in which the objective has been achieved despite
having experienced a phase of execution full of changes, delays and problems.

The closure phase also serves to analyze this, in order to avoid making the same
mistakes in the future and not adequately assessing certain risks.
The four phases of this life cycle may vary according to the sector and the type of
project, but in general they are valid in any area.

When a project manager follows Project Life Cycle taking into account all the factors
of each individual phase, he will have already taken the first step towards success.

Understand the Work Breakdown

Structure (WBS)
The work breakdown structure can be confusing, especially for new project
managers. Despite its name, it doesn’t actually involve breaking down work; it
involves breaking down deliverables.
This, among others, is one of several reasons why you need a thorough
understanding of the work breakdown structure before you can create your own.
What is a WBS or Work
Breakdown Structure?
As with most things in project management, let’s start by looking at what PMBOK
has to say about the work breakdown structure.
“A deliverable-oriented hierarchical decomposition of the work to be executed by
the project team to accomplish the project objectives and create the required
deliverables”

That’s a mouthful!
Let’s try another definition, this time from the Association of Project Management:
“A Work Breakdown Structure (WBS) is a hierarchical structure of things that the
project will make or outcomes that it will deliver”

This one is far better.

Let’s simplify things further:
“A work breakdown structure defines all the things a project needs to
accomplish, organized into multiple levels, and displayed graphically.”   

Essentially, the WBS defines the “what” of the project. Everything you need to
accomplish in the project is displayed in a single, easy to understand chart. The
purpose of this chart is to break down complex activities into smaller, more
management constituents.
For example, here’s a WBS example for an aircraft system:
 
 
Developing an aircraft system is obviously a very complex endeavor. You need
an aircraft (which itself is an extremely complex undertaking), a system to train
staff and pilots, a way to manage infrastructure, etc.
As shown above, a WBS breaks down all these complex activities into smaller,
more management constituent parts.
Thus, you might have one group responsible for building an aircraft. Within this
group, you might have one team focused on building the airframe, another on
creating a propulsion system, and so on.
It’s common to have three levels of decomposition in the WBS. You might have a
fourth and even a fifth level in case of extremely complex projects. For most
projects, however, three levels will suffice.
Here’s another example of a bicycle construction broken down into three levels:
 

 
The numbers next to each item indicate the number of hours or resources
required to complete the work. The sum of all these must be 100 at each level.
This is the oft-quoted “100% rule” - that the sum of the work at each “child” level
must be 100% of the work at the “parent” level.
 
 
You’ll notice that the WBS doesn’t describe any actions. Instead, every item is a
noun describing an end product - a bicycle seat, fork, handlebar, etc.
This is one of the fundamental features of a WBS: it describes deliverables, not
the activities necessary to get there. Every item in the WBS must correspond to
an end product (real or virtual). If there are any verbs in your WBS, then you’re
doing something wrong.
For example, if you’re creating a work breakdown structure for manufacturing a
car, you’ll include items such as “car body” (a deliverable), not “welding steel” (an
activity).
Before we dive further into the benefits and impact of a WBS, there are a few
additional definitions you should know.

Additional Definitions
Throughout this article and others related to WBS, you’ll come across terms such
as “work”, “deliverable”, “work package”, etc.
In the context of project management, these terms often have very specific
definitions:
 Work: According to PMBOK, work refers to “work products or deliverables
that are the result of effort and not the effort itself”. That is, “work” defines the end
result of any activity. The work remains constant even though the amount of
effort needed to get there might inflate/deflate.

 Deliverable: PMBOK says that a deliverable is “any unique and verifiable

product, result, or capability to perform a service that is required to be produced
to complete a process, phase, or project”. Deliverables will vary from project to
project and client to client.

 Work package: According to PERT (which developed the WBS), a work

package is “the work required to complete a specific job or process, such as a
report, a design, a documentation requirement or portion thereof, a piece of
hardware, or a service.” PMBOk has a simpler definition: “a work package is a
deliverable at the lowest level of the WBS.”

For example, if you’re building a bicycle, a “bike seat” might be one of

your deliverables. All the work required to create the seat - cutting leather,
shaping foam, creating metal frame, etc. - would be part of the work package.

What are the Characteristics of the Work

Breakdown Structure?
Not every breakdown of project deliverables can be classified as a WBS. For it to
be called a work breakdown structure, it must have certain characteristics:
 Hierarchy: The WBS is hierarchical in nature. Each “child” level exists in a
strict hierarchical relationship with the parent level. The sum of all the child
elements should give you the parent element.

 100% rule: Every level of decomposition must make up 100% of the

parent level. It should also have at least two child elements.

 Mutually exclusive: All elements at a particular level in a WBS must be

mutually exclusive. There must be no overlap in either their deliverables or their
work. This is meant to reduce miscommunication and duplicate work.

 Outcome-focused: The WBS must focus on the result of work, i.e.

deliverables, rather than the activities necessary to get there. Every element
should be described via nouns, not verbs. This is a big source of confusion for
beginners to WBS.

Work Breakdown Structure (WBS)

Examples
The best way to understand how work breakdown structures work is by looking at
different wbs examples. Seeing how complex projects are actually broken down
can help you do the same in your projects.
While work breakdown structures are technically supposed to focus on
deliverables, not activities (i.e. nouns, not verbs), plenty of project managers skip
this rule in actual projects. Which is why you’ll see WBS examples where top-
level “deliverables” actually describe activities. 
This isn’t ideal, but keep in mind that people use work breakdown structure for all
sorts of things, even outside of project management - writing a book, planning a
vacation, etc. If you’re using it casually, you don’t really have to follow all the hard
rules we discussed above.
On that note, let’s look at some work breakdown structure examples.
A construction project WBS example
This first example comes courtesy of StakeholderMap.com and shows a WBS for
a construction project. 

This is a three-tier WBS with each level denoted with numerical notation (such as
“1.1.2”). For each subsequent level, you’d add another decimal to the notation
(such as “1.1.2.1”). 
Also note how the WBS is organized into broad deliverables and sub-
deliverables, all of which are nouns, not activities. Further, if you were to add up
all the deliverables together, you’d get the first level in the WBS, i.e. the 100%
rule.
This is the key defining trait of a good WBS.

A casual WBS example

The convenient format of the WBS means that you can use it for any number of
purposes, including managing casual projects.
In such cases, you don’t really have to follow the formal guidelines of a work
breakdown structure. Rather, your goal should be to create natural categories
and sub-categories. The only restriction? They should all add up to 100% of the
work to be done.
Here’s an example from AmericanWaterCollege.org:

Note that the WBS lists activities (“cut lawn”) instead of deliverables. This
wouldn’t pass muster in a formal work breakdown structure, but if you’re using
something internally, it doesn’t really matter as long as each level makes sense
to you.
 
Computer program WBS example
In this third WBS example from VisualParadigm.com, we see one of the biggest
mistakes people make when creating the WBS: mistaking activities for
deliverables.
As you can see below, the third-level in the WBS identifies activities such as
“develop business case” or “perform primary planning”. 

This is superfluous within the context of a WBS. If you remove the verb from
each of these WBS levels, you’d get a deliverable (i.e. a noun), not an activity.
That is, you don’t need “develop business case” - just “business case” is enough.
Keep this in mind when you create your work breakdown structures. Remove
verbs from each WBS level. You are, after all, describing things that need to be
delivered, not the tasks necessary to deliver them.
 Work Breakdown Structure vs Project
Schedule vs Project Plan
Another common source of confusion for beginners is the difference between the
work breakdown structure, project schedule, and project plan.
While these three things often describe the same thing - what is to be achieved in
the project - they vary greatly in scope and details.

 Work breakdown structure describes the deliverables needed to

complete the project, i.e. the “what” of the project. It doesn’t include timelines or
resources. The goal of the WBS is to give the project team a hyper-focused idea
of what they need to achieve.

 Project schedule describes the project’s deliverables as well as their

deadlines and resource requirements. Think of it as the “what”,
“when”, and “who” of the project.

 Project plan is an expansive document covering virtually every aspect of

the project and its management. It includes details on how the project will be
executed, managed, and controlled. It usually has several constituent plans
governing communications, risk management, change management, etc.

In terms of the level of detail, you can think of the project plan as the broadest,
followed by the project schedule, and finally, the work breakdown structure.
 
  
This might make you ask: why bother with the work breakdown structure at all?
Can’t you get all the same details in the project schedule?
As you’ll see below, the WBS has several advantages over the project schedule.
 

What are the benefits of a WBS?

The WBS is a laser-focused breakdown of all the key deliverables needed to
make the project successful. Creating one offers several advantages, such as:

 Project schedule: The WBS is the foundation of the project schedule and

budget. Once you know all the deliverables required to complete the project, as
well as their hierarchical relationships, it will be much easier to assign resources
and set deadlines.

 Accountability: Since all elements in a WBS are mutually exclusive, it

helps create accountability. A team assigned to a single work package is wholly
accountable for its completion. This reduces overlaps in responsibility.
  

 Commitment: The WBS gives teams a very high-level overview of their

responsibilities. Since each team is responsible for a specific component at a
time, it helps make them more committed to completing their assigned tasks.

 Reduces ambiguities: The process of developing the WBS involves the

project manager, project team, and all relevant stakeholders. This encourages
dialog and helps everyone involved flesh out their responsibilities. Thus,
everyone has less ambiguity and a better idea of what they're supposed to do.

Creating a WBS is the first step in developing a comprehensive project schedule.

It can be of massive help in getting everyone to understand the project’s scope
and deliverables at different levels.

Work Breakdown Structure in Project

Management
This brings us to an important question: where does the WBS fit within the
project management framework?
The work breakdown structure springs from the project charter. Ideally, the high-
level deliverables in the WBS should match, word for word, the goals and
deliverables listed in the project scope statement.
Consequently, the WBS is one of the first documents you create in the project
management lifecycle. You’ll create it before you create the Gantt chart or the
project plan.
Which is to say, the WBS is often the first deliverable in a project.
 While the stated benefit of a WBS is in helping you keep track of deliverables and
managing project scope, it has another key use in project management: creating
the project schedule.
As this PMI conference paper points out, understanding the deliverables included
in a WBS and mapping their relationships is crucial for charting a project
schedule. Within this process, you first create a WBS dictionary (i.e. list of
deliverables), turn these deliverables into a map of relationships (i.e. a network
diagram) and use it to create the schedule.

You can also use the map of deliverables (and the relationships between them)
in a WBS to figure out the resources to be used in their creation. This is called
a Resource Breakdown Structure (RBS). 
A resource breakdown structure consists of both the material and human
resources required to complete a deliverable. For example, if you’re creating a
chair as part of a larger house remodeling project, you’ll need:

 A carpenter

 Raw materials such as wood, polish, nails, glue, etc.

 Tools such as hammers, saws, drills, etc.

You can represent these resources as follows:

Once you understand how resources will be used to create each deliverable, you
can also improve your project scheduling - one of the many ways a work
breakdown structure finds use in project management.
I’ll share a process for creating a WBS in the next section.
 
 
 

 
 How to Create a Work Breakdown
Structure
The output of the WBS development process might seem simple: a short
document with a list of deliverables. To create it, however, you need a thorough
understanding of the project’s scope, your team’s capabilities, and your
stakeholders’ requirements.
Here’s a process for creating a WBS from scratch.

1. Understand the Project’s Scope

In our earlier project management guide, we identified the WBS as one of the key
documents created at the end of the ‘Planning’ phase.
 
  
Before you can create it, however, you need a thorough understanding of the
project’s scope and objectives.
Chiefly, you need two things:

 Project scope statement to understand the project’s scope in detail.

 Project scope management plan to understand how to deal with

changes to the project’s scope (which will affect your deliverables).

You’ll want to refer to your project charter to develop the scope statement and
scope management plan.
The output of the entire WBS development process is as follows:

 Work breakdown structure

 WBS dictionary

 Scope baseline

2. Determine Major Deliverables

Once you have an understanding of the project scope, start the WBS
development process by figuring out the key deliverables.
For example, if your goal is to “build a house”, you might have the following three
broad deliverables at Level 2:
  

 
There are two heuristics you can follow for determining major deliverables at the
2nd level:

 Each deliverable must be essential to the success of the project. For

example, you can’t build a house without a foundation, exterior, or interior.

 Each deliverable should be the responsibility of an independent team. In

the above example, the team responsible for laying the foundation won’t be the
same as the team building the interiors.

3. Determine Work Packages

A work package, as you learned above, is a deliverable at the lowest level of a
WBS.
In a typical 3-level WBS, determining work packages would be the next step after
identifying major deliverables.
This is one of the most important parts of the WBS development process and
one that will require extensive input from your project team and stakeholders.
 Your goal is to pick a major deliverable, then identify all the work necessary to
complete it. This work package must be:

 Independent: The work package must be mutually exclusive and have no

dependence on other ongoing elements.

 Definable: The work package should have a definite beginning and end,
and should be understood by all project participants.

 Estimable: You should be able to estimate the work package's duration

and resource requirements.

 Manageable: The package must represent a "meaningful unit of work", i.e.

it must accomplish something concrete, and can be assigned to an individual or
team. It should also be measurable.

 Integratable: The package must integrate with other elements to create

the parent level.

 Adaptable: Ideally, the package must be able to accommodate changes in

scope as per the project's requirements.

In case the work can’t meet the above requirements, you can decompose the
WBS into another level.
 There are a few heuristics you can follow for determining work packages:

 8/80 rule: A common rule of the thumb is that each work package must be
no longer than 80 hours and no less than 8 hours in total length. If it is longer,
decompose it further. If it is shorter, think of going up by one level.

 Reporting period: Another common rule is to limit each work package to

a single reporting period. If it takes longer than one reporting period (monthly,
weekly, etc.), to accomplish, decompose it further.

 Use nouns: You should be able to describe each work package with a

noun or an adjective. To break it down further, you’ll need to use verbs. For
example, “bike seat” is a noun describing a work package. If you break it down
further, you’ll need to use verbs like “cut foam”, “stitch leather”, etc.

4. Create a WBS Dictionary

The WBS dictionary is a document that outlines the definition and scope of each
element contained in the WBS. It is a supporting document meant to help
incoming project teams understand each work package better.
You don't necessarily need a WBS dictionary, especially if the project is simple or
limited in scope. For complex projects with a lot of churn, however, the dictionary
can greatly improve clarity.
Further, the WBS dictionary takes you one step closer to creating the project
schedule. You can often transplant details from this dictionary straight to your
project scheduling tool.
 Here are a few details you can include for each item in the WBS dictionary:

 Work package ID (see the ID convention below)

 Work package name

 Work package description

 Assigned to (individual or team name)

 Department

 Date of assignment

 Due date

 Estimated cost

The level of detail you want to include is entirely up to you.

Here's an example of a more simplified WBS dictionary with element ID, name,
and description:
 
 A WBS dictionary helps project team members understand each element (Image
source)

5. Use the Right WBS Format

Once you have all the work packages and WBS dictionary, it’s time to create the
WBS.
There are several WBS formats you can follow. The simplest way to do this is to
create text-based hierarchical groupings. By convention, you use numbers and
decimal points to indicate the level of the element.
For example, the number 1.1.1.3 means that you’re referencing the 3rd
element of the 4th level of the WBS.
Thus, you might have a text-based WBS as follows:
 
 
Alternatively, you might use a more visual tabular structure as follows:
 

 
Another option is to create a flowchart:
 
 
Once you’ve made the work breakdown structure, share it with your team. Use it
to get a high-level overview of the project’s progress.
 

Work Breakdown Structure Template

While creating a work breakdown structure is technically easy (it’s just a
flowchart or an Excel sheet, after all), it can be time consuming.
Which is why we created this work breakdown structure template to help you get
started.

All risk management processes follow the same basic steps, although
sometimes different jargon is used to describe these steps. Together these 5
risk management process steps combine to deliver a simple and effective risk
management process.
Step 1: Identify the Risk. You and your team uncover, recognize and
describe risks that might affect your project or its outcomes. There are a
number of techniques you can use to find project risks. During this step you
start to prepare your Project Risk Register.

Step 2: Analyze the risk. Once risks are identified you determine the
likelihood and consequence of each risk. You develop an understanding of the
nature of the risk and its potential to affect project goals and objectives. This
information is also input to your Project Risk Register.

Step 3: Evaluate or Rank the Risk. You evaluate or rank the risk by

determining the risk magnitude, which is the combination of likelihood and
consequence. You make decisions about whether the risk is acceptable or
whether it is serious enough to warrant treatment. These risk rankings are
also added to your Project Risk Register.

Step 4: Treat the Risk. This is also referred to as Risk Response Planning.

During this step you assess your highest ranked risks and set out a plan to
treat or modify these risks to achieve acceptable risk levels. How can you
minimize the probability of the negative risks as well as enhancing the
opportunities? You create risk mitigation strategies, preventive plans and
contingency plans in this step. And you add the risk treatment measures for
the highest ranking or most serious risks to your Project Risk Register.

Step 5: Monitor and Review the risk. This is the step where you take your
Project Risk Register and use it to monitor, track and review risks.

Risk is about uncertainty. If you put a framework around that uncertainty, then
you effectively de-risk your project. And that means you can move much more
confidently to achieve your project goals. By identifying and managing a
comprehensive list of project risks, unpleasant surprises and barriers can be
reduced and golden opportunities discovered. The risk management process
also helps to resolve problems when they occur, because those problems
have been envisaged, and plans to treat them have already been developed
and agreed. You avoid impulsive reactions and going into “fire-fighting” mode
to rectify problems that could have been anticipated. This makes for happier,
less stressed project teams and stakeholders. The end result is that you
minimize the impacts of project threats and capture the opportunities that
occur.

The project team mitigates risks in the following ways:

 Risk avoidance
 Risk sharing
 Risk reduction
 Risk transfer

Each of these mitigation techniques can be an effective tool in reducing individual risks and the
risk profile of the project. The risk mitigation plan captures the risk mitigation approach for each
identified risk event and the actions the project management team will take to reduce or
eliminate the risk.

Risk avoidance usually involves developing an alternative strategy that has a higher probability
of success but usually at a higher cost associated with accomplishing a project task. A common
risk avoidance technique is to use proven and existing technologies rather than adopt new
techniques, even though the new techniques may show promise of better performance or lower
costs. A project team may choose a vendor with a proven track record over a new vendor that is
providing significant price incentives to avoid the risk of working with a new vendor. The
project team that requires drug testing for team members is practicing risk avoidance by avoiding
damage done by someone under the influence of drugs.

Risk sharing involves partnering with others to share responsibility for the risk activities. Many
organizations that work on international projects will reduce political, legal, labor, and others
risk types associated with international projects by developing a joint venture with a company
located in that country. Partnering with another company to share the risk associated with a
portion of the project is advantageous when the other company has expertise and experience the
project team does not have. If the risk event does occur, then the partnering company absorbs
some or all of the negative impact of the event. The company will also derive some of the profit
or benefit gained by a successful project.

Risk reduction is an investment of funds to reduce the risk on a project. On international

projects, companies will often purchase the guarantee of a currency rate to reduce the risk
associated with fluctuations in the currency exchange rate. A project manager may hire an expert
to review the technical plans or the cost estimate on a project to increase the confidence in that
plan and reduce the project risk. Assigning highly skilled project personnel to manage the high-
risk activities is another risk reduction method. Experts managing a high-risk activity can often
predict problems and find solutions that prevent the activities from having a negative impact on
the project. Some companies reduce risk by forbidding key executives or technology experts to
ride on the same airplane.

Risk transfer is a risk reduction method that shifts the risk from the project to another party. The
purchase of insurance on certain items is a risk transfer method. The risk is transferred from the
project to the insurance company. A construction project in the Caribbean may purchase
hurricane insurance that would cover the cost of a hurricane damaging the construction site. The
purchase of insurance is usually in areas outside the control of the project team. Weather,
political unrest, and labor strikes are examples of events that can significantly impact the project
and that are outside the control of the project team.
Contingency Plan

The project risk plan balances the investment of the mitigation against the benefit for the project.
The project team often develops an alternative method for accomplishing a project goal when a
risk event has been identified that may frustrate the accomplishment of that goal. These plans are
called contingency plans. The risk of a truck drivers’ strike may be mitigated with a contingency
plan that uses a train to transport the needed equipment for the project. If a critical piece of
equipment is late, the impact on the schedule can be mitigated by making changes to the
schedule to accommodate a late equipment delivery.

Contingency funds are funds set aside by the project team to address unforeseen events that
cause the project costs to increase. Projects with a high-risk profile will typically have a large
contingency budget. Although the amount of contingency allocated in the project budget is a
function of the risks identified in the risk analysis process, contingency is typically managed as
one line item in the project budget.

Some project managers allocate the contingency budget to the items in the budget that have high
risk rather than developing one line item in the budget for contingencies. This approach allows
the project team to track the use of contingency against the risk plan. This approach also
allocates the responsibility to manage the risk budget to the managers responsible for those line
items. The availability of contingency funds in the line item budget may also increase the use of
contingency funds to solve problems rather than finding alternative, less costly solutions. Most
project managers, especially on more complex projects, will manage contingency funds at the
project level, with approval of the project manager required before contingency funds can be
used.