Subject: Using metrics to monitor software projects

Author: By Lawrence Oliva
Summary:
This article provides you details on metrics at project level in general
Theme:
“ Using inaccurate metrics to manage a project budget of $20,000 per day (or more) often leads to a significant project recovery situation.”
Using metrics to monitor projects is not a new concept to project managers. The builders of the pyramids used metrics to monitor and report progress (cubits of earth moved, stones placed, resources needed, etc.) Today's software project managers measure lines of code completed, bugs repaired, and engineering productivity using Web 2.0 tools. The concepts -- working to schedule and budget -- remain the same after thousands of years.
However, it is important for metrics to support your project and not just be a bottomless pit for data collection and weekly presentation. If currently used metrics are not driving your team's time, energy, and skill set mix towards achieving project success, it's time to select a new set of measurements.
One problem PMs encounter is selecting the most applicable measuring tools or standards from the vast number of potential metrics available, including earned value, cost budgets, Gantt charts with baselines, PERT charts, risk registers, network diagrams, function points, lines of code (LOC), bug counts, use case points, conditional complexity, time to repair, and time to fail. Working your way through this list can be daunting, especially if your client or management doesn't see the value of using (or paying for) metrics. Each project has its unique issues, constraints, and deliverables. Taking extra time to evaluate which metrics are best to use is a smart PM investment.
My advice is to select two metrics that are most relevant to your manager, two that are relevant to your team, and two that are relevant to you. Selecting a few appropriate metrics and frequently updating the data is a far more effective use of your limited time. Many PMs find metrics usually provide valuable reference information for estimating future project resources and schedules.
Metrics don't need to be stated on bar charts or have multiple pretty colors. But they do need to be accurate. Using inaccurate metrics to manage a project budget of $20,000 per day (or more) often leads to a significant project recovery situation. Many PMs don't survive a project that needs a 50% budget increase to recover from internal mistakes the PM should have caught.
Which metrics are most useful to software PMs? I would suggest these six:
For management: Earned value and Gantt charts. These metrics provide good information on overall schedule, budget, and project movement in graphical formats, clearly showing progress to date and work left to complete.
For the project team: LOC and bug counts. These metrics show daily or weekly progress made by team members as needed to achieve schedule milestones and how many defects are occurring "in-process."
For the project manager: Conditional complexity and use case points. These metrics illuminate potential areas for additional (or different) resources, programming tools, or time. Knowing when and where these problems may arise helps the PM minimize their potential impact to the project.
Successful software project management has always been a combination of delivering what clients said they wanted combined with exceeding expectations. Metrics enable a PM to achieve what is traditionally expected -– completing on time and on budget -– while providing the opportunity to impress management, promote the project team's talents, and surprise the world. Just like the pyramid builders!

End of document