Not much work getting done this week on account of our moving cities. Sounds more dramatic than it really is… at least in terms of the actual distance of the move. For some folks, not familiar with the US’s East Coast “megalopolis” that runs from Boston to Richmod, VA (some say it doesn’t go farther south than Washington, DC), it may sound odd to say we’re “moving cities” when we’re really only about 37 miles (59km) from our previous home. Practically speaking, we could have moved the same distance in almost any other direction of the compass and we would have still been in the Washington, DC suburbs. In any case, we’ve moved from the suburbs of DC to the suburbs of Baltimore (Maryland) for many reasons, though dominated by the proximity of our new home to family.

So here we are, amidst a floatilla of boxes, trying to find our stuff. Thanks to the less-than-spritely response time of the ‘big iron’ dominant phone power of the region, my voice/data lines don’t get installed until the 30th… Right now I’m ‘borrowing’ bandwidth from a neighbor’s entirely unsecured wireless access point. ;^>

I might write about the ordeal of moving, or the games being played by the he-was-being-such-a-jerk-it-was-all-I-could-do-to-not-hit-him buyer’s real estate agent on the day of moving/closing/settling…. maybe I’ll write something about a funny exchange between my mom and me about our differences in how we value planning vs. priorities vs. rework… but what I hope to do is to find an Agile CMMI thread to this week’s events and write about them.

Someday.

I would probably need to find the humor in all the week’s stress before that happens.

Stay tuned.

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.

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.