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.