Measure What Really Matters

I ran across a very interesting op-ed by Tim Jackson on productivity today in the New York Times. The gist of his well-articulated argument is that due to our relentless drive for increased output, certain professions and their attendant tasks become negatively skewed because production and output are more important than outcomes. He cited medical practice and teaching as examples, and I believe that we can add enterprise, data, and solution architecture and project management to the mix.

His article and viewpoints resonated with me because over the past few years I have witnessed multiple incidents where enterprise, data, and solution architecture work was 'commoditized' by management and/or project leadership and results measured primarily by how much output (regardless of quality or usefulness) was produced in a defined timeframe. For example, I was a member of a project team designing a data warehouse where progress on the data model was measured by how many tables and table attributes were produced from business analysis documents per day - as opposed to examining this output with respect to it's clarity and usefulness to the database administrators and developers on the project team.

What the project manager failed to realize with respect to this effort is that there are multiple ways to judge the quality, usability, and completeness of a physical data model - the primary ones are correctly building and linking the model to the accepted/approved business analysis, adequate and correct linkage of related tables, ability of the physical model to be implemented in a database, and correct types and size of data. There are others, but these are the basics.

Instead this individual chose, incorrectly, to measure progress only by how many corresponding tables and table attributes were created in a given time frame. This led to an 'assembly line' mentality on the project where the project manager evaluated and treated the team akin to factory workers putting bolts into car frames as they pass by on the line. Not only was he not getting a true picture of where the deliverables stood at any point in time, but he introduced substantial risk on the project with respect to the quality and usefulness of the data architecture and models because he was only measuring gross output, not context or quality of the deliverables.

When this happens, astute project team members know how to play the game: if they are only going to be measured on gross output of work in defined time frames, and not completeness and quality, they'll simply produce as much crap as can be inserted into documents, spreadsheets, or modeling tools and they will meet expectations. Apply these 'methods' to software developers, and what is usually generated is lots of lines of code, but the developed 'system' may not work or have severe performance issues. Of course, it's going to matter later that such crap is flawed and perhaps unusable, but hey, they did meet mandated performance targets right?

Knowledge work cannot be managed, much less optimized on such crude and misleading metrics. While project timelines and deadlines certainly matter, there is a degree of subjectivity in knowledge work that cannot be adequately planned in advance, much less successfully evaluated with crude, misleading, and incorrect output metrics. Does your physician talk rapidly or ignore your comments during your examination, perhaps thinking about his patient load that day or some other issue unrelated to your care? How about your attorney, accountant, or dentist? Fredrick Taylor-style 'productivity' metrics when applied to such situations not only do not work, but they often severely impair real solutions and progress, in addition to being 'gamed' by astute project team members that adjust their work and output to what is being 'measured' with quality and usefulness of the work outputs being, in most cases, damned.

Knowledge worker outputs matter in terms of eventual positive results and outcomes moving projects forward, not in the measurement of minutiae per time increment.

 

 

Comments

[Miya]

Interesting post.Thanks for sharing your thoughts about this!

[ulkoistaminen]

I want to convey my love for your personal kind-heartedness providing assistance to people that really require help with your articles. Your commitment to finding the perfect solution all-around continues to be extremely worthwhile and has now definitely persuaded colleagues exactly like myself to start their particular ambitions. A new fascinating standard suggests a great deal to me personally and many more to my workers in offices. Appreciate it!Let me know by email or just comment/contact me on my website, if you would like. Regards, Carisa Heaphy

[Philadelphia custom sportswear]

--The regime is like a blown piston in a car's motor wreaking complete havoc upon everything it touches.

[dj and south bay dj and south bay wedding dj]

I love this site.so cool looking this site

[Best Project Management in the Philippines]

I have enjoyed reading through your post. You have a very good point on the article you have read. Looking to read more of your posts!

[garcinia cambogia reviews]

Hi there very nice web site!! Man .. Excellent .. Amazing .. I will bookmark your site and take the feeds additionally? I am satisfied to seek out a lot of useful information right here within the submit, we want develop extra techniques on this regard, thank you for sharing. . . . . .