End-to-end responsibility

September 1st, 2008 | by Ivan Pepelnjak |

If you’ve ever had the “privilege” of buying equipment from a large systems integrator (or directly from a large vendor), you’re probably familiar with this process:

  1. The salesman (politely called the “Account Manager”) brings an engineer (“Sales Engineer”) with him. Although they do some network design in the presales cycle, their usual focus is the “kit list” they need to place an order.
  2. If you’re not proficient enough in the technology you’ve just bought, another team is brought in: the Professional Services (PS) team. Ideally, the kit list produced in the early design phase is accurate enough to implement the network. However, I’ve been involved in projects where no one knew what the kit list was trying to accomplish, and we were forced to design the network around the existing hardware (although half of it was superfluous) in order to satisfy the customer.
  3. Once the network is up and running and the ready-for-use (RFU) documentation is signed, the Professional Services team is gone. When you encounter post-implementation issues, you have to talk to Technical Support. If you’re a big enough customer, the Technical Support team might have the design and implementation documentation prepared by the PS team; otherwise, you have to explain to the Technical Support team what their Professional Services colleagues were doing.


Fortunately, NIL realized more than a decade ago that this system was broken, and we implemented a completely different approach that has remained very successful (even though we’ve grown from 15 to almost 100 employees in the meantime): a single engineer is responsible for all phases of the network lifecycle.

To start with, we don’t have presales engineers. When salespeople need technical support (whether for a customer visit or a follow-up technical solution), they get the best engineers from the support group. These engineers also prepare the network design and sign the kit list before the proposal is sent to the customer. Ideally, if the customer understands the value of our services, a detailed network design would be done before we even start discussing the details of the kit list; otherwise, the engineer who produced the kit list also creates the network design that serves as the blueprint in the implementation phase (also led by the same engineer)… and he remains the primary support contact for the customer. This procedure ensures that there are no easy escape routes: if you’ve messed up the design, you will have to fix it yourself and live with the network – as you’ve designed it – until the next upgrade. Because no engineer wants that sort of headache, he ensures that the design is well planned, right from the beginning. Sound too good to be true? Believe me, it’s true (you can easily test it), and this approach results in fantastic customer satisfaction and loyal customers.

  1. 2 Responses to “End-to-end responsibility”

  2. By MPLS-Routing on Sep 3, 2008 | Reply

    Ivan

    In our company we used to follow the tradition which you were talking about. But now a days out CTO has changed the same like you were talking, in which a technical guy is sent with the sales person to understand the problem and after that technical guy prepares the design and handover to the implementation team and design guy will work with that team also. Prior implementing the solution we were fcing lot of problems like sales & presales guy commited the solution which may have some constraints in technical but now a days after the implementation of new solution we relaxed so much.

    regards
    shivlu

  3. By pavel skovajsa on Sep 15, 2008 | Reply

    Ivan,

    there are number of areas in which I think your way of running a company has couple drawbacks.

    Mainly I think that this is not a sustainable model for running a bigger company as it does not conform to the ‘factory’ approach, where each unit specializes in the area in which they are best.

    Yes, I agree that the way the ‘factory’ approach tranforms into reality is somehow cumbersome – sometimes presales are ‘too’ high level (“let’s put some network devices here and there”), implementation guys want to “just get the work done and gone”, and support people “don’t really care”, but I believe this all can be tamed and glued together with some good management skills and official handover processes.

    To give you an example, we at work have something which is called a ‘release to production acceptance’ process which is run every time ‘something’ has to move from ‘implementation’ status into full ‘production’ status thereby the implementation guys are handing over the network to the support guys. As part of this process the support/ongoing delivery guys check whether everything is properly documented and handed over properly, there are no flaws in the design, monitoring is setup etc.

    The second drawback that I see in this way of running a company is that it is against the specialization approach where some people are only good at certain things (talkative people for presales, tech geeks for implementation etc.). Also you are giving away the time of your expensive CCIE employee, just to fix some small problem for a customer and be distracted by it from current work, which has obviously cost implication for you and your customers.

    All in all, running the company with one man end-to-end responsibility is maybe nice for the customer, but certainly not sustainable and effective from long-term perspective.

    Regards,
    Pavel

You must be logged in to post a comment.