This article was originally published October 28, 1999!
International flights provide a great opportunity to catch up on reading. This especially applies to the weekly, biweekly and monthly trade magazines of our industry. Each time I get this opportunity I look forward to my time to review this portal of our industry. One interesting and thought provoking news event reported was with regard to Telia’s recent ousting of Cisco due to an apparent failure to deliver against agreed deliverables in an integrated IP network solution. According to the report, Telia has experienced massive growth in its IP service market and wanted to invest in IP infrastructure to meet the growth demand. The deal in the hundreds of millions of dollars has faltered and neither side is really talking too much about it.
My first thought was “Ouch! That hurts.” Certainly it hurts Cisco’s reputation as it tries to gain acceptance as a carrier class solution provider and overcome the rumor of “not ready for prime time” carrier networking, but it must also hurt Telia as well.
The article stopped short on getting to the cause due in part to both tight-lipped parties’ lack of commentary.
What causes these problems? How could a major player like Cisco let something like this happen? Perhaps the article authors missed that school of hard knocks. I happen to own one of those T-shirts, and I’m not proud of it in the slightest. Any one who has been in the telecom business for a significant time and has been in the business of designing/building/selling telecom products has one of those T-shirts too (if you can get them to admit it). On the other hand, as I watch my next of kin learn from mistakes (as I’m sure many readers have as well), I can transcend the past. My philosophy is that the school of hard knocks is a beneficial place to have to visit every now and then to keep the learning process fresh. Based on my experience then, I am going to postulate on what could have gone wrong without regard to order of importance or probability.
Over commitment. Over committing is usually done on one or both of two planes: time frame and solution content. When I am teaching I often pose the challenge to my students: let’s say you are a network operator and you are nearly out of bandwidth between two major cities. A major customer of your competitor calls you up and says “I am a disgruntled customer, and I’m willing to change my services to you if you can provide fifteen DS3’s between A and B [the cities we are in trouble with]. Can you do it?” What is the right answer? Saying yes is an over commitment for sure. Certainly one we can rectify for this new business right? My point here is that this is an easy trap to fall in to, especially since we are operating in Internet Time.
Under-delivery of content. One can make a good commitment, both in content and delivery schedule, and then something goes wrong. Unexpected hurdles along the way can cause schedules to slip. In this business we rarely get an opportunity to pad schedules in case of an unforeseen problem. Try it some time and your competitors will probably win deals. So even with the best planning we face challenges and trade off’s must begin to be considered. This usually takes the form of feature content or what the developer will claim is unnecessary for initial roll out. Phased deployments become fashionable in this instance all masking the basic issue which is missing content.
Change in requirements. I sometimes used to call this the “go get a rock” syndrome. Interleaved into the requirements are some vague statements or even blunt TBD’s which all agree will be discussed later or, worse yet, are agreed to be delivered even though no one knows what the requirement is. So we go get a rock. Mid way through the program, a clarification or correction is made and this causes tension and a breakage in the relationship. “That’s not the rock I wanted.” So off we go to get another rock. Very few understand how to manage change appropriately and how to avoid changes in requirements by solidifying plans up front.
Political Motivation. These come in all flavors ranging from market level politics (we need to be in this space) to individual sales people needing to meet sales quotas to product managers needing to find a project and customer. The bottom line here is that serious business agreements end up being made based not in mutual success, profit and improvement. Let’s face it, in technology and telecommunications we are under a tremendous growth curve. While the Asian economic crisis was occurring sales of wireless handsets was growing exponentially and few of the Asian telecom stocks took beatings.
Master of Solution Story not the Problem Solution. Extremely sharp people, with clear vision, and mastery of a solution story often start programs. They can also seed new program concepts and direction. By the time this is translated into specific requirements and content, these visionaries get bored, transfer, and move on to the next opportunity. I am convinced, particularly in the field of telecommunications, too much of this goes on. It really comes down to a management issue. I used to have a sign in my office: “If you are smart enough to tell me my problems, be smart enough to offer a solution.” To extend this a little, if you are smart enough to offer a solution, be smart enough to see it through to delivery.
Lack of Communication. Any program agreement is a partnership. Any partnership is a serious business investment by both parties and alternatively levies serious consequences. If the relationship is not an open, trusting, and well-communicated one all parties will suffer. If I keep telling you I will deliver and I don’t, you will be very upset. Part of the communication model here is to properly set expectations. If I promise to install an ATM switch that is compliant to industry requirements and I deliver one that meets the requirements or one that has some additional features, you will be a happy customer. I have set your expectations at the right level and delivered or over delivered against those expectations. If I don’t do this I will not meet expectations and then regardless of what Herculean effort I applied to delivering what I did, you will be disappointed. Telling you about the Herculean effort afterwards usually has little effect. This is a communication model – proper setting of expectations – that can be easily overlooked.
Lack of total package vision. So you want my ATM switches, but the management system, the billing system, and the post installation support, integration, service, and customer care is not encompassed in my solution, then you end up disgruntled. No one can just “make boxes” anymore. Solving this problem requires that there are mechanisms and relationships, which extend the offering to cover a total package vision. If you think you know what the total package vision is, bounce it off your customer and double check. When you are done, triple check it. An example of this lack of vision was the Bricklin of the 70’s. A splendid new design with a center beam construction – a radical departure from industry standards of the time. But without a service and parts network the product never sold heavily.
As we have seen, there are numerous specific pitfalls surrounding what can go wrong and cause deals to fall through. Complicating this is you can also have an alloy of these specific items – a little of this and a sprinkling of that to make things worse.
While I have no specific insight into what happened to Cisco’s effort to deliver to Telia, I could say it had to be something from my menu of offered areas of failure. And with that, Cisco can probably add one of those T-shirts to its collection though the prize probably won’t go very far to heal the pain.