Software Project Management – Series on has published a series of Software Project Management webinars on their site. These are the direct links to the webinars.

Software Project Management Series (Session 1): Projects Simplified

Software Project Management Series (Session 2): Project Risk Management

Software Project Management Series (Session 3): Agile Project Management – Paradigm Shift of Generation X Project Management

Software Project Management Series (Session 4): Trends in Project Management and Its Future

Software Project Management Series (Session 5): Prince2 Vs PMP: Are you in a Dilemma?

Software Project Management Series (Session 6): Critical Success Factors for Managing Global Projects

Software Project Management Series (Session 7): Effective Project Scheduling Techniques and Best Practices

Software Project Management Series (Session 8): Leadership of Global PMO to Meet Global Challenges

Software Project Management Series (Session 9): Project Estimation – Techniques, Challenges and Best Practices

Software Project Management Series (Session 10): Metric Program for Release Predictability and Assessing the Project Health

Software Project Management Series (Session 11): Stakeholder Management Mindset in Managing Communications in Modern Times

Calculating Schedule Variance and Effort Variance

Which part of Project status reporting is a challenge for you?

View Results

Loading ... Loading ...

Schedule variance and effort variance are the values which the corporate management wants to see in a project. This will help them analyse the performance of the project. Variance calculation is trickier but is very easy.

Basic inputs are derived from the task planner or the task tracking sheet. This is the sheet that you maintain within the WBS. WBS has tasks and their respective start date and end dates which are estimated in the project initiation phase. Project Manager or team members have to update this sheet regularly with the actual dates when the task was done, as well as the hours spent on each task. These values form the basis for the variance calculation.

Schedule Variance

Now that you have estimated start and end dates of a task and the actual start and end dates of a particular task, it is time to calculate the variance. The difference between these estimated end date and actual end date becomes the Schedule Variance.

For example, if a task is estimated from 22-Feb-2016 to 27-Feb-2016 (6 days), but the task was actually performed between 24-Feb-2016 to 3-Mar-2016 (8 days), the  variance is 4 days, since the dependent tasks are pushed by 4 days each. This calculation is for individual tasks. For deriving final variance we have to consider the project estimated end date and the actual end date.

It may also happen that a task was delayed by X days, but the overall project end date did not change. In such case the Schedule variance is zero.

Effort Variance

This is determined by the difference between the estimated efforts in hours and the actual hours spent.

For example, if a task is estimated as 56 hours and the actual hours are 78 hours, the variation is 56-78 = 22 hours. Now this 22 hours is converted to percentage.  56hrs = 100%, so 78hrs = 139%. So calculated variance percentage is 39% for a particular task.

Effort  variance will be calculated on the totals. i.e. total estimated hours of all the tasks and total actual hours of the tasks. Then difference is calculated and that becomes your Effort variance.

Schedule and Effort variances can be calculated for sprints, milestones and most of the time, for the complete project.

Let me know your thoughts in the comments below.

General project documentation required

Project documents include but are not limited to the following:

  1. Source Code
  2. SRS documents. For all the new requirements, Service Provider shall conduct a detailed system study and update the SRS documents.
  3. HLD documents (including but not limited to)
    1.  Application architecture documents
    2. ER diagrams and other data modelling documents
    3. Logical and physical database design
    4. Data dictionary and data definitions
    5. Application component design including component deployment views, control flows, etc.
  4. LLD documents (including but not limited to
    1.  Application flows and logic including pseudo code
    2. GUI design (screen design, navigation, etc.)
  5. Test Plans and Reports
  6. Requirements Traceability Matrix
  7. Issue Logs