You'll never get a second chance at making a first impression; that's the old saying, and it's so true of many things. Take, for example, the standard life cycle of an IT project: design, build, test, and roll out.
All these sections are equally important for the success of the project; it is the data centre design stage, however, that is fundamental to good delivery and, more to the point, the requirement gathering stage. It is here that many a project has already been doomed to failure. Without good requirements gathered during the interview stage, the rest of the design team and the subsequent implementation and delivery teams are working with one hand tied behind their backs.
Without good requirements gathered during the interview stage, the rest of the design team and the subsequent implementation and delivery teams are working with one hand tied behind their backs.
Tom Howarth, Contributor,
The requirement gathering process is possibly the most important but most often least understood of tasks; without correct and proper requirements, the architect cannot design a solution that meets the customer's needs. It is amazing the amount of projects that still start with a "back of a beer mat" design.
Issues with pre-sales teams and requirement gathering
There are two main issues with the first major part of an IT project, which is often delivered by the pre-sales team in preparation for a formal bid. Firstly, a pre-sales team member is a cost-centre to the vendor and, as such, his time is seen as "free" to the customer but as an expense to the vendor. Subsequently, this leads to the vendor desiring that the requirement gathering process be done as quickly as possible.
This is the exact opposite of what should be done; the customer not only senses this desire for haste but views the requirement gathering exercise as a waste of valuable time that's spent not delivering the solution. This also impacts on the customers' view of the vendor. Remember, the requirement gathering stage is the first time, other than the initial sales pitch, whereby necessity dictates the vendor is on their best behaviour and only showing their best side.
The second issue relates to the skills required for the task; those tasked with the delivery of the requirement gathering exercise should be versed in business analysis. This task is not a technical task but a business function. It is about mapping the current business processes and functions, the desired needs and requirements to enable a solution architect to deliver a high level overview of the design.
All too often, technical people are tasked with the delivery of this section. This is wrong on many levels, not least of which is that a technical person starts thinking about the solution to be delivered and designed rather than concentrating on the requirements of the customer. A technical person will enter the conversations with a view coloured by their technical pre-conceptions; this can lead to a "shoe horn" solution, i.e. one made to fit a vendor model rather than one custom-made to the needs of the business.
That is not to say a technical person cannot do requirement gathering. A business analyst, however, will not be coloured by preconceived technical perspectives; they will colour the information in a manner that a trained solution architect can use in the next stage of the process. If this is done correctly, the next phases are made significantly easier.
Statement of Requirements Document
On completion of the requirement gathering exercise, the vendor will deliver a document called the Statement of Requirements Document. This document is the guide that will be used to drive the next stages of a project. It provides:
- An executive summary of the requirements for management purposes.
- A statement of key objectives -- a "cardinal points" specification. This means the stated aims of the project.
- A description of the environment in which the system will work.
- Background information and references to other relevant material.
- Information on major design constraints.
Requirement gathering is the most important but most often least understood of tasks. Without correct and proper requirements, the architect cannot design a solution that meets the customer's needs.
Tom Howarth, Contributor,
This document should detail all the needs of the customer, including their business processes and the issues that the solution will solve, automate or replace.
A business analyst will ask open questions to draw out as much detail as they can. So, instead of "Do you have an Active Directory?", the question will be proffered as "What authentication services do you use?" The former will elicit a "Yes/No" response; the latter will provide a deeper answer and provide opening for further probing.
Requirements define the problem rather than solve of the problem. In other words, provide what the user wants not what the user needs.
Mixing problems and solutions
Okay, so what happens if you mix problems and solutions? Well, there is not a proper understanding of the issues, constraints are muddled and ownership is blurred. This is a recipe for disaster.
So how do you stop making these mistakes? Simply by correctly segregating the information in the problem domain -- concentrate on what the business wants the system to do. For example: "User must be able to print from any printer in the building independent of their location" or "User must be able to access their personal desktop customisations from any device in the company." If not, do not attempt to design the system.
At the system level, it will state what the system must do, for example: "The system must deliver a seamless printing environment, capable of being used from any devices at any location" or "The system must provide access to user customisations from any device and/or location."
To make your life a little easier, here are four key questions that should always be answered with a requirement gathering exercise:
- What is the purpose of the project? Remember to focus on the problem not the solution, the solution comes later when you understand their needs.
- What is the underlying goal? To drive productivity, reduce costs etc.
- Is there an implied solution? This is usually the case, for example the customer is in the market for a virtualised infrastructure.
- What is the success criteria? , i.e when will you know the needs have been met.
About the author: I live with my wife, Catherine, and our kids in Lancashire, U.K. When not working or spending time with my family, I am blogging or answering questions as a moderator on the VMware Communities Forum. I've been in IT for more years than I care to admit, starting as a junior support guy on Novell and "Green Screens." Along the way, I have been a Novell Guy, the Notes Guy, "the Citrix Bod," an IT manager, and more recently a consultant, firstly for resellers doing Citrix and server-based computing. Currently I am an independent consultant specialising in VMware and its associated technologies, with a bias towards VDI. I am also an owner/blogger at PlanetVM.NET and have contributed to two books, VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment and VCP: VMware Certified Professional on vSphere 4 Study Guide.