Archive for the ‘process’ Category

Three Big IT Transformation Mistakes That HP Made

Wednesday, May 13th, 2009
HP's IT Department Made Some BIG Mistakes During Their Transformation

HP's IT Department Made Some BIG Mistakes During Their Transformation

If you made three costly IT mistakes would you admit it? I think that most of us would probably say “no” – we’d run and hide our mistakes under a rock somewhere. However, thankfully over at HP they’ve decided to come clean about a few of the mistakes that they’ve made during their multi-year IT transformation project. We can all learn from their mistakes.

HP’s CIO Randy Mott decided to remake HP’s IT department when he came on board a few years ago. In order to kick the project off, they needed to make some assumptions about how things were operating and move forward.

Chris Murphy over at InformationWeek had a chance to sit down with Randy and ask some questions about where HP’s assumptions were just flat out wrong. What he’s learned holds a lot of information for all of us. Here are the big three:

  1. The Secret World Of IT: When HP decided to remake their world of IT, they had to start the process by finding out how big the IT operations were. They grossly undercounted. Going in they thought that HP was using 3,500 applications to run the business. It turns out that they were using more like 6,000. They knew for sure that they had 85 data centers being used by the business. Ultimately, they ended up discovering more than 400 locations where they had massed computing infrastructure.
    Lesson Learned: take the time to do a complete inventory BEFORE you ever start any sort of IT transformation.
  2. Plan For Growth: It sure would be nice if we could freeze time, make changes to our IT departments, and then start things back up again. HP seems to have thought that they could do this because they didn’t remember to plan for acquisitions to occur during the project. Well, you know how this story goes – HP kept buying up other firms and since there was no IT incorporation plan, it caused big headaches for the IT team that was trying to transform IT.
    Lesson Learned: Create a solid process for bringing in new IT departments to any ongoing projects.
  3. Beware Of Success: Once again, the business keeps moving while IT works on its projects. In this case, HP shot past their growth projections. What this ended up doing was pushing the IT transformation project off of its tracks – data centers that were to be consolidated were suddenly needed because they were supporting unplanned for growth.
    Lesson Learned: Make sure that you have a backup plan that tells you what you are going to do if sales projections change from what has been forecasted.

In the end, HP was successful with their IT transformation and they ended up reducing those 6,000 applications down to about 1,500, reducing those 400 data centers down to 6, etc. However, because of the three mistakes that they made, this difficult job was made just that much harder. Now you know – don’t repeat this mistakes!

Have you ever been surprised to discover that there is a whole “shadow IT” department operating in your business that nobody has ever counted? Has a merger or acquisition ever screwed up one of you IT project’s schedule? Has your IT department ever been surprised by unexpected growth? Leave me a comment and let me know what you are thinking?

IT Work Split: The New 80/20 Rule

Monday, May 11th, 2009
IT Departments Need To Apply The 80/20 Rule To Support Work

IT Departments Need To Apply The 80/20 Rule To Support Work

Pity the poor CIO – he manages a team of professionals that do great work, but he / she rarely gets any credit for a job well done. Why you ask? Well an unfortunate comparison can be made to the maintenance staff that takes care of the building that your work in. It’s great that they keep everything up and working and looking good, but how often do you ever really think about them?

What’s missing here is for CIOs to determine what the right work split is for their team. No matter what we do, there is always going to be some support and maintenance work to be done, but how much is too much?

HP’s CIO Randy Mott was facing this problem when he came on board a few years ago and he’s moved quickly to try to resolve it.

Chris Murphy over at InformationWeek had a chance to sit down with Randy and ask some questions about how he’s gone about getting his team to work on the things that really count.

When Mott first joined HP the IT department was spending about 70% of its time doing support work – keeping the network up, resetting passwords, recovering deleted files, etc. This meant that only 30% of their time was being spent doing things that moved the company forward.

So did Mott do? First he cut his IT payroll almost in half – they went from 19,000 staff (50/50 contractors and employees) down to under 10,000 (90% of which are employees). The thinking here is that if you are just doing support, it really doesn’t matter who doing the job, contractor or employee, as long as it gets done. However, if you are doing mission critical system development, then the person doing the work had better be an employee so that you’ll have continuity.

The way that Mott figured out who to keep and who to let go was by documenting what everyone was doing. Once a week folks would stop and document what they had been working on that week. The thought was that if you don’t have good data on what folks are doing, then you can’t make good decisions about what they SHOULD be doing.

One other key change that HP made is in how they define work. There are only two buckets these days: support or “new development”. No middle ground is permitted so say goodbye to “enhancements”.

In the end, Mott’s been able to get his work split to a 70 / 30 mix. It’s not quite the 80 / 20 that he’s shooting for, but he’s getting close. This approach also allowed Mott to get enough data to be permitted to decommission some popular but high maintenance applications. How many other IT departments wish that they could do that?

What is the work split between support and new development in your department? What would you like it to be? What steps are you taking to reduce the amount of time that your team spends on support activities? Leave me a comment and let me know what you are thinking.

Why Don’t IT Alliances Work Out?

Monday, April 20th, 2009

IT Department Alliances Can Make Everyone Stronger - If They Are Done Correctly

IT Department Alliances Can Make Everyone Stronger - If They Are Done Correctly

You would think that the more alliances that your company / IT department makes with other firms, then the better that they would become at making them. After all, practice makes perfect – doesn’t it? It turns out that this is not always the case.

Koen Heimeriks has spent time studying 200 firms that had formed more than 3,400 alliances. What he has found just might surprise you.

He found that those firms that had the most experience striking up alliances actually had worse results when compared to those firms who had moderate experience.

Why the difference? It turns out that there are two problems that develop in firms that already have  a number of alliances:

  1. they have a tendency to become overconfident in their alliance building skills, and
  2. they can develop learnings about alliances that are in actuality based on unsupported ideas about cause and effect.

So what can make an IT department’s alliance with another firm actually work out well? It turns out that it’s the methods and procedures that the firm uses to create alliances that will determine their eventual success. Established firms that already have many alliances will probably have rigid and inflexible business processes for making decisions and selecting partners.

However, IT departments with fewer existing alliances will have more flexibility built into their processes. An example of this would be where employees who have worked on previous alliances share information with the employees who are trying to create a new alliance. This type of discussion can lead to experimentation and allows novel approaches to each alliance opportunity.

So in the end, what does all of this lead to? Heimeriks reports that the larger firms who had many alliances and a more rigid alliance creation process had an alliance success rate of around 50%. Those firms that had fewer alliances and a more flexible alliance creation process had an alliance success rate of around 71%. Sure looks like flexible processes are the key to successful IT alliances!

Does your IT department have any alliances with outside firms? Would you say that you have a lot or a few of these alliances? Are they generally successful or not so successful? Do you feel that your alliance creation processes are fixed or flexible? Leave me a comment and let me know what you are thinking.