End-to-End Responsibility
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:
- 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.
- 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.
- 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.
When I was the technical director at a small (but fast growing) system integrator almost three decades ago we realized that this system was broken, and implemented a completely different approach that has remained very successful (even though the company has grown from 15 to over 100 employees in the meantime): a single engineer is responsible for all phases of the network lifecycle.
To start with, we had very few purely presales engineers. When salespeople needed technical support (whether for a customer visit or a follow-up technical solution), they got the best engineers from the support group. These engineers also prepared the network design and signed off the kit list before the proposal was sent to the customer.
Ideally, if the customer understood the value of our services, a detailed network design would be done before we even started discussing the details of the kit list; otherwise, the engineer who produced the kit list also created the network design that serves as the blueprint in the implementation phase (also led by the same engineer)… and remained the primary support contact for the customer.
This procedure ensured that there were no easy escape routes: if you had messed up the design, you’d have to fix it yourself and live with the network – as you’d designed it – until the next upgrade. Because no engineer wants that sort of headache, the designs were usually well planned from the start.
Sound too good to be true? It worked for us, and resulted in fantastic customer satisfaction and loyal customers.
however, what happens if that "single engineer" leaves the company?
It also helps that people don't quit overnight in Europe, so there's always a transition period.
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)
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.
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)