Microsoft Access Specialist

Important questions to ask when choosing an Access developer

1. What is the level and depth of their experience?

Depth of experience

There are many people who claim to be "Access Developers" but their levels of experience and expertise vary considerably.

Things to consider include:

• How long has that person been working with Access
• Have they been working with it pretty much full time or is it just a small component of their overall workload.
• Do they have extensive real-word commercial experience rather than academic or hobbyist experience
• Do they have experience delivering easy to use client facing applications rather than out-of-the-box appplications for their own use
• Do they have good experience of all areas of Microsoft Access? For example it is quite common to find developers who can build tables and simple forms but cannot develop the VBA code necessary to produce effective automation within the database
• Do they understand how Access fits into an organisations overall IT infrastructure?
• Do they have experience integrating Access with other office and back-office applications?

Level of experience

Although you made find it difficult to find someone who has experience of your exact situation you should be able to find someone who has experience in similar industries and types of organisations.

For example it is often important to find someone who has experience of working in a particular corporate environment with the levels of professionalism, presentation and communication which that involves.

Similarly if you work in a large organisation then finding some with experience of working in that type of environment and who understands the structures, politics and other nuances involved is important.

In many cases it is necessary for the developer to interact with your staff, colleagues and senior management and having someone with the experience and confidence to do this properly is critical.

2. Do they only work with a formal written specification and how to do they deal with changes to the requirements?

A specification document outlining the key requirements of the system allows you to check that no important elements have been missed before you start development and helps ensure that you know what you are going to get and that the developer knows what they have to provide.

The level of detail in a specification document will vary considerably. Also it is quite possible that where you have an existing system that is being upgraded or replaced that the functionality provided by this will essentially constitute a large part of the specification itself.

A specification document may be written by the client or it may be written by the developer after reviewing the clients requirements in appropriate detail. In many cases there will be a collaborative approach to determining the requirements.

In order to deal with the situation where requirements change during the course of development it is common practice for developers to use a prototype model of development where they will start off with a very light level of requirements documentation and quickly build a prototype system to show how the requirements would be met. This is then reviewed by the developer and the client in detail and refinements are made to it after which it is reviewed again.

This cycle may be repeated a number of times before the final requirements are fully realised. This flexible approach leads to a system that is as closely as possible aligned to the requirements of the client. It also eliminates the problems caused where previously fixed requirements keep changing. It does however, require a higher degree of flexibility and understanding on behalf of both the client and the developer.

3. Do they give you all the source code?

It is essential that your developer gives you the full source code for the system that they have developed otherwise you will be locked into that developer for future updates and changes and you run the risk of not being able to make changes if that developer is no longer willing or able to assist you in the future.

Even if the developer supplies you with a locked down database for deployment purposes you should ensure that you also get a full copy of the unlocked database.

4. What level of support will you get when the system goes live?

You should expect your developer to at least provide on-demand telephone, email and remote assistance support (remote control of your PC) via the Internet. The level of support, response times and precise methods of support will vary according to the complexity of your system and the needs of your business but your developer should be able to put an appropriate package together for you.

Support may be paid for in advance or paid for as it is required but it is important to have an understanding in place with your developer in terms of how support will be provided and at what cost.

5. What happens if you discover a bug after the project has been delivered and paid for?

No matter how much testing is done by the developer and by end-users there is always a chance that a bug will be discovered at some stage in the future. In all but very trivial systems it is effectively impossible to guarantee they are bug free and the time taken by the developer to give you such a guarantee would significantly add to the development costs thereby making the development uneconomic.

Therefore you should look for some sort of guarantee that bugs caused directly as a result of the development work are fixed free of charge. If you plan to part develop the system yourself or make or own amendments then you will need to have a different understanding in place as it then becomes difficult to identify the cause of any bugs. Also in highly collaborative projects where you are working with the developer on a unique and complex system it may be that you assume more responsibility for testing and need a more flexible arrangement for dealing with bugs.

6. Can I talk to your existing clients and see examples of your previous work?

All reputable developers should be happy to put you in touch with clients for whom they have done similar work. You should arrange to phone or visit these reference clients and quiz them on:

• how well they were able to develop a working relationship with the developer
• how well the developer understood their needs and requirements
• the quality of system that was developed and delivered
• timeliness, cost effectiveness and communication - how easy was it to get hold of the developer when required and how well did the developer keep the client updated with progress, and was the develop delivered within the expected budget
• quality of ongoing support

7. How do they charge?

This is a difficult question to answer!

Depending on the nature of the project developers will either charged a fixed price or a daily or hourly rate.

If you have very clearly defined requirements up-front then a fixed price arrangement may be suitable. Where there has to be more flexibility over the requirements than a daily rate is better.

Ultimatley you need to find a developer who has an appropriate level of experience and skill for your project and offers value for money and with whom you can build a long term trustworthy relationship.

As with most things in life the cheapest and most expensive ends of the market are best avoided.

Payment terms are also important and payment should normally be staged so that you make payments as key stages of the project are reached.