Project Summaries
When an organization executes a certain number of projects over a period of time, it needs to calculate certain summaries in order to assess the company’s performance.
Some of the metrics that need to be calculated are net effort variance or total effort variance from planned effort. During the project planning phase, a project manager estimates the effort required to complete a task. A task in a software engineering company can be an analysis task or a programming task. So, during the planning phase of the project, the scheduler sets that a specific scheduling task would take a certain number of hours to complete.
When the project is executed, the actual effort is measured (say) and recorded against the planned activity, there may be a variance or a difference between the two values. The same goes for the project schedule. On a related note, the project schedule should be derived from effort and not independently of effort by using independent models for effort and schedule, since schedule is statistically correlated with effort.
When planning the schedule and then measuring the actual, there may be a difference or variance. During some review period, an organization publishes organizational baselines with summary information on effort, schedule variance, and also number of defects occurred, productivity rate, etc.
Care must be taken when calculating (say) the net stress variance, ie not adding up all project variances to get the cumulative variance. To explain why this should not be done, many of these projects may have been running concurrently and many of them may have a common cause of variance, for example if there was a server crash on a particular date, the time Downtime can affect many projects uniformly and can lengthen the time required to complete a task. Adding all these variations without doing a causal analysis will lead to reporting a higher figure. What can be done is to mathematically divide the effort/schedule variance among all the projects that are affected by it.
An analysis of variance should also be performed and checked for false positives or false negatives using hypothesis tests. Stratified sampling should also be used to analyze the net variance. For example, if a group of projects with lower developer skill dominate the metrics, the corresponding scale factors should be applied to each metric obtained from individual projects so that one sampling group does not dominate the others.
In short, the variance obtained after comparing the actual in the project with the plan should be subjected to standard ANOVA tests. Also, the actual value of the variance must be filtered for repeated measurements of the same variance caused in multiple projects.