Lessons in IT Leadership: Best Practices in Leveraging Emerging Technologies and Delivering Strategic Business Value

Mark Settle: So thank you for joining me this morning. How many folks joined us last year for the conversation on lessons in leadership? Okay, great. So we have some folks. The rest of you, I'll give you a bit of an introduction to what we're going to do here today. 

You're actually sitting in the customer success track, but what we really want to focus on, or I plan to focus on in the next 45 minutes is your personal success as IT professionals and IT leaders. And we kind of want to use this opportunity to change gears. The last two days of the conference here, as we end up, we've been asking you to think strategically about ways you can use identity management tools to secure the Axos to critical business systems. 

I'm going to challenge you for the next 45 minutes to think strategically about your careers as IT leaders, and specifically talk about some of the key skills that are needed to be successful in the future. It's kind of funny with the remark about the forward-looking statements. Many of my observations are going to be backward-looking at things that have gone wrong in the past, and hope that I can share some pitfalls with you that you can all avoid in your own careers. 

My objectives for the conversation we're going to have today are simultaneously very broad and ambitious, but at the same time very modest and focused. So my ambitious goal is to sincerely provide information or insights that will benefit you and advance your careers. That's a pretty ambitious goal. On a more modest level, I'm hoping you can take away one idea or recommendation from the conversation today, and when you get back to work on Monday, you can either start doing something different or stop doing something that you're currently doing, or do more of potentially, something that's part of your daily and normal work behaviors. So I'm going to kind of have you all become members of the one idea club for the next hour or so, and I hope you can take away one idea from the conversation that we're going to have. 

So what are we going to talk about? Now, last year, we talked about two foundational skills. Specifically, financial management and how to develop relationships with your peers in the business. Those of you who were with me last year will be relieved to know we're not going to repeat that conversation. We're going to talk about two others. This year, I want to focus on technology innovation, and how you go about constructing projects and delivering initiatives that actually have strategic significance from a business perspective. So those are going to be the two focus areas. 

In the course of the conversation, I'm going to try to impress upon you the importance of no. Specifically, with respect to technology innovation. Many of you in the audience may be scratching your heads and saying, "What is he talking about? I spend 3/4 of my day just trying to get people to say yes, to get interested in something. I've got an idea I'm trying to sell, or pitch, or intrigue folks about, and so all my effort goes into actually driving consensus and getting to a yes." But one of the takeaway messages that I hope you leave here today with is that when it comes to looking at new tools, and technologies, and ideas, a fast no is actually very much more productive, in most cases, than a long maybe that can tie you up in knots for a long period of time. So we're going to talk about the importance of getting to no. 

A third focus topic for us today will be to discuss some of the IT phobias of business leaders. And when I put the talk together this year, I was looking at this slide, and particularly this agenda topic, when I thought, "Gee, maybe this is the topic for next year" because business leaders have so many phobias about IT that I could easily fill a conversation for 45 minutes about that. But specifically, I want to focus on those that are relevant to major initiatives and how we partner with our business colleagues in driving those kind of initiatives. 

And then finally, I'm going to challenge you all to dig deep into your high school physics memories. We'll have a little test to see if you can recall one of the principles that you learned back in high school. 

Now, how am I qualified to spend some time with you this morning to cover these topics? So I'm a seven-time CIO. In sales circles, I'm known as a repeat offender. The companies I've worked for are shown there in the gray-backed Chiclets, and I've worked across many different industries. I've managed groups of many different sizes, supporting many different business models. I've also had the good fortune to develop a pretty extensive network within the CIO community, and you won't be surprised to know that when I get together with my colleagues, we talk about having many of the same problems and making many of the same mistakes across the board. So the experience I'm going to share with you today is not just based on my own direct experience as a CIO, but lessons I've learned from my colleagues as well. 

And then finally, across the bottom there, I striped in blue a series of jobs that I had early in my career that involved various aspects of program management and project management, which will be relevant to the strategic initiative conversation that we're going to have. 

There was a disclaimer at the bottom, which I want to go back to. So I would be the first to recognize that every company, or enterprise, or organization has a unique set of personalities, and politics, and culture. There are different external business drivers. There may be competitive threats. There may be opportunities through mergers and acquisitions, et cetera. So I'm not trying to argue that any of the observations or suggestions I'm going to make today are universally applicable, but I think there'll be enough opportunities to connect the dots, and many of the things we'll talk about will resonate with folks in the audience. 

So I want to start an focus initially on technology innovation. So where do new ideas come from? And I should caveat this and start it by saying innovation is a very, very relative term. So if you're trying to come off a Lawson HR system that you've had for the last ten years and move to Workday, that's a huge technology innovation, right? But there'll be some other enterprise that's maybe been on Workday for five years, and they've got some other idea in mind. They're going to go off and build an eComm platform or something, and to them, that's a real technology opportunity. So innovation doesn't always have to be blockchain, or IOT, or machine learning, or some brand new, cutting-edge technology. It can be many different things, depending on the relative situation you find yourself. 

Historically, many of the ideas for new tools and technologies come from the vendor community, and that's obviously no surprise to the folks in the audience. I'm sure you get berated by vendors all the time, but it is interesting to note that what's happened over the last ten years or so ... You know, the mega-vendors of the past like Oracle, and Microsoft, IBM, Cisco, and others were the primary sources of innovation in the industry. So they had R and D labs, put a lot of money in R and D, and brought a lot of new ideas, products, and services to market. That's really changed radically over the last ten years or so, and the venture capital community is now the primary source of innovation that happens within our industry. And in fact, they've outpaced the legacy providers, and as illustrated by the fact that many of these legacy firms actually purchase. They buy startup firms, then they just add those services or products to their portfolio. So the vendors are our primary source of ideas for new things that you can try and incorporate in your business. 

The second are your business partners. So I'm going to admit that this is a cheap shot at my own business colleagues because what I did for this graphic is I went to the SFO Airport, and I took a picture of a young woman looking at business magazines. You can't make this out, but it's Fortune, and Inc., and Success, and Fast Company. And I'm sure that if we were to purchase those, I'm sure the terms digital transformation appear many times in at least half of those publications, right? 

So we used to kid ... The business leaders would go on a trip someplace, and they'd read a magazine on the airplane, and they would come back and say, "When are we going to build that mobile app that I read about on the plane? How come we don't have one of those things? It was such a huge success story," et cetera. That's kind of the old-fashioned way, the way we used to critique the ideas that the business partners brought in. But it's actually become more insidious because as you all know, with SAS tools, it's very easy in many cases, for functional groups to go off and set up sandboxes with some kind of new SAS product, and start kicking the tires, put a little data, and kind of play around. 

And so it's not just them kind of showing up, saying, naively, "How would this work?" They've actually gotten their fingers dirty a little bit, playing around with the tool, and many times they'll have the knowledge of IT. So the second source of new ideas are the folks in your functional groups, and the third is your own staff. 

So most IT professionals, deep in their heart, are technologists, and they have experience as well. So they may have used a particular tool or system in a prior job that they think, logically, should be used in their current place of employment. They may have friends or family, acquaintances in the industry, and/or they may go to shows like this and wander around the exhibit area, and stumble across a few things that look intriguing. So your own staff is kind of bringing all these ideas in at the same time. 

The net effectiveness is that any IT shop is drowning in technology innovation opportunities. There's just a ton of ideas that are out there, and I think a mistake that a lot of organizations make is they either intentionally or inadvertently encourage a Darwinian competition among all these different ideas. So the philosophy is let 1000 flowers bloom, and we'll just kind of see what rises to the top of this totally unstructured and kind of chaotic set of conversations that are going on within the IT organization. Personally, I am categorically opposed to that kind of governance free approach to screening new technologies for two primary reasons. 

So one is, there's a lot of wasted energy that can go out. There's lots of reasons why you do and don't implement a new tool, many of which are not obvious to some of the technical people in your organization. They get all excited about something, and there may be change management issues, process re-engineering issues, budgetary issues, political support issues, et cetera, that they are totally unaware of, that will just make it impossible to do something with the technology that they fall in love with. So there's a lot of wasted energy. 

And it the staff goes down too many of these dark alleys and box canyons, well guess what? They get demoralized, so then they start grousing, and they tell all their friends around town, "We're not a very innovative organization. You probably wouldn't want to come over here and work because we haven't had anything new in a long time. When we've had good ideas, we just can't get our management interested," etcetera, etcetera. And neither of those, obviously, are good things. 

There's kind of a third negative consequence, which can sometimes happen, and I've been bitten by this myself. Members of my own staff have actually brought new tools into production environments, and it's stalled in the production environments, and guess what? They were kind of cool when they were in the sandbox and we played with them on a standalone basis, but they didn't play so nicely with some of the other operational tools that we had once they were actually put into production. So we had to back things out and we had a few hiccups along the way, right? So I can see somebody nod up here. They've been to this movie before. 

So bottom line, unbridled, ungoverned approaches to evaluating different tools is something that I've tried to correct in many of my past jobs. And so, what I want to is a way in which organizations go about doing this and my recommendations about how to do it, and I want to talk about that in two contexts. So one is an organizational context and then a process context, okay? 

So from an organizational point of view, when you go to vet these various opportunities ... I apologize. You're going to hear that word a lot, opportunities. But with these different emerging tools or new systems, et cetera, the classic approach is to have your enterprise architecture team lead the evaluation, and a good EA team is uniquely qualified to do that on a couple of counts. 

So they should have a pretty broad understanding of the business model that IT is there to support. They've been through other vendor selection kind of exercises in the past, so they know all the right questions to ask, and one of the most valuable commodities that they have is time. So your tech archs, or your solution architects, this is part of their job. They're supposed to be doing this, as opposed to it being a hobby or a part-time activity by somebody else that's on the staff that has a broad spectrum of other responsibilities. 

A mistake, as you all are quite aware, that EA teams sometimes make, probably all too frequently, is they don't involve an appropriate cross-section of subject matter experts in evaluating these new tools. So for example, if you were going to take a look at flash storage for your data center, you would obviously want to involve the existing storage engineers, maybe even some of the storage admins to kick the tires and be part of that evaluation. I can tell you an anecdotal story where I failed to do this. 

I was involved in an organization in the past where we had about 1/3 of the IT group that was sitting offshore in India, and there was a tool, and I truthfully can't remember the tool, but we went through a competitive bake-off and we selected this tool. We purchased it, and then we now said we were going to implement it. Well, it turned out that I have three members of the IT organization in India who had worked for the vendor, that we were totally unaware of. And they were intimately familiar with both the capabilities and more importantly, the limitations of the tool, but there was no way that they would know what we were up to in North America. There was kind of no way that they could actually participate in the evaluation. So one of the things that a good EA team does is to try to involve the broadest possible cross-section of SMEs on these kind of discussions. 

The second organizational approach that's frequently used is sanctioned skunkworks. So in a sanctioned skunkworks approach, you have some kind of a proposal or application system, where an individual or a small team of people get interested in a new tool, they write a proposal to management, and what they are primarily requesting is time to work on the idea. But they may want some modest resources for a server, or they may need to open up a firewall port or to do a couple other things, and so there's competition. So they submit a proposal, and if they're selected, they get told, "You can go off and do this." 

Some of the more enlightened companies actually have a separate physical space they call their innovation lab, where these small teams can meet and kind of pursue these ideas. And this all sounds very well-intentioned and a commendable thing to pursue. My experience is that there's some, again, unintended consequences of this, and so one of the unintended consequences is because this is a kind of in-addition-to activity. So most of these kind of projects, it's not as if somebody's told, "You can take the next three months off and do nothing but this particular evaluation." Usually, they're told, "You can take a couple days a week," or whatever. Almost invariably, these evaluations take longer than planned because they're just kind of gravitational force that keeps taking them back to their normal day job, so it's more difficult for them to get to the finish line. So that's one unintended consequence to this approach. 

The other is there are people that get told no. No, you can't do that. And the no answer is not always predicated on the potential value of the tool or the concept that's being proposed. It can be because we have other organizational priorities. The project we have you on today is too critical to the organization. We just can't let you go do that at this point in time. And for every one person or small team that's elated at the opportunity to kind of go have fun, there can be four or five others who feel like, "Why did I get stuck with this? I would love to go pursue my idea. Why didn't I get to do that?" So that's one of the issues that you run into with these kind of approaches. 

Now, one of the more modern concepts that overcomes both of those negative consequences are hackathons. So the thing about a hackathon, in most cases, there's a fixed period of time that's been set aside. It could be two or three days, and the period of participation is very low. So almost anybody that has an idea, that wants to take the time, is sanctioned to go off and do something, and then there's some kind of feedback at the end of the process about ideas that might be pursued. So that is one way to approach this. It's a little more pluralistic if you will, and avoid some of those consequences. 

The last is the incubator organization, and this is very popular in larger Fortune 500 companies, where they take a small team of people who continually scan the landscape of startup companies, and they kind of do some very lightweight POC exercises. They document the results, and then they're waiting for the business to step forward and say, "We have a problem we need to solve. Who do you know that could help us solve this kind of a problem?"

A lot of times, startups try to avoid incubators because they really don't have budget or decision making power to go off and actually buy the tool or implement it themselves. Right? They're just kind of in the middleman role, waiting for the business to step forward with a requirement. So these are just some of the organizational approaches to screening tools. 

Now, I want to turn to the process, and to do that, I want to turn you all into salespeople. So when you think about it, almost all of us have sales organizations, and they screen opportunities all the time. I mean, they've turned it into a science in which they find a target company that they think of as a lead. Then, they try to qualify the lead and eventually make a sale to that target company. 

So let's just think about that as if you were in the selling mode, and some of the common steps, you've all participated in this process, but as buyers, not as sellers. But when the target's identified, the sales organization tries to figure out, "Does this fit with our target market? Does this look like some customers we have today already? If the other customers bought it, maybe we can get this target to buy it." 

You're contacted in some fashion, and agree to actually take a meeting, could lead to a demo, start to identify the people who are going to make the decision about this at the end, when you get to the prospect phase. Then, you get into some more rigorous evaluation that's around proof of concept with specific used cases, reference calls to those other customers, and you get to a final cost proposal. 

So the important thing about this kind of pipeline is it needs to be balanced. Organizations make the mistake of spending too much time at the front-end of the pipeline. And this would be similar to the Darwinian competition I referred to before, where there's tons of good ideas, there's tons of targets out there, and I can spend tons of time with targets. This doesn't mean we're actually going to get to a sale at the end of the day.

Conversely, I can put too many eggs in one basket and get laser-focused on one or two opportunities, and kind of miss the boat because there's other sources of innovation, other cool things that we could actually do. So the same way that sales management is obsessively focused with balancing a sales pipeline, technology leaders should be obsessively focused with managing their technology pipeline. And so I'm going to flip you into a different role now as a buyer of the new tool or technology but I'm going to plagiarize many of the same kind of stage gates that you saw illustrated in the previous slide. 

So what happens in this kind of a process? Again, we've all participated in this. This isn't some kind of brand new idea. So the cool technology. You walked around the floor here at the Octane meeting. You were intrigued by a vendor. They made some claims about what they can actually do. They flashed some customer names by you. You might have even gone up on a website and looked at their current user group. You might have done some social networking with your peers at one of their current customers, etc., and you're intrigued. So you're really intrigued. 

The next step in that process is to ask for a demo, typically, get some list pricing, and do some functional reference checking. So you're trying to prove to yourself. Like, "They told me it did this, but I really want to prove to myself that it does what they've claimed."

The next level of effort gets to that more detailed POC where you actually have used cases. You've done your homework. You said, "Here are the five things I want to be able to do with this technology. I want to go and do a better job of understanding your competitors like where you overlap and under-lap. And then I need to take a deeper dive on some due diligence. So I need to know where I'm getting into in terms of trying to implement this technology and how it's going to get supported going forward. What skill sets am I going to need? What range of support vendors are out there in case I get into trouble? And at the scale, I tend to use this particular technology, what kind of pricing discount might be involved?

All too often in these kind of conversations, the world intention technology people jump right to pricing as if they were vendor management specialists and they try to go off and negotiate final pricing which is like when we're trying to fix the engine in my car or something, they're professionals that know how to do that and it's not advisable for technology people to try to play that role.

And I finally get to the opportunity, a phase where maybe you've had some business folks involved in this evaluation process. But then you need to step it up a notch and you need to find somebody at a senior level who's going to endorse the recommendations that maybe the director of marketing operations was making. You got to get the CMO to say, "Yeah, that's going to change our demand generation capabilities if we can go for that tool."

Just because someone loves the organization there's been concurrence at a director, senior director level. You're really going to need an executive sponsor if this is going to be a major opportunity for the company. And then you go through the final steps of this process.

If you look at this end to end, the initial stages are really focused on fit for purpose. You're trying to drive the ground with the claims the vendor made about what the thing does and you're trying to relate that to what you think you really need. And then the final stage is focus on fit for use. So okay, it does that. Now, let's think about if it was really here. Remember, I made that remark before about a tool not playing nicely with other tools. Well, that's the part or the stage of this conversation where you're going to need to just really think through the implications of what you're going to get yourself into.

Now, so this is great conceptually. How do you implement this in practice? So I'm going to make a recommendation to you based on a process that I've used in the past. So I've created committees or boards if you want to call them. In one organization we called it the technology acquisition board. And my direct reports and some of the key EA people, we meet together every six weeks and every technology that was under evaluation at whatever stage was formally bucketed into one of these categories that you see here. 

And to move a target from the candidate to the prospect stage, everybody had to follow the same ground rules like the amount of effort we're going to put into this, this is what you have to do. And there was a person's name associated with it. So this has been advocated somewhere in the organization, Mark Settle is responsible for getting this from the candidate phase to the prospect phase. He had to come in and tell us I completed the demo, we'd done the reference checking, I've got some pricing, it still looks viable, I want to spend more time, we have other people who want to spend more time.

At the end of every one of those meetings, we actually would publish to the entire IT organization the status of all these opportunities and invite people to participate in the process. Now, we did that in a way that we didn't want to tip off our hands to the vendors that we're competing for our business but we wanted to make sure that at least the leaders and some of the key technical folks in the organization could participate. So that was important. 

And we had vigorous debates about stopping things. And so again, I'm just going to sound a little bit like a broken record here. There's so many reasons not to do things that are the practical reality of why things can't get implemented. There was one storage virtualization tool that I had a DBA team fall in love with and the initial entry point in terms of cost was pretty low. But if we had actually implemented that across all of our databases, it was going to be a multi-million dollar investment and I didn't see any prospect for being able to find that money on the short term.

There're other technologies sometimes and I'm sure we all played this game together, that looks promising, but you have to wait for some kind of strategic initiative to come along so that you can kind of tuck it in as part of the circus coming to town and then try to get your funding that way. I've seen that phenomenon where I've played that game, by the way, once myself.

So again, just to summarize, I mean, the benefits of that more structured approach are involving the broadest possible cross-section of talent that you have in your organization. Two, is holding individuals specifically accountable. A lot of times these activities, these evaluation activities, they're very organic. Like if you ... the people who are working on it change over time. So and so get involved, well, he's not there anymore. And then she asked these question so we had her become part of the PLC etc.. It's not clear who's responsible before we as an organization find out we've like burned up all this time and effort, the staff things we've got to the opportunity phase. They've negotiated the pricing and terms and conditions, and it finally show up out of the desk of the VP of infrastructure and, "We're not going to do that." 

Again, it could be the most fabulous opportunity, but I have these other priorities. We're already committed to getting something done in October. There's no way we're going to get distracted and go chase some kind of a new cool storage solution. 

So the important takeaway here is saying no early and often. And if I can't convince you of that, I'm going to invoke one of the high priests of our business here. And one of the famous quotes from Steve Jobs is that "Innovation is Saying "No" to 1,000 things." And he admitted he was as proud of many a things that they didn't do at Apple as the things that actually got done at the end of the day. So just bear that in mind.

Sorry about that, I got mangled a little bit in translation. I don't know what happened. Now it's sticking out by itself. Okay. So we've fallen in love with something. Let's just say it's not a very professional way of talking about it, let's say we can see the opportunity for the business if we were to make this investment.

We have to go find a dance partner. Because anything that's going to have a business impact, IT can't go in and change the business process or relocate warehouses, or get partners involved in our distribution function or whatever. And so one of the famous quotes that has resonated with me over the last year or so, I met a CIO and he said, "Don't forget, I only consume technology through project. I don't just fall in love with the idea and go out and do it."

The one exception to that, obviously, are collaboration tools. So this tool is a collaboration tool, you might bring in Slack or Teams or something else and just let it sit there and the entire organization might take off and start using that with really no structured introduction process by IT and sometimes with very little involvement by IT. But take away the collaboration case, you know, almost any major new system or application that's going to have that more strategic impact, you're going to have to have a partner to come along and play with you.

So that's not as easy as it might sound because this is the point of the conversation where we're going to talk about the phobias of our business colleagues. And let's face it, most business executives shudder at the phrase strategic IT initiative. Mark wants to go on your calendar to talk about a strategic IT initiative on Wednesday morning at 10 o'clock. I don't think there's too many execs that say, "Oh, I'm looking forward to that meeting. That should be really interesting to me."

Now, why is that? So obviously, there're many past projects in which IT over promised and under delivered. And not A-typically in many of those cases the projects took longer, spent more money than was originally intended. And that can obviously tar or undermine the reputation of the business executive that has been helping to lead the charge. 

The other thing to keep in mind, on the lower left here, there's usually a pretty big miss-match between the timeframes in which the business runs and the time that's required to roll out really strategic IT-based projects. And as you all know, people in functional units, I mean, they're driven by quarterly sales numbers, qualified leads, inventory velocity, store traffic. There's all kinds of metrics that drive the business on much shorter timescales than most of the major IT initiatives that I've been associated with. And so it's very easy for business executives to get distracted by those more tactical and near-term considerations and hard to kind of hang in there with you through something that may take as much as three or six quarters to see from beginning to end.

And frankly, those folks that have played around with IT in the past, they might think back and say to themselves you know, I had to go to all those meetings in that last initiative and all those guys talked in acronyms and they kind of dragged me into doing their business or helping them do their business. And I'd rather go up to Minneapolis and hire three new sales guys and go visit some customers than go into those meetings at corporate headquarters with the IT guys, go through that exercise one more time. So there's a lot of preconceived notions about what's involved in partnering with IT that you need to overcome.

So I'm going to kind of head to the finish line here and talk about selling, delivering, and measuring major strategic initiatives. Let's talk about selling first. I had never been successful at selling a major initiative without a strong EA team. And it's funny, you know, we always talk about EA as being a really technically based organization. But when you think about it, when it comes to big multi-million dollar projects, they're usually the marketing arm of IT. Because other folks just have operational responsibilities and they just don't have the time. In some cases, they don't have the broader business perspective to really be able to go out there and convert the hearts and minds of the various functional leaders and the various levels of the hierarchy that are required to mobilize support for something that's a major initiative.

Another concept that I always think about where the goody A-team is it's like a debating team. So if you've debated in high school or college, they pick one topic for the season and you debate the crap out of this thing over and over. And sometimes you go to a meet and sometimes you debate the pro-side of the issues and sometimes you debate the con-side. And the A-team, they go out there and they start to discuss this idea with different people. And after a while, they can anticipate almost every issue that's going to come up. And it's kind of smart to work your way from the bottom to the top of the organization. So by the time you get in front of a CFO, you've already tried this on a couple of the finance people, the leader of FPNA or the controller, and you can almost intuitively anticipate the CFOs concerns and address them head on instead of being caught back on your heels trying to respond to those concerns. So I've always been a big fan of building up a big A-team. 

Now, how do you get the attention of a business leader? You can teach them. So that's the next two bullets here. So any intelligence that you can bring back about what the competitors are doing just fascinated business leaders. So if you were to say you're in a retail company and you're selling fashion or casual clothing or something like that and you say, "You know, Nordstrom's are the gap, they just put in this new system and they are monitoring the navigation pathways of every customer that comes in the store. And they're doing like this analysis around gender and age, and time of day. And so they've moved the merchandise around in a different way and actually, the per-store sales went up in the stores they tried this in because they kind of know how to track people's attention and do X, Y, or Z." So then immediately your guys says, "I got to have that. That sounds really like ... tell me about that. I want to know more, how did they do that exactly?" 

The second way to get somebody's attention, you can conduct a similar fact-finding mission within your own company. And so again, I don't think this comes as a surprise to most of the folks here. There's usually a huge gap in understanding between the way executives think things are happening operationally within the company versus the people in the trenches that are running things on a day to day bases. So you can bring back facts from here's the error rate when we go to process these kind of applications or here's how much inventory is not turning over in these particular categories etc., and we think we have an angle on this that we can approach. So that can be very galvanizing too in terms of getting the attention of a business leader.

One thing to avoid that I've ... I'm now talking about next, our business cases. And I am going to dip back a little bit into last year's conversation. Those of you who joined me for that have already been exposed to this particular rant. All too often, I think IT organizations get overly focused or obsessive about building out the numbers in the business case.

Let's face it, a lot of business cases have a lot of soft benefits in there. There can be productivity improvements, there can be avoided future costs. There can be regulatory compliance concerns that we're addressing etc. IT has a very hard time going on record saying it's going to make changes in the business, in terms of staffing levels or operating locations or manufacturing efficiency etc etc, in any credible way.

Where they are important is to have part of that conversation I talked about with the EA folks, because they're really more of a recruiting tool. You really want to plumb the minds of those business peers that you have about ways in which this particular initiative will benefit them, and not get hung up on the numbers and the precision. In fact, I've had this personal experience myself. I interviewed for a CIO job in Southern California several years ago.

At the end of my interview day, I was meeting with the CFO. For whatever reason, I felt compelled to give him a five minute monologue about how important I thought business cases were and how I structured them and how I thought they should be reviewed and stacked up and make investments on a serial basis, ensure we got a return on investment from our whole portfolio etc. He let me go on for about five minutes. At the end of that, he said, "I don't believe business cases at all." He's a CFO. 

He said, "People do anything with numbers. They can move my numbers around in the spreadsheet. I'll have this versus this, I don't put any credence in all that." He said, "I go to those meetings because I want to see the executive from the business have some fire in their belly that if we do this, he's going to deliver some benefit to the corporation." 

IT has gone wandered around and gotten halfhearted support from two or three functional leads, and they all sit there and say, "Yeah, yeah, yeah. I don't want to touch that project at all." The guy who says, "Man. I can move mountains if we just had this here," then I'm all in. Then, we're going to make the investment. Don't ever underestimate the power of executive passion.

Then, finally, you can put a lot of the fears of a CFO at rest if you can structure these kind of initiatives in a way in which you're generating some proof points. Now, ideally, they would be business proof points, but that's not always possible. If you can just come up with some inner milestones that, operationally or just in terms of the amount of work that needs to get done, can provide a sense of confidence that this isn't some black hole where, for 18 months, we're going to spend a lot of time and money and distract a lot of people with the hope that, at the end of the 18 months, some great grand thing is going to happen at the end.

CFOs hate those kind of projects. Inner milestones and proof points along the way are incredibly important in getting something sold. Okay, say, we've sold it. One of the mistakes that I've made in the past, but I think happens pretty commonly, you've got your marketing team, the A folks. They've done a great job. We had executive passion. We got approval for the money. Then, the PMO shows up. The PMO says, "Well this is all really great stuff. Now, we're going to have to have a detailed plan. What's going to go on next Tuesday? Who is going to do what to who in October?"

They start to go to the business. If you're not careful, the business says, "Wait a minute. Who hit the reset button? Where do these people come from? They're asking me the same questions that the EA guys asked me. Like why is it important? What are the drop dead target dates that we have to hit? Etc etc. Do I have to manage your own IT organization? I gave you all the information you needed. You got the ball. Go do it. Why am I going to have to do this all over again?" That's a trap to avoid.

You can actually piss away a fair amount of the initial enthusiasm of the business sponsors if they really have to take a deep breath and feel like they're starting the project over for a second time. It's important not to get too creative during these ventures.

You don't want technical architects who are coming up with cool new bolt-ons or enhancements to the original proposal or, hopefully not, finding that some of the things you thought the technology was going to do, it doesn't really do. Then, you're running around finding ways to plug the gaps. Being technically creative in the middle of a multimillion dollar initiative is a prescription for disaster and to be avoided whenever possible. 

Now, if you remember from the earlier slide where I talked about some of my early career experience, I had the good fortune of working for [Use 00:36:41] Information Systems. We were a systems integrator within an aircraft company. We built systems that we delivered to the Federal Government, civilian agencies and the Federal Government. Many of these contracts were fixed price contracts. Has anybody been a fixed price contract manager? Okay.

Here's first thing you learn, schedule is the most important thing in a fixed price contract. In a fixed price, if anything goes wrong, you, as the vendor or the supplier, have to eat the cost of fixing it, making it work. When I first started my career, I was more technically focused. I think, well if we could hammer out the scope, we all agree on the scope, we can estimate what the costs are. We know how long it's going to take and whatever. We get that and then the schedule will fall out of itself. It will just magically happen somehow on schedule.

What you rapidly learn, especially with fixed price contract, is you have to be myopically focused on schedule. The other thing which, unfailingly, if there are going to be schedule problems in a major initiative, they show themselves very, very early. Somehow, the entire team tells themselves, "We can make up for that. It's so early. We're not delivering for another 15 months. It can't be that bad. I'm two weeks behind on this thing."

I don't know if you've ever used Microsoft Project or similar tool, so if you have a lot of events, the standard gantt type chart thing, so all these things are supposed to happen. If you look at the cumulative, they're not even milestones, but interim events, there's a curve over time. Almost immediately, you start to fall off the curve. The first time you fall off the curve, you go, "That's like a week we're behind. That's only a month. It's a 12 month project, we're still good." Whatever like that.

Of course, nobody's ever thought about the holidays and all the other things that are going to happen along the way. We just treat every month like a standard month. Anyway, you can get in deep poo-poo real fast if you don't keep an eye on schedule. This is a battle scar. Are you sensing the battle scar here? 

Then, I'm going to move onto this other observation. I don't know if you're familiar with the management consultant, Peter Drucker. One of his famous quotations is that, "Culture eats strategy for breakfast." Meaning that you can have the grandest business strategy but if the culture of the company or enterprise doesn't know how to deal with it, or just passive-aggressive says, "That's a good idea," but resists every opportunity to implement it, it's not going to go anywhere.

The mistake I've seen in a lot of IT projects I've been involved in is we go off into flights of fancy about ways we can make the customer interface more appealing, or come up with navigation paths that are going to lead to sales opportunity faster etc etc. We can come up with ideas of ways of interacting with the users of our systems that really don't properly take into account some of the complexities in order management or supply chain management.

Actually I had a project several years ago where we threw away two months worth of work. We had gone off with one part of a company, and we had an Agile team. Every time we met with the business people, they said, "Gee. If it could only do this, it would be great. If it could do this, it would be great." We built that all in. Then, two months later, we brought in the supply chain guys and they said, "Yeah. We can't do that. If you wanted us to do it, that would cost a lot of money to make it work in that fashion."

We literally threw away two months worth of work. I think all too often, people get myopically focused on the user interface and the way you want users to interact with new systems. You overlook or you don't spend sufficient time looking into those kind of complexities. 

I'm going to talk a second about Agile, so obviously I can't stand up here and say that Agile is a bad thing. It obviously does some good things. Those are highlighted here in the bullets. I think some of the benefits of Agile obviously are it typically improves team productivity. It does help team members hold each other accountable in a way that management can't really hold people accountable. You've made a commitment to a peer that something is going to get done. That can be far more compelling than promising management that something is going to get done.

It's also a great way to keep your business partners involved in the project over a long period of time. Before Agile, a lot of times, the business would sign up for the project. Then, IT would haul the project into the cave and we'd say, "We'll come out in 12 months and show you all the great stuff that we did." Through Agile, they have to come, they're supposed to come. If they don't come, then you complain to their boss that like, "This was the promise that you made me that so-and-so was going to come to these meetings and be part of the project."

That part's all good. The darker underbelly of Agile is that sometimes you can leave some of the more difficult problems that you need to confront to the end. A classic one being data management. You may say, "Well we know the user interface. We know the process we want to put in place. We're going to have to initially source data out of multiple systems to create the go launch database for this thing." How clean is that data? How far are we going to go back? Are we going to version it? Does it need to be normalized? What if we have inconsistencies between multiple sources etc? 

You can get close to your go launch data and, suddenly, these data management concerns blow up in your face. It's because we just never talked about it before. We thought that would take care of itself at the end of the day. Or if you're implementing a system that you are actually going to operate in your own data center, there are tons of operational concerns that the software engineers don't even think about. Like if we lose this process, how are we going to monitor that? How are we going to restart it? How does this change things that are going on?

You don't want to leave the hard stuff to the end. This is not a newer profound observation. Don't forget that the business really absorbs new capabilities in a waterfall process. One thing to avoid is don't go running around in front of your business partners beating your chest about all the advances you've made and continuous integration and continuous delivery, because they haven't seen anything change for the last six months. They think you're having fun over there in your hobby box with your sand toys, but they haven't seen anything come out just yet.

Finally, something I suspect many of you have experienced. When I think about program management and project management leadership, before I put my foot too deeply down my throat, how many PMI certified people are in the audience? We have a few, okay. Okay. I'm excepting you from the following observation, okay? Present company excepted.

It's really hard to find somebody, especially for these bigger projects, who has the unique combination of energy and dedication, super extreme organizational skills and the ability to influence and align the behaviors of what's effectively a virtual team, people that don't report to that individual as the boss. There are some people that just have that DNA, they can do it, everyone wants to jump onboard and be part of this thing. 

Then, there are other folks, who are the project managers, who update the schedules, document the meeting minutes, call the meetings etc etc. There's not that same kind of focus and sense of urgency that's in part of the whole team. My experience is if you can find that PM leader that has the right DNA, that's a winner every time. I would gladly trade that off against formal PMI training. I'm almost done, thank you.

I told you we were going to have a high school physics quiz. I don't know how many of you remember the Heisenberg Uncertainty Principle, but it's a principle from atomic physics that says, "When you try to measure certain properties of atomic particles, the closer you get to that measurement, you actually change the particle in some way so you can't really measure it at the end of the day."

I'm going to plagiarize that and introduce you to the Subtle Uncertainty Principle, which is that it's fundamentally impossible to attribute the financial outcomes of major initiatives to IT in whole or in part. If there are Gartner people in the room, they probably just had a heart attack. The thing that Gartner always want you to do is run around and have these postmortems and figure out exactly what happened.

There's two corollaries to this principle. The one is IT should never manage business outcomes. IT doesn't have the insight or the credibility to step forward and say, "Oh we did the project. Guess what we just figured out?" I'll tell you. I mean there's cases where I've seen that done. Behind the scenes, the business execs say, "The real problem was the head of manufacturing. Things got better when we fired him. The new guy came in, that made the big difference here. Yeah, we have a new tool etc etc. Or we were able to close these plants etc." Whatever it is, IT people just have to be very careful about standing up.

Now, the IT folks can facilitate that measurement process and hope to make it happen. They shouldn't be reporting results, and they should never claim credit for what those outcomes actually are. The thing that you want is a high visibility, very public, attagirl or attaboy. I'm going to close with this one last story.

I was involved in an organization who implemented Salesforce.com for about a 2,000 person sales team in 10 weeks. We had been talking about making this transition from an en-premise Siebel CRM system for two or three months before the Christmas holidays. Our sales kick-off meeting the following year was April 6th, a date that will live in my personal infamy.

We finally got all the execs to agree the second week of January that they wanted to do this, and they wanted it 10 weeks later. They wanted it at the sales kick-off meeting. The good thing about that was this became job number one for IT. We all knew, it's like a merger acquisition, you drop everything and say, "We've got to work on the acquisition." Everybody in IT knew, our butts are on the line. If we can't get there to the sales meeting and have this thing working, we're in big trouble.

We did it. There were several divisions in the company. One of the division presidents, who had been one of the least interested in IT and one of the curmudgeons of the executive team, stood up publicly in multiple forums and said, "That is the best project IT has done in the last five years." He didn't give me any compliments even on non-IT matters or whatever. 

The credibility that came along with that, we mined that extensively over the next year and a half or so to launch a number of additional initiatives, both within his division and elsewhere. You want other people talking about how great you are. You don't want to be running around proclaiming your own greatness.

Key takeaways from this morning with regard to technology innovation, obviously you've got to screen a lot of opportunities to find one that's the right one for you, that you can actually leverage. Getting to that fast no is a great way to reduce organizational entropy, keep people motivated to keep bringing new ideas forward. Then, involve everybody in IT in these kind of exercises as appropriate.

On the topic of the strategic initiatives, a passionate business exec will trump a compelling business case every time in my experience. Let the business leaders talk about all the great benefits that they've achieved through these kind of initiatives. Please complete the survey card, we talked about that. Please take a copy of Truth from the Trenches on your way out. Several of these observations with even better anecdotal stories are in the book. I believe my email address is in the book and it's shown here. If anybody wants to continue this conversation on more of a one-on-one basis, I'm very happy to try to help. Thank you very much.