News

Michael Spandau of Fender Musical Instruments: Keeping IT in tune with the business

Michael Spandau is Chief Information Officer and Senior Vice President for Global Information Technology for Fender Musical Instruments and a member of the W. P. Carey School's Department of Information Systems Professional Advisory Board. KnowIT caught up with him after his thought-provoking presentation at the Arizona Chapter of the Society for Information Management.

2011-04-14

First published in KnowIT, April 2011

Michael Spandau is Chief Information Officer and Senior Vice President for Global Information Technology for Fender Musical Instruments and a member of the W. P. Carey School's Department of Information Systems Professional Advisory Board. KnowIT caught up with him after his thought-provoking presentation at the Arizona Chapter of the Society for Information Management. His topic was the way the Fender measures key performance indicators, and how the iconic guitar maker has applied the agile methodology to IT projects. The common thread? Fender has altered the traditional approach to information technology, closely aligning IT with the business. (19: 13)

Listen Here

Spandau: Your question is related to the 'house of brands,' and first of all, I think it's interesting to know that Fender has more than 20 brands out there, some of them being EVH, Gretsch, Squier, Charvel, and SWR. So how do we support these many brands? Well, from an IT perspective, we are organized by functions, which would be supply chain versus manufacturing versus sales versus HR. So the IT organization supports those functions. From a web presence point of view, we make sure that we support the individual brands as such and build websites that cater towards the individual needs of the different brands. But again, from an IT perspective, it's primarily supported by function.

Knowledge: I know that you've developed a strategy of measuring key performance indicators monthly. Can you give us an overview of what you're measuring and why, and how is this data used?

Spandau: Yeah, so Liz it might be helpful first to quickly explain how we are configured here internally. I have an infrastructure team reporting to me, applications teams, a security team and a program management team. We track key performance indicators on a monthly basis for each of these teams. So a document gets created on a monthly basis — on infrastructure versus applications versus security versus program management. I'm a very strong believer that we are a service organization to an organization that builds the best guitars and amplifiers in the world. This is not about IT. IT is a critical enabler but no more, no less. So it's absolutely critical to me that we make sure that we provide the service that the organization is expecting — they expect that email and phone and all the other systems are working. It really comes down to that. So how do we do this? We provide these services. We have the key performance indicators that tell us how well we are performing on a monthly basis. What we look at specifically is system up-times. We look at network utilization. We look at SAN utilization. We look at viruses. We look at financials, obviously. It's more on the infrastructure side, on the application side. What we try to do is correlate certain IT observations with business outcomes.

Specifically, for example, what we do is we monitor open purchase orders, and try to correlate that with certain business events. We monitor invoicing or lockbox processing, and again correlate that to business events. The advantage this has is we forced an environment within IT, which is strongly aligned with the business. So the IT professionals here at Fender have a very, very good understanding of what's happening on the business side, because they're being measured, and they track these key performance indicators that on one side are IT relevant, but on the other side are extremely application relevant.

Knowledge: How are these key performance indicators identified?

Spandau: Good question. That's more evolution than anything else. It took us, I would say, about three years to get to where we are today. We are constantly finding them. There are certain things that we drop off. There are certain things that we add. It's an evolution. As the business evolves, we evolve, and there are certain things we thought in the past were more important, and it turns out they are less important. There are certain things that are just less relevant, and we change them and adjust them.

Knowledge: So you say that IT here is a service to support the business side, so is that a conversation with the business side to decide what's important to measure?

Spandau: It's, yeah it's a constant conversation. It happens all the time. It kind of comes naturally. We don't necessarily sit down with the business and say well tell us what you're KPIs are. The business kind of, in my mind, has a difficult time articulating that, and I would argue that it's really not necessary for IT professionals to be told what the KPI's are. I've an expectation that within the IT organization, we understand the business well enough to figure out what these KPI's are. We tell the business what we're monitoring, and in most cases they're completely aligned.

Knowledge: Recently you were a guest speaker at the Phoenix chapter of the Society of Information Management, and a discussion ensued on managing big IT implementations. You expressed something about the way these projects are often managed, and that it's almost like a locked process. I think you said something about how these projects need to be managed a little bit differently so that the users are engaged with the IT department as they go along. The thing that occurred to me was that there's almost a clock speed in IT — are you suggesting that there are adjustments that are going to be made? Or is there a difference in the way your profession will be dealing with other functional areas of the business? What do you think?

Spandau: Liz, a great question that is really near and dear to me. I would say, as most other IT professionals, I was educated based on with the waterfall methodology.  We do things in phases. There's the initial planning, and then there's blueprinting and there's the construction phase, and there is the go-live phase, and then the stipulation phase, and then we kind of hand it over to the business. It's all well spec'ed out. We tell the business this is going to take, whatever, nine to 24 months, and we lock in the scope. We also give notice to the business, and if they were to change anything in scope, then all the timelines are off, and the budget is off and what have you.

I fundamentally believe that we need to change that as IT professionals, and the business is not any more willing to wait for nine to 24 months. A — They need a solution now. B — I would argue that it's very, very difficult for anyone, even the best project managers, to be sketching out plans that go beyond three to six months. I mean, how do you define project plans and budgets and resource requirements and locking in scope over a duration that goes beyond six months? I think that's extremely difficult to do.

Knowledge: Especially now as dynamic as business conditions are.

Spandau: Exactly. The third thing is — what's interesting is that when it comes to these types of projects, IT professionals try to cover every need that's out there. We look for the 120 percent solution. What's interesting is the business is not asking for the 120 percent solution. They would actually go with the 70 percent solution if they were to get the …

Knowledge: Interesting.

Spandau: … if they were to get the solution tomorrow. The other thing I would argue is, if you think about the other functions — supply chain and manufacturing and sales — they don't reserve the right to deliver something over 9 to 24 months. If a finance person were to state it would take them several months to close the books, it would be completely unacceptable. The question is, how can we change this with an IT? And this is really where the agile methodology can help. Agile is based on the premise that waterfall is something of the past, and you deliver components in scrum cycles, and a scrum cycle could be two weeks or four weeks. You define scope within two to four-week increments, and you deliver that in two to four-week increments, which requires multiple things — or which has multiple advantages. First of all, you're delivering on a monthly basis or bi-weekly basis; b) the business gets these results immediately; c) the business gets to change them …

Knowledge: Right.

Spandau: … every single time you deliver a certain scrum cycle. Indeed you're much better aligned, so the business knows exactly what we're working on. We implemented this here on our e-commerce site, and it has fundamentally changed how we deliver things, how we react to changing demands and requirements, how we interact with the business. We don't have — we have hardly any people here anymore running with large-scale Microsoft project plans. That is something of the past because again, we are planning things in these well-defined short scrum cycles.

Knowledge: Instead of implementing a fait accompli, if you will, a finished thing, it sounds to me like what you're doing is evolving the solution slowly as you go — or not slowly, but in time increments.

Spandau: We're building things in increments. We're building things incrementally. Now, of course, there are certain projects, or large-scale projects, that cannot be delivered in two weeks or four weeks. That's impossible, but what I would argue is that's not necessary. Even during the construction phase, we can deliver as an IT organization deliverables in these well-defined, small phases. Even if they do not get pushed into production, they get pushed into development or into the quality assurance systems where the business can go out there and start testing them.

Knowledge: I see. Yeah.

Spandau: Again, the big advantage this has is you're not in this very long development mode where the business gets to see the final product after 12 months and decides that's not really what they wanted. But you can take these course corrections as you go, which is a fundamental different way of delivering IT projects. Now there are people who say this really only applies to web development, because that kind of makes sense. It's a fast-changing environment, and you want to be agile and nimble and fast. However, we are using this now also in other areas such as infrastructure where we spin out a new phone system or new computing systems. We're using this agile approach in every function within the IT organization, and our research and development department is actually looking at it now very closely, too, when it comes to product introductions. I would actually argue that this is a methodology that you could be applied to any function of an organization.

Knowledge: I'm wondering how does this fit with the employees that you have?

Spandau: Interesting question. What does it take to switch from a waterfall methodology to an agile methodology? I've read studies where it's been stated that only 50 percent of your employees are willing to make that switch and the risk by implementing agile is that you lose the majority, or a large percentage, of your employees. We haven't experienced that. I will say that initially the switch was somewhat difficult because what fundamentally changes is that the employees have a need to be delivering a product every scrum cycle. So every two to four weeks, they have to report back …

Knowledge: A deadline!

Spandau: … on a deadline, and have to deliver — which is very, very different from the waterfall methodology where you just deliver with the majority of the work (at the end of the project). You have two to three weeks before 'go live.' That does change fundamentally and making that switch is difficult. The other thing where we had difficulties is — and this is true for waterfall methodology too, but it becomes more apparent with agile — is the estimation of work effort. I would argue as IT organizations, we don't do a good job in estimating work effort. We always tend to underestimate.

Knowledge: Exactly, and so do your clients I bet.

Spandau: Same thing, it becomes obviously much more apparent in these scrum cycles because now for every scrum cycle we estimate work.

Knowledge: Right.

Spandau: Initially I would say we underestimated by at least 50 percent if not more, but the team &mdash since we have been doing this now for several years now — has become much more knowledgeable about how to better estimate their work. One of the other challenges we have is that we don't have dedicated teams here at Fender that just focus on development versus upkeep of system. The team is required to do two things at the same time: develop new solutions while they're supporting existing solutions. When it comes to capacity assessments, there's a lot of discussions about utilization and capacity, which is good because now we have a much better understanding how much time people really have to work on new projects versus keeping existing systems up and running which is a by-product of the agile methodology.

Knowledge: Right, right, and it seems to me like you could get in a whole lot more trouble if you were working on that 9- to 24-month deadline versus touching base and adjusting in small steps along the way.

Spandau: Absolutely. I mean you just said it very well. The stakes are so much higher to deliver a product that really works after having worked for 9 to 24 months. I mean you're betting on the outcome of that project, because I mean that's all you have been working on. Whereas, when it comes to agile methodology you're constantly fine-tuning and adjusting the progress of the project.

Knowledge: But that goal is still out there …

Spandau: The goal is the same, but again what it really comes down to at the end of the day, under waterfall methodology, IT tends to develop the 150 percent solution. The business is not asking for the 150 percent solution. They're looking for the 70 percent solution tomorrow. They want to have it as quickly as possible. It's very difficult for them to build on a solution that will only be delivered sometime in the future. I mean that has very little business value to them.

Knowledge: Right. Right.

Spandau: Waterfall methodology probably has its place for certain projects, but I would argue that the agile methodology is something that most IT organizations should be looking at. It's a tool that responds to the flex, the fast pace of the business, of the economy we're in. The business is not willing anymore to wait for IT to get a critical component. They want it now. They want it immediately, and they are looking for business partners on the IT side that are much more agile and nimble and fast moving and adjusting — versus an organization, I would argue, where they're being locked into a certain project, into a certain scope, where they cannot make any changes. I would think that is something of the past.

Knowledge: It also sounds like it would be a much more interesting, engaging career to be in.

Spandau: Absolutely, we want to be aligned with the business. We want to be seen as true business partners. How do we get there? Not by locking in the business …

Knowledge: Right.

Spandau: … into some functional scope and project scope and timeline, but developing and forming and creating an environment that reacts and can keep up with the business as it changes.

Knowledge: Great! Well thank you very much for spending some time with me today.

Spandau: Thank you Liz.

KnowIT Managing IT Career development