Flawless Today. Right for Tomorrow.
NPAC

Podcast: Why large Projects Fail Part 3

CHAOS Tuesday #40 is the third part of our series on why large projects fail. Our special guest is Dick LeFave. Dick LeFave is an experienced Telecom CIO. This show highlights the experiences Dick had during the first NPAC projects and other large projects. Dick encourages the need for continuous Innovation in the telecom industry and how NPAC is a platform for innovation. In this program we explore:

  • Project Ownership
  • Sustaining Innovation
  • Gaining consensus
  • Frozen Applications
  • Methods of Transitions

Dick LeFave is Independent IT Consultant and corporate board member. Mr. LeFave, CIO level advisory service, specializes in helping organizations in IT transformation and M&A implementation. Dick’s experience includes over 25 years at the CIO level and 35 years in various IT executive positions. Dick worked with AMDOCS, Ciena, Nextel, Sprint, and Southern New England Telephone.

CHAOS Tuesday: Conversation in CHAOS brings to the forefront principal research and thought leadership in the area of best practices for business information project management. Each week Jim Johnson with co-hosts and special guests will explore distinct areas of project management.

The program will cover project cases, suggestions on how to resolve an issue, pitfalls, warning signs, book reviews, and a history of lessons learned. Each program will dig down deep into one of the CHAOS Best Practices or a burning current issue. Jim Johnson will present special data cuts from the CHAOS research database and what they mean. The team will challenge conventional wisdom, slaughter sacred cows, and question everything. The program will be featured on The Standish Group website.

Podcast Transcript

Male Voice:

Welcome to CHAOS Tuesday where conversations are always chaotic. Our host is Jim Johnson.

Jim Johnson:

Hi. This is Jim Johnson. Today we’re going to talk about why large projects fail. This is part 3 of our series. We are focusing on the Big, Bang, Boom paper. That’s a good example of how to do a pre-project assessment and some of the things you need to consider when you’re looking at a large project.

My special guest today is actually an industry expert and seasoned CIO in the telcom industry, Dick LeFave, and he’s going to be talking about some of the issues around a new NPAC. So this is going to be pretty interesting. That along with my two hosts, Dan Horsey and Jim Crear, we are going to have a great show. But first let’s hear from our sponsor.

[Commercial]

CHAOS Tuesday is sponsored by Neustar with a commitment to privacy and neutrality. Neustar operates complex data registries and uses its expertise to deliver actionable, data driven insights. Please visit www.neustar.biz to learn more.

Jim Johnson:

I’d like to introduce my two co-hosts, Dan Horsey and Jim Crear.

Dan Horsey:

Hi, I’m Dan Horsey. I’ve been a chief technology officer for publishing companies and did a stint at the Internal Revenue Service working with their modernization program as the director of enterprise architecture.

Jim Crear:

My name is Jim Crear, CIO and senior advisor for the infamous Standish Group.

Jim Johnson:

Thank you, Dan and Jim. Now, I’d like to introduce Dick LeFave. Dick, tell us about yourself.

Dick LeFave:

Sure. I’ve been in the IT industry for over 35 years. I’ve been a CIO for 25 of that 35. A variety of companies from financial services companies; the Boston Company, part of American Express; Southern New England Telephone, Nextel; Sprint. And then I formed my own company which I am now doing consulting firm for the last five years where I do a lot of engagements with large companies for IT activities, CIO-related activities, et cetera. I found the business to be something I liked a lot and I’ve been doing it for a significant amount of time. I’ve certainly seen my share of good projects, bad projects, and ugly projects.

Jim Johnson:

Thank you. Can you give us your three takeaways that you received from the Big, Bang, Boom paper?

Dick LeFave:

Well, I think it exemplifies the characteristics of large projects usually proposed to have great benefit but then they have high risk. So when I look at projects that are sort of structured in the same way, I look at them; I see characteristics that are similar. I look for ownership, difficult to find, who’s going to own this large project, and who is going to steer the process? So the business owner is an issue that needs to be clearly defined.

Another issue is it’s a very expensive project. It could be extensive in time. And the longer the project takes to do, the higher the risk. And then who’s going to stay with it and deliver it? Who’s going to shepherd this project through? Consistency of the team both on the technical as well as on the business side plays a huge role in the success of a project. And as shown in many of the analyses around what do you look at when you look at projects and the composition of their success or failure, every project runs a risk of ending up in the failure bucket if you don’t follow some of the basic components. I think you looked at it in terms of the paper.

You need to have ownership. You need to have adequate investment. You need to make sure there is a business case that shows what the value is. The point about deliverables is very important. So what are you going to get when? And then you have to ask yourself the fundamental question at the beginning: so what? So what do I get? Is this investment worth the amount of money that I’m going to put in to this for the benefit of what? So when you compare the cost versus the benefit side of large IT projects, the best ones I’ve seen are the ones that basically deliver value to the business in discernible, clear, very well-articulated ways so that the business walks away saying, I got my value for what I did.

Jim Johnson:

Thank you. Now, the paper features the NPAC, the Number Portability Administration Center. You were at the beginning of that project, and you’ve suffered through that project for a few years. Can you tell me from your experience how that turned out?

Dick LeFave:

Well, I think in the early stages of the first round of the whole deployment of portability, there were a tremendous number of unknowns. We were not very well skilled at defining the multiple stakeholders and their roles in the process. At that time, we had multiple options to go with. We could have gone with the Neustar solution. There were other solutions out there other people could use. We chose to go with what we thought was at the time the best collaborative model.

What did we learn? We learned that it was more complicated than we thought it was. Our testing required a lot of work, not just the initial testing of the interfaces between the telco infrastructure but also within the telco infrastructure because now we had a capability we never had before. I mean, now we had number portability that had to interface through all the infrastructure systems through the customer care component all the way through to the customer. And the customers were going to get a new capability that needed to be defined, marketed, articulated, and then we need to provide support for them.

So, we, in the early stages, it was rough sailing. We had problems with being able to port between various carriers. We had backlogs we needed to manage too. And it took us awhile to sort through all of that. It wasn’t something we did overnight. It took us months to be able to get through how we were going to work interfaces with varieties of carriers at different levels. The big carriers had spent a significant amount of money on infrastructure. The smaller carriers were still struggling with how much to invest. So that whole process was not simple.

The technology at the time wasn’t as sophisticated as it is today. There are certainly more tools and solutions that are available today than there were then. Those changes sort of take on their own enablement of projects like this. But when we did number portability, it was in the early stages, and it was the introduction of a new capability being able to move a customer from one carrier to the next, but then get their plan right, get their information right, and then make sure we didn’t encumber the customer where their phones wouldn’t light up. In those days, phones didn’t light up right away. There were hour delays between the time we ported someone to the time we actually activate them. Now all that stuff is instantaneous. We’ve moved further up with great sophistication that makes portability a non-issue.

Jim Johnson:

So the idea that another company would come in and replace Neustar as the operator of the NPAC, what kind of challenges do you see them facing?

Dick LeFave:

Well, I think anytime you talk about a transformational project like that, it’s challenging. I think you used the right word. I don’t think it’s a walk in the park for anybody. I think it’s going to require (a) a lot of investment to make sure that you’re up to the speed to be able to handle a project like this; great project management capability tools and people to be able to make that work; a clear understanding of a business case in terms what do you get when and how, and what’s your expectation. Are you clearly articulating to your business community? What am I going to give you when you’re going to get it? Because remember, this truck is running down the highway 65 miles an hour. The wheels are all on it; it’s running. You’re going to try to change tires on some of those wheels.

Those projects are complicated, very, very complicated. Forget about moving into a new business area or augmenting an existing system. You’re going to make a major transformation. It’s no different than doing an ERP system, swapping out SAP or Oracle or doing any of those. This is a major effort. And you’ve got to make sure that whoever or whatever is going to manage through that has the discipline and the investment and the governance to deal with it. The question is who’s the owner? Who owns this and who’s going to have a feeling of expectation of success or failure? And who guides this? So somebody steps into the chute and they all of a sudden have it. Who is going to be the guiding factor? And if it’s a collaboration of multiple players as we said from the very beginning of the first time, some will get it and some won’t get it. Some will have investment; some won’t have investment. How do you make all that work?

Do I think that the companies that are involved in this now are sophisticated and capable? They’re far more advanced than they were when we did it the first time. But still big projects are big projects. They all have the same DNA. The bigger the project, the bigger the risk, supposedly the better the reward. But if you don’t have the fundamentals, the project isn’t going to work right.

Jim Johnson:

What do think the investment is going to be for the 5,000 companies that use the current NPAC?

Dick LeFave:

Well, I think they start by looking at what do they spend today, because you’re going to migrate off of a platform with a new interface. For some companies that do a significant amount of internal systems, maybe it’s an API connection. But in some cases it’s a major overhaul of some of their infrastructure, so every company has to look at how do they want to use this capability and how does it affect the workflow from the perspective of the customer?

So if you begin with the customer being the person who buys the service, working that workflow all the way through, you’ll detect very quickly where are the breakpoints, where is it going to have complexity that you may or may not be enabled for? And remember some of this has been driven for years and years and years to a point where it’s a utility. Unfortunately, people view it as sort of I just logged into this thing. I plug in. I get what I’m supposed to get. I port from carrier A to carrier B. I just sort of get the information I need and I can function. You have to be able to continually enable that because at the end of the day, nobody wants to hear about I got to take an outage.

Look at the frustration with all of the affordable healthcare website issues being down for weekends, being down for weeks, being down for maintenance, being down to fix. Those kinds of stories don’t play well in Poughkeepsie. If anything, people look at that as though, you know, we didn’t sign up for that. We signed up for what you told me, which was all the good things.

Dan Horsey:

But I look for instance, I think, about the IRS and the systems that they deploy. These are systems that, number one, it’s not a question of whether or not we want to do it. It’s mandated by Congress that we have to have it done. Not only that but it’s mandated by Congress that we have to have it done by a particular date. And if it doesn’t get done, not only are we in trouble with Congress but there are serious economic issues for the IRS not to be able to collect taxes on April 15th.

Jim Johnson:

Thanks, Dick and Dan. Now, let’s hear from our sponsor.

[Commercial]

CHAOS Tuesday is sponsored by Neustar with a commitment to privacy and neutrality. Neustar operates complex data registries and uses its expertise to deliver actionable, data driven insights that help clients make high value business decisions in real time one customer interaction at a time. Please visit www.neustar.biz today or alternatively, www.neustartechnology.biz.

Male Voice:

The maxim of the day is “The inventor looks upon the world and is not content with things as they are,” Alexander Graham Bell.

Jim Johnson:

A new NPAC provider would take two to three years to get where Neustar is today. During that time, Neustar would freeze what they’re doing today. So we’d lose two to three years’ worth of innovation. How do you think that’s going to impact the industry?

Dick LeFave:

Well, I don’t know. I don’t know any platform that can sit still for three years and expect not to continue to innovate and provide services. I mean, things are changing. Utilities or telcos constantly are in the process of innovating new marketing solutions, coming up with new ideas, coming up with new solution and capability. So a platform that’s static is probably a platform that’s going to suffer in terms of its ability to support marketing. It’s going to make it very difficult. I know companies who, you know, they do ERP transformations all the time and they work through it. But at the end of it, your platform doesn’t stay static for that extended period of time.

Jim Johnson:

How do you think a frozen platform would affect the transition from PSTN to IP?

Dick LeFave:

Well, I think this frozen platform conversation is sort of the nuclear option. When you look at it, you say, wow, this is -- when you talked two to three years of a platform that’s static and then you think about what kind of support and maintenance. I do a lot of work with different companies around infrastructure and security – activities like that. Patching is probably the number one motivating factor to keep a platform stable. So what are the rules around that? How is this platform going to sustain itself? And the nuclear option to me is that you sit there for three years and you go nowhere. Companies are going to move on. They’re going to figure out another way. At this stage of the game, they have a platform that works. They have a platform that’s evolving. So you’re going to change all that. And again, the two to three year model is probably the most difficult one to appreciate when you look at these systems.

Jim Johnson:

One of the things that companies bid on is the specifications. One of the things that a new NPAC provider would rely on is specifications. What’s the delta between the specifications and real life?

Dick LeFave:

It’s a good question. A new provider’s challenge is going to be how do I know how this works and what knowledge do they bring to the table? What product understanding do they have in terms of the platforms? The best transformations are when you understand how it works and you adapt to that so you can take advantage of it. Unless you have figured out another way to do this that streamlines everything, if you have some type of a disruptive technology that sort of inserts itself into the process and wipes out all the old stuff, makes it so simple that you don’t need to do it, that’s the way you’re doing it today. Then it’s kind of a matter of learning the how-to model, making sure you’ve got the right people to do the requirements and the specifications. But then again, you’ve got multiple groups of people, different constituencies from large carriers to small who have different requirements.

Jim Johnson:

There are three options to recreate the NPAC today. One, you could take the code that’s sitting in a vault somewhere in Virginia and take that, create your own infrastructure, your own service organization, your own support organization. So that’s one method. You could take the specifications as they were written 17 years ago and try to update it on today’s environment and create a new code based upon modern technology. A third option would be to take an existing package running in another country like the UK or Germany or India and modify that package to work in the United States. Of all the three types, which do you think is the most dangerous?

Dick LeFave:

Well, I think that starting from scratch is probably the largest or the most significant exposure because you’re going to have to build what has evolved over a significant amount of time. So you’re starting with a blank sheet of paper, maybe some modules, maybe some open source, maybe some capabilities. Those projects by their very nature are extremely complex and high risk. I would say if you’re talking about taking an existing package and modifying it, the only failure or success to that is how good do you get the alignment of the requirements. So you have to have -- again, the truck running down the road. You have to be able to operate at the same speed. If people are used to portability in a certain amount of time, you have to be able to mirror that.

So if you’re taking a package where portability is not as important, if you’re taking a package where portability takes longer, if it’s a case where you’re dealing more pre-paid than post-paid, these complexities make it harder to do that alignment. Can it be done? Sure it can be done. But the question is how much time will it take and how much testing is it going to require to get that product to where it needs to be? That’s two.

The other one is taking a code from somebody else and managing to it. Can it be done? Sure, but do you understand it? You don’t walk in and download a bunch of source code and manage it. You have to dissect the code, understand the code. A code is not easily transferable. Intuitively, you need people who can support that. So you have to build to each one of those scenarios. And then the question is how much is it going to cost and how long is it going to take? Where are your milestones along the way? How are you going to make sure there’s failure or success? What are the drivers to get to the point where you want to get to? And can you wait as long as it takes to get it up and running?

Again, back to a model where you’ve had a platform that’s run for numerous years, providing certain services, whether it’s economically feasible or not to run at this rate, that’s a value discussion that carriers and customers always have to have around that. But the physical component of being able to deliver services requires an innate knowledge of what is this capability supposed to provide. The problem you run is, again, you have a portfolio of customers. You have large carriers, small carriers, medium carriers who all require the ability to connect. It’s not that simple as to say, well, I’m just going to do it for three or I’ll do it for two or maybe I’ll do it for five. You’re talking about hundreds of these carriers who need to build to a standard to deliver that service. The clearinghouse, the call center to be able to handle problems if it doesn’t work, that kind of capability doesn’t invent itself overnight.

Do companies like Ericsson and other folks have the ability to do very complex projects and services and systems? Absolutely. The question is, is this one in the timeframe you’ve bounded this and the service delivery you need something that is achievable and what’s practical? And who decides whether it’s achievable and practical? Obviously, the customers do. It’s going to be more complex than you’ve expected it to be.

Jim Johnson:

I’d like to get back to the idea of moving to an all-IP telephone system. When you look out into the future, when do you see that happening? What are the transitions going to be for that? What’s your vision of that?

Dick LeFave:

I think it comes in different waves, but I think for sure it’s accelerating rapidly. All these companies are driving to that model. It comes in layers. I think there’s a provisioning capability at every one of the layers. You have the switch layers that have to be capable of supporting it. You need the international networking capability to be able to do that. The software needs to be able to do that. The whole migration from hardware to software in the form of a software-driven network is clear. I mean, you look at companies out there today that are leaders in that space like AT&T. They are aggressively pushing along the whole software development model for the ability to isolate software from hardware so they can use hardware as they see fit. So switching is changing rapidly. I think three to five years is probably a good window.

Jim Johnson:

So three to five years we’re going to be on IP, and it would take three to five years to get a new NPAC.

Dick LeFave:

Yeah, exactly, and I think you have to figure that as one of the layers. So if you’re looking to stretch the model effectively, one could become the gating factor on whether you can move as quickly as you want to.

Jim Johnson:

Yet, when we consider vendors and we consider suppliers, if you have the opportunity to choose between the low-cost provider that would give you the basic specs and give you exactly what is called for in the RFP or proposal versus another vendor that actually would charge you a little more money or maybe a lot more money but would give you extra services, would make sure that the thing was working flawlessly, would execute a transaction in seven seconds, which would you choose?

Dick LeFave:

Well, I would look at it from the perspective of what is the value, and value isn’t always cost. Value is functionality. Value is delivery. Value is reliability. Value includes things like dependability. Can I count on the vendor to deliver what they have? And how much risk are you going to put me at from a carrier perspective to look at these various capabilities to change what I’m doing today? Now, maybe I can save some money. Okay, I can save some money, but am I going to be exposed in the other side by not getting the value proposition that I want? Am I going to pay for that savings in the form of additional internal cost, brand impact, marketing? How am I going to deal with all these? And are you going to disrupt the marketplace in such a way that the customer won’t understand it and you’re going to impact the brand?

So it’s kind of brand value is more important. And when I look at systems today, regardless of whether it’s this or others, I look at it from the value prop. Cost is only one piece. But there’s also the risk. There’s also the cost internally. I mean, you roll up the whole total cost of ownership for these projects, they’re huge. Is it really what you think it is when you look at the benefit side?

Jim Johnson:

The book of the week is Outliers: The Story of Success by Malcolm Gladwell. Gladwell is one of my favorite authors. He’s really entertaining. I love his books. The three takeaways from this book I found that there is no really common factor for success. In fact, a lot of what he talks about is that you are born lucky in the right time and the right place. So luck has a good portion of why people are successful. But the other thing, he calls it the 10,000-Hour Rule, which means you really don’t get proficient on any activity until you’ve worked for 10,000 hours at it. And if you think about the NPAC and a new company coming in, that means that every person will have to work or have worked 10,000 hours in that activity. I think that’s a tall task to accomplish.

And the other thing is the environment has to be successful. In other words, it has to be an environment to make it successful. This of course is all about our emotional maturity test kit and how to improve your environment to make sure the project is successful. And I think that people don’t spend enough time looking at the culture and looking at the culture for success. So I really like this book. I give it four out of five butterflies, and I think you should read it.

I’m here with Bill Reidway, vice president of Neustar. I want to get his comments on what Dick had to say. Bill, what do you think About Dick’s comments?

Bill Reidway:

So listening to Dick was fantastic, just given his experience when he was here, you know, from the early stages of local number portability and saw what the industry went through in order to get this essential capability out to customers at the time. A couple of things that I took away from is the extent to which local number portability and the data that comes from the NPAC is embedded so deeply within service provider infrastructure today. It goes so far beyond just the notion of walking into a store and being able to change out your service provider and keep your phone number.

This is the platform that allows carriers to get access to new telephone numbers and inject new value into their inventory. This is the platform that people use to upgrade their networks to new technologies and change their vendors and migrate to new technologies like all-IP infrastructure. And the extent to which not just the provisioning layers of the carriers but everything that they do from an operational point of view from billing, to customer care, to revenue assurance, to legal compliance, all of which relies upon this data. It was great to hear him kind of talk through that.

The second thing that I found fascinating listening to him was how the customer experience has changed from the time that local number portability was first implemented. People were sending faxes to one another because the infrastructure wasn’t reliable enough. We lived through those days, too, being Neustar, and we’ve spent years getting the industry and ourselves to a point where this really is invisible. It really is like running water. You turn the faucet up and there it is to the point where folks don’t really have to think about it.

And one of the things that as we contemplate the potential of moving to a new local number portability administrator is thinking about what would it be like to reset customer expectations back to the old days, to go back to an environment where carriers had to consider the possibility that the NPAC wouldn’t be available the weekend that they were going to be launching a new device or the weekend that they had a big network migration planned, and what that would do to not only the consumer experience but carriers’ abilities to invest and innovate on their own networks and their own service plans. So listening to Dick kind of talk about that experience I think has a lot of relevance.

Male Voice:

Today’s CHAOS Tuesday was sponsored by Neustar with the commitment to privacy and neutrality. Neustar operates complex data registries and uses its expertise to deliver actionable, data-driven insights that help clients make high value business decisions in real time one customer interaction at a time. Visit www.neustar.biz today or www.neustartechnology.biz.

Join us again next Tuesday for our infamous CHAOS Tuesday where conversations are always chaotic. Until then, be chaotic.