Bob and Greg discuss IT project success, squirrels, and what executive sponsorship really means.
I first learned about Bob Lewis’s column and books from a direct report staff member, Clark Swinehart (RIP). I think Clark saw some gaps in my knowledge, and was politely trying to educate me to be an effective leader in our profession. Bob’s work has been incredibly influential in my own work, and many will testify that they have received one of Bob’s books from me.
Bob Lewis, Author of “There is no such thing as an IT Project”
Since the 1996 launch of his “IS Survival Guide” column in InfoWorld, Bob Lewis has been an iconoclast in the echo chamber of same-old same old commentary about business and IT strategy, tactics, operations, and leadership. His unique blend of vision, pragmatism and sardonic humor have made him one of the most trusted and independent voices in the field.
The award-winning author of twelve books and more than 1,700 columns, Mr. Lewis held a wide variety of executive, management and staff positions before becoming a consultant – he did the work before advising about the work.
Mr. Lewis posts a weekly column (he refuses to call it a blog) at www.issurvivor.com, along with occasional guest columns on CIO.com.
Transcript
Greg Mader: [00:00:00]
Today, I’m speaking with Bob Lewis author of the “Keep the Joint Running”, and “IS Survival Guide” columns. He’s the author of 12 books and over 1700 columns. His latest book is “There’s no such thing as an IT Project: A Handbook for Intentional Business Change”. I love this book. There’s certainly some ideas I want to talk about from this book, but everything Bob’s written, I found to be incredibly valuable. So thank you for being on today.
Bob Lewis: [00:00:31]
No, my pleasure. Thanks for inviting me.
Greg Mader: [00:00:33]
The question I ask everybody is what’s your favorite snack food?
Bob Lewis: [00:00:38]
Malted milk balls. Is there any other possible candidates? Really?
Greg Mader: [00:00:42]
That’s interesting. A particular brand, Whoppers, some other brand?
Bob Lewis: [00:00:48]
Well, actually there’s a local store here in the Twin cities area, called “We are Nuts” and they do a dark chocolate covered malted milk ball. I have no idea where they manufacture the things, but they were fantastic.
Greg Mader: [00:01:04]
My wife was once attacked by a squirrel in the winter at the University of Minnesota campus, while she was eating malted milk balls. The squirrel was in a desperate situation and wanted those malted milk balls more than my wife did. So, she threw them to the ground, and ran away. So that connects malted milk balls with Minnesota.
Bob Lewis: [00:01:25]
Well, thank you for sharing that.
Greg Mader: [00:01:28]
I’d be remiss if I did not include that. Ronda listens to these.
Bob Lewis: [00:01:34]
I hope she was able to replace the malted milk balls and wasn’t too badly injured by the assault squirrel.
Greg Mader: [00:01:40]
Yes, she’s good there. Tell me a little bit about how you got to this place in your career, Bob.
Bob Lewis: [00:01:46]
I don’t have the faintest idea. It just, I woke up one day and here I was. The “how did I get here?” Way back when, I was a little bit frustrated with the company I was working for. They were on their 37th management fad and counting, and I’d been sent to seminars on every one of those fads. And so I wrote a book titled Total Quality for Cement Heads, which I then sent to various publishers, all of whom had a very similar response, “Love the book. Who are you and why would anybody want to read anything you have to say?” And so that book got withdrawn, but a lot of the ideas behind it stayed with me.
So the key to my success, way, way back when was that I subscribed to CompuServe. This was back pre-internet. It’s the least popular internet. And my frustration with CompuServe was that I had nobody to send an email to and back then email was, like, for the cool kids or at least the cool nerds.
And I was also an InfoWorld subscriber and InfoWorld had a guest column at the time called “Peer to Peer.” And the way you submitted a guest column was by email and they had a CompuServe address. So I wrote a piece that assaulted the Gartner Group’s total cost of ownership formulation, and they printed it under the inflammatory headline “Lies, Damned Lies, Statistics, Something Funny with Gartner Numbers.” And Gartner challenged me to debate them, which I did at their annual symposium and hilarity ensued and somehow or other it ran into a career.
Greg Mader: [00:03:41]
It’s interesting. Actually doing homework and having an opinion based on homework seems to actually be relevant now more than ever. You maybe pioneered a bit of that for the rest of us.
Bob Lewis: [00:03:54]
What a scary thought that is. I’ve always thought that my approach to this was to do just enough research to be vaguely credible, but mostly I’m guilty of what I accuse everybody else, which is using research as a source for ammunition instead of illumination. And I try to avoid that, but it’s very hard to do, but I do at least enough research that there’s some basis for at least many of the things that I write.
Greg: [00:04:26]
I’m going to jump a little bit to what I think the outcome of some of your work leads to, this idea of the culture of honest inquiry. And as I was rereading your latest book, one of the things that really stood out to me, was the idea that you start with the decision process, not a decision.
A good friend of mine named George actually has a very similar idea. You don’t have to trust the individuals, if you have a process that you can trust. So how did you stumble on this and where does this fit?
Bob Lewis: [00:04:58]
I stumbled onto this, and I actually don’t remember exactly what we were selecting, but it was a software selection process way back when, early in my career.
The first meeting unsurprisingly you know, the old stages, the team formation: “Storming, Forming, Norming, Performing.” It was an advanced organization; so we always skipped the forming part, and we got right into the storming. Basically the first couple of meetings were nothing but arguments and they were arguments about whose preferred solution was the better solution.
And somewhere in there, probably just out of frustration, I asked everybody to call a halt to the arguing for a minute and instead asked them, “How are we going to make this decision?” And strangely enough, while we were completely incapable of having a productive conversation about what the better solution was, we were quite capable of having a very productive conversation about how to make the decision.
Basically, what are the requirements in multiple categories, what are the relative importance of each of those? How are we going to tell? And then it flowed quite smoothly because we all committed to a process.
We had one guy at the end who wasn’t onboard. He had said he committed to the process, but he would not relinquish his favorite solution, even though it was not even a close horse race with the one that we selected. His argument was that our selection process was flawed because we had scored a feature down that he said his preferred solution was very strong at, and it turned out that he felt that solution was quite strong, but the vendor said it was quite weak.
So he, in fact, decided to argue with the vendor’s statements about their own product. And he got laughed out of the room because we’d all committed to the process. I learned
another lesson then, which is one of the easiest ways to unite people who don’t normally unite is to give them a common enemy. So that worked out too, although it was the less savory part of the solution.
Greg Mader: [00:07:14]
Yeah. I think since you talk about software selection, I’ve sent your column to, I don’t know how many, possible customers here. Tell us your feelings about RFPs. Is that a good way for an organization to select software?
Bob Lewis: [00:07:33]
Oh, you mean “Request for Pain?”
Greg Mader: [00:07:34]
Oh, yes.
Bob Lewis: [00:07:37]
There we go. Yeah, I’m a consultant. The answer to any question is it depends. Is an RFP, a good way to go? I think what it depends on is a couple of factors. One is how well you understand your requirements and at what level of depth, if you understand your requirements, you can formulate them.
Otherwise the RFP process, isn’t really a bad way of getting to understand them a bit better. Where I think RFPs go off the rails is that when the person writing the RFP, or the people writing the RFP, in effect, want to be the vendor. They don’t want to be the selector. They’re smart people. They want to do the solution. They want to show that they know how to do the solution. And as a result, they over specified, and they don’t give the vendor enough latitude to propose creative ways of solving the business problem. And I’ve been involved in pursuit teams where we’ve had RFPs with 500 or a thousand detailed requirements. And it’s just a preposterous way of approaching this.
What you want to do, I think, is explain to each of the candidate vendors:
- Here’s what we want to achieve.
- Here’s the business outcome we’re looking for.
- Here’s technical outcome that we’re pointed towards,
- Tell us the best way of solving the problem.
Don’t respond to a thousand detailed questions. So are RFP’s good or bad? I think like everything else in the world, it’s possible for them to be useful. It is possible for them to be horrible. And regrettably, I think there are more horror stories than there are successes.
Greg Mader: [00:09:25]
I agree with everything you said, Bob. if I can summarize: how I’ve often seen these as the receiver of them, it’s clear they hired a consultant or someone internally to go around and take a survey from everybody in the organization and get their wishlist, and the wishes may often be in conflict with each other. But nevertheless, it’s a list of what accounting may want, what procurement may want, what manufacturing might want, that may or may not have any coherence.
And what I’m afraid is that most people that respond to RFPs do, is they’re just going to check “Yes” on all 500 requirements, that “Yes, we do that,” maybe put in a few asterisks and unfortunately what ends up is everybody says, yes. So it’s a race to the bottom. Who’s going to offer the lowest price, whether, in fact, it ever solves any problems or not is irrelevant.
Bob Lewis: [00:10:22]
I trust that you have the good sense to tell everybody who sends you an RFP, that this is far and away the best RFP you have ever read. I’ve been on both sides.
Greg Mader: [00:10:32]
That’s exactly it. Yes. I absolutely tell them that best RFP I’ve ever read. Perfect.
Bob Lewis: [00:10:39]
Absolutely. No, I think you’re right on the money with that.
Although there are a couple of other styles of RFP I’ve been on again on both sides of this. I learned the hard way, when I put far too much effort in very often, what the RFP really is a request for free advice. And so I’ve shared our methods. I’ve shared our approaches and then the response is,” Well, we decided to take this in a different direction and what the different direction is that the In House team is going to do this, using the ideas they got from all of the vendors they sent RFPs to.”
Greg Mader: [00:11:15]
Yeah. That has happened as well. Moving on.
Bob Lewis: [00:11:20]
Okay. Good plan.
Greg Mader: [00:11:21]
Yeah. Back to the idea of a culture of honest inquiry, another point you made that really sticks out.
Don’t create disincentives for honesty. I think you and I talked about it briefly a few days ago, but the idea of bad news doesn’t get
better with age.
Bob Lewis: [00:11:40]
Yep. Well, okay, so let’s take it this way now.
The oldest formulation of this is probably the most common.
We just don’t shoot the messenger. The messenger has gone through a lot of work to get to talk to you and give you an honest take. And even if they’re wrong, unless you think that the reason that they’re telling you something you don’t want to hear is if they’re stabbing somebody else in the back, which does happen.
And here’s a thing: If you’re trying to hold people accountable, what that’s saying is that you think they won’t do a good job unless there’s a threat of punishment hanging over their head, like the Sword of Damocles.
And if you actually have hired people who only operate well under threat, what you ought to be doing is wondering why you hired people so badly, because the idea of holding people accountable and people taking responsibility are really polar opposites. You want to hire people who take responsibility so that you don’t have to hold them accountable.
And if you’ve hired people that you have to hold accountable? Two things:
- Give them the opportunity to instead find a job they can succeed in. They deserve to have the chance to be successful.
- Hold yourself and your HR and your recruiters and everybody in the loop hold them accountable for hiring people badly.
What does this all have to do with a culture of honest inquiry?
It’s pretty straight forward. The folks who are taking responsibility understand that something is going wrong, something needs to be done about it. And if you do a proper job of root cause analysis, The chance that the fundamental problem is that you’ve got a bad person involved is usually….First of all, it shouldn’t be your default assumption. And second, is probably not anywhere in the root cause. Usually the root cause is going to be the systems, you’re using the processes you’re using, the tools you’re using. When you shake it all down, The idea that if somebody gives you bad news that somehow or other, they should be held accountable to be punished for, it just means you don’t know how to handle situations well when something doesn’t go your way.
Greg Mader: [00:14:07]
That’s actually very positive and inspirational. An organization I once worked for was notorious for “Dead Dog Fridays,” where bad projects would only be discussed with Management as late as possible on Friday afternoons, which led to this vicious loop of unhappiness with all parties, and they clearly weren’t following the guidance that you laid out there.
What do you think about the role of “Grassroots IT” in an organization? Some companies call it “Shadow IT” or “Guerilla IT,” I think depending on the Director of IT’s personal values on this subject, but there is this idea that business users will go find a solution for themselves.
Bob Lewis: [00:14:54]
Shadow IT, Do-It-Yourself IT, Guerilla IT, IT rarely has flattering names for these. And the thing to understand about the mindset that leads to Do-It-Yourself IT and why is it in conflict with what most of us have been taught for most of the last 30 years, at least, is this fairly preposterous myth that IT should view the rest of the business as its internal customer.
And so here’s where things get very strange and sideways is everybody from the CIO down and IT understands it’s supposed to treat people like their customer, but if IT was
running a restaurant, they would not say to a customer, “No, you shouldn’t have the ribeye. You should have the Cobb salad, because you’re frankly getting a little pudgy. And as far as desserts are concerned, just take that right off the menu. We don’t think you should be eating dessert.”
In other words, IT would act more like a dietician than a restaurateur. If IT were running Home Depot, somebody would go in to buy some drywall, and IT would say, “Sorry, you can’t buy drywall from us. We have to install it.”
So it starts with a very peculiar inconsistency because, just looking at the metaphor superficially, you understand IT should not be in the business of saying no to their customers any more than any retailer says no to their customers.
Here’s the second thing, because metaphors are whatever you make of them, and it’s easy to take a metaphor off a cliff anyway, but business managers are better than IT is at knowing what they want technology to do. They’re better at knowing how they want their part of business to run differently and better.
IT is much better at designing and constructing a resilient—if you like, a robust, if you do choose another word, sturdy, perhaps, how to build things that are built to last. So really when somebody in the business is perhaps somewhat technology savvy, but isn’t an IT professional, but they’re really good at making things work properly when they go out, figures out how to solve the problem, building a solution out of Excel or Access, license something open source, license, something software as a service and make it work for their part of the business. They’re doing the job of the IT business analysts coming up with something that demonstrably works exactly the way they want it to work.
There ought to be a mechanism in IT. ( And we would very well be served to establish a mechanism) for taking these Do-It-Yourself solutions and rewiring them. Replumbing them to make them sturdier and more robust while preserving all of the business logic that the business is built in, and knows this is exactly what we needed to do.
So my shot at Shadow IT is that you should—Oh, by the way, one more piece of this. Very, very often when somebody licenses a “Software as a Service” solution, when somebody develops something to make their part of the business work better, the missing piece is integration and integration is probably IT’s last frontier. It’s always hard.
Even when it works properly, it’s hard to maintain.
I worked with a company once they had more than a thousand batch interface jobs that had to run in precise sequence every night or things would go sideways. It was just a mess.
So one of the things that IT can offer, either during the Do-It-Yourself stage, or as part of this process of taking a Do-It-Yourself solutions and bringing them into the IT tent is addressing the integration challenges as well, so that the business users who can’t do integration, and as a result, they generate a whole lot of re-keying from one system to another, so that piece of inefficiency also gets addressed.
Greg Mader: [00:19:13]
That was fantastic, Bob. Thank you.
Similarly, I don’t think grassroots projects are good or bad. I think under the best of circumstances, they are solving some problems, scratching some itch that needed to be scratched. Even if they’re not perfect, it often helps point the way for what the real solution is.
Bob Lewis: [00:19:35]
Absolutely. And I think one of the things where it really gets into trouble is when IT tries to stamp out Shadow IT. Where IT can really get into trouble is saying, “We won’t do it for you. We won’t let you do it for yourself.”
So if you have a problem that could be solved by information technology, that’s just too bad.
We won’t allow it. You need to use ledger sheets and 10 key calculators or torture Excel until it’s screaming for mercy. Because IT is in the “Stamping out a Technology” business. Who’s that character in Dilbert? Mordac, the Preventer of Information Technology? Sadly that’s the problem with Scott Adams, so much as preposterous, all you have to do is recognize it as preposterous and you’ve got humor.
Greg Mader: [00:20:22]
Yeah, I think everybody in our business, when we look at a Dilbert cartoon, there’s a bit of schadenfreude and we might recognize it.
Bob Lewis: [00:20:35]
Yeah. I think there’s a term. Yes. Yes. I couldn’t agree more.
Greg Mader: [00:20:42]
I do want to ask a big question here. A lot of the people I think that are listening to this podcast are newer in their career and that’s where they haven’t maybe made all the same mistakes or had the same experiences.
I am curious, Bob, do you have a particularly good story from the school of hard knocks?
Bob Lewis: [00:21:04]
Oh, yeah. I have practically nothing but. But know what they say, “Experience is just too late learning.”
Earlier in my career, I was one of five people who were collectively formed as the organizations Chief Information Officer. They were trying an experiment in a team-based leadership.
Of course, we all hated each other. Oh, that’s not fair. We were all were bitter rivals because all of us figured that it was like Highlander. And in the end there would be only one. Of course, we all wanted to be the one.
And then we had a change in Executive leadership that didn’t believe in self directed teams at any level, and certainly not at a management level.
The person to whom the five of us who were the CIO reported, sat down with each of us to get a sense of IT and what should be done and all that. And I spent an hour with this lovely woman, very smart woman, sharing all of my thoughts on what I thought needed to be done for IT to be the organization that the company needed.
What I didn’t do, was ask her one question about what she thought. The hard lesson—I wasn’t the one selected—and the lesson there was pretty straightforward, which is you
don’t impress people with how smart you are by talking. You would persuade people that you’re smart by listening to them.
And if anybody who’s starting out on their career, or anybody who’s finishing up their career, for that matter: you are always going to sound smarter by asking good questions than you will by giving good answers.
Greg Mader: [00:22:48]
A person I used to work for some time ago, would always tell people that were new to the company (including me) this one bit of advice, and that was “Seek to be interested, not interesting.” I found that pretty helpful.
Bob Lewis: [00:23:06]
Close to that first piece of advice is the second one, which, it’s a long story that I won’t bore you with for change of pace, but I found myself at a round table among groups of round tables. All of them within the table were supposed to come up with the one skill that would be most important for folks who wanted to become IT leaders. And our table with yours truly, I confess, as an instigator, established the single most important skill anybody could develop if they wanted to be in a leadership role, was the fine art of sucking up.
So, listen, don’t talk first, but when you talk, suck up. Nothing comes close.
Greg Mader: [00:23:52]
Wow. Okay. I’m not sure where to go.
Bob Lewis: [00:23:59]
I think the best thing you could do is change the subject.
Greg Mader: [00:24:02]
Let’s do that. Wrapping it up, again for new people that might be starting out in their career, what are maybe the top five things they can do to keep a project on track and make it successful? And maybe there’s five things that are destined for failure every time they’re tried.
Bob Lewis: [00:24:23]
Oh, that’s a hard one. Okay. So looking at this purely from a project basis, I don’t know that I’ll get to five. The first, the single most important one, is that you need to have an executive sponsor, and I say executive because they need to be able to make sure you get the resources that you need, which means they need to be able to spend money.
The second key thing is a good sponsor is not providing oversight. The good sponsor is a collaborator. A good sponsor has got to want the project to succeed at least as much as the project manager does, deep in their bones.
So if you don’t have the kind of sponsor, who’s fully committed to making the project successful and he doesn’t want you to give the man honest accounting, going back to an earlier subject of where the risks, where the issues are, what is going wrong? What could go wrong? If you’re not dealing with somebody like that, and you’ve got a sponsor in name only, and the best thing you can do under those circumstances is run and hide under a desk someplace and hope that they don’t notice you for awhile.
Okay. I guess I should give you at least two, since you asked for five.
Greg Mader: [00:25:36]
I’ll take whatever you give.
Bob Lewis: [00:25:39]
The hard part is they get me to talk to the hard parts to get me to stop talking.
Number two, perhaps on your how to make your project successful, and I’ve seen this go wrong a lot of ways, and that is make sure that you have weekly status meetings.
Not status reporting, not status management, not status readout.
The key thing about a weekly status meeting is that everybody on the team should—first of all, your plans should be down at a level of granularity that at the end of a week, you know whether somebody got what should be gotten done that week or not.
So your tasks need to be defined to that level of granularity. And the reason you need a weekly status meeting and not status reporting and not emails with product status updates that a project manager and collect into reports and all the rest of that is—you want to be able to ask each member of the team:
- What were you supposed to start doing this week? And did it start?
- What were you supposed to finish this week and did it finish?
- If it didn’t finish on time, what’s the plan for getting back on track?
And the key thing here is that each member of the team needs to say to the rest of the team whether they got done what was supposed to get done.
That’s the valuable piece of this because that applies peer pressure, which is far more effective in a team environment than any kind of management oversight, project management or other.
One more. So I’ll give you three out of five, that ain’t bad.
Greg Mader: [00:27:20]
I’ll take it.
Bob Lewis: [00:27:21]
So the third one is, and again, this is no particular order, but when you’re dealing with a project team, projects are hard.
Easy projects are hard. They get more difficult from there.
They start off looking great. You’ve got an inspiring idea. You’ve got something that is going to provide high value. The results are going to be very, very cool, maybe industry leading, and everybody’s pretty excited. But no, I don’t run marathons, but I imagined that if I did run a marathon the first block, would seem really, really great, through all of these people and they’re excited and it’s New York and they’re running through Central Park, and wow.
And after a block or two, I’m starting to feel tired. Now, not bad enough to be a problem, but there’s gotta be a point in the marathon where you ask yourself, “Why the hell am I doing this to myself?”
Like I said, I don’t run marathons, so I’m just speculating.
But projects are like this. Teams start with enthusiasm, drive, excitement, and energy and over a period of time, when you get past the launch and you’re in this day to day “Just put one foot in front of the other,” and there’s no discernible progress, because it’s a big project.
And what you’re able to accomplish in a day or a week is very small part of getting to the end. So where this is all going is that project teams have a fairly predictable set of stages they go through starting with unenlightened optimism progressing to daunting pessimism, and then you reach the pit of ultimate despair when you’re way, way into this, but there’s no end in sight and you’re just really bone tired.
If you keep going, the team will reach a point of enlightened optimism when they can start to see the finish line or at least envision it.
And then there’s one more dangerous spot. And that I call the pre completion doldrums. This is when you’re nearly done, you’ve done 95%, but you’ve got this nasty punch list of annoying little items.
And as fast as you take items off the punch list, new ones seem to appear. And so when you’re really close to the end, there’s this other energy draining stage that tends to happen. And the reason I’m telling you all of this—Oh, and by the way, you finally get the success. If you’re doing this well, the reason I’m taking you through this is that project management is usually described as a series of steps, the set of practices that you have to apply.
You’ve got a plan, you’ve got the sponsor, you’ve got weekly status meetings. People get their task assignments and so forth and so on. Okay. But a project is a very human enterprise. And one of the most important responsibilities of project manager has, is to recognize the emotional state of the team and the emotional state of the team members and take steps to provide energy when the energy is feeling drained.
Greg Mader: [00:27:20]
That’s really good. One of my favorite books is Solzhenitsyn’s novels called “In the First Circle.” And one of his characters was this engineer, who’s working on a
project and he comes up with “The Law of the Final Inch.” And the idea is that the final part of a project is probably the most painful and difficult.
And it seems very small to that idea of the punch list.You’re bringing up Bob, but it’s the most important part of the whole project. It’s that finishing big it’s the difference between getting across that finish line at the marathon on all fours versus getting across it on two legs and maybe being tired, but you’re happy that you did it.
Bob Lewis [00:31:22]
Yeah, just to put a bow on it. Harry Newton, he was close to a celebrity in telecom circles. Harry used to say that you need to beware of the 90% solution. The 90% solution, he said, anybody you hire, any employee, any place can take an idea and get it to 90% done. But the ones that can get that last percent done are very rare.
When you’re talking about the progress on a project, be very aware of the 90% done status, because that last 10% is as big as that first 90%. And probably then some.
Greg Mader: [00:32:01]
Absolutely. I’ve seen exactly the same thing. It was great to have you on, I’d love to have you on in the future, and I definitely want to stay in touch and tell me when your next books are coming out too.
Bob Lewis: [00:32:15]
Absolutely. Listen, thanks again for inviting me out. I hope that your subscribers find this interesting. If they don’t, well, this is now a half hour of their lives they’ll never get back.
Greg Mader: [00:32:26]
They can blame me.
Bob Lewis: [00:32:28]
That’s even better.
Greg Mader: [00:32:28]
Yes. Thank you again, Bob.
Bob Lewis: [00:32:31]
My pleasure. Talk to you soon.
