Lessons Learned - Check List

Before dive into the lessons learned, have to set the stage where I've gathered this information.  Past 10+ years I've consulting multiple large scale SP networks and executed complex DC migrations.  These lessons captured when I failed to notice something and to enforce in the future activities. As the title of this blog have to share what I've learned to a wider audience. Some are well-known fact but keeping a note will help to do a quick check before each meeting. I'll divide it into three parts will follow up with

1.       Don't expect customer knows his/her network:

This is especially true in large SP networks; There may be multiple reasons I've seen few widely; components added to patch temporary, stay lifelong and people tend to forget it.  Added functionality no more used and people around that already left the company.  Therefore don't take everything customer says 100% true there is always surprise waits for you. If possible try to do your study

2.       When a customer asks whether a feature supported don't answer yes/no, try to understand what is the story behind it:

I'm not talking in marketing terms:), this is relevant to the next lesson, but there may be a better way to do, the customer doesn't know. If you know the background, you can assess better and provide a better answer

3.       When you are suggesting a feature, check across the current network hardware/SW support matrix:

Again this is difficult, but due diligent is better rather rushing for the P1 case. I've worked mostly with Cisco platforms, but I assume all vendors have feature gaps in different platforms and software versions. Therefore feature x may be supported in V2 but not in V1. 

4.       During design/requirement gathering meetings try to understand the scale it is critical what platform/design you are trying to position.

a.        Most of the time vendors don't provide all the scale restrictions information publicly.

b.       At least validate against the scale information you have.