Right, the 30-day Blitz.  It’s funny; for years getting something done in say a six-to-nine month time frame was thought of as “gee, that’s pretty fast.  I don’t know if I can do that.”  Then this last fall, there was this mind shift... Going around to gee, probably 16 cities, I was sponsored by a company that wanted me to talk to their customers and their prospects about Agile Systems Development.  People in the audience almost in every city started saying, “you know we need to get something done in one to two months, what about that?”  I realized, yes, absolutely, it can be done and then started to realize I’ve got a couple of great case studies doing just that.  I’m doing just that right now with a company out on the West Coast.

What you start to realize is that in every situation, regardless of what it is, there is a handful of significant improvements that can be made in 30 days or less.  Actually, it is finding those and seeing them and then delivering those improvements.  That is what starts to deliver the IT group tons of credibility in the eyes of the customer.

Yes and a lot of people do feel like, well, for heaven's sake does that mean that you want me to cancel my life for 30 days and work like a crazed weasel?  No, that’s not quite it; although there are times when working like a crazed weasel does help, but the point is that it is actually a very rigorous application of what I call the core techniques.  There are six core techniques, and they are joint application design with business people and technical people to pull your ideas.  Secondly, process mapping, whatever style you may use.  Still, the point is you draw out a sequence of workflows that the business people can then make sure you’ve got it correct; and then they can plug in their individual ideas in that workflow for improvements.

Then data modeling once you know what the workflow with the data is passing through that workflow.  Once you’ve got those three things, you can then talk about building a user interface, which is some story board of screens that users can look at and say yes, I like or no, improve that.  Then, you’ve now got something where you can put together some technical architecture on the back end, make sure all that works, and then test it and roll it out.  Now, I take those six core techniques, and I use combinations of those six core techniques in a three-step process that I think many of the people on the call have heard me talk about or read about.  It’s only three because I’m just a regular guy; and I can’t remember more than three things, especially when the going gets tough.

Those three things are Define it, Design it, and Build it.  So, in the definition phase there are a specific set of deliverables.  I say you can do that definition in two days.  Once you know what the definition is, and one of the things that comes out of the definition is an agreement with the business people, to focus on what I call the robust 80 percent solution.  What are the most important things you need to get done?  Then, all agree to we’re going to get something done, significant in 30 days.  So, that actually helps you, not hinders you, because then everyone says all right, okay.  We can’t have scope creep and we really need to focus on what are the most important things; so, in two days you can do that.

I’m working with people right now to make that happen, and then in four to eight days, you can do the design.  That is, flesh out the conceptual system design, create that user interface, test the technical architecture to make sure that your assumptions are valid, and then in six to twelve days you can build what you just designed.  Again, it requires rigorous use of the core techniques and rigorous adherence to the time boxes that you all agree on.  But strangely enough, by agreeing to shorter time boxes instead of larger time boxes, business people will be much more agreeable to focusing on what they want and not adding the continuous new requirements that drive us all crazy with scope creep.

It really is, and there’s an old proverb, and I don’t know which country came up with it; but it’s true in any language.  That is, a voyage of a thousand miles starts with a single step and not just a great leap forward to try to get from here all the way down to the other end of the field in one huge leap.  Although sometimes we like to think that’s possible, I think again and again, those huge leaps are shown to be time-consuming and very risky.  Instead, if you take the approach of breaking that big project into smaller, significant self-contained pieces where each piece delivers value in its own right, that means not just a clump of paper that contains specifications, it means in every case you’re delivering a working subsystem.

The 30-day Blitz really is the opening of a process that could well go on for a year or more.  I’m doing this right now with a national restaurant chain headquartered on the west coast but with restaurants all over the country.  We started something in the summer last year where they wanted to get a better handle on their food supply chain.  We began working with a group of inventory planners, the distributors that deliver the food, and then there are six large food companies across the country that actually make the pastry items and some of the other stuff that they’re tracking.  Again, what we all decided right at the get go was that we would limit what we could do to 30 days.  That focused everyone’s minds, the inventory planners especially, on what do I really want?  They know what they want, you don’t really need to spend a lot of time talking about the “as is” because the people who have been working with that “as is” situation, they know what the issues are, they know what they want.  What we did was we gave them a system that focused on what they wanted; they’d defined about four or five main capabilities that they wanted that would give them visibility in their supply chain.  We delivered it.  They then worked with it for three or four weeks and then came up with a list of new things that they wanted.

Here’s the interesting thing, Jeff, is that the world never, almost never, unfolds in the way you think.  When I look at the world today and I think okay, two, three, four months from now, I know what’s going to be going on,  well, maybe I do; and maybe I don’t.  The other thing is that when you deliver something in 30 days, it’s easier to make a 30-day projection than a six-month projection.  We delivered the stuff that these inventory planners wanted and then, guess what?  Their business changed a little bit, some new products showed up that they hadn’t thought about, some new distributors, things that they had not thought about before suddenly became more important than what they thought they were going to need.  As we launched into the second 30-day Blitz, what they were getting was precisely what they wanted.

Here is what starts to happen is.  IT is seen as someone who delivers something that makes people’s jobs better and does it fast.  You get the credibility, you get the buy in, and you get the time commitment.  We IT people are always saying, “gee, the users don’t give us the time we want to really understand their requirements;” and we forget that it is because they’re busy as heck, just as we are.

Yes, and this is something that I’m almost on a soapbox about; so take me with a grain of salt.  I wrote an article for CIO Magazine.  It was called Show Them the Money, and it came out towards the end of the summer last year.  It basically talked about what I did as a CIO at Network Services to wrap our commodity products with a blanket of tailored value-added services that appealed to individual big customers.  We sold things like, we called them, food service disposables; that means paper cups, plastic forks, and what we affectionally refer to as the “JanSan” bundle, that means janitorial and sanitary supplies.

We’re talking mops, brooms, buckets, floor wax, Windex, so those are products that customers can buy anywhere.  Those are products where the price is fairly well known, so you can’t just arbitrarily raise the price.  Yet, we consistently got a few percent more.  I like to say, when you are responsive to customer expectations, when you really understand what their business model is, you can wrap any product or service and earn an extra two to four percent and sometimes more.  All of those value-added services are information-based.  They all require some serious IT support to make them happen.

Let’s take an example.  How do you get an extra few percent on a paper cup?  Well, how about you work with the people who are using those cups; and sometimes, believe it or not, if you’re working with say a chain restaurant, a fast food outlet, they use food service disposables that have their logo.  Suddenly, the paper cup guy is, guess what, mission critical.  So, any product or service can be mission critical.  Find the customers for your mission critical; work with them.  We worked with them, we worked with their finance people, with their operations people, with their supply chain people.  We wrapped that paper cup with valuable services like usage reporting, updated every day so they could see what the trends were, who was using what products at what locations.

It helped them for budgeting; it helped them for forecasting.  We packaged and labeled those products just so, so that they would fit into certain shelf spaces that they had right near where the checkout counter was.  It was easy to receive them, we bar coded them just the way that they wanted them so the whole receive and put away and retrieval processes were very efficient.  Then when we invoiced them, we invoiced them using whatever electronic format they wanted, whether it was just a flat file, or whether it was EDI or whatever.  We would pre-process the invoices and literally stick in their general ledger codes on each line item so that the whole thing just flowed into their system, and it automatically allocated the cost to wherever it was supposed to go.

Then, the sales guys liked to have me, the IT guy, come out and say during the presentation ... we’d show the folks what we were going to do for them.  We’d get people nodding and smiling.  Then I could say something (It’s just a techie.) that the sales guys did not want to say or couldn’t say.  I would say to the customer, “Hey, you like this stuff.  We know you’re going to lower your cost of use if we do this for you, so don’t beat my sales guys up on the last two to four percent.  That’s the money that I’m going to use to give you all the stuff that I just showed you.”  That sometimes even got them to smile — really tough purchasing directors — [we] got them to smile.

Yes, this happened some years ago; and it’s when I really understood that the 30-day Blitz can happen in any — any is a big word, but I have yet to see the situation where the 30-day Blitz will not deliver value.  At the time, I was a practice director.  I got called in for a company here in Chicago, financial services company, and they delivered commodities trading information to the accounting departments of large trading firms.  What was going on was a multi-million-dollar, multi-year project, to start delivering that information in real time to the accountants at the trading firms.  The accountants were worried that their traders were taking trades that were too risky, and they wanted just to get a better intra-day sense of what was going on.

Yes, a real-time flow of information coming right off the trading floor going right into some super duper systems that do reporting and ad hoc analysis — that was a very cool idea.  Yet, it wasn’t exactly what the accountant said that they wanted; they said it would be great if you could give me that.  When we started to press them, what they really said was, “A real-time data feed isn’t going to do me any good anyway.  If you just gave me the data maybe every 20 minutes or something like that and then gave me some standard reports [There turned out to be about five standard reports and then another 10 or so that were variations on that.] real fast, we would be already well down the road to knowing what’s going on every day on the trading floor.”

This multi-million-dollar project had been going on for more than a year.  As usual, it had gotten off to a fairly good start:  a lot of pep rallies, great bandwagon effect.  Then it bogged down somewhere, and then it created the kind of skepticism that we IT folks have often seen in the eyes of the business people.  While I was trying to figure out how to reorganize and reenergize the big project, I got some funding information to do several weeks’ worth of work to create a system that simply pulled data in a regular FTP batch cycle off the legacy clearing system mainframe, put it into a server based relational database, and then there encrypted it using the PGP algorithm — and you can buy that; that software is literally shareware, which doesn’t reduce its power in any way.

We would then encrypt it coming out of the server database and push it in rotating 20-minute cycles to PCs in the accounting departments of the trading firms.  They would then, literally, pull it into an Access database where we had already preprogrammed a simple user interface and some standard reports.  Most of those guys already knew Access already, and they knew how to take it and do whatever ad hoc work that they wanted.  All kind of simple I guess, but the users were delighted, delighted.  I wrote some Java code, I wrote some dot-Net code; we had it out in 30 days.  The accountants loved it.  It did not change the fact that we continued trying to reorganize, reenergize the big project.  But, what I saw happen was the users began to focus on this, which we had called a pilot, because we didn’t want to confuse people.  They began focusing on that.

They began every couple of weeks giving me a list of, “oh, could you do this and this and this?”  That thing scaled up, and you can think about it...  The architecture that I just mentioned:  it’s scaleable; it’s robust.  So, am I getting on a high horse here, Jeff, or does that make sense?

We’ve all been there somewhere in our careers as we’ve learned the fine art and technique of requirements gathering that you go back for the third and fourth time...  People just start to roll their eyes and say, “For heaven’s sake, haven’t I already told you that,” or “Come back tomorrow, I’m busy,” and tomorrow they’re busy, and they ask you to come back later.  What you wind up doing is, you make your best guess.  In order to keep the project going, you make your best guess.  A collection of best guesses, it’s one thing to make a few best guesses in two or three areas; but when you start making best guesses in five or six or 10 or 20 areas, they compound.  It gets really fuzzy.

So, again by focusing what you are doing, you’re eliminating this hopeless, I think, task of trying to gather requirements for the whole system.  Instead, you’re going to focus in on actually what people want to talk about the most anyway... is their paying points or the areas where they can see the greatest advantage.  They want to talk about that.  All this other stuff, they really don’t want to talk about that.  So focus on that, deliver that, and now you’ve got credibility in their eyes.  They will give you more time.

Connecting with them in shorter periods of time and delivering more frequent results gains their trust and respect for what you are doing and gives you the ability of having access as needed.

So, with that, we are nearing the end of our call.  If anyone on the line listening is interested in the concept of the 30-day Blitz and would like to know what they can do next, what we can do is arrange for a one-on-one call with Michael Hugos to discuss your particular environment and situation and determine what kind of 30-day Blitz would be appropriate to you.  So, in closing, I really would like to thank Michael Hugos for making this time for us today.