My colleague and friend Mike Gualtieri wrote a really interesting blog the other day titled "Agile Software Is A Cop-Out; Here's What's Next." While I am not going to discuss the great conclusions and "next practices" of software (SW) development Mike suggests in that blog, I do want to focus on the assumption he makes about using working SW as a measurement of Agile.
I am currently researching that area and investigating how organizations actually measure the value of Agile SW development (business and IT value). And I am finding that, while organizations aim to deliver working SW, they also define value metrics to measure progress and much more:
Cycle time (e.g., from concept to production);
Business value (from number of times a feature is used by clients to impact on sales revenue, etc.);
Productivity metrics (such as burndown velocity, number of features deployed versus estimated); and last but not least
Quality metrics (such as defects per sprint/release, etc.).
Is it a blog? Is it a musing (that’s not “amusing”)? Or is it just a cheap attempt to pick the brains of others smarter than myself? Does it matter? Can I do anything other than ask questions?
My point (or at least my line of thinking while I plan a couple of ITIL-related Forrester reports) is that we spend a lot of time talking about what to do (or more likely what not to do) when "adopting ITIL," but how often do we talk about whether we have been successful in applying the concepts of ITIL, the processes, and the enabling technology for business benefit?
Maybe it is because we quote the mantra that “ITIL is a journey” and we can’t see a point in time where we can stop and reflect on our achievements (or lack of)? Maybe we segue too quickly from the ITIL-technology adoption project into the firefighting realities of real-world IT service management? Whatever the potential barriers to taking stock, where is that statement that describes what we have achieved and our relative level of success?
Looking at this logically (fatal mistake, I know), assuming (potentially a big assumption) that there was a business case for the “ITIL adoption project” where is the post implementation review (PIR)? Where can we look to see the realization of business benefits (I deliberately didn’t say “IT benefits” BTW)? I’m trying not to be cynical but, even if we forget the formalities of a PIR, how many I&O organizations can quantify the benefits achieved through ITIL adoption? More importantly what has been achieved relative to the potential for achievement? Where did we get to in our desired-future-state?
Help mummy, that horrible man is talking about finance again.
I jest, but I very nearly titled this blog “Warning: This Blog Is About IT Financial Management And ITIL.” Sorry, but this is how I feel sometimes when I talk about the financial side of IT management, IT service management, and ITIL adoption.
But remember, accountants are supposedly boring not scary. The really scary thing is that IT infrastructure and operations (I&O) organizations have survived for so long without really appreciating what it costs to deliver their IT services.
There is no denying that I&O organizations have always “done finance” in some shape or form. There is not a single business function, IT or otherwise, in any organization that can escape the need for some semblance of financial management and the scrutiny from the formal finance department. So my question to I&O execs is not “Are you doing IT financial management?” but rather “How mature is your IT financial management?”
The changing business and IT landscapes are bringing an end to a somewhat slapdash approach to managing I&O’s finances and investment and usher in the need to extend IT financial management to encapsulate the concept of value. Read on, Macduff.
Why haven’t I&O execs focused on maturing their IT financial management practices?
The IT infrastructure and operations (I&O) organization is no different from any other business function. It employs a multitude of assets to create corporate value. Traditionally, however, I&O’s ability to manage its IT assets has been weak, from both a financial control and an IT asset life-cycle (ITALM) perspective.
Far too often, an I&O organization lacks the necessary controls to avoid IT wastage or remain compliant with software licensing or regulatory requirements. Thankfully (or unfortunately), to date most I&O organizations have been able to get by. But the-times-they-are-a-changing, as do-more-with-less efficiency mandates are prioritized, vendor software audits increase, and the business places greater focus on what IT costs and the value that internal IT delivers. Something has got to give and I&O leaders can step up their game and respond to these internal and external pressures by improving asset management processes to ensure that IT assets are leveraged to maximize the value generated for their parent business.