General characteristics of a project

A project is a temporary endeavour undertaken to create a unique product or service. It is specific, timely, usually multidisciplinary, and always conflict ridden. Projects are parts of overall programs and may be broken down into tasks, subtasks, and further if desired.

  • Vary in size
  • Vary in type
  • Have desired completion dates
  • Requires various kinds of knowledge
  • Requires domain knowledge
  • Requires team work
  • Requires responsibilities and authorities
  • Do not exist in isolation

General management vs. Project management

  • General management
    • Organizational management
    • Portfolio management
    • Program management
    • Not time limited?
    • No completion dates?
    • No managerial hierarchy?
    • Routine activities
    • Annual budgeting
  • Project management
    • Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements

Five categories of activities

  • Initiating
  • Planning
  • Executing
  • Monitoring and Controlling
  • Closing

How does the world look like?

  • Uncertainty
  • Plans go awry
  • Even the closest future is unpredictable
  • Chance events occur frequently
  • The life is a rough road
  • We need to do trade-offs every day
  • We constantly negotiate
  • We need flexibility

Manage uncertainties

Risk management

  • “Project management is risk management”
  • Identify potential problems before they occur
  • Put preventive actions in place before unrecoverable harm occurs
  • Risks – possible events that may affect the project negatively
  • Problems – events that have or will affect the project negatively
  • Stages in risk management:
    • Risk identification; project, product and business risks
    • Risk analysis; probability and consequences, triggers
    • Risk planning; how to address risks – eliminate, reduce, ignore
    • Risk monitoring; controlling and updating the risks
Risk reporting Matrix
Risk reporting Matrix

Decision matrix

Gantt chart

Strategic Plan for New Business
Strategic Plan for New Business

RACI matrix

  • Usually derived from the WBS

  • Clarify responsibilities

  • RACI

    • Responsible, who is responsible for actually doing the activity
  • RACI

    • Accountable, who is accountable for the completion of the task
  • RACI

    • Consult, who should be consulted
  • RACI

    • Informed, who must be informed
  • Note that combinations may exist, e.g. AR, CI, AC

  • Example



Critical path

  • A path from the projects start event to its finish event that, if delayed, will delay the completion date


Sprint, Sprint backlog

  • Sprint

    • A fixed period of time, usually 2 or 3 weeks but can be more
    • Always use the same fixed period
    • The development team should have full authority during the sprint
    • The Sprint goal must be defined in advance
    • The team can change (the depth of) the functionality of the Sprint, as long as it meets its sprint goal


Product backlog

  • Requirements gathering for the Product Backlog
    • Identify the stakeholders and their goals
      • Identify the different categories of stakeholders
      • Ask the question: “Why do you need this?”
      • What are the business objectives and goals?
      • How do we measure goal accomplishment?
      • The goals shall be SMART:
        • Specific
        • Measurable
        • Acceptable
        • Realistic
        • Time-based
    • Gather requirements for the Product Backlog
      • Meet the stakeholders
      • Understand the stakeholders needs
      • Use the “Tree and Forest” analogy
        • Identify the trees, branches and leaves
        • Use a top down approach mixed with bottom-up?
        • The leaves may be user stories
        • Group the leaves into branches
        • Group the branches into trees
        • Verify the stories with the stakeholders
      • The CUTFIT rules Validate the user stories
        • Consistent no conflict between user stories
        • Unambiguous one interpretation
        • Testable test cases can be created
        • Feasible possible to implement
        • Independent independent of other user stories
        • Traceable you can link the story to the project goals
  • Do not write stories endlessly. You can stop when you cannot decompose anymore or when you can derive tasks with working effort of approximately one day
  • Product Backlog Item (PBI), example
  • Scrum board
  • Some thoughts about the Backlog
    • Scrum in action recommends items to be stories (branches)
    • Frequently, in practice, it seems to be a mix of stories, features, functions, tasks, improvements and incidents
    • If you choose stories, you should consider defining tasks (leaves) in the stories
    • The tasks should be transferred to activities in the sprint planning


Burndown charts & EVM method

Earned Value Method - EVM

  • Negative schedule, negative cost
    Negative schedule, negative cost
  • Positive schedule, negative cost
    Positive schedule, negative cost
  • Negative schedule, positive cost
    Negative schedule, positive cost
  • Positive schedule, positive cost
    Positive schedule, positive cost

Trend projection - EV

Agile and Scrum tracking

  • Release tracking

    • Tracking story progress
    • Release burndown chart
  • Sprint tracking

    • Tracking task progress
    • Sprint burndown chart
Release burndown chart
Release burndown chart
Release burndown chart
Release burndown chart
Release burndown chart
Release burndown chart

Burndown charts

  • Displays the remaining effort for a given period of time
  • Do have good value for the stakeholders and the team
  • Visualization is a good thing to do
  • Conversation starters
  • Over time it will give you the average number of points for a sprint
  • You will learn the teams velocity
  • You need to have a clear definition of done (DoD)

Sprint burndown chart

  • Burndown charts
    • X axis displays working days
    • Y axis displays remaining effort
    • Ideal effort is (may be) a good guideline
    • Consists of real progress of effort
Put # of hours (story points) at the Y axis
Put # of hours (story points) at the Y axis
If backlog items are added to the sprint
If backlog items are added to the sprint

Scrum team

  • Why is Scrum effective?
    • Systematic reduction of problems and risks
    • A leaner software development cycle
    • More adaptive process
    • People´s motivation and pride are in focus

Monitoring and Controlling

  • Determine the current status of the project schedule
  • Influencing the factors that create schedule changes
  • Determining if the project schedule has changed
  • Managing the actual changes as they occur


  • All parties, stakeholders and others, must have available the information required to exercise control over the project
  • An effective information system is needed
  • Automated and manual
  • Collection, recording and reporting project information
  • Activities and performance need to be monitored


  • Uses monitored data and information to bring actual performance into agreement with the plan
  • Do we have the right information?
  • How shall we interpret the information?
  • How to balance into decisions?
  • Without control there would be confusion, scope risks and conflict among stakeholders
  • Chaos could be the norm of the project
  • Monitoring and Controlling are easily treated together

Execute plan - Design the monitoring system

  • Identify characteristics of scope, time and cost
  • Identify the goals, the objectives
  • Define the boundaries when do we need to take action?
    • Thresholds.
  • Monitor progress against the sub-goals (e.g. milestones, sprint goals)
  • Define data gathering mechanisms
  • Define communication plan
  • Measure activities, but always measure against RESULTS
  • Define the system before-hand, up front

Obtain results

  • Decide on the data format
    • Frequency, e.g. occurrence of event
    • Raw numbers, actual amount
    • Subjective numeric ratings, estimates, ranking
    • Indicators, indirect measures
    • Verbal characterization, team spirit, soft issues, feelings
  • Collect data
    • Decide on how to collect the defined data. More easily and preferably automated.

Analyse results

  • Analyse BEFORE reporting
  • Simple aggregation can be done
  • Compare with the planned results
  • Averages, summaries, medians, trends
  • Examples
    • Number of activities done/left
    • Actual cost/remaining cost
    • Number of bugs per unit
    • Performance or velocity
  • You should use data for discovering, and as input for decision making

Identify variance and Analyse results

  • Identify deviations from the plan
  • Variances can lead to severe problems
  • The goal is to identify variances as early as possible
  • Use plots, bars, lines, dots, etc. for analyzing trends (more later)
  • Compare the variances towards the planned (allowed) variances


  • Acceptable – continue to monitor
  • Unacceptable – additional action is required
    • Consult personnel
    • Consult expertise
    • Could it generate more problems?
    • Any additional risks?
    • Call for meeting, analyze in groups

Identify root cause and consider options

  • Do not immediately adopt the first identified solution
  • Try to find the optimal solution
  • Analyse side-effects to the different solutions
  • Resources needed?
  • Cost?
  • Time?
  • Need help/decisions from sponsor/stakeholders?

Corrective action and implementation

  • Decide on corrective actions
    • Review options
    • Define success measures if possible
    • Make choices of actions
    • Who decide?
  • Implement
    • How will it be implemented?
    • By whom? When?
    • Who is responsible?

Analyse the results

  • Analyse the results of the corrective actions
  • Compare against the defined measurements
  • If unacceptable result then go to root cause analysis (again)
  • If acceptable close the problem and store into lessons learned
  • Repository of Lessons Learned: Take care of your Best Practices
  • Avoid the situation from re-occurring


  • Different kinds of reports
    • Status reports
    • Progress reports
    • Forecast report
    • Time/Cost report
    • Variance report
    • Presentations
    • Demos

SWOT analysis

  • Strengths and Weaknesses
    • Internal factors
    • Human factors
    • Finances
    • Organisational factors
    • Physical resources
    • Experiences and knowledge
  • Opportunities and Threats
    • Trends
    • New research
    • Funding
    • Competitors
    • Competence
    • Channels (marketing)
  • SWOT analysis
    • Prioritize elements in the analysis
    • Define possible activities
    • Analyse if it is feasible
    • Decide on further management and activities
    • Close down strategic direction if found
    • necessary
    • Keep the SWOT-analysis continuously updated
    • Focus on the prioritized elements

Stakeholder Management

  • Definition of the term stakeholder:
    • An individual
    • A group
    • An organisation
    • who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.
    • Project governance the alignment of the project stakeholders´ needs or objectives
  • Stakeholder can be
    • The sponsor, the one who provides the resources and support
    • Customers and users persons or organisations that will approve and manage the project´s product, service or result.
    • Sellers provides components or services necessary for the project
    • Business partners provides special expertise, e.g. installation, training, support.
  • Example
    • Organizational groups internal groups affected by the project activities
    • Functional managers human resource, financial, accounting, procurement, IT
    • Other stakeholders government experts, subject matter experts, consultants,

Project Cost estimation

  • Budgeting the project
    • Must (always) be approved by management
    • Resources must be allocated based on the estimations
    • Should be connected to the vision and goals
    • Should be supporting to the portfolio and program management
    • Upper management is always (?) relating the project success to its relation to the approved budget
  • Budgeting the project, necessities
    • Shall always be related to the stakeholder requirements
    • You need to have an idea of which resources you have
    • Correct data must be collected
    • Timely reporting
    • Strong focus on resource and cost predictions
    • Confirm approval of changes
    • Consider always changed cost predictions when decisions are taken
    • Consider changed cost predictions when problems occur
    • Estimate changed cost predictions if risks become problems
  • Forecasting
    • What resources will be needed?
    • How much resources will be needed?
    • When will they be needed?
    • How much will the resources cost?
  • The resource cost can be differentiated by
    • Unit, role
    • Individual, level of competence or salary
  • Need to consider
    • Unit (hours, days, weeks, money,…)
    • Level of precision (round up or down)
    • Level of accuracy (range)
    • Links to backlog and stories
    • Threshold (agreed variations, if any)
    • Performance measurement (earned value or story points left)
  • Cost estimation tools and techniques
    1. Expert judgment
    2. Analogous estimation
    3. Parametric estimation
    4. Top-Down estimating
    5. Bottom-Up estimating
    6. Three-Point estimating
    7. Group-decision techniques
    8. Wide-band Delphi technique

User story & story points

  • User story
    • A story is a feature a bit of functionality with some characteristics (non-functional characteristics)
    • Keep the stories simple and as short as possible
    • A story is an agreement between the customer and the supplier
    • It must provide some value to the customer
    • Stories should be independent of each other
    • Stories must be testable
  • Examples
    • As a power user, I can specify files or folders to backup based on file size, date created and date modified.
    • As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.
    • As a consumer, I want shopping cart functionality to easily purchase items online.

Agile and Scrum

  • Agile and Scrum
    • Agile volatile, easy to move, easy to change
    • Scrum start the game over again.
    • Was originally launched as a contrast to plan-driven development
    • The goal is: To produce software more effectively
    • Embrace change
    • Embrace change quickly!
    • The change towards agile is not easy
    • You need to have the organization with you
    • See change as something positive
    • You need to change your mind-set
  • Scrum is
    • a risk reduction mechanism
    • a leaner software process
    • a more adaptive software project management process
    • A framework based on a team´s self-organization, motivation, ownership and pride.

Scrum master

  • Ensuring that Scrum values, practices and rules are used
  • Represents the management and the team to each other
  • Guide and coach the team towards achieving the goals
  • Should protect the team towards outside disturbances
  • Support in keeping track of progress
  • Organize retrospectives to help the team and the organization to learn how to be more effective
  • Enforces immediate decisions needed

7 qualities

  1. In-depth theoretical and practical knowledge about Scrum
  2. Great servant-leadership ability
  3. Strong organizational skills
  4. Great communication skills
  5. Excellent presentation skills
  6. Conflict resolution skills
  7. Great human development skills

Product Owner

  • Guards the product vision
  • Ensure the fulfilment of goals
  • Focus is on delivering business values and results
  • The dependence of a good product owner is high
  • The focus is to control the backlog by working with the stakeholders identified
  • Gather requirements for the backlog
  • Solely controls the backlog
  • Collaborate with the team and the scrum master to do release planning
  • Guide and support the team
  • Keeps himself/herself updated with project progress
  • Are available to the team, give the team feedback
  • Is one person, not a team

7 qualities

  1. Know how to manage stakeholder´s expectations and sometimes their conflicting priorities
  2. Have a clear vision and knowledge of the product
  3. Know how to gather the requirements and turn them into a good product backlog
  4. Be available for the team
  5. Know how to be a good organizer
  6. Know how to communicate better than the average person
  7. Knows that it is all about servant leadership

The Development Team, the Scrum team

  • Self-managed and self-organized
  • Estimate backlog items, stories
  • Turns items, stories into tasks to work on in the Sprints
  • Commits to the sprint goals
  • Keeps track of progress
  • Responsible for Sprint demos
  • The team should solve their internal problems by themselves
  • The team should be small, 7 +- 2 persons
  • Minimize communication interfaces
  • Teams should be cross-functional, including different capabilities
  • Open work environments are to be preferred

Line manager

  • Line management vs. Project management

    | Line management | Project management |
    | ———————————————– | ———————————————- |
    | Managing status quo | Overseeing change |
    | Consistent set of tasks | Changing set of tasks |
    | Responsibility limited to own function | Responsibility for cross-functional activities |
    | Permanent structures | Temporary structures |
    | Maintenance tasks | Innovative tasks |
    | Main task is optimization | Main task is resolution |
    | Success related to achievement of interim tasks | Success related by achievement of end-goals |
    | Limited set of variables | Contains a lot of uncertainties |

Agile Manifesto

  • Individuals and interactions——over processes and tools

  • Working software——over comprehensive documentation

  • Customer collaboration——over contract negotiation

  • Responding to change——over following a plan

Daily Scrum meetings

  • Where the team communicates

  • Approximately 15 minutes, short meetings

  • Stand-up meeting

  • Focus on three things:

    • What has been done since the previous meeting?

    • What are we going to do?

    • What risks and problems exists?

  • Removing obstacles

  • Making necessary decisions

Leadership style, Situational leadership style

Project Manager

  • The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives

Interpersonal skills needed

  • Leadership
  • Team building
  • Motivation
  • Communication
  • Influencing
  • Decision making

  • Political (company and business) awareness

  • Cultural awareness
  • Negotiation
  • Trust building
  • Conflict (healthy and unhealthy) management
  • Coaching

Project evaluation