Recently I was asked to participate and prepare a Specification Review for a potential new client. There were just two of us involved in the analysis and we only had a week to review the client's in-house application.

The client is preparing themselves for growth and expansion and came to SSW to determine if their intranet web application, developed using ASP, can be migrated to ASP.Net before the end of the financial year (which is about 5 months away). There are many modules to this application covering all areas of the business including purchasing, client / supplier details, client orders, manufacturing, etc. etc.

We were able to succeed in obtaining the contract despite the fact that the two of us have less than 8 months of combined experience with SSW. So, I decided to share with you the strategy we used that worked for us.

When negotiating a contract for new business it's important to keep in mind that the people that you are selling yourself to are not generally going to be in IT. This one point alone is the key to success. Let me explain a little about why IT plays a lesser role in winning new business.

If you walk into a business with an IT mindset and make recommendations about how you and/or your company can improve their systems you are most likely to be dissapointed when you walk away empty handed. The reasons are simple and yet a lot of people just do not understand why and/or how to go about winning new business. The key is to apply what I call the 3 L's. Look, Listen and Learn.

You Look through the client's system AND more importantly you Look at their business. It's crucial to identify how the business is run and how the internal processes interact with each other. This is made easier if you already have the first-hand practical experience behind you. Without this experience you cannot be expected to ask relevent questions outside of your knowledge of IT. Textbooks are a great source of information about how businesses operate but that is all they are, textbooks. Each business is different in how they work and operate and knowing the basics is a good start but actually knowing the processes from experience is better.

You Listen to everything that the client tells you and read between the lines. Often a client will tell you more than you may at first realise and being alert to this will give you an advantage. Ask questions about their business, how it got started, where it's been and where they would like to take it. This has some nice side benefits in that you get on side with the client by taking an interest in their company. You also need to concentrate on how the business is operating internally and if required how it interacts with the outside world. This is where an understanding of business processes really comes in handy. You are now working out how the business operates and your knowledge will allow you to see where there are potential issues within the client's processes. Asking questions about why they do things the way they do and providing other real world scenarios gives the client the confidence in your abilities in understanding their business.

Have you noticed anything about what I'm trying to tell you here? There's nothing about IT yet....NOTHING. We're gathering information and we want as much information as we can get. IT matters are the last thing that you want to be pushing out to the customer until you understand their business. I find that IT professionals THINK in IT. This is a bad thing to pocess and is only really useful when you are working on their systems. ie. If you cannot think outside of IT then you are better off cutting code and leave the initial analysis to those that can.

Next, you Learn what it is that your client is wanting to change / add / remove about their business. This step is really a concept that is applied to the first two L's (Look and Listen). When you have an understanding of the business rules and processes then following the client's requirements by comparing them to what you now already know makes this step a lot easier. ie. You'll be better equipped to understand what the requirements are and you'll also be able to foresee potential issues before any work is performed.

Sounds a lot harder than it really is...trust me! :)

As part of your investigations into the client's system you should document the screens/forms and grab screenshots along the way. Make a note of any errors, badly formed messages, complex forms etc. etc. You'll be needing this later as 'proof' to support your analysis of their system.

During your interviews with key staff members take notes about their concerns and ideas. Document the processes that they need to perform to complete a task. If you can see an easier way to do something then make a note of this in your documentation and also explain your thoughts to the client. Ask lots of questions and challenge why they do things that way (be polite when you do this as you don't want to annoy anyone). Ask if you can try entering unusual data in an attempt to cause an error. What you're really trying to do here is identify areas where improper data entered into a field could cause the system to break. eg. enter alphas into what should be numeric fields, or decimal values into integer fields (quantity fields are a good place for this). Document any unusual side effects that this causes.

Use SQL Auditor (providing that the client is using MS SQL Server) to get an idea about the queries performed. Time how long a query takes to return a result. Perform a quick analysis at the database and note how many tables there are, what relationships have been established, if there's any indexes etc. etc. The information gathered here might provide some immediate relief to the client by way of introducing indexes. All of this should be included in your findings. If performance gains can be accomplished by the simple introduction of an index then do a before and after timing test to prove your point and add this to your findings.

When you prepare your findings keep it at a high level. Don't put too much emphasis on the IT aspect. Remember, a client loves to hear about themselves and how good their systems are. Your findings should effectively praise the client for their good work while at the same time showing where the system can be improved along with the client's requirements.

If you're worried about your findings not having enough IT content then don't be. After the client agrees to give you the all clear to commence work then you can provide further documentation with more details relating to IT.

One last thing before I finish up, the client has brought you in to go over their system and in their eyes you're a professional. Act like a professional, be confident in your own abilities and always be honest to your client.

I hope that you find this information helpful in your own projects, it certainly works for us. I've used a similar technique before and mostly with success.