With this process such challenges should be rare, however, as network engineers within your organization should have early and frequent access to project information as it evolves through the analysis, architecture, and design processes. At times these challenges may be more political than technical. This is an unfortunate aspect of projects, one that we must be prepared to address. Fortunately, there will be a wealth of information by the time you get to the design, all of which can be used to address challenges, regardless of whether they are genuinely technical or merely political in nature. Before applying the discipline described in this book, my experiences were often that network designs would get challenged late in the design process, sometimes in competition for funding, other times over differing opinions regarding design choices. When such challenges were made, there inevitably followed long periods of discussion, wrangling, arguing over competing designs. What I discovered was that, without a welldocumented set of problem statements, requirements, architecture and design decisions, it was difficult to address competing design choices (technologies, vendors, equipment). Arguments often came down to differences in personal choices or desires, or at times simply what felt most comfortable-not a particularly strong position from which to drive a project to completion. However, after applying the analysis, architecture, and design processes, my experiences have been surprisingly (or maybe not so surprisingly) consistent. Armed with welldocumented problem statements, requirements, and architecture and design decisions, I have been (and continue to be) consistently able to address any and all challenges to my projects. In fact, when such challenges arise, all arguments quickly dry up as soon as I describe the traceability from decisions to their requirements and problem statements. As you will see for yourself, this is a testament to the power of this process. Addressing budget, schedule, and resource questions. Another type of challenge to the network design is to justify your budget, schedule, and resource expenditures. Questions such as “Why are we spending X$ for this project?,” “What are we getting for this money?,” “Why will it take this project so long to complete?” may need to be addressed. In addition, you may need to request more time or funding to complete your project and will have to make the necessary 426 CHAPTER 10 Network Design arguments. The background information provided by the processes in this book can be extremely helpful in arguing your case. Bringing newcomers up to date on how the design evolved. The documentation that you have developed throughout the project can be quite useful in helping others follow the evolution of your design. For example, I have found that those unfamiliar with the design (e.g., newly hired engineers) often have questions regarding why and how particular choices were made.