Application-developmen-Infographic-icoSee the difference optimization makes. Info-Tech’s World Class Operations workshop on Application Development is helping IT organizations address the biggest challenges to successful application development. These include:

  • Projects experience cost and budget overruns and fail to meet key requirements.
  • Process bottlenecks slow down development unnecessarily.
  • New technologies significantly challenge existing processes, contributing to process breakdown.
  • QA is focused on the wrong bugs. Issues that should have been solved during development are added to the QA workload.
  • Software requirements continually change and developers can’t keep pace.
  • Communication between the business and IT is infrequent and unclear.

That last item, communication, is critical but you need something worthwhile to communicate. Good communications is a means to get the business involved in good design, good development practices, and good testing practices. See our Application Development infographic below. Click on the image to see the full size version. From there you can also go to our full workshop page.

Application-developmen-Infographic

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter
Darin Stahl
Darin Stahl
Principal Consulting Analyst
Info-Tech Research Group

A Business Continuity Plan (BCP) is a complex project that touches all aspects of the organization, and yet often has few or no dedicated resources. It’s work that you hope to get done in between other projects, or at home at night after the kids go to bed. It’s no surprise so many organizations struggle with BCP.

Please join me and subject matter experts on Thursday, April 24, at 4 p.m. EDT for a webinar “Developing a Business Continuity Plan: Should it be IT or the Business?” Project ownership is just one of the challenges of Business Continuity Planning we’ll be discussing in this webinar.

Go here to register for this Webinar
(Video replay will be available at this link after the event)

Info-Tech Research Group webinars occur during the early weeks of our research projects. Attendees will weigh-in on several key polls and will be able to pose questions to the group.We want to work closely with our members and potential members as we build out our research to ensure we are thoroughly meeting your needs.

 

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

If you chargeback for IT, ensure that customer choices can actually save them and you money.

IT departments are increasingly being challenged to provide financial transparency and demonstrate IT’s value. In general, willingness to spend money to buy services is considered a reflection of perceived value, the conventional supply and demand equation. If a department spends $100,000 on a new application, the assumption is that the system will provide at least $100,000 of value.

The challenge is that in most organizations the cost of services is not visible, and, more significantly, the decision to consume IT resources typically has no financial repercussions on the consuming department.

I don’t normally recommend a complex chargeback mechanism for IT expenses. The data collection and allocation process typically takes significant effort for IT. And while the costs of IT may be more transparent, the re-charged departments can do little to change what IT costs them. There is generally no relationship between actual usage and chargebacks. The process achieves little in the way of cost-reduction or demand management. It is a tax more than a manageable expense to the consuming departments.

But we do want to reduce or increase usage when it makes financial sense to the business. So here’s a thought about chargeback approaches.

  1. Identify IT services that are candidates for direct chargeback. They must meet the following criteria:
    1. They are optional for the user department (for example, enabling an employee to access a design tool, or providing an employee with a higher performance laptop). If they are compulsory, the business unit has no opportunity to reduce demand.
    2. The cost of the service to IT varies somewhat in proportion to the number of subscriptions (for example, a per named user charge for software licensing, or the purchase of an additional device). If this is not the case, reduced consumption may have little impact on overall organizational costs.
    3. The total cost of the service is material to the IT budget. Don’t bother with lower cost services.
  2. Modify the current IT chargeback formula to reflect two components. First, establish variable charges for services that meet the criteria above. The charges should enable IT to offset the real costs for the service. Second, establish fixed re-charges for services that don’t meet the criteria above. A typical re-charge is based on number of departmental users or end-user devices supported.
  3. If appropriate, document the costs that constitute the shared component. But don’t waste time on a granular chargeback mechanism for services over which the business units have no control, or whose costs are fixed in the near term regardless of usage.

The result allows the business units to make decisions on the usage of at least some IT services based on their value relative to cost. And IT can avoid investing in tracking mechanisms where the information provides no incentive for reducing overall organizational IT costs.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

riskMetrics can be incredibly valuable, but also incredibly easy to get wrong. Of the plethora of available IT metrics, risk metrics are probably the most difficult to get right. This is mainly due to the fact that risk is tricky to define and therefore tough to measure.

You Can’t Manage What You Can’t Measure

Defining the word ‘risk’ itself is actually quite simple. In a nutshell, risk is the probability/likelihood of a negative event occurring multiplied by the magnitude of the impact/loss that could happen as a result of said event. Sounds easy enough, right? Not so fast…

Risk must be measured in a way that is meaningful to the organization. A good risk metric demands that you aggregate numerous measurements in order to create a piece of intelligence that’s actually useful to both IT and the business. As I mentioned in an earlier blog post on root cause analysis, accurate measurement means asking the right questions:

  1. What problem is the risk metric addressing?
  2. Which decision point(s) does the risk metric support?
  3. What context should the metric take into account?

Issues arise when these questions are not rigorously applied to each and every risk metric under consideration for deployment.

Metric Overboard!

The inclusion or exclusion of certain loss events (say, an asteroid wiping out your data center) are going to determine whether or not the risk metric itself has any meaning. Take the example of using a very basic risk formula to help flesh out which precautions should be taken in the IT disaster recovery plan:

% chance of loss event x $ loss magnitude

Sure, a meteor strike would probably have the highest dollar cost in terms of magnitude, but the likelihood of such an event is about as close to zero as you can get without falling in. I’m oversimplifying for dramatic effect here, but I hope you can see that such a risk metric utterly fails to take into account the three questions about problem, decision, and context.

Choosing Metrics That Matter

Here are a few takeaways to think about as you plan risk metrics for your organization.

1. Always consider your audience. Metrics for risk are high-level enough that they are probably being communicated to executives and others of that ilk. At lower levels, it’s all about IT managers and domain-specific professionals or support staff. Meet with these stakeholders on a regular basis to understand which metrics are the most important to them. For example:

audience type

2. Determine the suitability of each risk metric. This is where the three questions come into play. Once you’ve settled on the audience you’re delivering metrics reporting to, apply the questions accordingly. Let’s use security performance trends as an example:

  • Problem – how to determine effectiveness of the security program
  • Decision – whether or not to continue with certain program elements
  • Context – executives believe it’s just as important to measure failures

3. Tie risk metrics back to business objectives. Business objectives could include maximizing IT investments, using risk management to adapt to changing regulations, or a host of other business concerns. Whatever the objectives are, your risk metrics are going to be rendered useless if they’re not aligned with corporate strategic initiatives.

Obviously there’s a lot more to risk metrics than what I’ve talked about here. Please refer to the links below for more in-depth guidance.

Related Info-Tech Resources

 

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

LEAN_PDCALean IT, the extension of lean manufacturing principles to the development of IT products and services, is a good approach IT process improvement. But care must be taken not to go overboard force fitting manufacturing process improvement methodology into IT.

Lean manufacturing principles have been around for more than half a century but the application to IT is relatively recent. The central focus of Lean IT is the elimination of waste – work that adds no value to a product or service. Anything that requires rework or slows down decision making is “Waste” and a bug or an incident is a “Defect”.

Info-Tech recently engaged a client in a World Class Operations IT Strategy workshop (see infographic below). They were getting into Lean IT in a big way. Though Lean IT wasn’t the focus of the workshop, here are some of my observations:

  1. Frameworks such as COBIT and ITIL would identify improvement areas within an IT department, and Lean would provide the methodology on how to close the gaps. Lean doesn’t do an assessment on, say, Change Management or Disaster Recovery practices. For example, routine maintenance/upgrades/patches would follow a PDCA (Plan-Do-Check-Act) cycle, with formal documentation at each step in the cycle.
  2. Lean comes to us from manufacturing, so the terminology and thought process is all designed to drive out waste and defects. In my view it seemed to be a bit of a stretch how industrial concepts were being applied in IT, but this was early days of Lean for this client. A lot of Japanese words thrown around, of course (if you want to come across as any kind of expert) such as Muda (waste), Kaizen (improvement), and Kanban (high efficiency production methodology).
  3. IT organization design and staff seating arrangements follows their core workflows and frequency of touchpoints. If an application specialist is frequently contacted by the Service Desk, the specialist will likely sit in the neighbouring cube, not with the other application specialists.
  4. Lean IT is all about ideas being shared from all directions (especially from the levels closest to the work) and requires a motivated IT team to truly get the benefits of the “philosophy”. With this specific client, it wasn’t the case, and Lean IT initiatives were often seen as more paperwork and/or rework.
  5. There are some neat tools that Lean prescribes, some of which may be useful in Root Cause Analysis or Post-Implementation Reviews. “5 Whys”, etc.
  6. On a darker note, Lean IT is usually driven by a corporate Lean initiative, and as with religion, the corporate group may have concerns about any discussion about other framework orthodoxies such as ITIL or COBIT. I actually had to get the Lean group’s blessing that COBIT wasn’t saying anything disagreeable to Lean. This was to the point that the final deliverable had to be scrubbed of most references to COBIT (and always mitigated by statements on how COBIT is merely complementary to Lean).

All in all, I found Lean IT to be a useful approach to process improvement. But care should be taken to not make it the One True Religion. If an organization appoints a Lean Czar at the executive level, going down the path of (6) above becomes likely, which may actually apply blinkers/filters to the IT group’s view of the world.

For more on Info-Tech’s World Class Operations IT Strategy project and workshop click on the infographic below:

IT-Strategy-withfooter-edited_blog

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter