General discussion

Locked

Project Management Metrics

By sajidkhan ·
What are the commonly used metircs for managing software development projects through Contractors if the contract is based on Time and Material and is not a fixed price contract.
I have heard of things like schedule variance, first time right, defect density etc. But all this would be good for a fixed price contract. What good be a good metric for contract, where I pay based on the effort put in by the contractor and how do i ensure that the effort is the right effort.
thanks

This conversation is currently closed to new comments.

5 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

by Snow rabbit In reply to Project Management Metric ...

When you decide to pay based on effort I think there is no metric except hours spent. As you mention time and material but not fixed price my opinion is that you need to measure the following:
- quality of the products
- real progress to prevent 80% finished in 20% of the time and the remaining 20% finished ... never?
Hope this helps you on your way.

Collapse -

by DC_GUY In reply to Project Management Metric ...

Contracts written that way are always in danger of going wrong. I would never hire a contractor on that basis. After all, you wouldn't give your own staff a project with no due date and agree to pay them for as long as they keep working. Why would you do that with a contractor, who has even less accountability to you?

Collapse -

by SridharPandu In reply to Project Management Metric ...

Depends on the phase of the projects. It hardly makes a diference whether its a fixed or a time and material basis. A project is a project. A SEI CMM L 5 company captures the following.

Pre Proposal Stage - Effort, schedule, Cost
Proposal - Effort, schedule, Cost after restimation and and determine variance from Preproposal stage
Contract - Effort, schedule, Cost after restimation and and determine variance from Preproposal stage
Requirements - No of usecases / functionality; No. of requirements added or subtracted
Analyis and Design - defect density per thousand FP, root causes
Construction - defect density per thousand FP, root causes, leakage from earlier phases.
System Testing - defect density per thousand FP, root causes, leakage from earlier phases.

In addition you would also capture the cost of quality (arrived from the other construction, prevetion costs), effort slippage and schedule slippage in each phase, lessons learnt, risks and mitigation plans and perform causal (not casual) analysis, plot histograms.

Collapse -

by jtheires In reply to Project Management Metric ...

In addition to the other comments, I would suggest one of the efficiency metrics available. The traditional lines of code per person-month is helpful, but can be misleading. QSM's Productivity Index (PI) is good, and backed up with thousands of historical data points. Requirements delivered per labor-hour (assuming you track code back to requirements).
All of these efficiency (in fact, all quantitative) metrics assume you know what values/trends indicate good or bad levels/trends.
If nothing else, simple variance analysis (plan versus actual) at periodic and strategic points in the project can illuminate how the contract is progressing.

Regards,
James T. Heires, PMP
President
James Heires Consulting, Inc.
Home of EZ-Metrix code counting utility
www.ezmetrix.com

Collapse -

by jtheires In reply to Project Management Metric ...

First, get an estimate of the amount of code to be delivered to satisfy your requirements. This can be done using various units, but source lines of code (SLOC) is good (if defined first), since the collection of SLOC can be automated, in order to track actual contractor status. SLOC should be accompanied by some measure that equates to functionality, however, since you don't want to encourage your contractor to simply deliver lots of code - you want your requirements met. If you have good documented requirements, I suggest counting requirements before coding begins (e.g., paragraphs, pages, use cases, etc) and tracking code back to requirements as code is delivered and verified. When all requirements are satisfied with code, the software development part of the project is complete.
On a T&M contract, you will also have to worry about how much effort is being charged to your project. Normalizing effort with SLOC can give you an indication of efficiency (e.g., SLOC per person month). However, be careful with this measure, because if you apply it to an individual developer, it could backfire on you by sending the message that you want lots of code. A better efficiency measure is Productivity Index (PI), developed by Larry Putnam of QSM, but this is a more advanced metric, and could be more difficult to implement.
Obviously, there is more to managing a software project than this, but from a metrics standpoint, this should help.
Regards,
James T. Heires, PMP
President
James Heires Consulting, Inc.
Home of EZ-Metrix code couting utility
http://www.ez-metrix.com

Back to IT Employment Forum
5 total posts (Page 1 of 1)  

Related Discussions

Related Forums