Phase I – Project definition

In this first section, we are going to look at how we approach the project. This is broken down into four steps, as shown in the following diagram:

Let's start by looking at the business drivers.

Identifying business drivers

It may be an obvious point to make, but the key to identifying the business drivers is to really understand what you want to evaluate. By this, we mean is it a strategic decision based on the need to transform your organization with new working initiatives, or is there a more compelling event, such as the end of life of an operating system or application? It may simply be the need to reduce cost.

Whatever the case, you need to get that nailed down and written up on day one so the project has meaning and direction, and more importantly a baseline to refer back to when it comes to review time to gauge whether or not the project has been successful.

Primary drivers include things such as:

• Cost reduction – operating expenditure
• Centralized management of applications
• Scalability – faster, easier deployment of applications
• Reduced user downtime
• Reducing application refresh, deployment cycles, and updates
• Operating system migration

Now we have an understanding of why the business is considering this project, we can investigate further and start to build the specific business case.

Building the business case

Once we have defined the drivers behind an initiative or the compelling event that's kicked off the process, and understood the high-level objectives, the next stage is to start building the business case around these. By this, we mean to go to the next level of details and start to drill into the specific areas the solution needs to address.

To do this, you need to first understand the business strategy and then identify the key stakeholder for the project. We can then start to define the high-level requirements of each of the areas identified as drivers and also start to define user segmentation, for example, look at what different user types we have, how they work today, and what they need going forward. At the end of the day, it will be the end users who decide whether or not the project is a success. This leads us into the next section, the assessment phase.

Assessment

Once you have built your business case, validated it against your strategy, and identified that there is a requirement for a new way of delivering applications, the next stage is to run an assessment. It's quite fitting that this book is entitled "Learning", as this stage of the project is exactly that: learning about your current environment which is essential for a successful outcome.

So what do we mean by assessment? It comes down to several things that we are looking for. This includes examining your current application landscape by means of some form of application assessment so you can understand what applications are being delivered, to whom they are being delivered, and, more importantly, how they are being delivered.

The assessment is designed to build up a picture of what the current environment actually looks like. Some of the key metrics we are looking for include:

• Which users are using which applications?
• Application usage
• Are any applications being installed with a Windows Installer MSI?
• Identify any application virtualization/packaging technologies in use
• Unsuitable applications
• Which client operating systems are being used?
• Delivery methods (RDSH, XenApp, VDI, physical PCs, and so on)

If you have deployed a VDI solution already then you should have most of this data, but even so, if this was a while ago then it's worth re-running the assessment so you have up-to-date data, especially about the applications in your environment.

By gathering this assessment data, we are creating a baseline view of the environment. Then, as we move into defining the success criteria and proving the technology, we can refer back to the baseline as a reference point and use it to demonstrate how we have improved the current working environment and delivered on the business case and strategy.

There are a number of tools that can be used in the assessment phase to gather the information required and provide you with physical data, but don't forget to actually talk to the end users as well, so you are armed with the hard and fast facts from an assessment as well as from the user's perspective.

As part of the assessment, there are also some key things you need to understand about the existing application landscape and packaging strategy:

• Determine the existing application packaging strategy
• Is there a virtual first strategy, such as ThinApp or App Volume, or is it an MSI deployment with System Center Configuration Manager (SCCM)?
• Is the source media available?
• How does licensing work?
• Capture application usage per inpidual user

This information will help you to plan the number of applications per AppStack, bearing in mind that too many applications could increase the risk of conflicts between the different applications and also result in more complex management.

Defining the success criteria

The key objective in defining the success criteria is to document what a "good" solution should look like for the project to succeed and become production-ready.

We need to clearly define the elements that need to function correctly in order to move from proof of concept to proof of technology, and then into a pilot phase before deploying into production. You need to fully document what these elements are and get the end users or other project stakeholders to sign up to them. It's almost like creating a statement of work with a clearly defined list of tasks.

Another important factor is to ensure that during this phase of the project, the criteria don't start to grow beyond the original scope. By that, we mean other additional elements should not get added to the success criteria or at least not without discussing it first. It may well transpire that something key was missed; however, if you have conducted your assessment thoroughly, this shouldn't happen.

Another thing that works well at this stage is to involve the end users. Set up a steering committee or advisory panel by selecting people from different departments to act as sponsors within their area of business. Actively involve them in the application testing phases, but get them on board early as well to get their input in shaping the solution.

Too many projects fail when an end user tries something and it doesn't work. However, the thing those they tried is not actually a relevant use case or something that is used by the business as a critical line-of-business application and therefore shouldn't derail the project.

If we have a set of success criteria defined up front that the end users have signed up to, anything outside that criteria is not in scope. If it's not defined in the document then it should be disregarded as not being part of what success should look like.

Now that we have our assessment data and a scope of what we are setting out to achieve, in the next steps we are going to look at the options for proving the solution is fit for purpose and delivers the benefits required.