End-to-end responsibility

In the End-to-end responsibility post I recently wrote for our corporate blog, you'll find an approach to network design/deployment/support projects that has consistently resulted in very high customer satisfaction … as well as my views on the “industry-standard” approach to the same topic.

5 comments:

  1. it does sound like a better system, nobody wants to be lumped with implementation of some half-designed technically-impossible network sold to the client at a cutthroat rate

    however, what happens if that "single engineer" leaves the company?

    ReplyDelete
  2. This is a really good point :) There are mechanisms in place to ensure anyone from the technical team can figure out the current status of the customer network in a short time (the "single engineer" is obviously not always on duty and the customer might have a network-down situation in the middle of the night). I will write another post describing them.

    It also helps that people don't quit overnight in Europe, so there's always a transition period.

    ReplyDelete
  3. I disagree. The process you mention and dislike is the method carried out by the biggest vendors in the world and not just for IP networks and this is the network deployment lifecycle.

    It is not feasible when building carrier class networks to do it your way, both logistically and from a scaling the business POV.

    The problems you mention are due to bad management of the life cycle rather then the actual life cycle which is indeed proven.

    I do agree your way is very suitable for SMB.

    cheers (imho)

    ReplyDelete
  4. @anonymous#2: I guess you've mixed "responsibility" with "doing it yourself". If someone is "responsible" for something, it does not mean he has to do it himself (which would be indeed non-scalable and logistical nightmare in global deployment). The important part is that whoever has signed off the kit list, has to design the network with the kit the customer bought and retains responsibility for implementing it and getting it running.

    The problems I see in the "life cycle" you like is that the presales team can produce something that works on paper but faces implementation issues later on. The probability of this happening is reduced if the same engineers have to do a detailed design and lead the implementation.

    While I might agree with you that the approach I've described might not scale to huge networks, I doubt that some of our customers would like to be called SMB, but our opinions might differ.

    Last but not least, to end my comment on a humorous note, just yesterday Scott Adams had something to say about industry practices.

    And finally, I would really appreciate if you could take a few seconds, pick up a name or nick and use that. Although we'll both know your name is not Joe or Hamlet, it will be (at least) easier referring to your comments :) and will give them a slightly more personal touch.

    ReplyDelete
  5. hi

    Fair comments. Guess we need to agree to disagree, although its good that we can do this because it hopefully makes people think about evolving the whole process anyway.

    Interesting set of customers. I apologise for coming across as patronising (didn't mean to). I also work/worked for/with many of those same customers but have not yet bumped into you.

    Having worked almost exclusively in the carrier space. I do wonder if there are certain different ways of approaching the same processes as compared with the enterprise space. Correct me if I am wrong, but I guess the amount of money spent on a new carrier class network must be a more then that of a standard enterprise network and perhaps that focuses the mind on said process?

    cheers (IMHO)

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.