This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Friday, August 20, 2004
You Get What You Measure -- Another recent thread of conversation in the agileprojectmanagement discussion group is about measuring the productivity of programmers. Folks who have been in the productivity biz for a while really get it, as shown in this IndustryWeek article...
"There's no right or wrong way to measure productivity," says Roger Schroeder, professor of operations management at the University of Minnesota's Carlson School of Management. It's a favorite factory-level metric because it's perceived to be within management's control. If sales drop, output will go down; but if inputs are reduced, productivity can still be high.
As a real indicator of performance though, productivity alone is not enough. Schroeder notes that many productivity calculations presume quality is constant. Output is output. Better quality, which is certainly better from the customer's point of view, won't show up in a standard productivity measure. Product complexity changes also are difficult to account for.
"Productivity doesn't consider whether you deliver on time or not. It doesn't consider flexibility. It doesn't consider lead time. It's more of cost measure," says Schroeder.
And when one tries to apply metrics like productivity to individuals when the real value comes from the synergies of a team working together, plus the actual usability of the resulting system, one is bound to get distortions related to trying to make the numbers look good.
posted by Frank - Permanent Link -
|
View Frank Patrick's profile
