3.8 (2 ratings)
Instead of using a simple lifetime average, Udemy calculates a course's star rating by considering a number of different factors such as the number of ratings, the age of ratings, and the likelihood of fraudulent ratings.
16 students enrolled
Wishlisted Wishlist

Please confirm that you want to add PMP to your Wishlist.

Add to Wishlist


Improve Your Project Management Skills, Knowledge and Techniques
3.8 (2 ratings)
Instead of using a simple lifetime average, Udemy calculates a course's star rating by considering a number of different factors such as the number of ratings, the age of ratings, and the likelihood of fraudulent ratings.
16 students enrolled
Last updated 10/2016
Current price: $10 Original price: $200 Discount: 95% off
5 hours left at this price!
30-Day Money-Back Guarantee
  • 4 hours on-demand video
  • 12 Articles
  • 48 Supplemental Resources
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
What Will I Learn?
  • After successfully completing this course, the student will be able to: • Identify the elements of the PM life cycle, including: Plan, Control, and Organize and Allocate Resources • Understand PM processes • Comprehend basic tools and techniques to plan, organize and manage a project • Optimize results while managing the triple constraints • Manage stakeholder communications • Describe the principles of Team Leadership • Describe the career paths in the PM profession
View Curriculum
  • This course will be conducted by means of a sequence of lectures via videos. You need a good internet connection and must be able to read PDF scripts. Homework will be in the form of essay questions and exercises (calculations). Every student will be expected to contribute every week. There is a major Final Project due at the end of the course that will require the use of your new skills. Students will be required to demonstrate their understanding of the key features of PM, as well as the practical application of the tools.

Every facet of human life is a project. Every little step we take, from the moment we wake up up to the time we settle to sleep, is filled with mini projects. It's then not a stretch to assume that the way we handle actual projects (from work, school, etc.) is reflection of the way we handle the biggest project there is - our existence. That's why it's doubly important to come up with the perfect habit of proper planning and management of projects.

This page covers general information about the discipline of project management.

  1. A project is a temporary endeavor. Projects are unique and non-repetitive. Building a road is an example of a project. The process of building a road takes a finite amount of time, and produces a unique product. Operations on the other hand are repetitive. Delivering mail every day is an example of operation.
  2. The characteristics associated with a project are - unique purpose, temporary in nature, require resources (often from various domains), should have a primary sponsor and/or customer, and involves uncertainty.
  3. Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements
  4. A program consists of a related group of projects. Projects are finite where as programs are ongoing and continuous. Programs may be repetitive and cyclic. In some cases Project Management is a subset of Program Management. The project manager may report to the program manager in such cases. A project may or may not be a part of a program, but a program will always have projects.

    A portfolio consists of multiple programs. As an example Building a house may be a project. Building a colony consisting of row of houses is a program. Building a set of colonies to develop a new city can be considered a portfolio.

  5. A subproject is a subset of a project. Subprojects can be subcontracted. Technical or Functional Manager may be in charge of a subproject.
  6. Type of organization - This is an important concept to understand for the PMP exam. The type of organizations in decreasing order of Project Manager's authority are -
    • Projectized
    • Strong Matrix
    • Weak Matrix
    • Functional

    Project Manager has maximum authority in a Projectized organization and least authority in a Functional organization. In Functional organizations staff is organized based upon their specialty, such as engineering or sales. In these organizations, functional managers are responsible for specialized departments like marketing. In Functional organization, the role of Project Manager is limited. In Projectized organization, PMs have more authority and independence. All the persons in the project team report to the Project Manager.

    Real situations are a mixture of functional and projectized organizations. These mixed situations are called matrix organizations. Strong matrix organizations have characteristics of projectized organizations. Weak matrix organizations have characteristics of functional organizations.

  7. Leadership style varies from autocratic to democratic. Shared leadership involves team members taking most of the decisions. It encourages team development.
  8. Project Management consists of ten Knowledge Areas. These are
    • Project Integration Management
    • Project Scope Management
    • Project Cost Management
    • Project Time Management
    • Project Risk Management
    • Project Quality Management
    • Project HR Management
    • Project Communication Management
    • Project Procurement Management
    • Project Stakeholder Management
  9. Each Knowledge area has further Processes. There are a total of 47 processes. Each process has inputs, outputs and "tools and techniques" (ITTO). The PMBOK primarily covers each of the processes and it's ITTO in detail. You need to understand the concepts related to each of the input, output and "tools and techniques".

Who is the target audience?
  • This course is an asset to people in the following fields of employment engineer, construction, IT services, contractors and any job that requires a person to organize and manage a project. This course will teach you everything from planning , creating project scope, managing and controlling a project to closing .
Students Who Viewed This Course Also Viewed
Curriculum For This Course
62 Lectures
History of Project Management and Introduction to PMP
1 Lecture 05:05

A Brief History of Project Management

In this history of project management, I chart all the major developments and events in the discipline as far back as there are records. Although there has been some form of project management since early civilisation, project management in the modern sense began in the 1950s.2570 BC: The Great Pyramid of Giza Completed

The Pharaohs built the pyramids and today archaeologists still argue about how they achieved this feat. Ancient records show there were managers for each of the four faces of the Great Pyramid, responsible for overseeing their completion. We know there was some degree of planning, execution and control involved in managing this project.

208 BC: Construction of the Great Wall of China

Later still, another wonder of the world was built. Since the Qin Dynasty (221BC-206BC), construction of the Great Wall had been a large project. According to historical data, the labour force was organised into three groups: soldiers, common people and criminals. The Emperor Qin Shihuang ordered millions of people to finish this project.

1917: The Gantt chart Developed by Henry Gantt (1861-1919)

One of the forefathers of project management, Henry Gantt, is best-known for creating his self-named scheduling diagram, the Gantt chart. It was a radical idea and an innovation of worldwide importance in the 1920s. One of its first uses was on the Hoover Dam project started in 1931. Gantt charts are still in use today and form an important part of the project managers' toolkit.

1956: The American Association of Cost Engineers (now AACE International) Formed

Early practitioners of project management and the associated specialities of planning and scheduling, cost estimating, cost and schedule control formed the AACE in 1956. It has remained the leading professional society for cost estimators, cost engineers, schedulers, project managers and project control specialists since. AACE continued its pioneering work in 2006, releasing the first integrated process for portfolio, programme and project management with their Total Cost Management Framework.

1957: The Critical Path Method (CPM) Invented by the Dupont Corporation

Developed by Dupont, CPM is a technique used to predict project duration by analysing which sequence of activities has the least amount of scheduling flexibility. Dupont designed it to address the complex process of shutting down chemical plants for maintenance, and then with maintenance completed restarting them. The technique was so successful it saved the corporation $1 million in the first year of its implementation.

1958: The Program Evaluation Review Technique (PERT) Invented for the U.S. Navy's Polaris Project

The United States Department of Defense's US Navy Special Projects Office developed PERT as part of the Polaris mobile submarine-launched ballistic missile project during the cold war. PERT is a method for analysing the tasks involved in completing a project, especially the time needed to complete each task and identifying the minimum time needed to complete the total project.

1962: United States Department of Defense Mandate the Work Breakdown Structure (WBS) Approach

The United States Department of Defense (DOD) created the WBS concept as part of the Polaris mobile submarine-launched ballistic missile project. After completing the project, the DOD published the work breakdown structure it used and mandated the following of this procedure in future projects of this scope and size. WBS is an exhaustive, hierarchical tree structure of deliverables and tasks that need to be performed to complete a project. Later adopted by the private sector, the WBS remains one of the most common and useful project management tools.

1965: The International Project Management Association (IPMA) Founded

IPMA was the world's first project management association, started in Vienna by a group as a forum for project managers to network and share information. Registered in Switzerland, the association is a federation of about 50 national and internationally oriented project management associations. Its vision is to promote project management and to lead the development of the profession. Since its birth in 1965, IPMA has grown and spread worldwide with over 120,000 members in 2012.

1969: Project Management Institute (PMI) Launched to Promote the Project Management Profession

Five volunteers founded PMI as a non-profit professional organisation dedicated to advance the practice, science and profession of project management. The Commonwealth of Pennsylvania issued Articles of Incorporation for PMI in 1969, which signified its official start. During that same year, PMI held its first symposium in Atlanta, Georgia and had an attendance of 83 people. Since then, the PMI has become best known as the publisher of, 'A Guide to the Project Management Body of Knowledge (PMBOK)' considered one of the essential tools in the project management profession today. The PMI offers two levels of project management certification, Certified Associate in Project Management (CAPM) and Project Management Professional (PMP).

1975: PROMPTII Method Created by Simpact Systems Limited

Development of PROMPTII was in response to an outcry that computer projects were overrunning on time estimated for completion and original budgets as set out in feasibility studies. It was not unusual to experience factors of double, treble or even ten times the original estimates. PROMPTII was an attempt to set down guidelines for the stage flow of a computer project. In 1979, the UK Government's Central Computing and Telecommunications Agency (CCTA) adopted the method for all information systems projects.

1975: The Mythical Man-Month: Essays on Software Engineering by Fred Brooks

In his book on software engineering and project management, Fred Brooks's central theme is that "Adding manpower to a late software project makes it later." This idea is called Brooks's law. The extra human communications needed to add another member to a programming team is more than anyone ever expects. It naturally depends on the experience and sophistication of the human programmers involved and the quality of available documentation. Nevertheless, no matter how much experience they have, the extra time discussing the assignment, commitments and technical details as well as evaluating the results becomes exponential as more people get added. These observations are from Brooks's experiences while managing the development of OS/360 at IBM.

1984: Theory of Constraints (TOC) Introduced by Dr. Eliyahu M. Goldratt in his Novel "The Goal"

TOC is an overall management philosophy that is geared to help organisations continually achieve their goal. The title comes from the view that any manageable system is limited in achieving more of its goal by a small number of constraints, and there is always, at least, one constraint. The TOC process seeks to identify the constraint and restructure the rest of the organisation around it by using Five Focusing Steps. The methods and algorithms from TOC went on to form the basis of Critical Chain Project Management.

1986 Scrum Named as a Project Management Style

Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. In their paper, 'The New New Product Development Game' (Harvard Business Review, 1986) Takeuchi and Nonaka named Scrum as a project management style. Later they elaborated on it in, 'The Knowledge Creating Company' (Oxford University Press, 1995). Although Scrum is intended for management of software development projects, it can be used to run software maintenance teams, or as a general project and programme management approach.

1987: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Published by PMI

First published by the PMI as a white paper in 1987, the PMBOK Guide was an attempt to document and standardise accepted project management information and practices. The first edition was published in 1996, followed by a second in 2000, and a third in 2004. The guide is one of the essential tools in the project management profession today and has become the global standard for the industry.

1989: Earned Value Management (EVM) Leadership Elevated to Undersecretary of Defense for Acquisition

Although the earned value concept has been around on factory floors since the early 1900s, it only came to prominence as a project management technique in the late 1980s early 1990s. In 1989, EVM leadership was elevated to the Undersecretary of Defense for Acquisition, thus making EVM an essential part of programme management and procurement. In 1991, Secretary of Defense Dick Cheney cancelled the Navy A-12 Avenger II Programme because of performance problems detected by EVM. The PMBOK Guide of 1987 has an outline of Earned Value Management (EVM) subsequently expanded on in later editions.

1989: PRINCE Method Developed From PROMPTII

Published by the UK Government agency CCTA, PRojects IN Controlled Environments (PRINCE) became the UK standard for all government information systems projects. A feature of the original method, not seen in other methods, was the idea of 'assuring progress' from three separate but linked perspectives. However, the PRINCE method developed a reputation for being too unwieldy, too rigid and applicable only to large projects, leading to a revision in 1996.

1994: CHAOS Report First Published

The Standish Group collects information on project failures in the Information Technology (IT) industry with the objective of making the industry more successful, showing ways to improve its success rates and increase the value of IT investments. The CHAOS report is its biennial publication about IT project failure.

1996: PRINCE2 Published by CCTA

An upgrade to PRINCE was considered to be in order, and the development was contracted out, but assured by a virtual committee spread among 150 European organisations. Originally developed for Information Systems and Information Technology projects to reduce cost and time overruns; the second revision became more generic and applicable to any project type.

1997: Critical Chain Project Management (CCPM) Invented

Developed by Eliyahu M. Goldratt, Critical Chain Project Management is based on methods and algorithms drawn from his Theory of Constraints (TOC) introduced in his 1984 novel titled, 'The Goal'. A Critical Chain project network will keep the resources levelly loaded, but will need them to be flexible in their start times and to switch quickly between tasks and task chains to keep the whole project on schedule.

1998: PMBOK Becomes a Standard

The American National Standards Institute (ANSI) recognises PMBOK as a standard in 1998, and later that year by the Institute of Electrical and Electronics Engineers (IEEE).

2001: The Agile Manifesto Written

In February 2001, 17 software developers met at The Lodge, Snowbird, Utah resort to discuss lightweight software development methods. They published the Manifesto for Agile Software Development to define the approach now known by the same name. Some of the manifesto's authors formed the Agile Alliance, a nonprofit organisation that promotes software development according to the manifesto's 12 core principles.

2006: "Total Cost Management Framework" Release by AACE International

Total cost management is the name given by AACE International to a process for applying the skills and knowledge of cost engineering. It is also the first integrated process, or method of portfolio, programme and project management. AACE first introduced the idea in the 1990s and published the full presentation of the process in the 'Total Cost Management Framework'.

2008: 4th Edition of PMBOK Guide Released

The fourth edition of the guide continues the PMI tradition of excellence in project management with a standard that is easier to understand and implement, with improved consistency and greater clarification. The updated version has two new processes, not in the previous versions.

2009: Major PRINCE2 Revision by Office of Government Commerce (OGC)

A major revision has seen the method made simpler and more easily customisable, a frequent request from users. The updated version has seven basic principles (not in the previous version) that contribute to project success. Overall the updated method aims to give project managers a better set of tools to deliver projects on time, within budget and with the right quality.

2012: ISO 21500:2012 Standard for Project Management Released

In September 2012, the International Organisation for Standardisation published "ISO 21500:2012, Guidance on Project Management". It is the result of five year's work by experts from more than 50 countries. The standard is designed for use by any organisation, including public, private or community groups, and for any project, regardless of complexity, size and duration.

2012: 5th Edition of PMBOK Guide Released

The fifth edition of the guide, published in December 2012, provides guidelines, rules and characteristics for project management recognised as good practice in the profession. The updated version introduces a 10th knowledge area called, 'Project Stakeholder Management' and also includes four new planning processes.

What's Next?

With globalisation come ever bigger challenges and the need for increased speed-to-market with products and services. Projects become larger, more complex and increasingly difficult to manage. Teams are more diverse and spread across the world. The economic crisis pushes work offshore to low-cost countries, which itself presents several issues. The world is changing, and project management will need to change with it.

No doubt new techniques and better practices will arise as we push the boundaries of what is possible and new challenges face us. Human need drives us forward to a better future and with it will come improvements in the way we manage projects. When and where these developments will happen is uncertain, but they will happen.

Preview 05:05
What is a Project and Project Management
7 Lectures 46:19

Triple Constraint is a phrase used in project management to indicate that most projects have three inter-related boundary constraints: scope or results boundary, schedule or time boundary, and resource or budget and staff boundary.

When to Use Triple Constraint

The Triple Constraint boundaries should be identified at the beginning of the project. These constraints are then used to guide planning and risk management decisions. They are also used to direct the communication with stakeholders since the stakeholders typically set the triple constraint boundaries.

When a project encounters a problem, the triple constraint boundaries are often impacted. A problem in one constraint can cascade into another constraint. For instance, a delay on a task (schedule boundary) may lead to overtime payments (resource boundary).

Triple Constraint Steps

  1. Meet with the stakeholders to determine the project goals on scope (results), schedule, (time period) and resources (money and people).
  2. Determine which of these goals are fixed boundaries and which are more aspirational in nature. For instance is the goal of “complete by year end” due to a compliance requirement by a regulatory agency, or is it desired to reach personal objectives.
  3. Create a project plan and risk analysis based upon the triple constraints. If you cannot create a realistic project plan that is consistent with the triple constraints, go back to your stakeholders and request modifications to the constraints (more time, more money, different results) before starting the project.
  4. When a project replanning effort is needed, refer to the triple constraints to determine viable options for the replan.

Hints and Tips

  • Let the stakeholders set the constraints, not the project team, so that the constraints are tied to clear business objectives.
  • When problems arise on the project, consider which side of the triple constraint triangle is most impacted. Attempt to resolve the problem by relaxing a less critical or less impacted side of the constraint triangle.
  • Some organizations set both “stretch goal” constraints and “commit goal” constraints. The project plan is created to accommodate the “stretch goals” and if problems arise, the project team can relax requirements as far as the “commit goals.”
Preview 04:31

Circles of project management are a framework for considering different project management aspects. Based upon project and organizational considerations, some aspects may be emphasized and others de-emphasized.

When to Circles of Project Management

Whenever you are managing a project you are employing the circles of project management. A rigorous and detailed project management approach may be employing all four areas with emphasis. More likely, you will select one or two to emphasize and treat the other areas of project management lightly.

Instructions for Applying Project Management Circles

There are four circles, or aspects of project management, that are applied to plan and control projects:

  • High-level project plan
  • Detailed project plan
  • Project risk planning
  • Project control

A rigorous and robust project management methodology will diligently apply all four circles. However, this will also take a great deal of project management effort. Normally, based upon project constraints and organizational culture, one or two of the circles are emphasized and the others are only addressed lightly.

Selecting Circles for Rigor and Emphasis

  • High Level Plan. The high level project plan is quick and relatively easy. Its strength is communicating the big picture to managers and stakeholders. Its weakness is lack of detail. Use this approach when there are many stakeholders.
  • Detailed Plan. The detailed plan provides clear instructions and expectations to project team members. Its weakness is that, when there are areas of high uncertainty, it must make numerous assumptions – some of which will be wrong. When changing the plan for the correct status of the assumption, many team members becomes confused and frustrated. Use this approach when there are many inexperienced team members.
  • Risk Planning. The project risk plan emphasizes the uncertainty and unknown elements in the project and focuses on finding and responding to them. The weakness with this approach is that the team is regularly “fighting fires” and the plan changes frequently to accommodate the risk response. Use this approach when there are many high risk elements to the project.
  • Project Control. The project control approach emphasizes pulsing and tracking project progress in real-time. The weakness of this approach is that it feels like micro-management to the team because the project manager is constantly checking on them. Use this approach on a very urgent project or when there is a limited or weak plan.
Preview 06:41

Project Management Quiz 1
10 questions

Project Management Reading Exercise

The Project Leader is responsible for ensuring the project team executes the project. On small projects, the project leader often is also a team member with responsibility for executing several project tasks. On large projects the project leader role is often a full-time position and the leader focuses their time on project planning, issue/risk resolution, and project communication.

When to Use a Project Leader

All projects should have someone who is responsible for ensuring the project team executes the project. On very small projects there may not be a project team – everything is done by one person. In that case the individual assigned to the project is the project leader. Whenever there are multiple people conducting project activities, someone should be designated as the project leader. The individual filling the role of project leader can change as a project transitions from one phase to another.

Project Leader Steps

  1. When a project is approved, management should appoint a project leader whose role initially is to complete/update the Project Charter.
  2. The Project Leader coordinates the planning activities of all team members and ensures an integrated project plan is created. This includes any replanning due to project changes.
  3. The Project Leader should also lead the risk management process during the planning and execution phases of the project. Although all team members are responsible for identifying risk and developing risk response plans, the project leader coordinates and directs the activities.
  4. The Project Leader is the primary focal point for all project communication during the planning and execution phases of the project. This includes both communication within the project team and communication with project stakeholders who are not team members.
  5. The Project Leader tracks project status to ensure project tasks are being completed in accordance with the project plan and appropriately reports that status.
  6. The Project Leader either leads or delegates to the appropriate individual on the project team the responsibility for leading project issue resolution.

Hints and Tips

  • Projects Leaders are most successful if they have technical competence in an area of project activity, a network of relationships in the organization, and the respect of their peers.
  • Everything a Project Leader does can be boiled down to one of two categories of activities, risk management and communication management.
​Project Leader

Most large projects are managed by a cross-functional core team. Core team members have a dual responsibility; they are responsible for the project achieving its goals and they are responsible to ensure that the project complies with their function’s standards and best practices.

When to Use Core Teams

Projects that require many individuals from different departments or organizations should use the Core Team approach. The Core Team should be established as soon as the project is approved. The Core team stays in place until project completion.


  • Based upon the high live project plan, an assessment is made of which functions or organizations will play a significant role in doing the work of the project.
  • Each of the functions or organizations assigns an individual to be the Core Team member for the project.
  • The Core Team member works with functional managers and SMEs to create a plan for the function’s participation in the project.
  • Core Team members meet together and create an integrated project plan.
  • As the project progresses, Core Team members manage day-to-day project activities.
  • Core Team members ensure their respective functional or organizational leaders are informed about project decisions or risk issues prior to stage gate or management review meetings.
  • Core Team members work together to resolve issues and problems on the project.

Hints and Tips

  • Core Team members must lead in two directions. The must lead into their function or organization to manage the project tasks conducted by individuals in their function. They need to ensure the work is done in a way that meets the project goals and needs. They must also lead into the project Core Team to represent their function’s perspective. They must identify and resolve risks within the project relates to their functional areas. The need to ensure that all project work is done in a manner consistent with their functional standards.
  • Core Team members must be good negotiators and good at resolving conflict. Many Core Team meetings are spent resolving issues between functions.
  • Core Team members should stay with the project through project closeout. Their performance appraisal should include both project performance and functional performance attributes.
  • Core Team are not needed when there are only 2 or 3 team members or all the work is in one department.
Core Teams

The Project Stakeholders are any person or organization who is affected by the project. Project Stakeholders set the goals for the project and will ultimately determine whether the project is considered a success or failure. Project Stakeholder support is usually a key component in successful projects.

When to Use Project Stakeholder Management

All projects have stakeholders. The stakeholders may be only the project team members, but normally they also include managers of the organization and users of the project result. At the time the project is initiated the stakeholders should be identified and their goals objectives for the project should be clarified and captured in the Project Charter. At the time of project completion the stakeholders should be notified of the project results and their approval obtained. Throughout the project execution, many stakeholders will want to be kept informed about project progress and may want to participate in some project activities.

Project Stakeholder Management Steps

Many of these steps are expanded into more detail within other project management modules.

  1. Projects are normally initiated by one or more Project Stakeholders in order to achieve an organizational goal or objective.
  2. As the project objectives are identified, it often becomes necessary to include additional Project Stakeholders in the project definition since the goals or objectives will affect them in some manner.
  3. Once all Project Stakeholders are identified and their goals or objectives determined, the project leader will integrate those objectives and capture them on the Project Charter.
  4. Throughout the execution of the project, the Project Leader or their designated representative will meet with Project Stakeholders and inform them of the project status.
  5. At the time of project completion, the Project Stakeholders will review the results of the project and determine if they are acceptable.

Hints and Tips

  • Some Project Stakeholders provide the resources for the project, ensure you know their objectives and keep them informed on progress meeting those objectives, or they may remove the resources.
  • If a key Project Stakeholder does not support the project, leverage the relationship other Project Stakeholders have with that individual or organization to win their support.
  • Keep Project Stakeholders informed, especially during a project crisis. When there is a lack of information, they often assume the worst and may withdraw their support for the project.
​Project Stakeholder

The starting point in discussing how projects should be properly managed is to first understand what a project is and just as importantly what it is not

People have been undertaking projects since the earliest days of organized human activity. The hunting parties of our prehistoric ancestors were projects, for example; they were temporary undertakings directed at the goal of obtaining meat for the community. Large complex projects have also been with us for a long time. The pyramids and the Great Wall of China were in their day of roughly the same dimensions as the Apollo Project to send men to the moon. We use the term project frequently in our daily conversations. A husband, for example may tell his wife, "My main project for this weekend is to straighten out the garage." Going hunting, building pyramids, and fixing faucets all share certain features that make them projects.

A project has distinctive attributes, which distinguish it from ongoing work or business operations. Projects are temporary in nature. They are not an everyday business process and have definitive start dates and end dates. This characteristic is important because a large part of the project effort is dedicated to ensuring that the project is completed at the appointed time. To do this, schedules are created showing when tasks should begin and end. Projects can last minutes, hours, days, weeks, months or years.

Projects exist to bring about a product or service that hasn't existed before. In this sense, a project is unique. Unique means that this is new, this has never been done before. Maybe it's been done in a very similar fashion before but never exactly in this way. For example, Ford Motor Company is in the business of designing and assembling cars. Each model that Ford designs and produces can be considered a project. The models differ from each other in their features and are marketed to people with various needs. An SUV serves a different purpose and clientele than a luxury model. The design and marketing of these two models are unique projects. However the actual assembly of the cars is considered an operation, i.e., a repetitive process that is followed for most makes and models.

In contrast with projects, operations are ongoing and repetitive. They involve work that is continuous without an ending date and you often repeat the same processes and produce the same results. The purpose of operations is to keep the organization functioning while the purpose of a project is to meet its goals and to conclude. Therefore, operations are ongoing while projects are unique and temporary.

The project is completed when its goals and objectives are accomplished. It is these goals that drive the project and all the planning and implementation efforts undertaken to achieve them. Sometimes projects end when it is determined that the goals and objectives cannot be accomplished or when the product or service of the project is no longer needed and the project is cancelled.

A Formal Definition of a Project

There are many written definitions of a project. All of them contain the key elements described above. For those looking for a formal definition of a project, PMI defines a project as a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project's objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.

Project Characteristics

When considering whether or not you have a project on your hands, there are some things to keep in mind. First, is it a project or ongoing operation? Next, if it is a project; who are the stakeholders? And third, what characteristics distinguish this endeavor as a project?

  • A project has several characteristics:
  • Projects are unique.
  • Projects are temporary in nature and have a definite beginning and ending date.
  • Projects are completed when the project goals are achieved or it's determined the project is no longer viable.

A successful project is one that meets or exceeds the expectations of the stakeholders.

Consider the following scenario: The VP of Marketing approaches you with a fabulous idea. (Obviously it must be "fabulous" because he thought of it.) He wants to set up kiosks in local grocery stores as mini offices. These offices will offer customers the ability to sign up for car and home insurance services as well as make their bill payments. He believes that the exposure in grocery stores will increase awareness of the company's offerings. He told you that senior management has already cleared the project and he'll dedicate as many resources to this as he can. He wants the new kiosks in place in 12 selected stores in a major city by the end of the year. Finally, he has assigned you to head up this project.

Your first question should be "Is it a project?" This may seem elementary, but confusing projects with ongoing operations happens often. Projects are temporary in nature, have definite start and end dates, result in the creation of a unique product or service, and are completed when their goals and objectives have been met and signed off by the stakeholders.

Using these criteria, let's examine the assignment from the VP of marketing to determine if it is a project:

  • Is it unique? Yes, because the kiosks don't exist in the local grocery stores. This is a new way of offering the company's services to its customer base. While the service the company is offering isn't new, the way it is presenting its services is.
  • Does the product have a limited time frame? Yes, the start date of this project is today, and the end date is the end of next year. It is a temporary endeavor.
  • Is there a way to determine when the project is completed? Yes, the kiosks will be installed and the services will be offered from them. Once all the kiosks are intact and operating, the project will come to a close.
  • Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders will be documented in the form of requirements during the planning processes. These requirements will be compared to the finished product to determine if it meets the expectations of the stakeholder.

If the answer is yes to all these questions, then "Houston, we have a project".

What is a Project?

Project Management Quiz 2
11 questions
Project Management : Methodology, Toolset and Documentation
5 Lectures 43:05
What is Project Management? Reading Exercise

A methodology or system of project management helps those in the organization involved with projects to know what to expect. The definition of best practices and templates will normally speed up a project and improve its overall quality.

When to use a Project Management Methodology

A project management methodology is created by an organization to establish a pattern for a type of projects. If your project fits that type, you should follow the pattern or methodology.


  • When assigned to lead a project, meet with stakeholders to understand the goals, objectives, and constraints on the project.
  • Based upon those meetings, determine if your project fits the criteria of an established project management methodology in your organization.
  • If so, follow the methodology.
  • If not, determine if you project fits the criteria for a well-documented industry-standard approach.
  • If you have access to that approach, follow it.
  • If your project does not fit an established methodology, you will need to spend additional time and effort in the project planning and project control aspects of project management since there will likely be confusion about what should be done and how to do it.

Developing a Project Management Methodology

To develop a methodology, consider industry best practices for the type of project and examples of that type of project in your organization that went well.

Do not automatically adopt the best practice written about in books or on blogs. There is a culture that must accompany any methodology for it to be successful. If your organization is a “hero-based” culture, don’t adopt a methodology that requires strict process discipline. If your culture is data driven, rely on analytical project management approaches, not one that require extensive team meetings and integration activities.

For a methodology to succeed, senior management must understand the methodology and how they are to interact with projects. Senior managers who routinely direct the project teams to do things that violate the methodology will ensure that the methodology is not followed. If senior management wants to change the methodology, change it. It is better to have an imperfect methodology that is followed than no methodology at all.

A Project Management Office (PMO) is often needed to ensure that the methodology is both kept current and that it is followed. Many methodologies require elements of program or portfolio management and a PMO is almost always needed to for that level of project management planning and control.

Project Management Methodology

​Project Management Tools Reading Exercise

Project Dashboards are a quick summary of the project status and project health. They are normally used for management communication and/or team member communication.

When to Prepare a Project Dashboard

Dashboards are a communication tool. A dashboard is prepared as part of the communication plan. They are the best practice for quick communication with stakeholders and management. They are also very helpful for extended or virtual project teams. However, the format and content would be different for those two applications. The format for management dashboards normally follows a standard company template and focuses on “big picture” issues like project objectives and project-level boundaries. These dashboards are updated prior to sending out the management communication. The format for project team dashboards is usually derived from the project planning artifacts (schedules, task lists, etc.) and focuses on the daily progress and status of activities. These dashboards are normally updated as part of a team meeting.

Steps for Preparing a Project Dashboard

Project Management Dashboard

  1. When the project plan is initially approved, the planning information is entered into the dashboard template.
  2. Periodically (based upon the organization’s communication policy) the dashboard is updated to reflect current project status and current project health.
    1. Often the health is shown with Red/Yellow/Green indicators.
    2. The organization will usually have a scale to use for determining which color should be used.
    3. If no scale is provided, use Red for areas that cannot meet the project objectives, Yellow for areas that are experiencing problems but that the team believes they can solve, and Green for areas where there is an adequate plan and approach in place.

Project Team Dashboard

  1. When the project plan is completed, the project team decides which project planning artifact(s) it will used to track status and progress.
  2. At each project team meeting, team members report their progress and the status is shown on the project planning artifact(s).

Hints and Tips

  • Dashboards should be quick and easy to update – if it takes too long, no one will do it.
  • Dashboards are meant to communicate status and risk – don’t hide issues, expose them.
  • Graphs and charts are easier for people to understand than tables of data or bullet items on text – use charts as long as they are easy to create and update.
  • Don’t let your management dashboard become too cluttered. If management can’t find the information they want, they will ignore the dashboard.
  • Keep dashboards current – then you are always able to quickly provide a project status.
Project Dashboards

Project Management Documentation Reading Exercise

Project Management Quiz 3
7 questions
Project Management: Project Initiating
6 Lectures 26:17
Project Initiating Reading Exercise

The Project Lifecycle is the set of phases that a project goes through – it is a high-level outline of the project activities.

When to Use a Project Lifecycle

All projects go through a project lifecycle. An understanding of the lifecycle is beneficial during the planning phase of the project. If the project is well-defined, conducting familiar types of effort, and using a stable resource pool; the project can use a predictive lifecycle that allows the entire project to be planned in detail at the beginning of the project. Each phase and the activities within that phase are understood and therefore can be “predicted.” If the project is uncertain or unstable; an adaptive lifecycle is more appropriate. In an adaptive lifecycle, the instability and uncertainty prevents the project team from planning the project in detail at the beginning of the project. In this case, the team must plan portions of the project at a time, “adapting” the plan to the current situation. An adaptive lifecycle identifies the major phases and planning points.

Project Lifecycle Steps

  1. When a project is approved, the Project Leader, stakeholders and project teams determine the required project phases (lifecycle).
  2. If the project lifecycle is predictive, the project team plans the entire project and identifies the phase completion criteria.
  3. If the project lifecycle is adaptive, the project team creates a high-level plan for the project based upon the expected levels of risk and uncertainty.
  4. For adaptive projects, the project team then plans the details of each phase and the phase exit criteria one phase at a time.

Hints and Tips

  • Most organizations have created a procedure or template for categories of projects that outline the project lifecycle and phase exit criteria.
  • The phase entry and exit points are typically reviewed with the stakeholders to demonstrate progress and obtain stakeholder buy-in.
  • Ideally, phases represent completing and retiring a major amount of project risk.
  • Phases can overlap, but keep the deliverables separate so that you know what progress you have made within each phase.
Project Lifecycle

Project Project Lifecycle Quiz 4
4 questions

Identifying stakeholders enables the project team to create a strategy for each communicating and interacting with each stakeholder.

When to use Stakeholder Identification

At the time of project initiation the stakeholders should be identified and their needs addressed within the project plan. At the beginning of each phase, review the stakeholders to determine if they have changed or if your communication and interaction strategy needs to change for the new phase.


  • List the direct stakeholders of the project (all that apply) – customers/users, senior management reviewing the project, functional managers providing resources for the project, project leader and core team.
  • List the indirect stakeholders of the project (all that apply) – individuals or organization affected by the project, regulatory bodies with oversight of project activities or results, community groups.
  • Record the stakeholders and their contact information in a Stakeholder Register.
  • Based upon their power and interest in the project, determine an interaction strategy.
  • Use this Stakeholder Register when developing your project communication plan.
Stakeholder Identification

Many stakeholders have additional goals for a project beyond the primary business goal. Understanding those goals can help the team ensure project success and maintain stakeholder support

When to use

When the Stakeholder Register is first created, the stakeholder goal(s) should be identified. Whenever there is a change in stakeholders, the goal of the new stakeholder should be determined. At the beginning of each major phase of a project, the stakeholder goals should be confirmed to determine if there have been changes.


  • Determining stakeholder goals is often as easy as just asking them. They will of course want the business benefits, but ask them what would make this an exemplary project in their mind, and what make this a project failure.
  • If you are unable to ask the stakeholders directly, review their attitude and actions on other similar projects and infer their likely goals.

Personal and Business Goals

Personal goals are often even more important to some stakeholders than the business goals. When possible you should ensure the project also meets the personal goals for stakeholders. Often these can be accommodated with very little effort but will lead to strong stakeholder support. For example:

  • You may have a team member who is hoping to use this project as a step for promotion. They will probably want an opportunity to showcase their skills with senior management.
  • You may have a stakeholder who is primarily responsible for managing a portion of the organization and views this project as an irritant. They will want the project to make as few demands as possible on their time and attention.
  • You may have a stakeholder who is trying to use the project to further another initiative. They may want to modify the project slightly to align it with their initiative.
  • You many have stakeholders who are responsible for other large projects or initiatives. They want your project to not interfere with their project, and if possible enhance the likelihood of success on the other project.
Stakeholder Project Goals

The Project Boundaries are the list of project goals, assumptions, and constraints that are agreed upon by the project team and stakeholders at the time of project initiation.

When to Use Project Boundaries

Project Boundaries are most beneficial early in the project and whenever the project is undergoing change. An agreement between the project team and stakeholders on boundaries will reduce the likelihood of confusion on project goals and missed expectations at the end of the project. Setting the project boundaries at the time of initiation allows the project team to plan the project with a clear understanding of project goals, assumptions, and constraints. This speeds and simplifies the planning process. In addition, whenever there is a request for a project change, the boundaries help the team evaluate whether that change is within scope or out of scope. Clear boundaries will reduce the likelihood of scope creep.

Project Boundary Creation Steps

  1. At the time the project need is being validated, the project leader (if known) or project sponsor should meet with other stakeholders to identify project boundaries.
  2. In each meeting, a series of questions about the project are asked – the order of the questions does not matter. The questions are:
    1. What is the project supposed to accomplish?
    2. Why do we need to do this project?
    3. Who are the customers, stakeholders, and team members for this project?
    4. When does the project need to start and end?
    5. Where is the project activity to take place?
    6. How should the project team approach the project? (procedures, examples, constraints)
  3. The answer to some questions may be, “It doesn’t matter.” or the answer may be very specific.
  4. Summarize all of the boundary conditions and identify inconsistencies between stakeholders.
  5. Meet with the stakeholders who have a difference of opinion on one of the “W” questions . Explain the two responses and facilitate a negotiation between the stakeholders.
  6. Document the results of the boundary setting activities in the Project Charter.

Hints and Tips

  • Ask each stakeholder all six questions. Look for inconsistencies between stakeholders and resolve them.
  • Answers of, “It doesn’t matter.” or, “I don’t care.” are great answers. They give the project team flexibility on those boundary conditions.
  • Vague answers like, “As soon as possible.” for the “When” question, or “Everybody.” for the “Who” question often lead to missed expectations on the part of the stakeholders. If that type of boundary is important to them, work to get a specific answer.
  • I use these questions whenever I am being asked to start a project – even if it is just a small action item. The questions only take a few seconds to ask, and the answers are very helpful for planning and executing the work.
Project Boundaries

In-Frame/Out-of-Frame is a technique for clarifying project boundaries by list both the activities and deliverables that are in scope for the project and listing the activities that are not required as part of the project.

When to Use In-Frame/Out-of-Frame

In-Frame/Out-of-Frame techniques should be used at the time of project initiation. It is particularly helpful for those cases where the stakeholder’s requirements are unclear or uncertain. When that is the case, the technique can help the stakeholders to clarify their expectations.

In-Frame/Out-of-Frame Steps

  1. Meet with the stakeholders to determine the project goals and deliverables. List these “In-Frame.”
  2. Question the stakeholders about other possible activities that are related to the work of the project to determine if they are required. If so, list them “In-Frame,” otherwise list them as “Out-of-Frame.”
  3. Review the activities that are “In-Frame” and question the stakeholders about the need to extend any of these beyond the normal level for projects of this type. Clarify with them the boundary for completion and list activities on the appropriate lists.
  4. If agreement cannot be reached with respect to which list an should be placed on, place that activity “On-the-Frame” and include that activity in the Risk Register with a clear trigger point for when the decision will be made to move it either “In” or “Out.”
  5. If at some point an “Out-of-Frame” item is requested by a stakeholder, a project change must be processed which normally results in a change in schedule and budget.

Hints and Tips

  • You do not need to use a “picture frame.” That is just the metaphor that the technique relies upon. The key is to develop the two lists.
  • The “Out-of-Frame” list is your best defense against scope creep. A good discussion with this tool will ensure that everything that should be done on this project is included, and everything that is not necessary is identified and the stakeholders concur that it is not necessary.
  • Don’t go crazy on the “Out-of-Frame” list. You don’t need to list “solve world hunger.” Just list items that are logically related to the project, but not required this time.
  • Don’t portray the “Out-of-Frame” list as items that the stakeholders cannot have. If they want them, put them “In-Frame.” Rather the list represents those items that the stakeholders agree they don’t want to spend time and money on with this project.

Project Initiation Quiz 5
14 questions
Project Management: Scope Planning and Phases
6 Lectures 21:47
The Scope Planning Phase Planning

Primary Constraint

The approach taken when planning a project should be based upon the primary project constraint. Attributes of that constraint are planned first and then other aspects of the project are planned to support the primary constraint.

When to use Primary Constraint

The principles of managing from the primary constraint are applied when creating the detailed project plan. This will be at the beginning of a project and often at the beginning of each stage when using a stage and gate project management methodology.


First determine which is the primary constraint: scope/quality, schedule, or resources. Depending upon the constraint, follow the steps in the listed order.

Scope Constraint

  1. Identify all project deliverables.
  2. Set quality objectives for each deliverable.
  3. Determine best resource to complete each deliverable.
  4. Estimate amount of resource needed to complete the deliverable.
  5. Schedule based upon resource availability.
  6. Budget based upon deliverables, cost of resource and schedule.

Schedule Constraint

  1. Identify project schedule boundary.
  2. Set interim project milestones to support boundary.
  3. Determine resources available to support each milestone.
  4. Estimate deliverables and quality level that available resource could complete in available time.
  5. Budget based upon deliverables, cost of resource and schedule.

Resource Constraint

  1. Identify project resource constraint:
    • Cash, personnel, equipment
    • Both amount and timing
  2. Estimate deliverables and quality level that available resources could generate.
  3. Schedule deliverables based upon resource availability.
  4. Create budget based upon deliverable, cost of resource and schedule.
​Primary Constraint

Project Phases

Projects are often organized into phases. Phases provide structure and logic to the project and aid the project team and management to track progress.

When to use Project Phases

Project phases are normally used in one of these three situations:

  1. The organization has a Stage-Gate project management methodology that separates project into phases. In this case the phases are the standard way to do projects.
  2. Projects that have a great deal of complexity and risk are often separated into phases in order for the project team and management to focus on appropriate aspects of the project at the right time.
  3. A project that is funded incrementally by the organization or a customer will often be managed in phases based upon the deliverable that support the funding pattern.


When there is an organizational Stage-Gate methodology:

  • Using the Project Charter and any requirements documents, separate the project deliverables and activities into the phases per the methodology.
  • Create a high level project plan showing start and stop points for each phase and the key deliverables for each phase.
  • Create a detail project plan for each phase prior to starting that phase.
  • Present the results of each phase at the appropriate review.
  • Initiate each new phase once you have received the go-ahead.

When the project has a great deal of complexity or risk:

  • Divide the key project deliverables and risks into logical groups that are similar in the amount of time and effort. Each group is a project phase.
  • Determine the best sequence to address the risks in the project.
  • Create a high level project plan showing start and stop points for each phase and the key deliverables for each phase.
  • Create a detail project plan for each phase prior to starting that phase.
  • Present the results of each phase at a management review.
  • Initiate each new phase once you have received the go-ahead.

Next heading level is heading 3

  • Divide the project effort to support the deliverables in the funding pattern. These are your phases.
  • Create a detailed plan for each phase prior to the start of that phase
  • Present the results of the phase to the funding agency to get paid.
  • Initiate each new phase once you have received the go-ahead from the funding agency.
Project Phases

Task Descriptions are the statements of scope for each of the project activities. They are written in the format of “action – completion point.”

When to Use Task Descriptions

Task Descriptions are used during project planning, project execution and project control. During project planning the task descriptions are used for scope planning and creating estimates. During project execution the task description is used by those doing the activities to ensure they are doing the work correctly. As part of project control, task descriptions are used to measure completion of tasks and measure project progress.

Task Description Steps

  1. Starting with the scope statement, list of project deliverables, and deliverable deployment the project activities are identified.
  2. Each project activity is written using the format of “Action – Completion Point.”
    1. Action is needed to know what type activity is required so that the proper resources can be assigned.
    2. Completion Point is needed so that the individual or team doing the activity knows when they have completed the activity successfully.

Hints and Tips

  • Task Descriptions need to be actions, not departments or locations. Stating who or where the work will be done does not describe the type of work or the completion point.
  • If the activity is very large and complex, it is often best to break it into a set of smaller actions and completion points.
  • Poorly written Task Descriptions lead to poor planning, execution, and control of projects because the work is uncertain.
​Task Description

Deliverables Deployment is a project management technique for identifying all elements of project scope

When to Use Deliverables Deployment

The Deliverables Deployment technique is appropriate when there is no standard process describing the project effort needed to complete the work of a required project deliverable. The Deliverables Deployment technique provides a structured approach for thinking through all of the activities that must be accomplished. When a standard process exists, the process steps describe the scope of activities.

Deliverable Deployment Steps

  1. List the project deliverables (see project Charter or talk to stakeholders).
  2. For each deliverable ask the question, “What must I do to complete this deliverable?”
  3. For each of the items identified in question 2, ask again, “What must I do to complete that item?”
  4. Continue with step 3 until all of the required activities are identified.

Hints and Tips

  • The listed activities are the elements of Project Scope.
  • The work required to do the listed activities must be estimated and appropriate resources assigned to conduct the activities in order to complete the project.
  • If the deliverables are deployed correctly, when all of the listed activities are completed the project is complete.
  • You can start from the deliverable and work backward, or start from where you are an work forward to the deliverable – in either case identify all of the steps or activities required to complete the deliverable.
  • There is a tendency to overlook common basic activities because, “Everyone knows you have to do that!” List them anyway. If they are not on the list, the project plan will not allocate time and resources to do the work. Then when the activity is done, it shows up as a delay or overrun because it was not in the plan.
  • You can carry this technique to an extreme by breaking everything down to minute detail. A good rule of thumb is to break activities down into half-day or full-day increments of work.
  • All of these details do not need to be listed on the project plan – you can summarize them. But know the details when you begin to estimate the effort and time to do the work.
Deliverables Deployment

The WBS Dictionary is a table or spreadsheet that is organized by project task and contains all project planning details.

When to use WBS Dictionary

Small/Focused Projects: The WBS Dictionary is an ideal tool for consolidating and communicating the project plan on small or focused projects. The entire project plan can be presented in one table.

Large/Complex Projects: The WBS Dictionary is useful on large or complex projects for summarizing a portion of the project such as a phase or all the activities required to support a major deliverable. The technique becomes unwieldy when the table grows to include hundreds of tasks.


  • Determine the column headings for documenting the plan. There should be at least one column for the task description, normally at least two columns for the schedule – those being the start and finish date for the task, and at least one column for resources – either personnel or budget.
  • Determine the column headings for managing the project. There should be at least one column for current status. Often there are columns for items such as risk, variance, or relationships with other tasks.
  • List each of the project deliverables. If the project is managed in phases, list each phase and the deliverables for that phase.
  • List each task that must be accomplished to complete each deliverable under the respective deliverable.
  • As the project plan is developed, insert the planning information into the appropriate cell in the table.
  • As the project progresses, insert the status information into the appropriate cell in the table.
Work Breakdown Structure Dictionary

The Scope Planning Quiz 6
17 questions
Project Management: Schedule Planning
5 Lectures 22:52
Project Schedule Development Planning Reading Exercise

The Milestone Chart is a project schedule tool that shows items of significant risk or importance to the project.

When to Use a Milestone Chart

Milestone Charts are for communicating risk. If the project has many stakeholders or team members, a Milestone Chart helps everyone to understand the significant risk events on the project. The Milestone Chart is the primary schedule chart used in Management Reviews. If a project must integrate with other projects, the Milestone Chart of each project should be shared with the other so that each project is aware of issues that could impact the integration points. I don’t recommend using a Milestone Chart for small one-person projects that are not technically complex. The Milestone Chart does not add any value to project management in those cases and just becomes a waste of time.

Steps to Create a Milestone Chart

  1. At the time of initial project planning, the milestones for project phases are identified and the phase timing is set. Project phase represent a major set of project deliverables and the start and completion of those items is a significant event on the project.
  2. Within each phase, when the phase is being planned in detail, significant events and risk reduction points are treated as milestones and added to the Milestone Chart.
    1. Project deliverable completions are milestones since they represent a significant event in the success of the project. Ex: completion of software development
    2. Strategic project decisions are milestones since they represent a significant event the success of the project. Ex: selection of building architect
    3. Completion of major high risk activities are a milestone since they represent a significant reduction in overall project risk. Ex: completion of qualification test
    4. Major project Management Reviews are a milestone since management makes a determination on project progress or redirection. Ex: monthly project reviews
  3. The Milestone Chart is maintained as an active project management tool and is used in Management Reviews and often included in stakeholder communications.

Hints and Tips

  • Milestones should be meaningful events to stakeholders. Include their strategic “wins.” If they don’t care about an event but should, use the Milestone Chart to help them understand.
  • When creating a Milestone Chart with project management software, don’t assign any resource effort to the Milestone. Instead, create a task(s) of Milestone preparation effort. A Milestone is treated as a “zero-time” event in most software, Assigning effort to an event with no time often screws up the cost calculations.
  • Have at least one significant project milestone each month, not counting management reviews. This helps the stakeholders understand whether or not the project is making progress.
  • Try to describe your milestones in a “pass/fail” manner so it is clear whether or not the milestone was successfully passed.
​Milestone Chart

The Gantt Chart is a project schedule tool that shows summary and detail tasks represented by horizontal bars on a schedule timeline.

When to Use a Gantt Chart

The Gantt Chart is the most commonly used project schedule chart – although it probably shouldn’t be. It is easy to create and to read. However, its major flaw is that it is based upon the assumption that all estimates of task duration are accurate. This assumption is often false, either because of the inherent uncertainty in the work, the vagueness of the requirements, or the unpredictable availability of resources. However, when the estimates are accurate the Gantt chart format provides great schedule perspective for the project. It is easy to see what tasks the project team should be working on each day, and it is easy to see if adequate progress has been made by changing the color of completed tasks. When being used for tracking progress, I always add a “time now” line on the current date of the project to indicate how much progress should have been made.

Steps to Create a Gantt Chart

  1. List the project phases (Gantt Charts are often created one phase at a time).
  2. Within each phase list the summary level tasks and their associated detail tasks.
  3. For each task set the estimated task duration (use the units of the Gantt Chart timeline).
  4. Link the tasks that must occur in the project in a sequential manner.
  5. Either:
    1. Starting with the project start date and the first task, go forward in time plotting all the tasks on the timeline based upon their linkages; or
    2. Starting with the project end date and the last task, go backward in time plotting all the tasks on the timeline based upon their linkages.
  6. Record the placement of tasks, the start date, end date, and duration on the timeline.
  7. Insert any risk mitigation changes, such as adding buffers.
  8. As the project progresses, change the color of completed task bars to show they are finished.

Hints and Tips

  • The Gantt Chart is the easiest project schedule chart to read and understand.
  • Start with a summary level Gantt Chart and create detailed Gantt Charts for each phase.
  • Draw a vertical line on the timeline showing “time now” and move the line along the timeline as the project progresses. It will show what work the project team should be doing and you can easily track whether you are ahead or behind schedule.
  • Different color bars can be used to show additional information about a task, such as critical path, behind schedule, or task is complete.
  • The Gantt Chart relies on accurate and precise estimates for each activity. Using inaccurate estimates sets false expectations because team members try to meet the estimates, even though they quickly realize that some are wrong; and stakeholders begin to doubt the credibility of the project team when the actual durations are often different from the estimates.
  • The Gantt Chart cannot be created with variable estimates. If you have that situation either use a Network Diagram or start with the “most likely” estimate and build in a risk buffer.
Gantt Chart

A Task List Schedule is a schedule format used to communicate tasks with dates to extended team members or those who do not have a major role in the project.

When to Use Task List Schedules

Tasks List Schedules are best used in those situations where an individual is needed to lead a few tasks on a large project. In this case, the individual would probably not be on the Core Team, since their role is so small. However, the tasks that are their responsibility are important to the success of the project. Rather than sending them a project plan with hundreds of tasks and asking them to “find” the ones they must do, a Task List Schedule is created with only their tasks and sent to them.

Task List Schedule Steps

  1. Create the project schedule using your normal project scheduling and estimating techniques.
  2. Identify tasks that must be accomplished by “Extended Team Members” or those individuals who require special focus.
  3. Consolidate the tasks for that individual on one list.
  4. Sort the list by completion date.
  5. Send the Task List Schedule to the Extended Team member and confirm that they have received it and can complete the work.

Hints and Tips

  • The Task List Schedule is a form of Action Item List. Many people use this approach to schedule their work and plan their day.
  • This approach adds a sense of urgency to the tasks. Tell the Extended Team member that you will be checking with them on the day an item is due to receive its completion into the project files.
  • If the list is too long, in excess of 10 tasks, the Extended Team member should either be on the Core Team, or working directly with a Core Team member.
Task List Schedule

Project scheduling tool for managing a batch of similar items that must be processed through the same project steps.

When to use 2 Dimensional Task List

The 2D Task List is ideal for the project that has a batch of items must be processed through similar project management steps, such as the development of software modules or the qualification of many vendors/suppliers.


  • Create the project schedule based upon project requirements and constraints using Milestone Charts, Gantt Charts, or Network Diagrams.
  • Identify tasks that are a batch – similar set of activities applied to multiple items.
  • List the items in the first column of the matrix and the activities as column headings.
  • Plan an end date for each item and activity and place it in the appropriate cell of the matrix.
  • Show the batch as a single summary task on the Gantt Chart or Network Diagram.
  • As the work is completed, change the background color of the cell to indicate that it is done.
​2 Dimensional Task List

Schedule Planning Quiz 7
15 questions
Project Management: Resource Planning
3 Lectures 13:10

A Project Budget is a time-phased periodic spreadsheet where each row represents an element of project work and each column represents a calendar time period (such as a month).

When to Use a Project Budget

Virtually all large projects have a project budget. This allows the finance department to plan what financial resources will be required to conduct the project work and when they will be required. Small projects often have a project budget if they have a significant amount of purchased items. This helps the project management team, purchasing, and finance plan for the project activity. Small projects without a significant amount of purchased items (essentially a project with in-house labor only) often do not require a project budget. The labor is paid for as part of the various department overhead costs. In this case, the project is managed just with a schedule, task list, and team list.

Steps to Create a Project Budget

  1. List all project activities that require effort by project team members or suppliers.
  2. Estimate the amount of effort for each activity (typically labor hours or supplier quotes).
  3. Convert the effort estimate into an amount of money (based upon labor rate or value from the supplier quote).
  4. Create a spreadsheet with a list of project activities in the rows and a timeline across the columns.
  5. Place the amount of money for each activity in the appropriate time column.
  6. Sum the total for each column to create the estimate for how much money the project will spend during that time period.
  7. Create a cumulative sum that totals how much money the project will spend from its start until that time period.

Hints and Tips

  • Ensure you have identified and budgeted all the activities that will be charged to the project – even if the effort is not done by individuals in your department.
  • If the project budget is fixed or limited and scope is variable – allocate a budget amount to each phase then prioritize the work for that phase. Stop work on that phase when the budget is expended and go to the next phase.
  • To simplify accounting on long projects, if project budget is funded by fiscal year – rather than the entire project at one time – try to set the end of a phase at the end of each fiscal year. .
  • If a project spends money in multiple countries, ensure that it accounts for the exchange rate.
  • The date for a purchased item is normally the date the item is received, although finance may direct you to use either the date the purchase order is placed or the date the bill is paid.
  • If an activity spans multiple time periods, either spread the budgeted money based upon how much you think will be spent each time period or just spread it evenly between all periods.
  • The amount of money included for a budget reserve is either embedded as part of a task estimate or is allocated to a separate reserve task that is scheduled in the project.
Project Budget

The project Resource List is a list of all individuals working on the project with their contact information and all special equipment and facilities required to accomplish project tasks.

When to Use Resource List

If the project team is large, a Resource List is normally required to facilitate communication. If the project team is in different locations, especially different countries, a Resource List is often needed to ensure timely communication through appropriate communication channels. If the project requires special equipment, special facilities or special access to systems a Resource List is often needed to manage the coordination.

Often at the beginning of a project, some of the project team members or items of equipment are not yet identified. They may not be needed for several months, or their organization may not have been placed on contract yet to support the project. A Resource List can identify the team members or equipment by title until a specific person or system is identified for the project. The individual on the Resource List often changes at the beginning of a new phase of the project because the team members involved in that phase may be different from previous phases. In many organizations the Resource List also includes the point of contact for key suppliers and vendors working on the project.

The inability to identify someone for each role within a reasonable amount of time should become a project risk and tracked on the Risk Register.

Resource List Steps

  1. Identify the roles for the Core Team based upon the project goals and project scope.
  2. Contact appropriate business managers to assign Core Team members.
  3. Obtain contact information for each Core Team member and the project stakeholders.
  4. At the beginning of each phase, add the extended team members who will be working on the project to the Resource List. Note their role and obtain their contact information through their manager or Core Team member.
  5. When key or strategic facilities, equipment or suppliers are required to support the project, create a non-personnel list and add the key point of contact and their contact information.

Hints and Tips

  • Update the Resource Lists at the beginning of each phase.
  • Only use business contact information. Normally you should not put personal contact information (home address or home phone number) on a Resource List.
  • The Resource Lists are to assist in project communication management. Include the contact information for whatever communication channels you will be using on the project.
Resource List

The Responsibility Matrix is a project management tool for correlating project work assignments with project team members.

When to use a Responsibility Matrix

This technique is normally used with large teams and teams that are not co-located. Small co-located project team, assignment are normally managed in the day-to-day team interactions. When the team is large or members are not co-located, the assignment of responsibilities needs to be more formal to avoid confusion leading to duplication or omission of work.


  • List the project Team Members across the top of the matrix.
  • List the project tasks (summary or detail) down the side of the matrix.
  • For each task assign one person as the individual leading the task.
  • Assign the roles of other project team members assisting on each task.

Assigning roles in the matrix

There are many techniques in use for assigning roles in the matrix. It is strongly recommended that use one that assigns support roles in addition to lead roles for each task so that team members who must participate on a task are aware of that portion of their job.

The most common technique is based upon the CMMI methodology and uses the acronym RACI.

  • Responsible – someone who must do a portion of the work on the task but is not the task leader.
  • Accountable – the person who plans the task and ensures it is done correctly. Often they are the primary individual doing work on the task.
  • Consult – a team member who may be asked to provide information for the task, but is not expected to do any significant work on the task
  • Inform – a team member who needs to be informed about the work on the task because of its impact on their responsibilities.

Another technique that I like to use is CLAM.

  • Contribute – a team member who provides supporting effort for a task.
  • Lead – the team member who is responsible for planning and leading the task. They often do most of the work.
  • Approve – a team member who must review and approve the work of the task.
  • Monitor – a team member who tracks the progress on the task because of its impact on their responsibilities.
​Responsibility Matrix

Resource Planning Quiz 8
11 questions
Project Management: Estimating
4 Lectures 19:34

The most commonly used techniques for creating project estimates are analogous estimates, bottom up estimates, three point estimates, and using a parametric model. All of these techniques relay on some level of expert judgement and at least a tentative plan for how the work will be done.

When to use Estimating Techniques

Estimates are used to when planning a project or when replanning a project due to a change. This will occur at the beginning of a project or project phase.


There are many techniques that can be used. Listed below are the most common:

Analogous Estimate

This technique bases the estimate on the experience of a similar project. It relies on someone having done this type of work before. This is a very quick technique, but the estimate is very dependent upon who is doing the estimating and their experiences.

Bottom Up Estimate

This estimate requires that the activities of the project be decomposed into very small “micro-tasks.” Smaller tasks are usually easier to estimate accurately because all of the work is understood and you can normally find someone who has done a similar “micro-task” and can provide you with an analogous estimate. An entire project estimated in this manner will have an accurate estimate, but it can take a long time – sometimes months – to decompose all the tasks into “micro-tasks”.

Three Point Estimate

This estimating approach is often used with project activities that have high uncertainty. The estimator creates three estimates for the task – a best case, a worst case, and a most likely case. Often these will be different due to differing underlying assumptions about the task. These estimates are then combined in one of two ways. Either the three are averaged, which is called a triangular estimate, or a weighted average is created that gives more weight to the most likely estimate which is known as the PERT estimate. The project plan is created using one of the average estimates, although PERT will create two alternative plans, one with all of the best case estimates and one with all of the worst case estimates. This provides insight into the level of uncertainty in the project.

Parametric Model

In this case the experience of many projects has been codified into formula. The formula uses one or two parameters that are easily determined during project planning. By entering these parameters into the formula, a cost estimate or time estimate is derived. For instance, the time estimate on a shipping task may use a distance parameter in the formula.

Estimating Techniques

Project plans are built with an accumulation of estimates, each of which has a level of uncertainty associated with it. The level of uncertainty is a major contributor to the accuracy of the plan and the amount of project risk.

When to Use Estimating Uncertainty

When estimating any aspect of project tasks, determine what type of uncertainty exists and then apply the appropriate estimating strategy.

When preparing or revising estimates to complete the project, determine what type of uncertainty exists and then apply the appropriate strategy.

The estimating strategy can be applied to cost estimates, time duration estimates, or level of work estimates.

Estimating Uncertainty Steps

  1. For each task or task group, determine which category best describes the effort on this project:
    1. Basic – a task that is a core competency of the organization, little uncertainty.
    2. Dependent – a task that is well understood but the estimate is based upon some factor that is not yet certain.
    3. Uncertain – a task that is not well understood, there is a high degree of uncertainty.
    4. Unknown – aspects of the project for which the team has no information, there is total uncertainty.
  2. Depending upon the nature of the uncertainty, create the estimate.
    1. Basic – use standard project estimating techniques.
    2. Dependent – create an estimate of the task for each of the states of the dependent factor. Select the state that is most likely, but show the factor as a risk and monitor it as such.
    3. Uncertain – estimate the best case, worst case, and most likely case for the task. Normally use the most likely in the project plan, but build project reserves based upon the best case and worst case.
    4. Unknown – the estimate is a guess and the area should be tracked as a high risk aspect of the project.

Hints and Tips

  • Ignoring uncertainty does not make it go away, so acknowledge it and manage it.
  • Uncertainty factors can often be managed so as to bias the actual time and money spent on a task to be close to the estimate.
  • The majority of the tasks, even on high risk projects, will be basic tasks. Have your team use standard estimating techniques on these and focus your project management attention on the other tasks.
  • Uncertain tasks can often be decomposed into smaller tasks – many of which will likely be Basic tasks.
  • When working on project activities with Unknown tasks, do frequent pulsing checks with the project team to learn factors that can help you create an estimate.
Estimating Uncertainty

Project estimates of effort, duration, and money are inter-related. Based upon the cost and availability of the resources involved, once you have one of the estimates you can derive the other two.

When to use Effort – Duration – Money

When creating the project plan, you must estimate the tasks and activities. The estimate can be provided in the form of effort, duration or money and translate one estimate into the terms of the other two.


Project estimates can be created in effort, duration or money. Once an estimate is established it can be translated into the other two dimensions.

  • It is usually easiest to start with effort estimates. The task leader or a subject matter expert should estimate the numbers of hours or days of work (not calendar time) that are required to complete the task at the specified quality level.
  • The effort estimate can be translated into time or money based upon the selection of the resource(s) that will be doing the work.
  • To translate the effort estimate into time:
    1. Determine specifically who will be working on the task.
    2. Based upon the individuals working on the task and their availability, determine how long it will take them to finish.
    3. If there are portions of the task that require duration, but not effort (waiting for an approval) add the duration to the time.
    4. Accounting for holidays on the calendar, you can calculate the duration of the activities.
  • To translate the effort estimate into money:
    1. Determine specifically who will be working on the task.
    2. Based upon their labour rate or billing rate, determine how much their work will cost.
    3. If there is any portion of the task that requires expense that is not tied to doing task effort, add that to the total. (office supplies, travel expenses)
  • These translations can work in reverse. If you have a fixed amount of time or money, you can determine the amount of effort available to do work by asking the questions in reverse order.
Effort – Duration – Money

Time Boxes are an estimating technique that sets a finite time for a task or task group. The amount of scope that is completed is variable. Whatever scope is done when the time box ends is the amount of scope for that activity on the project.

When to Use Time Boxes

Time Boxes are used when estimating project activities where the schedule is the most important constraint and the performance or quality level of the scope can be varied to meet the schedule.

Time Boxes are most often used on Extreme or crisis projects – or projects that are going through a short time of crisis.

Time Boxes are also used in AGILE/Scrum projects as the primary schedule estimating technique at the project level.

Time Box Steps

  1. Determine the start and end date for the project or project phase.
  2. Based upon the total project timeline duration, allocate Time Boxes for project tasks or task groups.
  3. Estimates for the amount of work that can be accomplished by the individuals assigned to the tasks during the time group are generated, usually by the individuals doing the work.
  4. Individuals start work on the task as soon as the Time Box starts.
  5. Individuals work on the task or task group until the amount of time in the Time Box expires.
  6. Whatever level of scope achievement is created during the Time Box is by definition the level that is to be completed on the project.

Hints and Tips

  • Time Boxes are often considered to be the opposite of traditional project management – where the scope is defined as the project goal and as much time as is needed is used to achieve the goal. With Time Boxes, the schedule is the project goal, and whatever scope is completed is good enough for the project.
  • Time Box discipline is critical. Start on time and end at the end of the Time Box.
  • It is best to use dedicated resources during the Time Box.
  • Keep your Time Boxes for project activities short a good target is one to two weeks.
Time Box Estimating

Estimating Quiz 9
12 questions
Project Management: Project Risk
7 Lectures 34:31

A project risk is any uncertain condition or event that could either be a threat to the project’s ability to achieve project objectives (negative) or an opportunity to improve the project’s ability to achieve the project objectives (positive).

When to Consider Positive and Negative Risk

Risk management is an ongoing activity that begins at the time of project initiation and continues throughout the life of the project. The earlier that positive and negative risk can be identified, the better. More time increases the ability of the project to take advantage of positive risks. In fact, many times positive risks are not even recognized as an opportunity until they are past the point in the project when they could have been leveraged. More time also increases the ability of the project to prepare for and respond to negative risks. Negative risks occurring late in the project are almost always a major impact because there are so few options left to the project team to respond that they are forced into a delay, an overrun, a defective result, or a combination of those three.

Steps for Managing Positive and Negative Risk

Other modules in this training program will go into these steps in more detail. This is just an overview of the required steps for managing project risk.

  1. When setting project boundaries, identify those boundaries that are most sensitive to risk.
  2. During project planning, and again at the start of each phase, conduct a team meeting to identify project risk – both positive and negative.
  3. Analyze the risks to determine which ones require a response.
  4. Prepare the risk response plans.
  5. Implement the risk response plans.

Hints and Tips

  • Make risk identification and risk response planning an agenda topic at team meetings to reduce the likelihood that risks are not overlooked.
  • People have a tendency to dwell on the negative risks and not consider the positive risks. To identify positive risks ask, “What would have to happen for us to complete the project early (or under budget)?”
  • Negative and positive risks often have a “flip side” that would turn the one into the other. For instance if a negative risk is project personnel availability may be delayed, a positive risk is early assignment of project personnel.
  • Positive risks normally must be identified early in the project to take advantage of them. Otherwise the negative impact of changing the project can outweigh the benefit of the positive project risk.
  • At the time of initial project plan approval and at the beginning of each phase, review the risk response plans with management for the positive and negative risks that the project team has determined to be significant for that phase. This reduces the likelihood of surprises for management and allows the team to get approval for unique or unusual risk response strategies.
Positive – Negative Project Risk

The practice of identifying positive and negative conditions that may occur within the project and impact project objectives.

When to use Risk Identification

As soon as the Project Charter has been prepared and the project boundary conditions are determined, risk identification should start. Initially it is based upon the project assumptions. As project planning begins, areas of uncertainty in the plan are risks. Once the project progresses to execution, the project Core Team should be regularly identifying risks based upon what they have seen occur on the project. Risk identification does not end until the project is complete.


There are many techniques that can be used for risk identification. What is most important is that you are doing it. The techniques just aid the Core Team to identify risks that they may have overlooked. The techniques include:

  • Expert judgment – each Core Team member should apply their experience to identify risks
  • Project documentation reviews – gaps and uncertainty in documents such as Project Charter, requirements documents, and project plans
  • Information gathering – interviews and Delphi techniques are used to gather information for subject matter experts not on the team
  • Check lists and databases – lessons learned experiences from other projects are often codified in checklists and databases
  • Assumptions testing – considering the impact to the project if a planning assumption is not valid, or only partially valid
  • Diagramming techniques – Pre-morten diagram is used to identify possible causes that could create a positive or negative impact to the project, swim lane diagram is used to identify possible organizational handoff risks within the project
  • SWOT analysis – strengths, weaknesses, opportunities, threats – construct to consider from several points of view what may happen on the project.

The practice of identifying positive and negative conditions that may occur within the project and impact project objectives.

When to use Risk Identification

As soon as the Project Charter has been prepared and the project boundary conditions are determined, risk identification should start. Initially it is based upon the project assumptions. As project planning begins, areas of uncertainty in the plan are risks. Once the project progresses to execution, the project Core Team should be regularly identifying risks based upon what they have seen occur on the project. Risk identification does not end until the project is complete.


There are many techniques that can be used for risk identification. What is most important is that you are doing it. The techniques just aid the Core Team to identify risks that they may have overlooked. The techniques include:

  • Expert judgment – each Core Team member should apply their experience to identify risks
  • Project documentation reviews – gaps and uncertainty in documents such as Project Charter, requirements documents, and project plans
  • Information gathering – interviews and Delphi techniques are used to gather information for subject matter experts not on the team
  • Check lists and databases – lessons learned experiences from other projects are often codified in checklists and databases
  • Assumptions testing – considering the impact to the project if a planning assumption is not valid, or only partially valid
  • Diagramming techniques – Pre-morten diagram is used to identify possible causes that could create a positive or negative impact to the project, swim lane diagram is used to identify possible organizational handoff risks within the project
  • SWOT analysis – strengths, weaknesses, opportunities, threats – construct to consider from several points of view what may happen on the project.
Risk Identification

All project risks are not equal in their effect on a project. Project risks that have been identified are prioritized using qualitative techniques such as the Risk Matrix.

When to use a Risk Matrix or Qualitative Risk Analysis

Once project risks have been identified, they should be entered onto a matrix or qualitative assessment and prioritized for further action. As long as there are open risks on the project, a risk matrix should be used.


  • Determine the size of the matrix – the most commonly used size is 3 X 3. But I have worked with 4 X 4, 5 X 5, and even a 5 X 10 that combined positive and negative risk in one matrix.
  • Normally probability is set as the vertical axis. The scale is either low to high or it is set with probability values
  • Normally project impact is set as the horizontal axis. The scale is either low to high or an impact in terms of money or time is set.
  • For each risk, place it in the correct spot on the matrix based upon the probability that the risk will occur and the impact to the project if it does occur.
    • I use recent relevant experience on similar projects to assess the probability. If it happened on each of the last five projects, the probability is high that it will occur again. If it hasn’t happened on any of the last five projects, the probability is low.
    • I base the impact assessment on the current project plan. Assuming the risk occurs, what does it do to the plan? Is it a minor irritant or does the plan already account for the risk – then the impact is low. Does it require a totally new approach and a project rebaseline – then the impact is high.
  • Periodically update the risks as more information becomes available and as events occur within the project.
  • If you implement risk mitigation or risk response action in the project, the risk will normally be repositioned in the matrix – either the probability is reduced or the impact is decreased.
  • If you accept a challenge or change to project objectives (finish one month sooner) normally some risks will need to change position, either the probability increases or the impact increases.
  • Based upon the location of the risk in the matrix, the risk often receives a colour code. Risk with high probability and high impact are red. Risks with low probability and impact receive a colour code of green. Risks in the middle receive a colour code of yellow.
Risk Matrix and Qualitative Risk Analysis

The Risk Sensitivity Analysis is a technique to assess the magnitude of impact from a risk.

When to use a Risk Sensitivity Analysis

The Risk Sensitivity Analysis is normally used with risks that are considered to be high (red) or medium (yellow) during the Qualitative Risk Analysis such as with a Risk Matrix. This technique is used to quantify the impact and to aid in creating risk response plans.


  1. Create a project plan with the risk factor being analyzed at the “most likely” or nominal level.
  2. Holding all other project assumptions constant, vary the risk factor being analyzed to its negative extreme. Assess the impact on project goals such as total project time and money.
  3. Holding all other project assumptions constant, vary the risk factor being analyzed to its positive extreme. Assess the impact on project goals such as total project time and money.
  4. Based upon the magnitude of the impact, consider how to modify the project plan to accommodate the risk.
  5. If there are multiple risks being analyzed in this manner, the results are often displayed in a Tornado Diagram which shows the positive and negative extremes. A Tornado Diagram orders the risks from top to bottom with the risks having the widest range being at the top.
Risk Sensitivity Analysis

Negative Risk Response is determining what actions the project will take to address risk threats.

When to use Negative Risk Response

Once the risk analysis is complete (both qualitative and quantitative) risk response is prepared for all of the high (red) risks and many of the medium (yellow) risks. Typically no risk response is required for the low (green) risks.

Whenever a risk changes priority, the risk response should be reassessed.

If a risk response has been implemented in the project plan, but it is later determined to be insufficient to accommodate the risk, additional risk response should be created.


There are four approaches to Negative Risk Response. The characteristics of the organization and unique features of the project will determine which approach to use.


Change the project plan so that the risk cannot happen. This requires a change in tasks or resources so that the risky aspect is no longer part of the project plan. Many risks cannot be avoided because they risky aspect of the task is a mandatory part of the project.


This is the most common response. This requires a change in the project plan to reduce the likelihood of the risk or the impact. The most common form of mitigation is to modify the estimate to preposition the risk response in the task estimate or to preposition a risk response task in the project. Another mitigation approach is to create a trigger event early in the project which allows a risk response to be started sooner and at lower impact.


This requires a contract of some sort. Either to insure the project against the risk or to have an outside organization conduct part of the tasks, and therefore be responsible for its completion on time and with the proper quality level.


If you do not select one of the other approaches, you are selecting accept. This approach is appropriate for very small or unlikely risks.

Negative Risk Response

Positive Risk Response is determining what actions the project will take to address risk opportunities.

When to use Positive Risk Response

Once the risk analysis is complete (both qualitative and quantitative) risk response is prepared for appropriate risks. Early in the project, there are often risk opportunities available to the project team. As the project progresses, many times the negative cost and schedule impact of making the change is greater than the positive benefit. Therefore positive risk opportunities must be sought early in the project.

Whenever a risk changes priority, the risk response should be reassessed.

If a risk response has been implemented in the project plan, but it is later determined to be insufficient to accommodate the risk, additional risk response should be created.


There are four approaches to Positive Risk Response. The characteristics of the organization and unique features of the project will determine which approach to use.


Change the project plan so that the risk will happen. In this case the focus is on the likelihood aspect of the opportunity. By changing the project plan the opportunity is no longer uncertain but becomes certain. Some opportunities will always remain uncertain, but many can be built into the project.


This approach to an opportunity is to increase the likelihood the impact or both. This is often done by changing the resources or timing of an activity.


This is often structured as a joint venture or some other type of risk sharing partnership. The organization that you are “sharing” with will enhance or enable the opportunity.


If you do not select one of the other approaches, you are selecting accept. This approach is appropriate for very small or unlikely risks.

​Positive Risk Response

Contingencies are potential risk response actions that will only be implemented if some triggering event or condition has shown that the risk probability has gone from unlikely to likely.

When to use Contingencies and Triggers

When the risk analysis (qualitative and quantitative) has been completed, risks that are high impact but low probability often are addressed with contingencies and triggers.

In addition, when a rebaseline occurs or at the beginning of each phase or stage, the risks are again considered for contingencies and triggers.

When a contingency is implemented, other risks are checked to determine if the probability of those are increased or decreased by implementing the contingency.


This risk response is a two step response. The first step is to accept the risk. This is usually because the risk is unlikely. At this point the project plan normally remains unchanged.

However, an alternate project plan is developed (at least the first few steps) for the unlikely condition when that risk does occur. This alternate plan normally has some detrimental attributes as compared to the normal plan (it costs more, it takes longer). If the alternate plan was better than the normal plan, the project team should switch to the alternate plan immediately.

In addition to developing an alternate plan, a project condition should be selected to act as a trigger indicator. If the trigger condition occurs, it indicates that the risk has changed from unlikely to likely (or present).

When the trigger indicates that the risk in now likely, it is time for the second step; the project plan is changed to the alternate plan that includes a risk response for the risk condition.


Triggers are monitored by the project leader and Core Team. Effective triggers have these characteristics:

  • Appropriate for the type of risk
  • Timely to allow implementation of alternate plan
  • Discrete for a clear indication of the triggering event, no ambiguity
  • Documented so that the team knows what they should be tracking
Contingencies and Triggers

Project Risk Quiz 10
16 questions
Project Management: Project Execution
6 Lectures 32:07

The Project Core Team is the cross-functional team responsible for planning and executing the project activities. Project team building is a process that the Project Core Team normally goes through to improve team coordination and decision making.

When to Employ Project Team Building

Project team building is most important for large projects with a cross-functional set of project activities. A Project Core Team is assigned to plan and manage the project. This team will often have conflict due to different functional and personal priorities and concerns. Team building helps this team resolve the conflict in a positive manner and keep the project on track to achieve its objectives. The Core Team members must represent the needs and standards of their function within the project activities, but they must also represent the needs of the project within their function. They also will typically act as the supervisors for all project activities performed in their function, whether they are doing the work themselves or others are doing it. This is a challenging leadership position requiring good communication skills, negotiating skills, and functional skills. For that reason, Core Teams often need to address team building issues. Very small project may only have one or two people who are involved in conducting project activities. In that case, team building is often irrelevant.

Steps for Project Team Building

  1. Forming – whenever a project Core Team is first organized, or a change is made to the membership, the members must be introduced and get acquainted with each other.
  2. Storming – this often occurs whenever the project plan is being developed or changed as the needs and capabilities of different departments must be balanced. The GRPI method is an excellent tool to use at this time.
  3. Norming – effective use of GRPI will lead to project “norms” which are the resolution to the areas of conflict
  4. Performing – project Core Teams who have been together for several projects can reach this stage because they have established “norms” for the entire project lifecycle.

Hints and Tips

  • Core Team members should be good communicators and willing to negotiate. Stubborn individuals or hard line negotiators make poor Core Team members.
  • Core Team members must be technically savvy within their department. They need to have the respect of their department and are able to identify issues and negotiate compromises for their department.
  • Core Teams often have conflict. Expect it. But work to resolve it using GRPI – don’t ignore it.
  • If the Core Team membership changes during the project, plan a short team building session to accelerate through the forming and storming stages and get to the norming stage with the new individual.
  • All members of the Core Team should be held accountable for overall project success.
Project Team Building

Project Communication Management is a very broad term that refers to all of the communication activities associated with the project. This includes team communication, stakeholder communication, management communication, and archiving of project records.

When to Conduct Communication Management

If there is more than one person on the project team or if there is a stakeholder then communication will need to happen and it needs to be managed. A communication plan should be established during the project planning phase that identifies the timing and content of team communication, management/stakeholder communication, and project record keeping requirements. This plan then needs to be followed. When there is a major issue or crisis on the project, the communication plan is often modified to increase the frequency of communication until the issue is resolved. Communication management continues throughout the project and at project closure, the communication management plan ensure that all appropriate project records are archived.

Steps for Conducting Project Communication Management

  1. At time of project initiation, the Project Leader should determine the need and desired medium of communication for all major stakeholders.
  2. As the project is being planned, the Project Leader should determine the preferred communication approach among the Core Team members.
  3. As the project is being planned, the Project Leader reviews organizational archiving requirements and organizational communication technologies available to the team.
  4. The Project Leader integrates these needs and requirements into a project communication plan that addresses the team, management/stakeholders, and project record keeping requirements.
  5. The Project Leader and team members follow the plan.
  6. The communications plan is reviewed at the beginning of each phase and changes or updates are made when necessary.

Hints and Tips

  • Leverage existing communication channels and methods if they are working well.
  • Most people won’t tell you when they are in trouble. If a team member “goes silent,” investigate to determine whether there is a project issue or another personal or organizational issue that could create a project problem.
  • Don’t forget the project records and archiving requirements. Trying to recreate project records after-the-fact is often very difficult.
  • If you have a stakeholder who periodically interjects themselves into the project to “find out what is happening” and causes confusion and disruption, meet with that stakeholder and create a communication approach that satisfies their curiosity and reduces the project disruption.
  • There are numerous technologies for for sharing documents and communications (both hardware and software). These are rapidly changing. If the technology is commonly used by your project team and stakeholders, use it. If they don’t use the technology, imposing it on them may create more problems than benefits.
​Project Communication Management

Project Decision Making is the process whereby the project leader and project team decide upon project strategy, tactics, and acceptable actions. For Project Stakeholders, the decisions normally concern project boundaries. For Project Core Team members, the decisions normally concern project plans and execution.

When to Use Project Decision Making

Project Decision Making is required throughout the life of the project to make cross-functional decisions. A decision making process is often needed to resolve conflicting points of view.

At the time of project initiation, Project Stakeholders must make decisions about project goals and project boundaries.

During the project, Project Core Team members must make decisions about project plans, risk response, and the adequacy of project performance.

At project reviews and toll-gate reviews, Project Stakeholders and Project Team members must make decisions about project progress and risk response.

Project Decision Making Steps

  1. Clarify the decision that must be made and who should make it.
  2. Schedule an appropriate meeting(s) for those to gather who must participate in the decision based upon the selected decision making process.
  3. At the meeting, present the options, risks, and known data.
  4. Make a decision using the selected decision making approach.

Hints and Tips

  • Not making a decision that is needed is often the worst thing that can happen on a project; time continues to go by with the team not knowing what to do.
  • Communicate the decision making approach you will be using so that those involved can manage their expectations.
  • Different decision making approaches take different amounts of time, match the approach with the time available.
Project ​Decision Making

Team Meetings are a gathering of team members to discuss aspects of the project. Team pulse meetings focus on status. Team problem solving meetings focus on problem resolution.

When to Use Team Meetings

If a project has more than one person conducting project work, it will require project team meetings. These meetings, between project team members, can be face-to-face or virtual. The frequency and timing of the meetings depends upon the project and the project team.

Project pulsing meetings are status meetings. Project Core Team members and other team members as required should attend. The frequency of these meetings can vary based upon the urgency of the project and whether the project is experiencing a crisis condition. Normally these meetings occur once or twice a week, but can be as frequent as several times a day. These meetings should be focused on status updates only. Team members report what tasks they have finished since the last pulse meeting, what tasks they have started since the last pulse meeting, and identify any issues that require a problem solving meeting. These meetings are normally less than 15 minutes in duration.

Problem solving meetings are discovery and resolution meetings. Whatever team members are required to identify the causes of the problem and solve them should attend the meetings. These meetings occur as needed depending upon the problems. It may take more than one problem solving meeting to resolve an issue. The meeting duration is based upon the nature of the problem.

Team Meeting Steps

  1. The project leader should establish a schedule for regular project pulse meetings that all Core Team members will attend.
  2. If a project is undergoing a crisis or stressful period, the frequency of the meetings can be increased until the crisis is over.
  3. When an issue is raised in a pulse meeting, or at the request of a project Core Team member, a problem solving meeting is scheduled and those needed to resolve the issue are invited.

Hints and Tips

  • Don’t mix the two meetings. If they will occur sequentially, be clear to call an end to the pulse meeting and let those who do not need to stay for the problem resolution meeting leave.
  • Agendas are not necessary for the pulse meeting since what will be reviewed is what is in the plan for the current pulse.
  • Agendas are often helpful for problem solving meetings so that those in attendance can come prepared. These meetings also often have a summary and action items published following the meeting.
  • Large projects often have a “standing” problem solving meeting for the Core Team and invited team members that occurs at the same time every week. This is because there are often many active problems occurring at the same time. In these meetings, an agenda and minutes are very beneficial.
​Project Team Meeting

Task Accountability is the project management activity associated with ensuring successful completion of project activities.

When to Use Task Accountability

Task Accountability is required from all project team members. When a task is completed, it should be checked by another team member, normally a Core Team member, to ensure successful completion.

High risk tasks are often tracked with detailed “mini-deliverables” to monitor the progress. Low risk tasks are often tracked simply by ensuring the required resources are in place and working on the task.

On some projects technical reviews will also be used to check on successful completion of the project activities. These reviews are conducted by an independent team of experts and are covered in more detail in module 10.3, Technical Reviews.

When working with vendors or suppliers on unique project tasks, a work authorization process is often used to direct and control the effort at the supplier.

Task Accountability Steps

  1. Task requirements for quality, schedule, and cost are normally set during project planning. This may occur at the beginning of the project or at the beginning of the phase in which the task will be accomplished.
  2. The start of the task and completion of the task should be reported at the project pulse meeting (see module 9.3 Team Meetings).
  3. Following task completion, a Core Team member should meet with the task leader to review the task results and check for completeness.
  4. When required, a Technical Review will be held to check for the completeness of a group of tasks that comprise a technical deliverable on the project.

Hints and Tips

  • Establish a standard practice in your project that every task will be reviewed by a Core Team member. This is not meant to be a personal “performance review,” rather it is a double check of team members to be sure that nothing is accidentally forgotten or overlooked.
  • Do the Core Team member review as soon as the task is complete because the work is fresh in the task leader’s mind and they can quickly answer questions.
  • If possible, have the Core Team member who will be using the result of the task in their next task conduct the review.
  • When working with suppliers and vendors on unique tasks, the work authorization process will help to keep them in sync with the project. Otherwise they may get ahead of the project team and do work that will need to be repeated – and they will charge to do it twice.
  • The level of task risk should determine whether to monitor a task with “mini-deliverables” or “level of effort.” Risk may be because of technical complexity, organizational complexity, skill or experience of individuals conducting the task, time urgency, or resource scarcity.
Task Accountability

Contractors and vendors are often used to accomplish project tasks. The complexity, uniqueness, and uncertainty of the activity will determine the nature of the relationship between the project team and the contractor or vendor.

When to use Contractors and Vendors

Contractors and vendors are normally used on projects for one of four reasons:

  • There are insufficient internal resources to do the project work when scheduled.
  • A special skill or capability is required that is not available with internal resources.
  • The contract or vendor resources are less expensive than internal resources.
  • There is a requirement to use local resources as part of the project.


There may be significant project management challenges when using contractors or vendors. If the project has a high degree of uncertainty, it is difficult to develop a complete set of requirements and schedule for use with the supplier. This can lead to numerous change orders which often become very expensive on projects. Further, depending upon the nature of the work being done by the supplier or contractor, there may be a significant amount of time and effort on the part of the project team to interface with the supplier.

Project activities often require a supplier provide a “one-of-a-kind” development from vague requirements and on short notice. When this is the case, it is important to select a supplier who has high technical skill and can act quickly. This often is not the lowest cost supplier. However, the procedures in most purchasing departments are structured for creating long term contracts with multiple deliveries of a well-defined and documented product or service with the lowest cost provider. The purchasing department’s inability to quickly react can become a major obstacle to meeting the project objectives.

Finally, purchasing departments often have policies and practices that create difficulties for projects. There may be a long term relationship between the organization and a preferred supplier for a type of commodity. That relationship works well for standard operations, yet that supplier may not be able to meet the unique technical or schedule requirements of a project. This leads to conflict between the project team and the purchasing organization.

If you will have extensive use of suppliers providing specialty products or services on your project, you should have a purchasing member on your Core Team.

Supplier Relationship

The relationship between the project team and the supplier varies depending upon the level of uncertainty and the existence of special requirements.

  • Commodity provider – if there is nothing special or unique about the products of services, use the organization’s standard supplier. Purchasing should fully manage this relationship without additional project support.
  • Custom products or services – if the required product or service is unique to the project, but well specified, purchasing will have the primary relationship, but a project team will need to periodically interface with the supplier to answer questions and clarify requirements.
  • Project design effort – on some projects, there is no clear requirements document for the supplier to use. Instead the project is relying on the supplier to propose a special or unique solution for the project. In this case, the primary relationship with the supplier must be by the project team, not purchasing. There are numerous trade-offs to be made in the design process to help the project meet all its goals. A buyer in the purchasing department, unless a member of the Core Team, is too far removed from the project to make those decisions.

Contractors and Vendors

Project Execution Quiz 11
18 questions
3 More Sections
About the Instructor
Dr. Ardin Ramani ,  PhD, MA.Ed, PMP
3.8 Average rating
2 Reviews
16 Students
1 Course

Dr. Ardin Ramani has over 25 years of experience working with international companies and organizations such as The United Nations, Catholic International Language School, and Parsons Branterkof Ltd. and has taught and lectured in universities, in countries such as England, Dubai, Australia, Russia, China, Japan and Canada, USA, etc

Dr. Ramani graduated from the University of Cambridge, Cambridge, England. Has written various articles related to business, psychology and cultures. Dr. Ramani also has his PMP certification and has been teaching project management for over 5 years and has over 8 years field experience as a Professional Project Manager.

Dr. Ramani currently continues his practice as a psychologist often conducts lectures at various universities throughout Europe and North America and is also the director of Alpine Learning Center. He is often asked to coach and conduct team building exercise with professional corporations and industrial companies that have a multicultural environment. Dr. Ramani is also a personal life coach and business coach.