MA in T&M
Well, while profit (or "programmatics") is (are) the most "key" of business performance indicators when the contract is T&M, it turns out that there are valuable process metrics even in that scenario.
Admittedly, there's a small (and arguably fictitious) loop-hole in the MA (Measurement and Analysis) process area in CMMI. In brief, the MA process area expects companies to identify business goals and to find metrics from their practices that provide valuable business analysis / intelligence to further those goals. Whether those metrics provide insight into process improvement or only into programmatics is the potential loop hole. We can discuss that another time.
I'd considered the 'incentive' aspect as Wayne points out, but that's a matter for those who fashion the contract. Collecting metrics on or even influencing the contracts decision might be beyond the powers of most process improvement practitioners. -- Though I would say that in an ideal world, executives making contract decisions would be doing so with an eye towards their process improvement efforts and more than just profit, but let's be real. Those types of executives are far fewer than the kind the rest of us work with.
Back to our scenario... A common metric is estimates to actuals, but when the estimate is feature/functions, not time or budget, this becomes somewhat problematic, right? And, when the developer is using Scrum to manage development their ability to spend their allocated budget and deliver a product the client is happy with is pretty good.
What can we still learn from estimates to actuals on functions even when it's a seemingly feature-poor process metric? How about giving management data that tells them they can go and sell more business without increasing staff? E.g., "we so (over)|(under)-estimated what we could do that we could have (broken this up into several $20k jobs) | (sold more time during this period of performance)", etc.
Try that on.
posted by Hillel @ 15:58
2 Comments
Links to this post
2 Comments:
I'm going to ignore the T&M/FFP and contractor dynamics and propose some questions with suggested Scrum metrics.
Do we have the correct staff size? If we take the Scurm Product Backlog and track the estimated time to complete, we should be able to determine if the staff size is correct. If the time to complete is constantly growing, we are understaffed and if it is contantly shrinking, we are overstaffed. If the Product Backlog is too large, we may want to be overstaffed to bring it down to a reasonable level. I also propose that we do not want the Product Backlog to go to zero; this implies either staff sitting around doing nothing or that staff are being boiunced among various development/maintenance efforts. I think a control chart of the estimated time to complete the Product Backlog could give this information. I believe we would want the lower control limit to run at zero.
What is our software quality? I think we could track quality based on the number of helpdesk calls. This may need to be raw number, number per user, number per active user; though I suspect that with a control chart run for an adequate period of time that the qualifiers may not be necessary. As multiple things may affect quantity of calls to the helpdesk, this will be an indirect metric; significant changes would have to be investigated to determine the route causes.
I hope these might qualify as alternatives to estimated versus actual, and I suspect these metrics may come closer to providing "business value" than any Earned Value mechanism.
These are excellent alternatives!
My example of 'estimates vs. actuals' was specifically picked because when companies are first getting started with CMMI, this is the metric they most often choose.
Once they're good at Scrum, they can do a better job of deriving the metrics you've suggested.
In the case I was drawing the example from, the developer was new at *both* CMMI *AND* Scrum, and so they're rather process/method 'immature' all around.
Post a Comment
Links to this post:
Create a Link
<< Home