In most good consulting approaches, they start by pointing out that the way to effectively change something is to first measure it. If you can't measure it, how will you know it changed? By how much? For what reason?
Being able to measure is a cornerstone of any good management approach. It's the cornerstone of the quantified self movement which is built around the premise that once you measure something, being able to change or maintain becomes much easier.
With software and technology, this is no different. When it comes to the application lifecycle the ability to measure is just as necessary. Unfortunately, ALM tends to evolve at a fairly slow pace. While there are pockets of innovation, true change only happens inside big, slow, enterprises that are typically not being managed by the most *cough* technically astute. As such, they might ask for measurements but this largely for show. If you don't understand what you are measuring, how relevant can the measure be?
The gents over and McKinsey took a swipe at this in a recent article:
http://www.mckinsey.com/Insights/Business_Technology/Enhancing_the_efficiency_and_effectiveness_of_application_development?cid=other-eml-alt-mip-mck-oth-1308
While I think just substituting Use Case Points as the answer to how to measure is an easy thing to propose, it is certainly not the only or most obvious choice for addressing this significant need. The article does, however, break down the aspects of the problem and exposes some of the challenges that have created the situation in the first place. It is a good contextual read and likely to provide at least one uncommon perspective on something we take for granted but shouldn't. Definitely give it a read.
Being able to measure is a cornerstone of any good management approach. It's the cornerstone of the quantified self movement which is built around the premise that once you measure something, being able to change or maintain becomes much easier.
With software and technology, this is no different. When it comes to the application lifecycle the ability to measure is just as necessary. Unfortunately, ALM tends to evolve at a fairly slow pace. While there are pockets of innovation, true change only happens inside big, slow, enterprises that are typically not being managed by the most *cough* technically astute. As such, they might ask for measurements but this largely for show. If you don't understand what you are measuring, how relevant can the measure be?
The gents over and McKinsey took a swipe at this in a recent article:
http://www.mckinsey.com/Insights/Business_Technology/Enhancing_the_efficiency_and_effectiveness_of_application_development?cid=other-eml-alt-mip-mck-oth-1308
While I think just substituting Use Case Points as the answer to how to measure is an easy thing to propose, it is certainly not the only or most obvious choice for addressing this significant need. The article does, however, break down the aspects of the problem and exposes some of the challenges that have created the situation in the first place. It is a good contextual read and likely to provide at least one uncommon perspective on something we take for granted but shouldn't. Definitely give it a read.
