I’d like to welcome everyone today to our next interview in the CIO Interview series that we are doing.  My name is Jeff Cohen; I’m CEO and Cofounder of ProcessExchange, and have been moderating these calls.  Today joining us are Michael Hugos, CIO at Large:  Michael has been recognized and received four awards for his work at Network Services since 2003 by CIO Magazine, InformationWeek, and Computerworld.  He’s also an avid writer, author of five books and currently writes columns in both Computerworld and CIO Magazine.  You’ll find his interesting and informative blog on CIO Magazine's website as well.  Welcome to the call, Michael.  Thanks for joining us.

Glad to be here, Jeff.

I think we need to be clear within the IT profession about the kind of process that we’re going to use because what business does care about is, obviously, deliverables; and the faster things change as they do today, the more frequently business is looking for deliverables.  So then the question becomes, for the IT profession, what process are we going to use that meets the expectation that the business has, which is frequent working deliverables.

Unfortunately, Jeff, a lot of times they get involved in what process are they using, or what steps are we going through; and when we work with them, we actually try to focus on not so much what are the steps that they go through but what are the key concepts?  What are the key things that they need to focus on in order to meet the needs?  There are several things that help them when they’re looking to be more agile as, oftentimes in large organizations, again, they get these large processes; and they try to follow them step-by-step.  What ends up happening is they aren’t able to meet business needs because they’re too focused on detail, and detail is what they’re doing rather than what they’re delivering.

Absolutely.  There are a couple of key things that they need to focus on.  One of the mantra that we work with our customers on is frequent, tangible working results, okay?  They’ve got to deliver things, and they have to deliver them frequently.  They can’t wait for the big bang or this huge project because the business doesn’t stop while they’re waiting for the IT systems; they’ve got to deliver frequently.  They also have to deliver the right solution to the right problem, and we’ve talked a little bit about that; when business comes to IT with a problem, oftentimes IT ends up jumping to a solution very quickly, and what they’re solving is a symptom and not the actual problem.  By doing that, they are not meeting the customer’s needs, and then combined with the large process behind it; it doesn’t focus on delivery and incremental results.  Then they get into trouble; and all of a sudden, IT can’t deliver, and they get a black eye and the customer is very unsatisfied.

I think that that’s where the IT person, maybe not necessarily the IT developer but the business analyst, the project leader, that’s where they need to make sure that they are seeing past the symptoms that business is complaining about and really understanding what is the problem and then addressing the problem.  There was an interesting article that CIO Magazine put out last week where they interviewed the CIO of jetBlue, and he was talking about a flight information display system.  The problem was that the monitors in the jetBlue kiosks could no longer hold all the information because the company had grown so quickly; and now there wasn’t enough space on those screens to display the information.

People would complain that the screens aren’t big enough, but that really wasn’t the problem.  The problem was they couldn’t see their flight.  He had two options there.  It would have been a major project to go and retrofit all those kiosks, put in bigger screens, put in systems to drive the bigger screens, increase the power supply, etc., or what he did was he said, “Well, heck, real quick we went out, and we wrote an application that ran on BlackBerrys.”  We grabbed a bunch of BlackBerrys, took them out, handed them out to the jetBlue employees at the reservation desks, and then they could simply scroll up and down, which you couldn’t do on the big display screens, but you could do on the BlackBerrys.  So, if a customer couldn’t find their flight on the display screen, they would obviously go to a jetBlue person at the desk, that person would have a BlackBerry, they could scroll up and down, they could find it, and they could tell them.

Now, that wasn’t the end all and be all, but that was the immediate response, the agile response, to take the pressure off of the need to tell passengers what their flight information was.  Now he bought himself some time while he could go out and look at a more full featured solution.  A lot of times, IT folks forget the short, quick, agile solution and immediately leap to an elaborate, what I like to call gold-plated, atomic-powered baloney slicer, when all I really needed was a penknife to get started.

Mike, one of the things that’s also in that article is the commentary about having three major projects happening at the same time, taking up most of the IT resources…

And they were all long-term projects.

They’re resume-building activities; of course, you want to be on them.

I think a lot of it comes down to compensation, we are amazing creatures.  We tend to do what we’re compensated to do.  Obviously, if a developer is presented with an option of doing some little quick hit projects using some fairly common IT components like BlackBerrys and a little bit of Java code, or a little bit of dot-Net code, and then linking that up to a database, a spreadsheet and a webpage to create a fast deliverable to take some pressure off some immediate problems, that might be one option.  But, then there’s another option.  It’s a three-year project to install this great piece of software, well-known brand name, you put that on your resume, and you know that the headhunters are going start to call etc.  What are you motivated to do?  In that case, you’re obviously going to be motivated to go with the grander scheme that’s going to take a long time.

What if there was a recognition on the part of companies that because you need to do both and actually, believe it or not, I think it requires a lot more innovation and a lot deeper understanding of business to do those continuous quick-hit projects.  That’s much more creative.  You need to compensate the people then who can do that.  Ironically, what happens is that tends to be thought of as oh, well, that’s just like summer intern work; and we’re not going to pay for that; that’s throwaway stuff.  Then what do you get?  You get people going for the longer-term brand name; resume-building projects; and in the meantime, the business is stuck.

It’s a little bit of both, Jeff.  It’s the prestige, it’s the compensation, it’s how we are measured because that is the behavior that we’re going to get because if I get compensated more, both in prestige and dollars and rewards and so forth for working on that big project than the little small one, I don’t get the recognition on the small one.  That’s part of the change in the organization and changing the things and changing what they value.  Rather than, “Gee, we can accomplish the same thing by a series of these small quick-hit projects rather than this huge one that doesn’t deliver for a year and a half.  Oh, by the way, the last year and a half project we had didn’t deliver.  Everybody worked on it; they got the prestige, but the customer wasn’t satisfied.”  It’s changing the mind-set, the measurements by which we’re graded.  Those are the things that an organization has to look at when they want to start focusing on being agile.  They have to start looking at what are some of the obstacles; and one of the big obstacles they have there is how we’re measured and how we’re compensated and the prestige and stuff that goes along with that.

I’ve heard the word agile a few times.  We’re starting to distill down into the notion, I believe, that the three of us have talked about in the past which is you’ve got traditional requirements management and development efforts and methods today; but to be really successful in this world where business and requirements are constantly changing, you’ve got to change the rules.  You can’t do a six-month project all in one iteration.  You’ve got to do it in multiple iterations; and I think, Mike, this is where the notion of the 30-day Blitz that you and I talked about on our last interview really comes into play.  Maybe you can extrapolate some of the concepts that we’ve talked about so far in this call and help our audience understand how that translates into a 30-day deliverable instead of a six-month deliverable.

Let me ask another question, Mike.  We’ve seen this; we’ve talked about this, and this is a very real issue that business has today.  They want their process to include everything.  There’s a mind-set that the business has about what their project needs to be.  They always want it delivered now; obviously, you can’t deliver the robust 110 percent solution in 30 days.  The issue that I think I’m hearing in what you’re talking about and what Mac’s talking about is the business requirements for a project are often really, really big.  IT people come in, in order to develop the project; and if there’s a short timeline, what are the odds of failing in a short period versus the odds of failing over a long period with a big project.  There’s risk associated with that, and I’m curious.  Does that risk translate into compensation, prestige, job security, and those kinds of things?

Let me make sure I understood the question correctly.  In the longer projects, there’s always more risk because risk multiplies; risk is an additive.  I have to do this step, then I have to do that step; I may have to do a sequence of five steps in order to reach a successful conclusion.  The risk of that is multiplying the probabilities of successfully completing each step; and so since all probabilities are somewhere less than one, nothing is a sure bet.  The more sequential steps that have to happen, do the math; the ultimate probability then at the end of step five gets pretty darn low, often lower than 50 percent.  Big surprise.  When you do small things that may only require one or two steps, well, then again, do the math; your probability of success is going to be higher.  If you can build big systems by collections of small things, then your risk has gone down significantly; and you’ve been able to deliver, as Mac was saying, frequent, tangible working results.

We need to think through what that means and how we would change the way we work with the business, and also business needs to think about that and change the sorts of expectations and requests and pressures that they put on IT.  There’s a pervasive tendency in all of us humans to come up with very clever and complex solutions and think that that’s a sign of genius.  I would say complexity is actually a sign of an incompletely solved problem, and the real genius is finding elegantly simple, not simple-minded but elegantly simple, solutions.  That often takes a little bit of thinking.

To quote that same individual, using the KISS method, and that’s not the popular “Keep it simple, Stupid…”

So Mac, you just brought us to the next important segment of our call, which is:  Hey, we’ve identified a problem.  How do you fix it?  How do you get people to change their mind-set so that the problem can be resolved as opposed to continuing to do business as usual?

I think to build on what Mac is saying is, when business people start to see that you really are delivering tangible, working systems every 30 to 60 days, then they start to trust that they don’t have to cram every last thing into that first phase.  They all have been burned; they’ve all been through big projects where if they didn’t get their request into the first phase, there never was a phrase two.  They’re not just going to immediately trust you.  Most people though, will give you the benefit of the doubt if you’re nice and smile, for the first 30 to 60 days.  They’ll say, “All right, all right, all right…  Thirty to 60 days is not a lot of time, so go ahead.  I’ll agree that I only want these three, four or five things; make it happen.”  Then you do make it happen; and lo and behold, you give them those three, four, or five things.  And then, you’re sitting next to them and you’re saying wow, how do you like it?  What else now would you like to add to what I just delivered?  Now, you’re starting to get through to them.

You’re building on success.

In that infinite amount of time, then, there’s no reason to deliver.

We’ve both been there, Michael.

In fact, I’m sure that everybody that’s listening in to this call has been there.  Listen, I want to start wrapping up.  I think that we had a lively and interesting discussion.  It really sounds like the issue that we need to focus on for organizations is helping them change their mind-set to enable IT to take on small projects that can be incrementally improved upon.  Helping a lot of the enterprises that we work with – people that are listening in today – to change the mind-set of their organization from having big, long-term projects to having small, short-term, incremental projects that add up to the big projects, so that IT can deliver tangible working systems in short periods of time.