People who are paying to have a network configuration architected and implemented are usually on time requirement that limits when and how they do certain tasks. One of the first questions they have is 'How long will it take?'. They're looking at production schedules, sales calls that can't be logged into the system, invoices that are sitting idle and purchasing requirements getting delayed.

Every minor delay tends to cascade to the maximum number of people in an organisation. Everything causes ripples. Which means that the people in charge of schedules are rally displeased at things that disrupt them, and have very little empathy for 'routine' things taking longer than expected.

Unfortunately, the short answer on 'how long will my new network take to install' is "It depends". The general rule of thumb is that the simpler the network is in its architecture, and the more thoroughly its requirements are documented, the more realistic an estimate can be given, but the time is, realistically, an estimate.

Factors that complicate network implementations are wide ranging, and can come from inadequate hardware support for the network being implemented, such as insufficient router capacity, to data migrations onto new hardware. The other thing that slows down network installations is a tendency to want to rush them. On the surface of it, most things in a network roll out can be run simultaneously. And if everything works as planned, and intended, this is a great way to save time. Unfortunately, it also means that if something goes wrong, more things have to be checked to eliminate the failure point. More network installations have gone over budget and well past deadline due to trying to parallel install systems than for any other reason.

Similarly, things that can speed up a network installation include using a standards based implementation. Using a structured cable system means that you're spending less time running cables through crawl spaces, and trying to identify which cable goes where. Likewise, using a standards driven approach to your network installation means that more of what's being put into place will work 'as the manual intended'. It's making networks that can handle legacy components that quickly turn into situations where the network engineers are all sitting around with laptops reading ancient manuals, trying to get something to work.

The more people who have to be supported in a network, the more complex the network has to be; this increases its topological complexity, and makes its architecture of server and data sets and security policies more ticklish to implement and set up. This is why most network installations are staged ones, where they handle one department's load, and then sit for a day or so trouble shooting, then implementing the next department on the list to see what can be done with it. Incremental roll outs take more time on the schedule, but end up saving time in the long run.

In the end, like any process, the choice lies between spending the time to do it right, or rushing and doing it over. Experienced network engineers will ask a lot of questions, and will build a schedule from the answers you give them. Understand that they're not trying to stretch out the installation to pad their paychecques, they're trying to ensure that it's done right the first time.