Are we trying to test a web application, an application, a device, or something else? This is where we start to identify what our virtualized environment is going to require; also, we identify how we are going to configure and build the required components.

This is the step where we will define what the time frame is for what we are attempting to create. In this area, it is important to have a defined timeline; otherwise, we could continue building with no set outcome. While some inconsistency or unknowns are part of the process, the better we define the time, the more productive we will be. It is like goal setting: if you set goals, but you never specify a time frame, then it is not a well-defined goal.

As you read this, you may wonder how goal setting made its way into these pages. For those of you who are wondering, I will provide an example. While developing labs for a training course for a client, I was trying to create and build a Cisco router emulation capability that works very well. As I had not decided on the number of tries, and more importantly, a time frame for this activity, this resulted in three days of fruitless activity. I will cover this and provide steps on how you can build your own later in this chapter.

The virtual platform required for the course was going to be Hyper-V. I used this solution for more than five years in a VMware environment, but no matter how much I tried, it did not work when I started to build the platform in Hyper-V. I first tried to convert one of my virtual machine VMDK files using the StarWind software, and that did not work. The network could not talk to the router emulator, and it could also not talk to the host. Therefore, in short, there was no connectivity. I then built the virtual machine from scratch thinking that it might work, and that did not work either. I worked on it for three days, reading every blog post, whitepaper, anything I could get my hands on. A better plan would have been to give it one day, or limit it to a number of tries, but when I started the plan, I did not have any timeline to it, and as such it cost me three days of time. I am sharing this with you now so that you, hopefully, do not make the same mistakes that I made.

A good way to quantify and track your planning is to use a form of time chart or project tool. There are several available, but it is beyond the scope of this book to cover them. It really does not matter which one you use. If you are like me, you would want to use a simple one and not have to learn another program. So, the one I use is the calendar within Microsoft Outlook. Some of you probably use Microsoft Project; that is fine, use whatever works for you. I believe that most, if not all, of us have used a mail program at some point in time, and if the capability is in the mail program, then it is something worth exploring.

We will look at an example. I use the tasks and event components together, so if you start your Microsoft Outlook program, you can click on New Items at the top of the menu. This will bring up the menu to create a new item. An example of this is shown in the following screenshot:

We want to create a new task; to do that, we click on the Task option, and this will open a new menu, as shown in the following screenshot:

From this point, it is a relatively easy process to create tasks and then be able to track them; furthermore, you can, at any time, refer to your task list and see what tasks still remain. You are encouraged to use tasks and events as you plan your building of network architectures. We will provide you with step-by-step processes to build your environment within this book, but when you stray outside of the book, there are chances you could run into challenges like the one with creating router emulations. When you do, it is essential that you plan for possible time delays and other unforeseen instances. The more time you spend in the planning phase, the fewer obstacles you will encounter as you progress to the later stages of development.