Much of the theory behind modern project management has been developed in an effort to mitigate out of control budgets and schedules that have plagued large scale engineering programs over the years. Nevertheless the problems don’t seem to go away. It is still rare that a project really nails the schedule, budget, scope and quality parameters.

By collecting, analyzing and using measurement data, software project managers are more able to have visibility into and control over their projects. Measures and the metrics that can be derived from them allow the managers to determine the status of their programs, track the project's progress against the plan, measure the quality of the product being developed, and become aware of potential problems. Using software project metrics can allow managers to have objective information which helps them make everyday decisions necessary to run their projects. Collecting this data also helps them by providing the basis for possibly improved estimates for future projects.

If the true situation were known and risk management matrix is available earlier, program managers would often be able to take appropriate action and bring things under control again. But it is unfortunate that most project teams continue to spend most of their time naively managing schedule projections with Gantt charts and just assume that budget, scope and quality will remain in an acceptable range.

GANTT charts – the biggest liars in any project team?
One of the main issues is that Gantt charts often take on more importance that they deserve and there is a blind reliance on the schedule information that they present. Moreover, experience shows that Gantt charts often track a program’s delays after they occur rather than predicting an accurate finish date from project inception. Generally there is a “hockey stick” curve as initial optimism fades and the reality of back end schedule compression starts to bite.

The reasons behind this are complicated and varied but often the fundamental problems shared by most projects in trouble from a schedule standpoint are:

• Gantt charts are only concerned with schedules and do not take into account any of the other project disciplines such as resource management, quality control, budget management etc
• Information is collated and entered by leaders rather than the troops who are really doing the work. Often there is poor communication of the real status upwards which leads to overly optimistic schedules.
• People are often unwilling to admit that they are behind to an open forum. They assume that they can pick up the pace behind the scenes and no-one need ever know.
• Roll-up of sub tasks into tasks and beyond is often poorly handled with critical dependencies remaining unclear until it is too late
• Risk management is usually poorly executed and mitigation plans are put into effect after the risk has turned into reality.

The shortcomings have nothing to do with Gantt charts as a management tool, but rather the manner in which they are often used. The reality is that they are only as good as the information which is put into them. The method of harvesting of that information from the project team is crucial in establishing the validity of the schedule data.

Metrics – a balanced view
Although the principles of metrics can be applied to more or less any program type, a good example can be shown in the software industry. For many years software project metrics were used exclusively as a quality control mechanism. Software testing metrics and software defect metrics were mainly used to track process improvement initiatives and were often considered a fit-criteria of customer requirements. Even today risk management metric charts are usually only viewed from a top level as a business case metric while individual risk items are tracked in a risk management matrix to activate individual mitigation strategies.

However in recent years much attention has been placed on extracting information about software project health from various project metrics. By applying the result into the overall schedule to test the sanity of the data far more confidence can be gained that the project goals will indeed be met. Much of the data is lateral information which tends to identify more critical items and influence the early activation of mitigation plans, alternate solutions, extra resources or re/de-scoping of the program.

The nature and type of software testing metrics and software defect metrics are often proscribed by a methodology or process model. Many of the items collected can be of extreme value in determining ancillary information about the project’s health – in many cases by comparing with historical values for similar projects. In typical programs software testing metrics such as fault coverage can give powerful indicators of test-plan status. Software defect metrics can give a strong trending indication as to the stability of a release if viewed against the normalized bell curve displayed by most projects. Risk management metrics – especially risk management metric charts can be used to compare against other programs at that point in the project lifecycle.

The gateway to project Peripheral Vision: Compound Metrics
One of the most exciting things to come out of modern project tools is the ability to analyze trends based on compound metrics. Since new generations of collaborative working environment (CWE) platforms allow teams to capture all manner of project artifacts in a single system, it becomes possible for the first time to monitor trends derived from multiple artifacts.  In the old models project managers would simply track concepts such as summarized risk probabilities over time in a risk management matrix. However a more insightful measurement system would also take into account the number of meetings being held per week where a specific risk item was discussed, the number of action items that are associated with it over time, the number of other projects facing similar issues or any other aspect that anyone would care to inquire after. Compound metrics are just what the name implies – groups of data extracted from multiple sources which give a clearer view of project status on demand.