Douglas P. Smith

In my last post I went over briefly how to do an assessment. This article I shall discuss why you would want to do an assessment.

First, lets explain what an assessment is. An assessment, other wise known as a GAP analysis is defined as, “The process of determining, documenting, and approving the variance between business requirements and system capabilities in terms of packaged application features and technical architecture.” To put it in plain english, we take input from everyone on what they want and translate it into what can be delivered, taking into effect things like pre-existing condition, budget, staff, etc.

In my opinion the assessment does two things, it allows you to review an environment to see if there is anything that will impact your ability to bring the project in on time and on budget; and it allows you to set reasonable expectations with the stakeholders and decision makers. Let me elaborate.

When you are in the process of taking on a new project, especially for a new client, you never know what you will run into. I usually look at anything that will effect my project from end-to-end within reason. For example, if I am installing a vSphere Cluster using an iSCSI SAN as the back-end storage. I know they are purchasing all the equipment new and that the hardware has been certified to work with vSphere and I size it appropriately given a list of servers that will be virtualized with some baseline memory and CPU usage that was collected for a week upon request. I know that all servers will be WIndows Servers, but nothing intensely I/O intense like Exchange, SQL or ORACLE. I get a list of a rough number of users, groups and computers. I discover during my gathering of network configurations, that one of the devices is actually a cheap Netgear switch that they plan to use. This switch has no management capabilities and no support for jumbo frames. Here is the show stopper, they will need to purchase a new switch with the guidelines I set forth for this project. It would have to be explained this switch needs to be replaced before the project could begin. If the project were to use this switch it may cause unforeseen issues and cost the customer or the vendor unneeded costs for labor in troubleshooting.

Once an overview of the environment is done you also have to manage the expectations of the project outcome. Sometimes the client may have misunderstood something they have read or was told by a sales person. It is up to you to clearly outline what the product can and can’t do within the confines of the business requirements and the budget. This can be done in many different ways, but what I usually do is to do several designs. I give them the design they want without budget as a constraining factor and one with. There maybe some other designs in there depending on what the customer set forth as requirements. I will give you example, I had a client that wanted to deploy a separate ESX server at each location and have them replicate back to the central site. There reasoning for this was when our links go down we do not want people not to be able to function. I did a design on this criteria and when I presented it to them with the added cost, I pointed out one very important question during the assessment process; “In the last three to five years, how many times have the links go down, and when they did how long were they down for?” The answer was once, and it was back the next day. Long story short the added cost could not be justified for something that happened once within the last five years.

THese are just some of the many reasons to do an assessment before a project, there are many others. Remember though an assessment is a Roadmap of where you want to go, not how you are going to get there (that comes later on).

Before taking on any project, especially with a new client, I always insist on doing an assessment. An assessment should be used to uncover any issues that may impact the project (aka. a GAP analysis). Depending on what the project is depends on what you will need, you may need access to switch configurations, file data sizes, logon scripts (if anyone is still using them), and so on.

You will find that the customer will have most of this information readily at hand in different locations. It is my job to interpret the data, ask questions and make recommendations to stakeholders and decision makers. All this data is cleaned up and is usually included as a series of appendices at the end of the assessment document.

The assessment document should be written so that no matter the stakeholder or decision makers background they will comprehend a specific section. The executive sections should highlight benefits of the project, while the technical piece should highlight the design benefits.

If you have competing views of how a project designed, include full work ups of both all designs with costs and associated pros and cons. This will help show everyone which design is better from multiple points of view.

So we know the document has an executive section and a technical section. The document should be wrapped up with a cost analysis section stating the cost of the project, some high-level milestones and deliverables.