What is requirements gathering in project management?

Requirements gathering is the process of identifying your project’s exact requirements from start to finish. This

process occurs during the project initiation phase but you’ll continue to manage your project requirements

throughout the entire project timeline.

Requirements gathering typically happens during the project brief or initial kick-off meeting.

Some questions include:

• How long will our project schedule be?

• Who will be involved in the project?

• What risks may we face in this project?

Requirements gathering shouldn’t be complex, but it’s an important component of the project initiation process.

The 6-step requirements gathering process

To gather your requirements, use the following six-step process. Once you’re finished, you should have a

comprehensive requirements document outlining the resources you need to move forward through the project

phases.
Step 1: Assign roles

The first step in requirements gathering is to assign roles in your project. This is when you identify your project

stakeholders.

A stakeholder is anyone invested in the project, whether they’re internal or external partners. For example, a

customer is an external stakeholder, while a department manager or board member is an internal stakeholder.

Identifying these roles first will help you determine who should analyze your project scope later on.

Other roles include the project manager, project administrator, designers, product testers, and developers. These

people can help you identify the requirements and resources you need in order to hit your project goals.

While you may feel tempted to jump headfirst into your project and start listing all the things you know you’ll

need, this can be a mistake. Slow down and stick to the process and you’ll have a better chance of

preventing project risk.

Step 2: Meet with stakeholders

Once you’ve identified your project stakeholders, meet with them to get an idea of what they’re hoping to get

out of the project. Understanding what stakeholders want matters because they’re ultimately the ones you’re

creating your deliverables for.

Some questions you can ask include:

• What is your goal for this project?

• What do you think would make this project successful?

• What are your concerns about this project?

• What do you wish this product or service would do that it doesn’t already?

• What changes would you recommend about this project?

The stakeholders are the people you’re ultimately developing the project for, so you should ask them questions

that can help you create your list of requirements.

Step 3: Gather and document

Step three in the process happens at the same time as step two. You’ll gather information as you ask your

stakeholders questions. The goal is to document everything you can, so have all of the answers you need to start

your project.
Use a project management tool to collect and document this information. That way, you can keep your project

plan, project requirements, and project communication all in one place. Some examples of what you might

document include:

• Stakeholder answers to interview questions

• Stakeholder questions

• Stakeholder requests

• Stakeholder comments

• Questions and comments that arise during interviews

You don’t have to use every answer you receive, but having everything documented can help you see all of your

stakeholders’ perspectives, which will help you with requirements management.

Step 4: List assumptions and requirements

Now that you’ve completed the intake process, create your requirements management plan based on the

information you’ve gathered.

Consider the questions you initially set out to answer during the requirements gathering process. Then, use them

to create your requirements goals, including:

• Length of project schedule: You can map out your project timeline using a Gantt chart and use it to

visualize any project requirements that depend on project milestones. Some requirements will apply for

the full duration of the project, whereas others may only apply during distinct project phases. For

example, you’ll need a specific budget for team member salaries throughout the entire project, but you

may only need specific material during the last stage of your project timeline.

• People involved in the project: Identify exactly which team members will be involved in your project,

including how many designers, developers, or managers you’ll need to execute every step. People are

part of your project requirements because if you don’t have the team members you need, you won’t be

able to complete the project on time.

• Project risks: Understanding your project risks is an important part of identifying project requirements.

Use a risk register to determine which risks are of highest priority, such as stakeholder feedback,

timeline delays, and lack of budget. Then, schedule a brainstorming session with your team to figure

out how to prevent these risks.

Like SMART goals, your project requirements should be actionable, measurable, and quantifiable. Try to go

into as much detail as possible when listing out your project budget, timeline, required resources, and team.

Step 5: Get approval

Once you formalize your project requirements, you’ll need approval from stakeholders to ensure you’re meeting

user needs. Encouraging clear communication can also prevent scope creep by ensuring your stakeholders know

the limits of the project from the beginning. You can then proceed with your implementation plan, which may

include acquiring resources and assembling a team.

Step 6: Monitor progress

The last part of the process is monitoring the progress of your project. You can use project management

software to track your project budget and other requirements as you move through project execution. The

benefit of project management software is that you can see changes to your project in real-time and take

immediate action when things go awry.

Read: How to write a software requirement document (with template)

Requirements gathering techniques

While the basic process of requirements gathering involves asking stakeholders for their input, sometimes

stakeholders won’t know what’s best for a project. In those cases, you're responsible for gathering the

information necessary to understand what your project requirements should be.

To ensure you’re fully prepared for the project life cycle, you can use the following research techniques.

• Questionnaires: Questionnaires can be beneficial if you need to ask stakeholders the same question

across the board. Share the questionnaire with stakeholders in advance, and give them time to answer

questions about project requirements, to ensure no one leaves anything out. While questionnaires can

be valuable ways to gather requirements, they’re not very effective for executive stakeholders, who

may be too busy to fill them out.

• Use case scenarios: A use case scenario is a written description of how you think your team members

will execute the project. These scenarios may include who’s involved in the project, what you expect

them to do, and the steps they’ll take to accomplish your project goal. Sharing a use case scenario gives
 stakeholders a clear picture of the project roadmap and planned deliverables. Stakeholders then have

something to respond to if the use case doesn’t meet their expectations.

• Mind mapping: Mind mapping is a visual form of brainstorming that’s particularly helpful for

assessing what project requirements you need. In the center of your mind map, place your main project

objective. In bubbles branching off from the main objective, list categories of things you need. As the

map continues to branch out, you can include more detailed with your requirements until you’ve

captured all of your project requirements.

• Prototyping: Interviewing your stakeholders may not be successful if they don’t know exactly what

they want out of the project. In that case, try creating prototypes to show stakeholders what the

potential deliverable could look like. This can help your stakeholders define what they do and don’t

like so you can identify the exact requirements you need to launch the project.

If none of these techniques feel quite right, check out other online tools to also help you gather information, like

an idea board, a focus group, user stories, or a decision matrix template.

A work breakdown structure (WBS) is a visual, hierarchical and deliverable-oriented deconstruction of a

project. It is a helpful diagram for project managers because it allows them to break down their project scope

and visualize all the tasks required to complete their projects.

All the steps of project work are outlined in the work breakdown structure chart, which makes it an essential

project planning tool. The final project deliverable, as well as the tasks and work packages associated with it rest

on top of the WBS diagram, and the WBS levels below subdivide the project scope to indicate the tasks,

deliverables and work packages that are needed to complete the project from start to finish.

Project managers make use of project management software to lay out and execute a work breakdown structure.

When used in combination with a Gantt chart that incorporates WBS levels and task hierarchies, project

management software can be especially effective for planning, scheduling and executing projects.

ProjectManager is an online work management software with industry-leading project management tools like

Gantt charts, kanban boards, sheets and more. Plan using WBS levels in our tool, then execute with your team

via easy-to-use kanban boards and task lists. Try it for free today.
Why Use a WBS In Project Management?

Making a WBS is the first step in developing a project schedule. It defines all the work that needs to be

completed (and in what order) to achieve the project goals and objectives. By visualizing your project in this

manner, you can understand your project scope, and allocate resources for all your project tasks.

A well-constructed work breakdown structure helps with important project management process groups and

knowledge areas such as:

• Project Planning, Project Scheduling and Project Budgeting

• Risk Management, Resource Management, Task Management and Team Management

In addition, a WBS helps avoid common project management issues such as missed deadlines, scope creep and

cost overrun, among others.

In other words, a work breakdown structure serves as your map through complicated projects. Your project

scope may include several phases, or smaller sub-projects—and even those sub-projects can be broken down

into tasks, deliverables, and work packages! Your WBS can help you manage those items, and gain clarity into

the details needed to accomplish every aspect of your project scope.

Work Breakdown Structure Example

Now that we’ve gone through the definition of a WBS and learned why they are a great project management

tool, let’s take a look at a work breakdown structure example.

For our WBS example, we’ll be creating a work breakdown structure to lay down the work plan for a

commercial building construction project. This is potentially a complex project, but a WBS chart will take that

complexity and boil the project scope down to simpler tasks to make the project manageable.

Study the phase-based work breakdown structure example of a construction project below:
At the top of the work breakdown structure is your final deliverable (in this instance, the construction project).
Immediately beneath that is the next WBS level, which are the main project phases required to complete the
project. The third and lowest level shows work packages. Most WBS charts have 3 levels, but you can add more
depending on the complexity of your projects.

Each of those five project phases—initiation, planning, execution, control and closeout, also act as control
accounts and branch off the main deliverable at the top. Once decided, they are then broken down into a series
of deliverables. For example, the initiation phase includes site evaluation work and creating the project charter.

You’ll also need a work package to go with each of those project deliverables. In the execution phase in our
construction example, we can look at the interior work deliverable. That deliverable is divided into two work
packages, which are installing the plumbing and setting up the electricity.

The WBS, when created as thoroughly as possible, is the roadmap to guide you to completion of what would
seem to be a very complicated project scope. However, when broken down with a WBS, project planning,
scheduling and resource planning suddenly become much more manageable.

Types of WBS

There are two main types of WBS: deliverable-based, and phase-based. They depend on whether you want to

divide your project in terms of time or scope.

Deliverable-Based Work Breakdown Structure

A deliverable-based WBS first breaks down the project into all the major areas of the project scope as control

accounts, and then divides those into project deliverables and work packages.
Here’s an example of a deliverable-based WBS that’s taken from our free work breakdown structure

template. Download the template today to practice building your own work breakdown structure in Excel.

An deliverable-based WBS example showing control accounts, work packages and tasks.

Phase-Based Work Breakdown Structure

The phase-based WBS displays the final deliverable on top, with the WBS levels below showing the five phases

of a project (initiation, planning, execution, control and closeout). Just as in the deliverable-based WBS, the

project phases are divided into project deliverables and work packages. Our previous graphic in the “Work

Breakdown Structure Example” section contained a phase-based WBS example.

Types of WBS Charts

Once you’ve chosen a deliverable-based or phase-based WBS, you can also choose between different types of

WBS diagrams. Let’s take a look at the main types of work breakdown structure charts.

Work Breakdown Structure List: Also known as an outline view, this is a list of work packages, tasks and

deliverables. It’s probably the simplest method to make a WBS, which is sometimes all you need.

Work Breakdown Structure Tree Diagram: The most commonly seen version, the tree structure depiction of

a WBS is an organizational chart that has all the same WBS elements of the list (phases, deliverables, tasks and

work packages) but represents the workflow or progress as defined by a diagrammatic representation.

Work Breakdown Structure Gantt Chart: A Gantt chart is both a spreadsheet and a timeline. The Gantt chart

is a WBS that can do more than a static task list or tree diagram. With a dynamic Gantt chart, you can link
dependencies, set milestones, even set a baseline. This is the most common version in project management

software.

Build a work breakdown structure Gantt chart diagram in ProjectManager in just a matter of minutes. Get

started for free today.

WBS Elements

A typical project work breakdown structure is made up of several key components. We’ll use our WBS example

above to identify each of the main WBS elements.

• WBS Dictionary: A WBS dictionary is a document that defines the various WBS

elements. It’s an important component of a WBS because it allows the project

participants and stakeholders to understand the work breakdown structure terminology

with more clarity.

• WBS Levels: The WBS levels are what determines the hierarchy of a WBS element.

Most work breakdown structures have 3 levels that represent the project’s main

deliverable, control accounts, project deliverables and work packages.

• Control Accounts: Control accounts are used to group work packages and measure their

status. They’re used to control areas of your project scope. In our example the execution

project phase could be a control account because it has several deliverables and work

packages associated to it.

• Project Deliverables: Project deliverables are the desired outcome of project tasks and

work packages. In our WBS example, we can observe some examples of project

deliverables such as the project budget or interior work. Both of them are the result of

smaller tasks and work packages.

• Work Packages: As defined by the project management institute (PMI) in its project

management body of knowledge book (PMBOK) a work package is the “lowest level of

the WBS”. That’s because a work package is a group of related tasks that are small

enough to be assigned to a team member or department. As a project manager you can

estimate costs and duration of these work packages, which makes them an essential WBS

element.
 • Tasks: Your tasks make up your work packages and therefore, your project scope. A

WBS will help you define each task requirements, status, description, task owner,

dependencies, and duration.

If you prefer a visual and verbal explanation of this information on work breakdown structures, watch this

video.

How to Create a Work Breakdown Structure In Six Steps

To create a WBS for your project, you’ll need information from other project management documents. Here are

six simple steps to create a work breakdown structure.

1. Define the Project Scope, Goals and Objectives

Your project goals and objectives set the rules for defining your project scope. Your project scope, team

members, goals and objectives should be documented on your project charter.

2. Identify Project Phases & Control Accounts

The next level down is the project phases: break the larger project scope statement into a series of phases that

will take it from conception to completion. You can also create control accounts, which are task categories for

different work areas you want to keep track of.

3. List Your Project Deliverables

What are your project deliverables? List them all and note the work needed for those project deliverables to be

deemed successfully delivered (sub-deliverables, work packages, resources, participants, etc.)

4. Set WBS Levels

The WBS levels are what make a work breakdown structure a “hierarchical deconstruction of your project

scope”, as defined by the project management institute in its project management body of knowledge book

(PMBOK). You’ll need to start at the final project deliverable and think about all the deliverables and work

packages needed to get there from the start.

5. Create Work Packages

Take your deliverables from above and break them down into every single task and subtask that is necessary to

deliver them. Group those into work packages.

6. Choose Task Owners

With the tasks now laid out, assign them to your project team. Give each team member the work management

tools, resources and authority they need to get the job done.

How to Make a Project Schedule: In-Depth

Project scheduling occurs during the planning phase of the project life cycle. When beginning to put together a

schedule for your project, you should ask yourself four things to start:

1. What needs to be done?

2. When will it be done?

3. Who will do it?

4. Where will it be done?

The answers to these four questions will greatly inform your project schedule moving forward, as you’ll use this

information to plan start and end dates, link activities, set the duration, create milestones and manage resources.

Follow these steps to create a project schedule of your own!

1. Create the Project Scope

The project scope statement is created during the initial planning. It’s a document that contains the specific

goals, deliverables, features, budget, etc of your project. All of the tasks needed to complete the project

successfully are listed here (which requires understanding the stakeholder’s requirements.)

Be thorough when putting a task list together, you don’t want to leave anything out. By using a Work

Breakdown Structure (WBS) you can organize these activities and lay them out in order of completion.

Understanding task dependencies and their sequence is very important for schedule management.

2. Establish the Sequence of Tasks

Tasks are the small jobs that lead to the final deliverable, and it’s fairly crucial to map out the sequence of those

tasks before diving into them. Oftentimes a task will be dependent on another to start or finish. You don’t want

to get halfway through a task before you realize you can’t complete it due to hanging objectives.

3. Group Tasks
Once you’ve collected your tasks and have them in proper order, you should take the opportunity to divide your

tasks by importance. You need to know which is critical to the project implementation schedule and must be

done first and those less important that can be done if there’s time. You could use a priority matrix to facilitate

this process.

Then, break your tasks down with milestones that relate to the five project phases—initiation, planning,

execution, monitoring and close. Organizing your tasks with milestones makes it easier to track progress, and

gives your teams a sense of accomplishment that boosts morale and productivity.

4. Link Task Dependencies

Some tasks can be done simultaneously, but some tasks are dependent on others to start or finish before they can

start or finish. These task dependencies must be mapped out in your schedule to keep you aware of them, or you

risk bottlenecks and blocking your team.

5. Find the Critical Path

The critical path is a method for scheduling tasks in a project to find those which are critical to the success of

the project. This allows you to make smart choices about tasks that can be ignored if time and costs become

constrained. This method is commonly used for schedule risk analysis. A software that can find the critical path

for you can make this step a lot easier.

6. Assign Resources

Resource management and project scheduling are closely related. Every task on your schedule should have the

related resources and costs associated with completing it. Tasks aren’t done on their own, and without mapping

the resource availability to each task you’re in danger of going wildly over budget. With resources attached to

tasks, you can more accurately plan your team’s time and keep their workload balanced.

Creating a Project Budget

As noted above, there are many components necessary to build a budget, including direct and indirect costs,

fixed and variable costs, labor and materials, travel, equipment and space, licenses and whatever else may

impact your project expenses.

To meet all the financial needs of your project, a project budget must be created thoroughly, not missing any

aspect that requires funding. To do this, we’ve outlined seven essential steps toward creating and managing your

project budget:

1. Use Historical Data

Your project is likely not the first to try and accomplish a specific objective or goal. Looking back at similar

projects and their budgets is a great way to get a headstart on building your budget.

2. Reference Lessons Learned

To further elaborate on historical data, you can learn from their successes and mistakes. It provides a clear path

that leads to more accurate estimates. You can even learn about how they responded to changes and kept their

budget under control. Here’s a lessons learned template if you need to start tracking those findings in your

organization.

3. Leverage Your Experts

Another resource to build a project budget is to tap those who have experience and knowledge—be they

mentors, other project managers or experts in the field. Reaching out to those who have created rough order of

magnitude estimates and budgets can help you stay on track and avoid unnecessary pitfalls.

4. Confirm Accuracy

Once you have your budget, you’re not done. You want to take a look at it and make sure your figures are

accurate. During the project is not the time to find a typo. You can also seek those experts and other project

team members to check the budget and make sure it’s right.

5. Baseline and Re-Baseline the Budget

Your project budget is the baseline by which you’ll measure your project’s progress once it has started. It is a

tool to gauge the variance of the project. But, as stated above, you’ll want to re-baseline as changes occur in

your project. Once the change control board approves any change you need to re-baseline.
6. Update in Real Time

Speaking of changes, the sooner you know about them, the better. If your project planning software isn’t cloud-

based and updating as soon as your team changes its status, then you’re wasting valuable and expensive time.

7. Get on Track

The importance of having a project management software that tracks in real time, like ProjectManager, is that it

gives you the information you need to get back on track sooner rather than later. Things change and projects go

off track all the time. It’s the projects that get back on track faster that are successful.

If you manage your project expenses using these building blocks you’re going to have a sound foundation for

your project’s success.

A stakeholder is an individual, group or organization that is impacted by the outcome of a business venture or

project. Project stakeholders, as the name implies, have an interest in the success of a project, and can be

internal or external to the organization that is sponsoring the project.

Stakeholder relationships can have a positive or negative influence on your project life cycle, so you’ll need to

identify your key stakeholders and create a stakeholder management plan to meet their requirements.

Keeping track of your key stakeholders with project management software is a great way to stay on top of things

and ensure your project stakeholders remain satisfied and productive.

Who can be a project stakeholder? That’s a long list. Some examples are as follows.

• Project manager and project team members

• External customers

• Contractors and subcontractors

• Investors

• Suppliers

• Government agencies
There are two main types of project stakeholders: internal and external. Let’s see how they differ from each

other and how the stakeholder management process works for each stakeholder group.

Difference Between Internal and External Stakeholders

Internal Stakeholders

An internal stakeholder is someone whose interest in the project is directly related to being a part of the

organization that is managing that project. Internal stakeholders want to achieve the business goals and strategic

objectives of the project. They can be project managers, team members, sponsors, owners or even investors in

the organization.

External Stakeholders

External stakeholders are those who aren’t directly related to the organization, but they’re important to the

business or are impacted by the project to some extent. These are usually part of the supply chain, creditors or

public groups.

Related: Stakeholder Analysis Template

What Is Stakeholder Management?

Stakeholder management is a project management process that consists in managing the expectations and

requirements of all the internal and external stakeholders that are involved with a project.

To do so, project managers need to create a stakeholder management plan, an important project management

document that explains the stakeholder management strategies that will be applied during the project.

In addition, project managers use tools and techniques such as project status reports to facilitate the stakeholder

management process through each phase of the project life cycle.

It must be noted that the term stakeholder management is not exclusive to project management, but can also be

related to business administration. Stakeholder relationship management is as important for a small business as

it is for large corporations, medium-sized companies and even non-for-profit organizations.

Similarly, both project management teams and businesses of any size can benefit from using a project planning

software such as ProjectManager for stakeholder management. That’s because ProjectManager offers robust

planning tools such as Gantt charts, kanban boards, calendars and task lists.
What Is a Stakeholder Management Plan?

As stated above, a stakeholder management plan is a project management document that identifies your project

stakeholders and the strategies that you’ll use to communicate with them and meet their requirements.

A stakeholder management plan usually includes the following elements.

1. A list of all your project stakeholders along with their basic information.

2. A stakeholder map or power interest matrix.

3. A stakeholder prioritization section.

4. A stakeholder communication plan.

5. A section describing the various stakeholder management strategies to be applied in

different scenarios, such as conflict resolution or project status reporting techniques.

How to Make a Stakeholder Management Plan in 5 Steps

Even though each stakeholder management approach can be different depending on the needs of your project or

business, there are some best practices to manage your stakeholder relations.

Follow these five steps to make sure all of your bases in the stakeholder management plan are covered.

1. Identify your Stakeholders

The first step to any good stakeholder management plan is proper stakeholder identification. Identify who are

the key individual stakeholders and stakeholder groups to your project or business. Stakeholder theory can help

you better understand who your stakeholders are and how they’re affected by your project.

2. Prioritize Your Stakeholders

Note which key stakeholders are going to have a bigger influence over the project, and at which stage their

influence becomes lesser or greater. You can use an onion diagram for the stakeholder prioritization process.

Always keep an eye on your key stakeholder relations as they can have the highest impact in your project or

business.
3. Interview Your Stakeholders

Working with new stakeholders can be tricky at the start. Knowing your stakeholders is key to effective

stakeholder relationship management. Because of this it’s advisable to interview your project stakeholders, here

are some examples.

• What are your expectations for this project?

• Which deliverables are you most interested in?

• What do you hope this project changes after launch?

• How quickly do you see this project rolling out?

• If you feel positively about this project, why?

• If you have worries about this project, why?

4. Create a Power Interest Grid

A power interest grid or project interest matrix is a chart that allows you to determine the level of power and

interest that your stakeholders have in the project. It’s a very helpful project management tool for stakeholder

analysis.

You can identify these four stakeholder groups using this tool. They’re listed by importance.

• High power, high interest stakeholders

• High power, low interest stakeholders

• Low power, high interest stakeholders

• Low power, low interest stakeholders

5. Set & Manage Expectations

Clearly identify which stages each key stakeholder will be involved in, and timelines by which their feedback is

needed. Create a stakeholder engagement or stakeholder communication plan to define how you’ll manage your

stakeholder relations. As always, be realistic, transparent and honest at every project management phase.

Project Stakeholder Management Video

Setting and managing expectations is perhaps the most important aspect of any stakeholder management plan.

Stakeholders are invested in the project and will have a lot of opinions on how it should proceed, both good and

bad. To learn more about how to manage stakeholder relationships, we’ve embedded a tutorial video below.
Stakeholder Management Process

1. Stakeholder Analysis

Stakeholder analysis is not a single step but a series of steps, stakeholder identification, stakeholder mapping

and stakeholder prioritization. In simple terms, stakeholder analysis could be defined as the process of

understanding who your project stakeholders are, what’s their level of influence and involvement, and their

importance for your project or business.

2. Stakeholder Identification

Stakeholder identification is the first step in the stakeholder analysis process and it’s the base of your

stakeholder management plan. As its name implies, this process consists in identifying all your internal and

external stakeholders. Later these stakeholders will be analyzed, prioritized and engaged.

Here are some things project managers should consider during the stakeholder identification process:

• Review project planning documents such as your project charter to help you find

stakeholder information.

• Look for any government regulations that might apply to your project. If so, those

government agencies become project stakeholders.

• Ask your team members and other internal stakeholders for feedback.

• Identify all the people and organizations involved with your supply chain.

3. Stakeholder Mapping

Now that you’ve identified all your internal and external stakeholders, it’s time to determine their level of

interest and the power or influence they have over the project. This is an important step in the stakeholder

relationship management process, because this is when you’ll get the information needed for stakeholder

prioritization.

The easiest way to do this is to create a power interest grid or power interest matrix. Try ProjectManager’s free

stakeholder map template.

4. Stakeholder Prioritization

Once you have a thorough list, you can begin prioritizing your project stakeholders by their importance to the

project. Decide who among them have the most influence on the project and are affected by it.

Once you’ve determined who your key stakeholders are, it will be easier to keep an eye on them and determine

which are the best stakeholder management strategies to keep them satisfied.

5. Stakeholder Engagement

Finally, with the information created in your stakeholder map, you figure out how to engage your stakeholders.

This is the process by which you decide how you’ll communicate and interact with your project stakeholders.

This leads to a stakeholder communication plan that outlines the channels and frequency of communications

between you and each project stakeholder. You can use our communication plan template to get started.

Conflict resolution strategies

Thomas and Kilmann based their strategies on the choices people make about how assertive or cooperative they

will be in a conflict. Everyone has a different, preferred approach to managing conflict in the workplace;

understanding these strategies can help move a project or team forward when a conflict occurs.
Strategy 1 – Avoiding

This is when people seek to withdraw from or ignore any conflict, usually because feeling uncomfortable about

the confrontation outweighs any possible reward from resolving it. The problem is that this strategy doesn’t

really resolve the issue because there is a lack of contribution to the conversation.

Strategy 2 – Competing

People who are overly assertive rather than cooperative enter into conflict resolution with the intention of

winning. There is an assumption that one person wins and the other loses, pushing out any chance of seeing a

different perspective. As a result, this is not usually a good strategy for resolving conflicts within a group.

Strategy 3 – Accommodating

Giving in to the wishes or demands of another is being cooperative, but not assertive. Yes, it appears that the

person is being gracious should their argument be incorrect, but when a person gives in just to keep the peace, it

isn’t necessarily helpful. Similar to “avoiding”, it doesn’t always lead to a satisfactory resolution to an issue, and

leaves the door open for more assertive members of the group to take control.

Strategy 4 – Collaborating

For most project or team managers, this is probably the strategy they’ll use. A collaborative person is

cooperative and assertive at the same time, allowing each member of the group to contribute and then resolving

the issues by establishing a shared solution that all can support.

Strategy 5 – Compromising

The last strategy is similar to “collaborating” but the person is only halfway towards being assertive and

cooperative. The concept is that each member of the group gives up something so that no member gets

everything. This is perceived as the best outcome, working to a compromise that is fair although, often, no one

is completely happy with the final resolution.

6 project management leadership styles

Understanding different project management leadership styles and how to properly apply them may help you
choose the leadership style best suited for your team and project. Here are six types of project management
leadership styles with examples of how to apply them:
1. Visionary

This leadership style defines the vision for a team and project. It motivates team members by establishing a
shared vision in which all project participants can identify and strive toward. When team members understand
how their work fits within a project's vision, it may motivate them to apply their specific skills because they
know how their role directly contributes to their project's success. This style is most effective after the
development of a strong team bond.

This style of leadership works best when a project manager frequently communicates project goals with their
team. For example, a project manager may use this leadership style when introducing a new team member to a
project. A project manager communicates the project's vision and invites the new member to reflect on how
their skills apply to fulfilling project objectives. Visionary leaders often work to earn and maintain their
credibility because team members are more likely to engage with this style when they trust their team leader and
feel involved in determining a project's vision.

2. Affiliative

The affiliative leadership style helps members of a team build positive relationships with one another. It
promotes team bonding by prioritizing the emotional needs of individuals. By focusing on individual needs and
positive feedback, this leadership style creates a team culture of support and positivity. This leadership style is
effective for:

• Increasing team morale during stressful moments

• Limiting and managing conflicts between team members
• Restoring trust in a project, goal or individual

It can also help improve communication among team members and help them develop good workplace
relationships. Leaders who use this style focus on offering praise and employing team-development activities.
For example, a leader may conduct an activity for team members to introduce themselves and learn about one
another before starting a project.

Although this leadership style can be a great way to maintain morale and support a team through work-related
challenges, it may be less effective in addressing performance-related issues. This style may not be effective in
situations where leaders provide constructive feedback or set clear directions for their team.

3. Participative or democratic

A participative or democratic leadership style invites team input and feedback on decisions. This leadership
style values group discussions, collaboration and teamwork. It promotes a work environment where team
members feel encouraged and empowered because it values their voices and contributions. A workplace
environment where the democratic leadership style is effective may include one that produces creative work.
When members of a creative project have some form of ownership when producing creative content, they may
feel more motivated to contribute.

However, the participation or democratic style may not be effective in all situations. This leadership style may
be less efficient than other leadership styles because it may take time to establish a consensus among team
members. It may also be less effective with teams that are still developing. Teams that have not yet received full
training may not have the knowledge or skills to make effective decisions regarding the goals and direction of a
project.

4. Coaching

The coaching leadership style focuses on identifying the strengths and weaknesses of individuals to promote
long-term professional growth and development. This leadership style considers the interests and motivations of
individuals when setting professional development goals. It invests in the growth of team members to help
individuals optimally perform. Using a coaching leadership style encourages individuals to grow their skills and
reach higher standards of performance. By assigning team members tasks that challenge them, leaders prompt
members to advance their skills or learn new ones.

This leadership style is most effective when members seek professional development. When individuals accept
or seek feedback and feel motivated within their workplace environment, they are likely to respond well to
coaching. A coaching leadership style may be less effective for individuals who are less receptive to feedback or
for projects that have strict deadlines. The coaching style can take longer to produce results than other
leadership styles.

Related: Coaching Leadership: How To Become a Coaching Leader and When To Use This Style

5. Pacesetter

A pacesetter leadership style promotes a high standard of performance with an emphasis on achievement and
efficiency. Leaders who use this style hold their team accountable for meeting expectations. They may also
intervene or assign themselves extra work to compensate for lapses in their team's performance. This style may
be effective with teams that are highly motivated, competent and thrive in fast-paced environments. This style
also sets high expectations and encourages its members to efficiently achieve project objectives.

However, a pacesetter leadership style may be less effective when team morale is low or when team members
require feedback, mentorship or development. Therefore, this style may be best suited for established teams with
individuals who are comfortable with their specific roles.

6. Directive or autocratic

Some project managers may also use a directive or autocratic leadership style. With this leadership style, a
leader offers clear directions and may either make decisions alone or with a small group of other leaders. To
help their teams meet project objectives, these leaders employ direct communication, corrective feedback and
well-defined expectations. This leadership style often works best in situations where a project's stakes are high.
These situations may include:

• A tight deadline
• A significant level of technical skill involved
• Success only guaranteed with a highly controlled environment

The military is an example of an industry where directive leadership is important for fulfilling mission
objectives that may be dangerous or include sensitive information. A directive leadership style may also be
effective when training new team members who need clear, specific feedback on their work.

A directive or autocratic leadership style may be less effective for projects that rely on teamwork and
collaboration for setting goals, establishing plans and making decisions. Some teams work better with a
leadership style that allows them greater agency in how they accomplish their objectives. For teams that are self-
motivated, experienced and require less supervision, a directive leadership style may decrease motivation and
employee ownership of goals and tasks.

Earned Value Formulas

Budget at Completion (BAC)

BAC is the sum of all budgets established for the work to be performed. It indicates how much was initially
planned for the project to cost. No single formula exists. BAC is derived by looking at the total budgeted cost of
the project.

Planned Value (PV), or Budgeted Cost of the Work Scheduled (BCWS)

Planned value is the authorized budget assigned to the scheduled work and does not include management
reserve. It indicates how much work should have been completed at a point in time based on a plan. It is derived
by measuring planned work completed at a point in time.

• PV = Planned % complete * BAC

Earned Value (EV), or Budgeted Cost of the Work Performed (BCWP)

The earned value management indicates how much work was completed during a given period. It is the budget
associated with the authorized work that has been completed. It is derived by measuring actual work completed
at a point in the schedule.

• Actual % complete * BAC

Actual Cost (AC), or Actual Cost of Work Performed (ACWP)

The actual cost is the realized cost incurred for the work performed on an activity during a specific time period.
It indicates the money spent during a given period of time.

• The sum of the costs for the given period.

Cost Variance (CV)

Cost variance is the difference between what we expected to spend and what was spent. It is expressed as a
difference between earned value and the actual cost.

• CV = EV - AC

Schedule Variance (SV)

Schedule variance indicates the difference between where we planned to be in the schedule and where we are in
the schedule. It is expressed as a difference between the earned value and the planned value.

• SV = EV - PV

Cost Performance Index (CPI)

Cost Performance Index is the rate at which the project performance is meeting cost expectations during a given
period of time. It is expressed as a ratio of the earned value to the actual cost.

• CPI = EV / AC

Schedule Performance Index (SPI)

Schedule Performance Index is the rate at which the project performance is meeting schedule expectations up to
a point in time. It is expressed as a ratio of earned value to planned value.

• SPI = EV / PV

Estimate at Completion (EAC)

Estimate at completion is the expected total cost of completing all work. It projects the total cost at completion
based on project performance up to a point in time.
 • EAC = BAC / CPI – If the CPI is expected to be the same for the remainder of the project, the EAC
can be calculated using this formula.
• EAC = AC + BAC - EV – If the future work is accomplished at a planned rate, the EAC can be
calculated using this formula.
• EAC = AC + Bottom-Up ETC – If the initial plan is no longer valid, the EAC can be calculated
using this formula.
• EAC = AC + (BAC - EV ) / (CPI * SPI ) – If both the CPI and SPI influences the remaining work,
the EAC can be calculated using this formula.

Estimate To Complete (ETC)

The estimate to complete is the expected cost to finish all the remaining work. It projects how much more will
be spent on the project, based on past performance.

• ETC = EAC - AC – Assuming that the work is proceeding to plan, the cost of completing the
remaining authorized work can be calculated using this formula.

Variance at Completion (VAC)

Variance at completion is the projection of the amount of budget deficit or surplus. It is expressed as a
difference between budget at completion and the estimate at completion.

• VAC = BAC - EAC

To Complete Performance Index (TCPI)

To complete performance index describes the performance that must be achieved to meet the financial or
schedule goals. It is expressed as a ratio of the cost to finish the outstanding work to the budget available.

• TCPI = BAC - EV / BAC - AC – The efficiency that must be maintained to complete to plan.
• TCPI = BAC - EV / EAC - AC – The efficiency that must be maintained to complete the current
EAC.

Why are contracts important in project management?

Having a proper contract for a project provides a legal framework for the job that reduces any uncertainty about
timelines and payment details. The contract dictates what work is required, who is responsible for completing
the specified tasks, when the deadline for the project is, and how payment will be received. Having a legally
binding contract for a project helps facilitate a positive relationship between buyer and supplier by creating trust
that the task will be completed on time and payment will be received in the agreed upon amount.

3 types of contracts in project management

In project management there are three primary types of contracts. Depending on the type of project you’re
creating an agreement for and how payment will occur, one of these is the best starting point for drawing a legal
framework of the working relationship.

Fixed price (FP) contracts

Fixed price contracts are useful when the scope of the project is clearly defined and easy to understand. Since
the parameters of the project are clearly outlined from the outset, the seller or supplier can provide a definitive
price quote for the work. As the name suggests, the price is fixed and cannot be altered (without making formal
contract amendments) once the buyer agrees to the terms and conditions. FP contracts can be beneficial to the
seller if they can complete the work outlined in the contract for less than they originally thought, allowing them
to capitalize on the profit. However, in a FP contract the supplier is assuming cost-related risks because they
cannot increase their prices if unexpected expenses crop up over the course of the project.

FP contracts are considered lump sum contracts because there is one price to be paid upon project completion.
There are a few types of FP contracts, including:

• Firm fixed price contract

• Fixed price incentive fee
• Fixed price with economic price adjustment

Time and material (T&M) contracts

T&M contracts are a good choice for buyers who aren’t sure exactly what they want from the outset of the
project. With a T&M contract, the buyer contracts the seller based on rates for variables such as materials used
and hours or days worked. The contract should include all rates with possible markups on the cost of materials.
Once the contract is signed, the agreed upon rates remain in place throughout the course of the project and are
used to calculate the final amount the buyer owes the supplies based on the work they do.

Cost reimbursable (CR) contracts

A CR contract is often the best choice when there’s little information for all parties starting out on a project. For
example, if it’s a research or development initiative, the CR model removes the need to set fixed rates for work
that is difficult to predict or foresee. Instead, the buyer fronts the costs for whatever materials, products or labor
is necessary to see the project through to completion.

The responsibility falls solely on the buyer, guaranteeing the supplier that all material costs plus a fee for their
services will be covered. In the case of CR contracts, the buyer needs to closely monitor the expenses of the
project because there is no obligation on the part of the seller or supplier to keep costs down to stay within a
budget. All costs incurred within the scope of work fall on the buyer. The various types of CR contracts are:

• Cost plus percentage of cost

• Cost plus fixed fee
• Cost plus incentive fee
• Cost plus award fee (CPAF)
Types of Project Estimation Techniques

Now that we understand what we’re estimating, let’s look at some of the more popular project estimation

techniques. Projects will likely use one or more of these when making estimations and the more you use, the

more likely your estimates will be accurate.

1. Top-Down Estimate

Top-down estimates are an estimation technique that starts with an overall time for the project and then breaks

that down into phases, which are then broken down further into tasks. This is a classic estimation technique that

uses a look such as the work breakdown structure (WBS).

This is commonly used when a client demands that the project be completed within a certain timeframe. This

project estimate technique works well for this scenario as you have a block of time and can split it into activities

to meet the deadline.

2. Bottom-Up Estimate

This is the reverse of the above estimate technique. Instead of breaking up the timeline into tasks, you estimate

each task and combine them into an estimate for the whole project.

This is a more accurate method as using smaller tasks to build a larger schedule will give you a better estimate

of the time it’ll take to complete the project. The problem is this estimation technique takes more time.

3. Analogous Estimating

Analogous estimating is a technique in which the project manager looks at a previous, similar project and

studies its variables to come up with an estimate for the time and cost of the current project. This comparison

works best when there’s more data that leads to more accuracy.

This is a top-down estimating technique as the project manager is first estimating the project’s costs and then

breaking it down into smaller parts. It’s helpful to use this estimation technique when you have limited

estimation resources.
4. Parametric Estimate

This is another estimation technique that takes advantage of past project data. In this estimation technique, there

are attempts to adjust the data to reflect the differences between the past project and the new one you’re

estimating.

By taking the details from a previous project and pro-rating it, the project manager can estimate the current

project more accurately. This is sometimes referred to as parametric modeling.

5. Three-Point Estimating

Often when estimating from the bottom up, three-point estimating will be used. In this case, instead of

estimating the duration of a single task, three estimates are applied. One is the optimistic estimate, the other is a

pessimistic one, and, finally, the most likely guess. The average of these will be used as the actual estimate.

You might be familiar with three-point estimating if you’ve ever used the program, evaluation and review

technique (PERT). It, too, uses what’s called a weighted average as an estimating technique to forecast more

accurately.

6. Expert Judgement

Seeking the help of experts or those with experience managing the type of project is by far the most common

estimating technique. It’s certainly faster and easier than making calculations. People tend to trust others who

have gone through a similar experience.

It’s a flexible estimating technique in that you can use it for top-down or bottom-up estimating. In some cases,

experts and experiences don’t align with your current project. Experts can still be helpful, but their opinions

should be tempered by other estimating techniques.

5 Successful Methods of Project Estimation

Project estimation is hard. Why? Because the only time you know precisely how long it takes to complete a
project is when it’s done. Up to the point of delivery, teams use educated guesswork to predict the future. And
the bigger and more complex a project is, the hazier that future is. Faulty estimates mean missing deadlines and
breaking budgets—two of the main symptoms of project failure.

Being a skilled estimator is a crucial part of setting schedules, establishing budgets, managing resources and
running a thriving team and business. Using the best online project management software for the job is a huge
help, but knowing the methods and learning how to do them well is how you become a great estimator. There
are a number of estimation methodologies to choose from—and where we’re going to look at five tried-and-
trusted ones that work for all types of projects.

1. Expert judgment

This is probably the most common way people get a project estimation. Talk to the men and women with the
best hands-on experience and understanding of the project requirements. Just make sure that everyone has the
same understanding of what needs to be delivered. And try to find experts who will actually be working on the
project.

2. Comparative or analogous estimation

If your current project is similar to past ones, take the data from previous work and extrapolate it to provide your
estimates for the new job. Before proceeding, make sure to check whether those projects were successful!

3. Top-down

Using a high-level work breakdown structure and data from previous projects, you can add estimates for each
project work item to determine the overall effort and cost. The top-down method lacks detailed analysis, which
makes it best suited for a quick first-pass at a prospective project to assess its viability.

4. Bottom-up

This method uses a detailed work breakdown structure and is best for projects you’re committed to. Each task is
estimated individually, and then those estimates are rolled up to give the higher-level numbers. (If you use the
right project management software, it will roll up the estimates for you). This process makes you think about
what’s required in order to take a step back to see if the big picture still makes sense. You’ll receive more
accurate results than the top-down method, but it’s also a greater investment of time.

5. Parametric model estimating

This is a more scientific method that essentially auto-calculates estimates using detailed data from previous
activities. Let’s say you have data from your last three office network installation projects. You can use this to
get a days-per-workstation value or something similar. You then plug in the number of workstations for your
new installation and out pop the estimates.

This can be a quick method but needs robust data to feed it. And because it’s all about the math, it’s hard to
adjust for the environmental, political and cultural differences between projects.
Organizations don’t just want to have broad goals that only top-level personnel are aware of – they want to set,
track, and measure goals across the entire company. Download our new eBook to learn how your team can
better manage project uncertainty.

Agile effort estimation techniques

There are many different Agile effort estimation techniques to choose from. Here are three of the most common

ones:

1. Planning Poker: In this method, team members sit together in a circle to assign values to story points.

Each individual will have a set of cards with the numerical values that can be assigned: 0, 1, 2, 3, 5, 8,

13, 20, 40, and 100. The product owner will read out a user story to the team members. They will have

a discussion and then decide which value it should have. If everyone is in agreement, the final estimate

is decided. If not, the team will discuss further until a consensus is reached.

2. T-shirt Sizes: Here, story points take the form of sizes: extra-small (XS), small (S), medium (M), large

(L), and extra-large (XL). Estimators will determine the sizes to get a quick and rough estimate that can

be converted to numbers later.

3. Dot voting: This approach enables team members to sort items in the product backlog from low to high

priority. User stories are posted on a board and estimators get four or five dots to use as votes. The one

with the most dots is deemed the highest-priority item, and so on.

Summary: Agile metrics provide insight into productivity through the different stages of a software
development lifecycle. This helps to assess the quality of a product and track team performance.

Metrics are a touchy subject.

On the one hand, we've all been on a project where no data of any kind was tracked, and it was hard to tell
whether we're on track for release or getting more efficient as we go along. On the other hand, many of us have
had the misfortune of being on a projects where stats were used as a weapon, pitting one team against another or
justifying mandatory weekend work. So it's no surprise that most teams have a love/hate relationship with
metrics.

But it doesn't have to be this way. Tracking and sharing sound agile metrics can reduce confusion and shine a
light on the team's progress (and setbacks) throughout the development cycle. Here's how.

Know your business

"Done" only tells half the story. It's about building the right product, at the right time, for the right market.
Staying on track throughout the program means collecting and analyzing relevant data along the way. In any
agile program, it's important to track both business metrics and agile metrics. Business metrics focus on whether
the solution is meeting the market need, and agile metrics measure aspects of the development process.
"A program's business metrics should be rooted in its roadmap."

For each initiative on the roadmap, include several key performance indicators (KPIs) that map to the program's
goals. In addition, include success criteria for each product requirement such as adoption rate by end users or
percentage of code covered by automated tests. These success criteria feed into the program's agile metrics. And
the more teams learn, the better they can adapt and evolve.

How to use agile metrics to optimize your delivery

Sprint burndown

Scrum teams organize development into time-boxed sprints. At the outset of the sprint, the team forecasts how
much work they can complete during a sprint. A sprint burndown report then tracks the completion of work
throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete,
measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the
sprint.

A team that consistently meets its forecast is a compelling advertisement for agile in their organization. But
don't let that tempt you to fudge the numbers by declaring an item complete before it really is. It may look good
in the short term, but in the long run, it only hampers learning and improvement.

Learn how to use burndown charts in Jira Software

ANTI-PATTERNS TO WATCH FOR

• The team finishes early sprint after sprint because they aren't committing to enough work.
• The team misses their forecast sprint after sprint because they're committing to too much
work.
• The burndown line makes steep drops rather than a more gradual burndown because the work
hasn't been broken down into granular pieces.
• The product owner adds or changes the scope mid-sprint.

Epic and release burndown

Epic and release (or version) burndown charts track the progress of development over a larger body of work
than the sprint burndown, and guide development for both scrum and kanban teams. Since a sprint (for scrum
teams) may contain work from several epics and versions, it's important to track both the progress of individual
sprints as well as epics and versions.

"Scope creep" is the injection of more requirements into a previously-defined project. For example, if the team
is delivering a new website for the company, scope creep would be asking for new features after the
initial requirements had been sketched out. While tolerating scope creep during a sprint is bad practice, scope
change within epics and versions is a natural consequence of agile development. As the team moves through the
project, the product owner may decide to take on or remove work based on what they're learning. The epic and
release burn down charts keep everyone aware of the ebb and flow of work inside the epic and version.

ANTI-PATTERNS TO WATCH FOR

• Epic or release forecasts aren't updated as the team churns through the work.
• No progress is made over a period of several iterations.
 • Chronic scope creep, which may be a sign that the product owner doesn't fully understand the
problem that body of work is trying to solve.
• Scope grows faster than the team can absorb it.
• The team isn't shipping incremental releases throughout the development of an epic.

Velocity

Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points
or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team
can work through the backlog, because the report tracks the forecasted and completed work over several
iterations–the more iterations, the more accurate the forecast.

Let's say the product owner wants to complete 500 story points in the backlog. We know that the development
team generally completes 50 story points per iteration. The product owner can reasonably assume the team will
need 10 iterations (give or take) to complete the required work.

It's important to monitor how velocity evolves over time. New teams can expect to see an increase in velocity as
the team optimizes relationships and the work process. Existing teams can track their velocity to ensure
consistent performance over time, and can confirm that a particular process change made improvements or not.
A decrease in average velocity is usually a sign that some part of the team's development process has become
inefficient and should be brought up at the next retrospective.

ANTI-PATTERNS TO WATCH FOR

When velocity is erratic over a long period of time, always revisit the team's estimation practices. During the
team's retrospective, ask the following questions:

• Are there unforeseen development challenges we didn't account for when estimating this
work? How can we better break down work to uncover some of these challenges?
• Is there outside business pressure pushing the team beyond its limits? Is adherance to
development best practices suffering as a result?
• As a team, are we overzealous in forecasting for the sprint?

Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn't mean
that team B has higher throughput. Since each team's estimation culture is unique, their velocity will be as well.
Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on
each team's unique interpretation of story points.

Control chart

Control charts focus on the cycle time of individual issues–the total time from "in progress" to "done". Teams
with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many
issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum
teams can benefit from optimized cycle time as well.

Measuring cycle time is an efficient and flexible way to improve a team's processes because the results of
changes are discernable almost immediately, allowing them to make any further adjustments right away. The
end goal is to have a consistent and short cycle time, regardless of the type of work (new feature, technical debt,
etc.).
ANTI-PATTERNS TO WATCH FOR

Control charts can appear fickle at first. Don't be so concerned with every outlier. Look for trends. Here are two
areas to watch out for:

• Increasing cycle time - Increasing cycle time saps the team of its hard-earned agility. In the
team retrospective, take time to understand an increase. One exception: if the team's definition
of done has expanded, cycle time will probably expand too.
• Erratic cycle time – The goal is to have consistent cycle time for work items that have similar
story point values. Filter the control chart for each story point value to check for consistency.
If cycle time is erratic on small and large story point values, spend time in the retrospective
examining the misses and improving future estimation.

Cumulative flow diagram

The cumulative flow diagram should look smooth(ish) from left to right. Bubbles or gaps in any one color
indicate shortages and bottlenecks, so when you see one, look for ways to smooth out color bands across the
chart.

ANTI-PATTERNS TO WATCH FOR

• Blocking issues create large backups in some parts of the process and starvation in others.
• Unchecked backlog growth over time. This results from product owners not closing issues
that are obsolete or simply too low in priority to ever be pulled in.

Even more metrics

Good metrics aren't limited to the reports discussed above. For example, quality is an important metric for agile
teams and there are a number of traditional metrics that can be applied to agile development:

• How many defects are found:

o during development?
o after release to customers?
o by people outside of the team?
• How many defects are deferred to a future release?
• How many customer support requests are coming in?
• What is the percentage of automated test coverage?

Agile teams should also look at release frequency and delivery speed. At the end of each sprint, the team should
release software out to production. How often is that actually happening? Are most release builds getting
shipped? In the same vein, how long does it take for the team to release an emergency fix out to production? Is
release easy for the team or does it require heroics?

Find insights in context

Insights are a great tool for teams to access metrics when they need them: during sprint planning, checking in at
the daily standup, or optimizing delivery. You can find insights in the upper right-hand corner of the board,
backlog, and deployments view of Jira.

Insights give a visual snapshot of the following metrics:

• Sprint progress
• Issue type breakdown
 • Sprint commitment
• Deployment frequency
• Cycle time

Use these metrics to continuously optimize team performance. Learn more about insights.

In conclusion...

Metrics are just one part of building a team's culture. They give quantitative insight into the team's performance
and provide measurable goals for the team. While they're important, don't get obsessed. Listening to the team's
feedback during retrospectives is equally important in growing trust across the team, quality in the product, and
development speed through the release process. Use both quantitative and qualitative feedback to drive change.

The Four Values of The Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile
approach to software development. Each Agile methodology applies the four values in different ways, but all of
them rely on them to guide the development and delivery of high-quality, working software.

1. Individuals and Interactions Over Processes and Tools

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people
more highly than processes or tools is easy to understand because it is the people who respond to business needs
and drive the development process. If the process or the tools drive development, the team is less responsive to
change and less likely to meet customer needs. Communication is an example of the difference between valuing
individuals versus process. In the case of individuals, communication is fluid and happens when a need arises.
In the case of process, communication is scheduled and requires specific content.

2. Working Software Over Comprehensive Documentation

Historically, enormous amounts of time were spent on documenting the product for development and ultimate
delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test
plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long
delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the
developer what is needed to do the work without getting bogged down in minutiae. Agile documents
requirements as user stories, which are sufficient for a software developer to begin the task of building a new
function.
The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation

Negotiation is the period when the customer and the product manager work out the details of a delivery, with
points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With
development models such as Waterfall, customers negotiate the requirements for the product, often in great
detail, prior to any work starting. This meant the customer was involved in the process of development before
development began and after it was completed, but not during the process. The Agile Manifesto describes a
customer who is engaged and collaborates throughout the development process, making. This makes it far easier
for development to meet their needs of the customer. Agile methods may include the customer at intervals for
periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all
meetings, ensuring the product meets the business needs of the customer.

4. Responding to Change Over Following a Plan

Traditional software development regarded change as an expense, so it was to be avoided. The intention was to
develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a
priority as everything else, and with a large number of many dependencies on delivering in a certain order so
that the team can work on the next piece of the puzzle.
With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new
features can be added into the next iteration. Agile’s view is that changes always improve a project; changes
provide additional value.

Perhaps nothing illustrates Agile’s positive approach to change better than the concept of Method Tailoring,
defined in An Agile Information Systems Development Method in use as: “A process or capability in which
human agents determine a system development approach for a specific project situation through responsive
changes in, and dynamic interplays between contexts, intentions, and method fragments.” Agile
methodologies allow the Agile team to modify the process and make it fit the team rather than the other way
around.

The Twelve Agile Manifesto Principles

The Twelve Principles are the guiding principles for the methodologies that are included under the title “The
Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the
work. They also demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to
the Agile Manifesto, which is to bring development into alignment with business needs.

The twelve principles of agile development include:

1. Customer satisfaction through early and continuous software delivery – Customers are happier
when they receive working software at regular intervals, rather than waiting extended periods of time
between releases.
2. Accommodate changing requirements throughout the development process – The ability to avoid
delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the team operates
in software sprints or iterations that ensure regular delivery of working software.
4. Collaboration between the business stakeholders and developers throughout the project – Better
decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their
best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development teams are
co-located.
7. Working software is the primary measure of progress – Delivering functional software to the
customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a repeatable and
maintainable speed at which they can deliver working software, and they repeat it with each release.
9. Attention to technical detail and design enhances agility – The right skills and good design ensures
the team can maintain the pace, constantly improve the product, and sustain change.
10. Simplicity – Develop just enough to get the job done for right now.
11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and
motivated team members who have decision-making power, take ownership, communicate regularly
with other team members, and share ideas that deliver quality products.
12. Regular reflections on how to become more effective – Self-improvement, process improvement,
advancing skills, and techniques help team members work more efficiently.

The intention of Agile is to align development with business needs, and the success of Agile is apparent. Agile
projects are customer focused and encourage customer guidance and participation. As a result, Agile has grown
to be an overarching view of software development throughout the software industry and an industry all by
itself.
The Risk Management Process in Project Management

When you start the planning process for a project, one of the first things you need to think about is: what can go

wrong? It sounds negative, but pragmatic project managers know this type of thinking is preventative. Issues

will inevitably come up, and you need a mitigation strategy in place to know how to manage risks when project

planning.

But how do you work towards resolving the unknown? It sounds like a philosophical paradox, but don’t

worry—there are practical steps you can take. In this article, we’ll discuss strategies that let you get a glimpse at

potential risks, so you can identify and track risks on your project.

What Is Risk Management on Projects?

Project risk management is the process of identifying, analyzing and responding to any risk that arises over the

life cycle of a project to help the project remain on track and meet its goal. Risk management isn’t reactive only;

it should be part of the planning process to figure out the risk that might happen in the project and how to

control that risk if it in fact occurs.

Related: Free Risk Tracking Template for Excel

A risk is anything that could potentially impact your project’s timeline, performance or budget. Risks are

potentialities, and in a project management context, if they become realities, they then become classified as

“issues” that must be addressed with a risk response plan. So risk management, then, is the process of

identifying, categorizing, prioritizing and planning for risks before they become issues.

Risk management can mean different things on different types of projects. On large-scale projects, risk

management strategies might include extensive detailed planning for each risk to ensure mitigation strategies are

in place if issues arise. For smaller projects, risk management might mean a simple, prioritized list of high,

medium and low priority risks.

How to Manage Risk

To begin managing risk, it’s crucial to start with a clear and precise definition of what your project has been

tasked to deliver. In other words, write a very detailed project charter, with your project vision, objectives, scope

and deliverables. This way risks can be identified at every stage of the project. Then you’ll want to engage your

team early in identifying any and all risks.

Don’t be afraid to get more than just your team involved to identify and prioritize risks, too. Many project

managers simply email their project team and ask to send them things they think might go wrong on the project.

But to better plot project risk, you should get the entire project team, your client’s representatives, and vendors

into a room together and do a risk identification session.

With every risk you define, you’ll want to log it somewhere—using a risk tracking template helps you prioritize

the level of risk. Then, create a risk management plan to capture the negative and positive impacts of the project

and what actions you will take to deal with them. You’ll want to set up regular meetings to monitor risk while

your project is ongoing. Transparency is critical.

What Is Positive Risk?

Not all risk is created equally. Risk can be either positive or negative, though most people assume risks are

inherently the latter. Where negative risk implies something unwanted that has the potential to irreparably

damage a project, positive risks are opportunities that can affect the project in beneficial ways.

Negative risks are part of your risk management plan, just as positive risks should be, but the difference is in

approach. You manage and account for known negative risks to neuter their impact, but positive risks can also

be managed to take full advantage of them.

There are many examples of positive risks in projects: you could complete the project early; you could acquire

more customers than you accounted for; you could imagine how a delay in shipping might open up a potential

window for better marketing opportunities, etc. It’s important to note, though, that these definitions are not

etched in stone. Positive risk can quickly turn to negative risk and vice versa, so you must be sure to plan for all

eventualities with your team.

Project management software can help you keep track of risk. ProjectManager is online software that helps you

manage risks in real time. Create risks just as you would tasks, assigning an owner, dates, priorities and tags.

You can even view risks on your project menu which can be sorted and filtered to your liking. Then, use the

dropdown menu to note the risk’s status to mitigate it accordingly.

How to Respond to Positive Risk

Like everything else on a project, you’re going to want to strategize and have the mechanisms in place to reap

the rewards that may be seeded in positive risk. Use these three tips to guide your way:

1. The first thing you’ll want to know is if the risk is something you can exploit. That

means figuring out ways to increase the likelihood of that risk occurring.

2. Next, you may want to share the risk. Sometimes you alone are not equipped to take

full advantage of the risk, and by involving others you increase the opportunity of

yielding the most positive outcome from the risk.

3. Finally, there may be nothing to do at all, and that’s exactly what you should do.

Nothing. You can apply this to negative risk as well, for not doing something is

sometimes the best thing you can do when confronted with a specific risk in the

context of your project.

Managing Risk throughout the Organization

Can your organization also improve by adopting risk management into its daily routine? Yes! Building a risk

management protocol into your organization’s culture by creating a consistent set of tools and templates, with

training, can reduce overhead over time. That way, each time you start a new project, it won’t be like having to

reinvent the wheel.

Things such as your organization’s records and history are an archive of knowledge that can help you learn from

that experience when approaching risk in a new project. Also, by adopting the attitudes and values of your

organization to become more aware of risk, your organization can develop a better sense of the nature of

uncertainty as a core business issue. With improved governance comes better planning, strategy, policy and

decisions.
6 Steps in the Risk Management Process

So, how do you handle something as seemingly elusive as project risk management? You make a risk

management plan. It’s all about the process. Turn disadvantages into an advantage by following these six steps.

Identify the Risk

You can’t resolve a risk if you don’t know what it is. There are many ways to identify risk. As you do go

through this step, you’ll want to collect the data in a risk register.

One way is brainstorming with your team, colleagues or stakeholders. Find the individuals with relevant

experience and set up interviews so you can gather the information you’ll need to both identify and resolve the

risks. Think of the many things that can go wrong. Note them. Do the same with historical data on past projects.

Now your list of potential risk has grown.

Make sure the risks are rooted in the cause of a problem. Basically, drill down to the root cause to see if the risk

is one that will have the kind of impact on your project that needs identifying. When trying to minimize risk, it’s

good to trust your intuition. This can point you to unlikely scenarios that you just assume couldn’t happen. Use

a risk breakdown structure process to weed out risks from non-risks.

Analyze the Risk

Analyzing risk is hard. There is never enough information you can gather. Of course, a lot of that data is

complex, but most industries have best practices, which can help you with your risk analysis. You might be

surprised to discover that your company already has a framework for this process.

When you assess project risk you can ultimately and proactively address many impacts, such as avoiding

potential litigation, addressing regulatory issues, complying with new legislation, reducing your exposure and

minimizing impact.

So, how do you analyze risk in your project? Through qualitative and quantitative risk analysis, you can

determine how the risk is going to impact your schedule and budget.
Project management software helps you analyze risk by monitoring your project. ProjectManager takes that one

step further with real-time dashboards that display live data. Unlike other software tools, you don’t have to set

up our dashboard. It’s ready to give you a high-level view of your project from the get-go. We calculate the live

date and then display it for you in easy-to-read graphs and charts. Catch issues faster as you monitor time, costs

and more.

Prioritize the Risk

Not all risks are created equally. You need to evaluate the risk to know what resources you’re going to assemble

towards resolving it when and if it occurs.

Having a large list of risks can be daunting. But you can manage this by simply categorizing risks as high,

medium or low. Now there’s a horizon line and you can see the risk in context. With this perspective, you can

begin to plan for how and when you’ll address these risks.

Some risks are going to require immediate attention. These are the risks that can derail your project. Failure isn’t

an option. Other risks are important, but perhaps do not threaten the success of your project. You can act

accordingly. Then there are those risks that have little to no impact on the overall project’s schedule and budget.

Some of these low-priority risks might be important, but not enough to waste time on.

Assign an Owner to the Risk

All your hard work identifying and evaluating risk is for naught if you don’t assign someone to oversee the risk.

In fact, this is something that you should do when listing the risks. Who is the person who is responsible for that

risk, identifying it when and if it should occur and then leading the work towards resolving it?

That determination is up to you. There might be a team member who is more skilled or experienced in the risk.

Then that person should lead the charge to resolve it. Or it might just be an arbitrary choice. Of course, it’s

better to assign the task to the right person, but equally important in making sure that every risk has a person

responsible for it.

Think about it. If you don’t give each risk a person tasked with watching out for it, and then dealing with

resolving it when and if it should arise, you’re opening yourself up to more risk. It’s one thing to identify risk,

but if you don’t manage it then you’re not protecting the project.
Respond to the Risk

Now the rubber hits the road. You’ve found a risk. All that planning you’ve done is going to be put to use. First

you need to know if this is a positive or negative risk. Is it something you could exploit for the betterment of the

project? If not you need to deploy a risk mitigation strategy.

A risk mitigation strategy is simply a contingency plan to minimize the impact of a project risk. You then act on

the risk by how you prioritized it. You have communications with the risk owner and, together, decide on which

of the plans you created to implement to resolve the risk.

Monitor the Risk

You can’t just set forces against risk without tracking the progress of that initiative. That’s where the monitoring

comes in. Whoever owns the risk will be responsible for tracking its progress towards resolution. But you will

need to stay updated to have an accurate picture of the project’s overall progress to identify and monitor new

risks.

You’ll want to set up a series of meetings to manage the risks. Make sure you’ve already decided on the means

of communication to do this. It’s best to have various channels dedicated to communication.

Whatever you choose to do, remember: always be transparent. It’s best if everyone in the project knows what is

going on, so they know what to be on the lookout for and help manage the process.

7 Basic quality tools for effective project management

Quality is one of the modern project constraints which leads the project management processes and
activities. There are 3 processes of quality management throughout the project lifecycle. These are -

1. Plan quality management

2. Perform quality assurance
3. Control quality

Each of the 3 processes have their own tools, but there are some tools that can be used in all the 3 processes.
These 7 basic quality tools are examples of shareable tools :
1- Flow Chart:-

It is a graphical description of workflow steps. So it can describe the steps of any process through graphical
symbols which are connected to each other by paths that represent the direction of the workflow. The
symbols can be circles, rectangles, diamonds or any other shapes which must be predefined to make the
flowchart easy for understanding.

We begin the flowchart by the start node, which is often represented as a circle shape. Then we represent
each action or step we do by a rectangle shape. When we want to make a decision or a test that will give
more than one result, each result will direct us to a different path with a different action. Flowcharts are very
useful when we want to make a correction for any process. It helps us eliminate redundancy and unuseful
work steps. Also, it is very useful when we use it for creating the project statement of work.

2- Pareto Diagram:-

It is a special vertical chart that is divided into categories that show all possible probabilities or events that
can occur. Categories are ordered by the frequency of each category from high frequency on the left side of
the vertical axis to the low frequency on the right side of it. Pareto depends on the rule of 80/20, which
proves that 80/100 of problems come from 20/100 of causes. So when we know that 20/100 of the causes
and give more attention and resources to avoid them, we will solve 80/100 of the errors and problems. So
Pareto Diagram is very useful when we use it with a cause and effect diagram (also called Ishikawa or
fishbone). The below example shows Pareto Diagram for the reasons that lead to delays in a software
project.
3- Histogram:-

It is a tool for showing the central tendency, statistical distribution, and dispersion of a given set of
measurements that will be shown on a vertical bar chart. It is very useful when we want to know which
categories have a larger frequency. We can use it in many applications such as defining the resources that
will perform the project work by using Resource Histogram which is shown below

We can do the same thing with one resource in a timely manner such as dividing the categories by months and
defining the number of one resource such as senior developer via each month of the project lifecycle.

4- Cause and Effect Diagram (Ishikawa or Fishbone):-

It is a diagram that represents the cause and effect of a fishbone. Its head represents the problem or objective
and the body represents the causes of the problem or the actions that should be performed to reach the goal
or objective at the head of the fishbone. When we find a problem with any process such as a process
variation or an increasing number of defects, we can use the fishbone to find the source of the problem.
Each resource can also be divided into a number of resources, till we reach the original resources of the
problem. The Fishbone problem statement often comes from the Control Chart when its measurements point
to a problem in the process stability. The following diagram shows the cause and effect diagram for the
delay of software projects
5- Checksheets (Tally sheets):-

The check sheet is a sheet that contains items of inspections and tests and the attribute that each test can
result in. The acceptance criteria of each test must be listed on the sheet to be a guide for determining if the
inspected item of the sample such as a piece of code in the software project has passed a test item (such as a
unit test). Then we gather the frequencies of each defect and represent them in Pareto Chart.

6- Scatter Diagram:-

A Scatter diagram (called also Correlation Diagram) is a diagram represented by two axes X and Y. So any
measurement or data shown in Scatter Diagram is represented by a pair of (X, and Y). The correlation
between x and y shown is based on the rule that Y is dependent on X but X is not dependent on Y. So there
are many types of correlations such as positive correlation (proportional), negative correlation (Inverse), or
pattern of no correlation (Zero Correlation). An example of a positive correlation is - the weight of the
human and its relation to his age (between one year and 40). We find that the weight of the human depends
on and is affected by age (an increase in age will lead to an increase in weight but the reverse is incorrect).
So we will consider the age on is X axis and the weight on is Y axis. In a negative correlation, when X is
increased, Y decreases.

Are you looking to get PMP certified? If you are, it’s best that you enroll in a PMP exam prep course. You
can learn online, from the comfort of home, and at your own pace.

7- Control Chart:-
When we want to determine if a process is stable or not, we use a control chart. It consists of-

1. Upper Specification Limits (USL) and Lower Specification Limits (LSL) which come from
specification
2. Upper Control Limits(UCL) and Lower Control Limits (LCL) which come from statistical calculation
+_3 standard deviation above and below mean
3. Mean which equals UCL+LCL/2

The process is considered unstable if one point exceeds the UCL or LCL or seven consecutive points are
above or below the mean.

When we ensure that the process is unstable, we perform corrective action and monitor the result of these
actions to measure its effect on the process stability.

So these 7 tools are very useful and can be used throughout the project lifecycle to plan and maintain the
quality of associated activities.
The 10 Project Management Knowledge Areas (PMBOK)

Table of Contents
• 1. Project Integration Management
• 2. Project Scope Management
• 3. Project Time Management
• 4. Project Cost Management
• 5. Project Quality Management
• 6. Project Human Resource Management
• 7. Project Communications Management
• 8. Project Risk Management
• 9. Project Procurement Management
• 10. Project Stakeholder Management

What do you need to know to succeed at project management? Everything! While there’s some truth to that

joke, it’s not helpful to the student or the experienced professional who is looking for a way to understand the

myriad responsibilities of being a project manager.

The vast range of project management tools, terms, skills and knowledge that are within its discipline can be

intimidating. This is why PMBOK was created — to help unify and standardize the many parts of project

management.

What is PMBOK in Project Management?

PMBOK stands for Project Management Body of Knowledge. It is a set of standard terminology and guidelines

for project management published and updated by The Project Management Institute (PMI).

Project Management Knowledge Areas

PMI has divided the large field of project management into 10 more digestible parts, which it calls the 10

project management knowledge areas in its A Guide to the Project Management Body of Knowledge (PMBOK).
Project management knowledge areas coincide with the process groups, which are project initiation, project

planning, project execution, monitoring and controlling, and project closing. These are the chronological phases

that every project goes through.

The knowledge areas take place during anyone of these process groups. You can think of the process groups as

horizontal, while the knowledge areas are vertical. The knowledge areas are the core technical subject matter,

which are necessary for effective project management.

1. Project Integration Management

What holds a project together? That would be project integration management, which includes such fundamental

plans as developing a project charter that is created during the initiation phase. This is the document that sets up

the project and assigns the project manager.

Another aspect of this area is the project management plan, which is developed as a project roadmap for the

project to reach a successful end. Once created, the project plan is approved by stakeholders and/or sponsors,

and then it’s monitored and tracked through a change log as the project progresses. Project management

software, like ProjectManager, can help managers keep track of these project plans.

The project integration area also includes the directing and managing of the project work, which is the

production of its deliverables. This process is monitored, analyzed and reported on to identify and control any

changes or problems that might occur.

Also, any change control will be carried out. That might require request forms, approval from stakeholders

and/or sponsors or another admin. This area is also part of the project closure at the end of the project.

2. Project Scope Management

Scope relates to the work of the project. So, that includes plan scope management, which is part of the project

management plan. It also is when a detailed requirement for the final product or service is collected.

You’ll also need to define scope in a scope statement. This is anything from a sentence to a bulleted list that is

comprehensive to reduce major project risks. And a work breakdown structure (WBS), which is a graphic

breakdown of project work, is another part of this area.

Validate scope during the project, which means making sure that the deliverables are being approved regularly

by the sponsor or stakeholder. This occurs during the monitoring and controlling process groups and is about

accepting the deliverables, not the specs laid out during planning.

The scope statement is likely going to change over the course of the project to control the scope, such as if a

project falls behind schedule.

3. Project Time Management

Project time management is, no surprise, time consuming. The project is divided into tasks, which are scheduled

with start dates and deadlines, as well as budgets for each task. And things are constantly changing over the

phases of any project, which means revising these things often.

This involves plan schedule management, which involves creating a schedule for the project and determining

who is responsible for what. That means defining activities, which is not the same as making a WBS, but

similar. So, you create a task list that touches on every aspect of the project.

These tasks are then put in an order that makes sense, and any dependencies between them is noted. These

dependencies are then determined to be either finish-to-start (FS), finish-to-finish (FF), start-to-start (SS) or

start-to-finish (SF). This is mostly for larger projects.

With the tasks now sequenced, the resources required for each must be estimated and assigned. The duration of

each task is also determined at this point. All this will lead to a schedule by first figuring out the critical path and

float for each task. Use a Gantt chart to place the tasks on a timeline, and then work on resource leveling to

balance resource usage.

Once the schedule is made, plan to control the schedule are necessary. Earned value management is performed

regularly to make sure that the actual plan is proceeding as it had been planned.

4. Project Cost Management

This area involves the project budget, which means having good estimating tools to make sure that the funds

cover the extent of the project and are being monitored regularly to keep stakeholders or sponsors informed.
Plan cost management will determine the method to establish the budget, which includes how and if it will

change and what procedures will be used to control it. Each task will have to be estimated for cost, which means

including all resources such as labor, materials, equipment and anything else needed to complete the task.

This will determine the project budget, once you take all the task costs and combine them. Then comes the need

to control those cost through an earned value analysis. This is performed regularly throughout the project to

make sure the estimated costs are in line with actual expenditures.

5. Project Quality Management

A project can come in on time and within budget, but if the quality is not up to the standard set, then the project

is a failure. Plan quality management is part of the overall project management plan, though it can be a

standalone document if it contains the quality specs for the product or service.

The process needs to include quality assurance, which is just a way to make sure that quality standards are being

met. Therefore, to control quality, the deliverables must be inspected to make sure that those standards outlined

in the quality management plan are being met.

6. Project Human Resource Management

The project team is your most important resource, so it’s crucial to assemble the best team and to make sure

they’re happy. But also you need to track their performance to ensure that the project is progressing as planned.

A human resource management plan will identify their roles and their requirements for those positions, as well

as how they fit in the overall project structure.

After you’ve determined the job descriptions, it’s time to fill those positions and acquire a project team. This

can be done in-house by drawing from other departments in the organization, by getting new hires or by a

combination of both. The team needs development, possibly training and other things that will make them viable

for the project.

Managing the project team is an ongoing responsibility of the project manager. The team is monitored to make

sure they’re working productively and that there are no internal conflicts, so everyone is satisfied.

7. Project Communications Management

All areas of project management are important, but communication management might be paramount as it

informs every aspect of the project. Communications inform the team and stakeholders, therefore the need to

plan communications management is a critical step in any project.

Related: Free Communication Plan Template

It is at this point that the dissemination of communications is determined, including how it’s done and with what

frequency. Target who needs what and when. Also, note how communications will occur when issues arise in

the project, such as changes.

Manage the communications when the project is executed to make sure it runs as planned. This will also involve

controlling communications by reviewing their effectiveness regularly and adjusting as needed.

8. Project Risk Management

Risk management plans will identify how the risks will be itemized, categorized and prioritized. This involves

identifying risks that might occur during the execution of the project by making a risk register.

Perform qualitative risk analysis after the biggest risks have been identified and classified by likelihood and

impact. Then prioritize them. Then perform quantitative analysis according to their impact on the project, such

as its budget, schedule, etc.

Now you’ll need to plan risk responses. If those risks in fact become issues, then a response needs to have been

written in advance, with an owner who can make sure the risk is properly identified and handled. Controlling

risk involves regularly reviewing the risk register and crossing off those risks that are no longer going to impact

the project.

9. Project Procurement Management

This deals with outside procurement, which is part of most projects, such as hiring subcontractors. This will

obviously have an impact on the budget and schedule. Planning procurement management starts by identifying

the outside needs of the project and how those contractors will be involved.
Now conduct those procurements by hiring the contractors, which includes a statement of work, terms of

reference, request for proposals and choosing a vendor. You’ll want to control the procurement process by

managing and monitoring, and then closing the contracts once the work has been done to everyone’s

satisfaction.

10. Project Stakeholder Management

The stakeholders must be happy, as the project has been created for their needs. Therefore, they must be actively

managed like any other part of the project. To start one must identify the stakeholders through stakeholder

analysis. It’s not always easy, but it’s a crucial part of starting any project, so find out who they are and what

concerns they have.

Now plan stakeholder management, which means listing each stakeholder and prioritizing what their concerns

are and how they might impact the project. This will lead to managing stakeholders’ expectations to make sure

their needs are met and that you’re in communication with them.

Throughout the project, control stakeholder engagement. Do this by determining if the stakeholders’ needs are

being addressed. If not, figure out what changes need to be made to either satisfy those needs or adjust the

expectations.

Project management knowledge areas bring a project to life, but that life can be chaotic and complex, which is

why a project manager needs a tool to help manage all these moving parts of a project. ProjectManager is

a cloud-based project management software with real-time dashboards and Gantt charts to monitor the project

accurately throughout its many phases. See how it can help you manage your projects by taking this free 30-day

trial.

What Are the 5 Phases of Project Management?

A project phase is a collection of related project management activities. The relationship of the phases in the
project life cycle is often sequential, and each project phase culminates with the completion of one or
more project deliverables.
The five phases of project management are:

1. Project Initiation
2. Project Planning
3. Project Execution
 4. Project Monitoring & Control
5. Project Closure

Each stage of the project life cycle has a distinct focus that’s different from other stages.

That said, the project management skill sets, tasks, processes, stakeholders, and involved organizations for each
of the project phases would differ. Still, repeating processes across all Process Groups is an excellent way to add
a degree of control within each phase.

Project Initiation Phase

A team’s performance during the Project Initiation Phase can result in either authorization, delay, or
discontinuation of a new project.

The main goal of the Initiation Phase is to ensure that the project meets business needs and that stakeholders and
project teams are aligned on the project success criteria throughout the project life cycle.

To achieve the project goal, it’s best to involve internal and external stakeholders from the Initiation Phase. This
way, you can effectively align expectations and increase the likelihood of completing all the deliverables
throughout the project management life cycle.

During the Initiation Phase, the entire project team defines the project idea, and the project sponsor evaluates it
and authorizes the project to proceed. The project manager starts the documentation process, which includes the
justification, deliverables, risks, estimated cost, and resource requirements.

The Project Charter is a key deliverable of the Project Initiation Phase and contains all this information. It is the
first formal definition of the project. It authorizes the project to exist, establishes the authority of the project
manager, and documents high-level requirements, project milestones, and success criteria.
Another important document in the Initiation Phase is the Stakeholder Register. This document includes
information about all the stakeholders of the project. It identifies the people, groups, and organizations that have
an interest in the task, project, and its results.

Approval of the Project Charter signals the advance of the project to the next phase, the Project Planning Phase.

Project Planning Phase

Once the expectations and success criteria are clear, the next project management life cycle phase focuses on
planning each task the team needs to perform to cover the scope, achieve the deliverables, and meet the overall
goal.

In the Project Planning Phase, the project team members dive into specific requirements, tasks, timelines, and
actions. The project manager works with the entire team to create the design, enumerate the task list, and
estimate the budget.

The project team builds the resource plan, the communications plan, and the initial project schedule. The project
manager also establishes the roles and responsibilities of the team and stakeholders. The project scope is
finalized depending on approved available resources and client priorities.

During the Planning Phase, the project team finalizes the Work Breakdown Structure, Project Plan,
Requirements List, Communications Management Plan, and other relevant documents to iron out the workflow
and coordination with involved parties.
The Project Plan is a key deliverable and contains a detailed work breakdown structure (WBS) or task list with
start and end dates, and estimated effort and duration. It identifies milestones, resources, and the schedule. It
also includes task dependencies that will allow the project team to use the critical path method if it chooses.
Other important deliverables are the Communications Management Plan, which helps facilitate effective
communication with stakeholders, and the Resource Allocation Plan which identifies the schedule of project
team resources as to their availability during the whole project life cycle.

Something PMs should keep in mind: As you discover more information, you may have to adjust your previous
Project Plan and related procedures. More complex projects will require more back-and-forth approvals for
every task created.

Project planning is an iterative process so the project manager should review, revise, and revisit all the plans at
least once a month until the completion of the project. It is crucial for the project team to involve relevant
stakeholders in this stage of the project life cycle as well.

Project Execution Phase

The Project Execution Phase is where the project team executes and follows through on tasks based on the
Project Plan. At this stage, the team spends most of its time coordinating with people, helping to ensure quality
work, keeping track of resources, and updating stakeholders.

Sometimes called the Implementation Phase, this is the phase when the project manager tries to manage every
task and aspect of project delivery to keep the project on track for the remaining duration of the project life
cycle.

The project team focuses on achieving all the objectives set in the earlier phases. At this phase, the project
leader likely uses project management software to assign every task to team members. Tools that centralize task
information, along with resource availability and team communication can simplify and optimize the needed
project management processes.

Quality Assurance documentation, meeting minutes, and Work Orders are some of the documents created
during the Execution Phase of the project management life cycle.

It’s also likely that you’ll discover new information that will require a revisit and update of the initial project
management plans. Be vigilant with change requests, and make sure that the necessary adjustments are
managed.

Project Monitoring & Control Phase

The best way to ensure progress and improvement is by tracking and reviewing project performance.

Simultaneously during execution, the project team carefully tracks the progress of the project based on the
Project Plan established earlier. Tracking the performance of the project through various metrics is crucial to
ensure the project stays on schedule, within budget, and within scope.

The project team keeps track of change management documents, spending records, QA checklists, and team
time tracking. They are able to measure where efforts and resources go throughout the project life cycle,
crosschecking it with the Project Plan.

Both the Execution Phase and Monitoring & Control Phase are critical times that can determine project success.
Aside from monitoring the progress of tasks, the project manager also tries to identify issues or risks, creates a
mitigation plan with the team, and reports the project status regularly to stakeholders.

Being diligent in recording and measuring project progress puts the project team in a strategic position. They
can identify bottlenecks and initiate essential discussions or project management process improvements.

Having a proactive approach will allow the project team to respond rapidly to any change in the plan. Consistent
and appropriate status reporting will update interested stakeholders and provide them the opportunity to
intervene in or redirect the project as needed.
If additional planning, time, or resources are needed, you’ll need to communicate them to relevant project
stakeholders before it’s too late. You’ll also have the data and results to back up your requests, so you have a
better chance of justifying your requests and maintaining their trust despite circumstances.

Project Closure Phase

In the last project management life cycle phase, all the activities related to its completion are concluded. These
may involve the submission of a final deliverable, fulfilling contractual obligations, terminating relevant
agreements, and releasing project resources.

The causes of a project closure can be completion, cancellation, termination, or transfer to a new organization.
The documentation required to complete Project Closure will differ depending on the situation.

In this phase, the project manager communicates the final project disposition and status to all stakeholders. This
phase also ensures to inform participants and stakeholders of any follow-on activities or continuing product life
cycle so they can communicate and coordinate with the people in charge.

Regardless of the outcome of the project life cycle, however, it would be good for the team to conduct a project
retrospective. During this post-mortem activity, the project team can process new lessons and ensure the
improvement of current project management processes for a future project.

During the project closeout, documents to turn over can include various project documentation, final meeting
minutes, and other closure reports. These documents can identify and capture lessons learned and best practices
for future reference and reuse.

It is a good idea to organize and store project materials in a shared team folder. These materials can provide
reference during performance evaluation. The opportunity to continuously test, improve, or reinvent ways to
manage the whole project life cycle can help grow the organization and its business.

In project management, the critical path is the longest sequence of tasks that must be completed to complete

a project. The tasks on the critical path are called critical activities because if they’re delayed, the whole project

completion will be delayed.

Finding the critical path is very important for project managers because it allows them to:

• Accurately estimate the total project duration

• Identify task dependencies, resource constraints and project risks

• Prioritize tasks and create realistic project schedules

To find the critical path, project managers use the critical path method (CPM) algorithm to define the least

amount of time necessary to complete each task with the least amount of slack.

Once done by hand, nowadays the critical path can be calculated automatically with project scheduling software

equipped with Gantt charts, which makes the whole CPM method much easier.
Now that we know what’s the critical path of a project, we can learn about the critical path method (CPM), an

important project management technique that’s based on this concept.

What Is the Critical Path Method (CPM)?

The critical path method (CPM) is a technique that’s used by project managers to create a project schedule

and estimate the total duration of a project.

The CPM method, also known as critical path analysis (CPA), consists in using a network diagram to visually

represent the sequences of tasks needed to complete a project. Once these task sequences or paths are defined,

their duration is calculated to identify the critical path, which determines the total duration of the project.

CPM History

The critical path method was developed in the late 1950s by Morgan R. Walker and James E. Kelley. The

origins of the critical path method are closely related with the Program Evaluation and Review Technique

(PERT), a similar method which is commonly used in conjunction with CPM.

Why Is CPM Important in Project Management?

Projects are made up of tasks that have to adhere to a schedule in order to meet a timeline. It sounds simple, but

without mapping the work, your project scope can quickly get out of hand and you’ll find your project off track.

Using the critical path method is important when managing a project because it identifies all the tasks needed to

complete the project, then determines the tasks that must be done on time, those that can be delayed if needed

and how much float or slack you have.

When done properly, critical path analysis can help you:

• Identify task dependencies, resource constraints and project risks

 • Accurately estimate the duration of each task

• Prioritize tasks based on their float or slack time, which helps with project scheduling and

resource allocation

• Identify critical tasks that have no slack and make sure those are completed on time

• Monitor your project progress and measure schedule variance

• Use schedule compression techniques like crash duration or fast tracking

CPM Key Elements

Before we learn the steps to calculate the critical path, we’ll need to understand some key CPM concepts.

• Earliest start time (ES): This is simply the earliest time that a task can be started in your

project. You cannot determine this without first knowing if there are any task

dependencies

• Latest start time (LS): This is the very last minute in which you can start a task before it

threatens to delay your project schedule

• Earliest finish time (EF): The earliest an activity can be completed, based on its duration

and its earliest start time

• Latest finish time (LF): The latest an activity can be completed, based on its duration and

its latest start time

• Float: Also known as slack, float is a term that describes how long you can delay a task

before it impacts its task sequence and the project schedule. The tasks on the critical path

have zero float, because they can’t be delayed

Let’s take a look at some critical path examples to better understand these critical path analysis elements.
Critical Path Examples

Here’s an example of a CPM diagram. Although it’s high-level, it can help you visualize the meaning of a

critical path for a project schedule. For now, we’ll use this critical path diagram to explain the elements that

make up the CPM method.

As you can see in this critical path diagram, project activities are represented by letters and the critical path is

highlighted in green. Tasks F, G and H are non-critical activities with float or slack. We can also identify task

dependencies between the critical path activities, and also between activities (A, F and G) or (A, H and E),

which are parallel tasks.

Here’s another critical path example from Harvard Business Review, which shows a critical path schedule for

the construction of a house. Each circle in the CPM diagram represents a project activity, as well as it’s

duration, while the bolded arrows link the critical path activities. As projects become more complex, you’ll find

more parallel tasks, like in this example.

How to Find the Critical Path of a Project in 8 Steps

Now that you know the key concepts of the critical path method, here’s how to calculate the critical path in 8

steps.
1.Collect Project Activities

Use a work breakdown structure to collect all the project activities that lead to the final deliverable.

2. Identify Task Dependencies

Figure out which tasks are dependent on other tasks before they can begin. Use your judgement and your team

members’ feedback. Failing to define task dependencies correctly makes the critical path method useless.

3. Create a Critical Path Diagram

A critical path analysis chart, or network diagram, depicts the order of activities.

4. Estimate Timeline

To use the critical path method, you’ll need to estimate the duration of each task. Use data from past projects

and other sources of information such as subject matter experts.

5. Use the Critical Path Algorithm

The critical path algorithm has two parts; a forward pass and a backwards pass.

Forward Pass

Use the network diagram and the estimated duration of each activity to determine their earliest start (ES) and

earliest finish (EF). The ES of an activity is equal to the EF of its predecessor, and its EF is determined by the

formula EF = ES + t (t is the activity duration). The EF of the last activity identifies the expected time required

to complete the entire project.

Backward Pass

Begins by assigning the last activity’s earliest finish as its latest finish. Then the formula to find the LS is LS =

LF – t (t is the activity duration). For the previous activities, the LF is the smallest of the start times for the

activity that immediately follows.

6. Identify the Float or Slack of Each Activity

Use this formula to determine the float or slack of each task. Float = LS – ES

7. Identify the Critical Path

The activities with 0 float make up the critical path. All of these critical path activities are dependent tasks

except for the first task in your CPM schedule. All project tasks with positive slack are parallel tasks to the

critical path activities.

8. Revise During Execution

Continue to update the critical path network diagram as you go through the execution phase.

These critical path analysis steps determine what tasks are critical and which can float, meaning they can be

delayed without negatively impacting the project schedule. Now you have the information you need to plan the

critical path schedule more accurately and have more of a guarantee you’ll meet your project deadline.

You also need to consider other changes or constraints that might change the project schedule. The more you

can account for these unexpected events or risks, the more accurate your critical path schedule will be. If time is

added to the project because of these constraints, that is called a critical path drag, which is how much longer a

project will take because of the task and constraint.