When you’re talking about IT Asset Management, and especially when you talk about Software License Management, it won’t take long before the conversation turns to ‘tools.’

In fact - that’s one of the quickest ‘ITAM maturity checks’ for an organization - do they think of ITAM as being about an ‘asset discovery tool’ or suite? or do they understand that a tool is only part of the solution?
Reminds me of an old gag about IT and tools:

Q. Why do IT organizations evaluate alternative technologies?
A. Because they don’t know what else to do.

If that’s a little painful for you - you’re not alone.

Being technologists, we tend to seek a technical solution to every business problem. And business today demands that we solve the problem (implement the solution) as fast as possible.

The problem of course, is when we ONLY define and implement a technical solution, and ignore or don’t pay enough attention/ time / effort to things like business / IT alignment, process standardization, and control objectives (to name only a few of many).

So, if you’re stuck in a conversation with management about asset discovery tools, what should you really be looking for? What questions should you be asking, and what plans should you be making?

• Ask “why?” before we ask “what?” or “how?” Sometimes the answer is “we don’t know why we’re doing this” which leads to the next point:
• Define the bigger reasons behind this project and align with those as your benchmarks
• Define “what happens next” Meaning: “assuming we achieve these goals, how do we keep the data current, learn from the information, change and enforce the new practices and policies, leverage the information for even more business value?”

Many companies will confuse the “why?” with “ROI” This is dangerous because it’s only part of the reason that companies (senior executives) do things.

More about this next week.

Hey - did you flinch when you saw the Q and A above? Send me a note and tell me why!

—–

As mentioned last week, I’d like to share our approach to framing challenges so we can deliver business value. Best of all, it is not too hard to do, gives a good rounded view of the issues, and gives you a way to checkpoint your value delivered.

What is the 5 x 5 approach? It is a method of looking at a need from 5 apertures, and looking at the returns projected from 5 bases of value. It reflects the fact that our clients are large, complex organizations, and the work we do crosses many parts of the organization. Here are the 5 apertures we use–

1) Strategic / Business Alignment - does this initiative align with the CEO’s and CIO’s top initiatives for the year ahead? If so how? if not how might it? How does it effectively support a system or effort that does align?

2) Organizational / Roles and Responsibilities - How does this affect the organization? What consensus do we need to build? What is our plan for doing so? How will we market the plan and approach to get support? How do we find and leverage the best practices that already exist in our company? How do we determine the IT governance impact? What is federated(required) and what can be decided locally? What are the roles and responsibilities needed across the company? Who will fill them, how much time will it take, and what training or skills might they need to be able to deliver? What processes will we establish to ensure periodic reviews of the effectiveness of this area?

3) Standards / Governance - What are the appropriate outside standards that should guide us? What are best practices that should guide us? What alignment is required with internal standards? our enterprise architecture, our IT governance model, our project management process, quality practices like 6 Sigma, financial accountability like Balanced Scorecard? What parts of outside standards like CMM, CoBIT, ITIL, and Sarbanes-Oxley are important and / or add value in our business? What parts can we ignore? How do we combine multiple standards that might apply into a logical framework? What emerging trends / standards should we consider and watch in our strategy? What process will we establish to ensure periodic reviews of the effectiveness of this area?

4) Policy / Process (PP) - What are our current PP in place regarding this area? Do they vary by the different component areas of IT? Are they in conflict? How are they enforced today? How do we codify the strategic, organizational, and standards goals in the planning for the new policy approach? Are there proven best practices in policy management that exist in the company today in this area? How do we get policy consensus across the silos of IT? What if any process baseline exists in our company today? How do we control process development to prevent over-engineering? How will we ‘test’ process design before making it operational? What mechanisms ( functionality that ensures a high degree of compliance with a minimum of management) can we put in place to ensure an high degree of adoption quickly after we go live with the new system? How will we ‘market’ the new system internally to drive adoption, and uncover those who are resisting or struggling with the change? What are the key reporting / management metrics will we want to determine that policy and process are being followed? What process will we establish to ensure periodic reviews of the effectiveness of this area?

5) Technology - What core technical functionality is required? What technology do we already own that can be leveraged for a good solution? Are there What functionality must be added? Can we additional technology from current vendors to solve the problem, thereby not having to add another vendor, development environment, new skills, etc to our current complexity? How much additional integration needs to be developed and maintained for the solution? Are the gains worth the increased cost and complexity to our environment? Are all of the considered vendors well established in the market or the market leader? Will their technology be relevant in five years, or do they have a track record of effectively staying current? Are they developing for companies of our size and complexity, or are they trying to address the whole market with one size fits all? Do they understand our business problem and can they articulate it though proven solutions in current customers?

This works well for us. What works for you? Do you have other ideas that have helped you establish and maintain strategic value in your projects? I welcome your feedback.

—–

Welcome back!

Let’s continue chatting about enquiries (requests) and then provide a brief example of an ITIL enquiry in action.

If you look at the ITIL diagrams that the ITSMF (http://www.itsmf.com) assembled, you’ll see 10 ITIL process boxes, a bunch of reports & stuff, plus a CMDB. However, in its current incarnation, ITIL doesn’t have a separate process for Request Management as it does, for instance, with Incident Management.

Perhaps the reason is that requests (or queries) really are implicit throughout the model. In a way, enquiries are the reason that most of the boxes exist in the first place - especially on the Service Delivery side of the model. After all, it should be obvious that IT can’t only be about fixing service outages - IT has to add value by handling customer requests for value-added services! It’s a supply-demand thing.

Here’s one small example from the real world.

A manager who works in one of my client’s IT departments stopped-by my desk this week to ask “what ITIL would say” in response to one of his internal customers, who had approached him with a request. Seems that the customer had asked the manager to modify his incident management software so that the customer could use multiple types of incident closure codes (other that just “incident closed”), and also add another custom field in which they could track a “reason code” for the closure.

Good idea? Not? What would ITIL say? Should we modify the incident management software to satisfy the customer? Or should we leave the program unmodified and think of another way? What does ITIL require in terms of incident closure procedure and nomenclature? What would you have recommended to the manager if you were in my place?

Stay with this blog to find out what happened next!

Thanks for reading — more to come soon.

—–

We know that frameworks like ITIL are just a guideline for how IT work should get done. It’s great that the British government and many others have finally codified what anyone who has worked in IT for a few years already knows.

Even so, it can be difficult to understand how ITIL should work in our daily IT life. Furthermore, ITIL doesn’t cover everything IT does - it’s got some important gaps, which can affect how we put ITIL into action.

Do you know what ITIL’s weaknesses are? Share your thoughts!

Anyway, now that we’ve kicked-off the discussion, let’s look at a recent example from daily life:

A large IT organization we know is struggling with understanding the impact of the large number of service requests they receive on a monthly basis. Their organization has perhaps 8 different ways that a request for service might be received, analyzed, processed and tracked. Is this a good situation or a bad one? What would ITIL say? Should the situation be improved? Can it be?

Well, if you have studied ITIL, you know that the model proposes two types of events: Incidents and Enquiries. Incidents are generally defined as interruptions to one or more defined IT services. What’s an “Enquiry” then? Why doesn’t the ITIL model have a specific process for Request Management as it does for the Change and Release processes?

We’ll continue the story in our next entry. In the meantime, I’d enjoy hearing your thoughts on this issue. Jump right in!

—–

As ITIL has gained momentum more and more focus is being placed on IT service management as a business value add as opposed to a necessary evil (cost). Additionally, government regulations, such as CoBIT and Sarbanes Oxley, imposed in the wake of corporate financial scandals have made certain processes within the realm of IT Service Management mandatory. These changes have made the traditional helpdesk critical to the success of an organization.

Most organizations at this point have at least heard of ITIL and understand its premise. Many of these organizations are scrambling to get their staff trained on ITIL and ITIL implemented. ITIL is a framework and set guidelines for the implementation of IT Service Management processes. IT Service Management seeks to provide quality IT services at a reasonable cost. At the foundation of IT Service Management is a process for continuous improvement.

IT Service Management is a broad topic that covers many interrelated processes. I have worked as a consultant, implementer, and project manager providing Service Management solutions of over 7 years but like many have just begun to study ITIL. I am recently ITIL certified and hope to couple my vast experience with the ITIL concepts to continue to help organizations implement Service Management in such a way that it provides value to the company.

I welcome your input and questions on any of the Service Management disciplines and will happily share my opinions with you based on my experiences. The intent of this blog is to provide a forum for sharing thoughts and posing questions related to building business value through IT Service Management.

—–

Welcome!!! What is the Business Value of IT? Does it matter to us? Why? Is it impossible to effectively capture? Can strategic value be measured? While Evergreen focuses on improving IT operations in large complex organizations, these questions matter for any IT undertaking. These are the kinds of issues and discussions this Blog is all about.

IT projects need to produce business results. So how do we go about it?

We believe it can be done - but it takes thinking, and it’s hard work. Henry Ford said, “thinking is the hardest work there is, that’s why so few engage in it.” But, thinking can be made easier, with a little structure to the process.

Evergreen uses a process we call 5 by 5 to focus on solving the problem(s) and delivering business value in projects. It helps us structure thinking, while still keeping things simple enough to focus on what matters.

High level questions first.

• Why are we doing this? What problem(s) are we trying to solve?
• What happens if we do nothing?
• Does this align with key strategic activities? If not, how might it? How might it provide critical support to an activity which is strategic?
• What are potential gains?
• Are there reasons why this MUST be done? What are they? What will happen if we do nothing? If there is no strategic benefit, what is the least we can do to meet the needs?

What are your thoughts? How do you answer these questions in your organization? What additional up front questions are important to you? Have you ever worked on a project without clear goals? Without effective planning up front? What happened?

I welcome your comments, and look forward to a continuing dialogue.

—–

Howdy, welcome to the IT Asset Management / Software license management blog.

So why are you here? Tell me what’s on your mind.

Until then, I’ll tell you why we’re starting this blog:

IT Asset Management and Software License Management are REALLY HARD.

Even if you can get beyond the 8 million possible tools (desktop inventory, software discovery, remote control, asset management suites, software metering and usage, on and on), you still have to deal with the DATA. Spreadsheets. Purchase orders. Vendor part numbers. Licensing terms. Contracts. People. Org Charts. Help Desk tickets.

And then you realize that if you’re really going to do this right, you’re going to need some CHANGE in the organization (Uh-oh!).

And oh by the way, where’s the ROI? How do we get there? How do we PROVE IT?

So, this blog is about HOW and WHY, not so much WHAT.

Plus some battle stories you might get a kick out of. Sad Stories of Pitiful Mistakes with Multi-million Dollar Consequences. And if you’re lucky, a few useful tips and best practices in implementing IT Asset Management and Software License Management.

So, who am I? Thanks for asking. The name’s Scott Braden. I’ve been in the IT world for about 15 years now, in various places. But the last 10 years have been focused on IT Operations in big companies. So I’ve worked on massive desktop refresh projects, helped negotiate over 500 software volume license contracts, ran a pretty large outsourced help desk, PM’d all kinds of small and large projects, and have experienced the in’s and out’s of asset and software management up close.

So, what’s your story? Send me a note.

—–