When getting a new database – pay attention to the delivery factors

For every Search Firm, there comes a moment when it must change the present database. Nothing happens overnight, but one day you are there. Simply put, one day, your database is no longer up to its task. Wait too long, and you may be too late. The moment to decide when to get a new database may be as important as to decide what kind of database to buy.

In any Executive Search Firm (in most Firms I suppose) the database is the very engine that keeps the company’s heart = the business “pumping”. In a Search Firm, in my mind, the database may even be more important than a Search Consultant or Researcher. Seldom will just one person stop your business, while the wrong database might do just that! The worst scenario case may cost you millions or even be the beginning of the end of your Firm.

How a bad database looks like! I have heard many bad stories about recruiting-related databases. E.g., the database does not deliver, is unreliable, lacks capacity, and is awkward, slow and insecure. We cannot customise it. We can never find any data because the codes are wrong and the data we can find is no good anyway because the data is insufficient, or no one has updated it. We cannot print the reports we want, and we cannot get the business intelligence we want. The screens are full of small text no one can see. It is impossible to get a good candidate overview on one screen. Difficult to learn, difficult to use. Horrible user experience. The list of complaints longer than my arm.

So, my question is: Why was the “bad” database acquired in the first place? Why did you not do a proper Due Diligence of everything before you acquired the database? The focus here is on “the why”, not on “who did this”. We all make mistakes, me too. Focusing on finding a scapegoat does not solve the problem. Finding out what went wrong and why might. Besides, I think people usually tend to know “who did this” but not “the why”. We should focus on “the why” so we do not repeat the same mistake all over again.

A metaphor to make a point: If you would like to become a Formula 1 world champion; a) choose Lewis Hamilton as the driver, b) choose the best Formula 1 car in the world and c) make certain all the settings in the car are right. That should, if not quite guarantee you to become a winner, take you a long way. However, if just one of these three factors is wrong, you will never have a winner. If e.g. the settings in a Formula 1 car are wrong, having factors a) and b) right will not help you.

It is the same thing with a database. If you have just one critical factor wrong, e.g.:

If your best practise and knowledge management are not up for their task.
If the database does not support your business needs If your database codes are wrong.
If so, even the most advanced database in the universe won’t help.

My point: Focus on getting all the business-critical factors right when you are in the process of choosing a new database! Define the business-critical factors in your work. Whatever database = software you are getting, it should fully support these factors. Easy for me to say, I can imagine many persons thinking. How do we do that? For me, it helps to focus if I think of business-critical factors as delivery factors. Why?

Well, in my mind, the only customer promise a Search Firm can have is to deliver results, to deliver as promised and agreed to the clients’ satisfaction – simultaneously delivering a high degree of customer satisfaction all through the search process for both the client and the candidates.

The Delivery Factors

I define a delivery factor is any factor that is critical for the successful execution of the search assignment, as stated in my customer promise above. In my experience, these delivery factors usually relate to the execution of the search process, the daily work and the needs arising from here. The database = the software must fully support the delivery factors. In a database, this puts the focus on factors like:

High efficiency, reliability, capacity and data security in the database is a must-have.
A 100% reliable and efficient help-desk service is a must-have.
The database input, processing, output actions, and functionality features must support your work processes as defined by your best practise and knowledge management. If not so, what is the point of having the best practise in the first place? The database should efficiently support the search process all through the search, e.g., the research, the contacting and evaluation of candidates, presenting of the finalists and the reference checking, and the CRM actions, both for client and candidate. Not having a best practise is not a very good strategy.
Some Firms put their money on marketing and branding factors instead. This may lead to excellent marketing, but potentially ignoring the delivery factors may lead to poor delivery. Excellent marketing and poor delivery is a bad combination. You first get a lot of Search Assignments – then a lot of unsatisfied clients.
Putting your money on delivering to everyone’s satisfaction is also the best marketing effort ever because here the satisfied clients and candidates will do the marketing for you.
Lastly, as to what to avoid, in any database, check chapter three in this article. If you bought a database like this the last time, don’t do it again.

When in the process of changing your database – project points

To give some ideas for the road, below some points I feel are worthwhile to pay attention to. I am not going into details as to what the database should look like. How could I? I don’t know the specific details or the exact needs of your company. Nor does any other outsider. I look here at the big picture and address some very basic issues, which I feel are important.

Someone must oversee the project and be in charge, so start by choosing someone to lead the project. In my mind having the business understanding is of paramount importance. Giving the project decision-making authority to an IT-expert have risks. No disrespect towards any IT-expert, but I feel that IT technology may start playing a bigger role than the business needs. Even more so if you outsource the decision making to an external IT-expert who does not know your business.
In a Search Firm, the project team should, in my mind, always include a Search Consultant, the Research Manager, and a Personal Assistant. Together they have all business process, search process and miscellaneous office work process knowledge needed. As a team, they have the skill, the ability and the know-how. Leave one out, and you may miss something important.
As a main rule, we should never start a database project by letting technological limitations become our guiding star, potentially restricting our thinking. Only our business needs should dictate what kind of database we should strive for. There always exist restrictions in any database, forcing you to compromise somewhere, but we should not cross that bridge until we come to it.
We should always start by doing a proper, thorough Due Diligence of “everything” potentially affecting the way we conduct our business in the future, e.g. all present work processes, personnel, database, client’s needs, candidate’s needs, the market environment, legal changes.
The starting point should be our business. The database chosen should be the one most efficiently supporting our business needs. Not because “everybody else has it, and they are tremendously satisfied”, or “the newspapers say it is a good buy”, or “the software provider promises you the earth”. Neither because “the boss says so” or “because your colleagues or competitors have it”. You are not your colleagues or your competitors. You may have different needs. Sometimes the decision as to what database to buy has already been made by the headquarters. This is no reason for not doing Due Diligence. You may need something your headquarter does not.
When you are about to buy a new database, you tend to ask the users. “Is there any particular feature you would like to have/need”? You will get a lot of requests. Here, at all costs, avoid “nice to have features”. They are simply put, features people like to have, but then never use. They also have the potential of creating unexpected problems and may unnecessarily burden the IT-support. Remember to keep on asking until you are convinced, that there is a real and genuine need for the request put forward. Only then put it on your list.
Here, if ever, it is important to be objective, pragmatic, rational, logical and to keep emotions and organisational ranks away from the decision making. Focus on facts only. Also, keep things simple. Avoid technical “IT-language” no one understands.
Remember, there exists no “piece of cake IT-projects” when talking about a business-critical IT-project. There exists no such thing as a “100 % perfect database” with no unwelcome features, surprises, bugs, limitations or restrictions”. Do not believe if someone tells you otherwise. The idea with a proper Due Diligence is to find out this in advance. Will you still bump into unforeseen problems you must solve? Yes, most likely, but now they are much less likely to be unsolvable.
Beware of first buying a new database and only later, surprise, find disastrous unexpected restrictions in it. Issues like “we can’t print this kind of report or CV” or “we can’t produce the business intelligence you want, sorry”, “we can’t use your codes”, “we can’t fit your processes into our system”, are easy to check in advance.
Everything should comply with the data privacy regulations, the laws and the local habits in the country and the market where you operate. Check this in advance.
Beware of having a code structure in your database that is practical, efficient, reliable, logically consistent, easy to understand, easy to use. If you have a bad code structure, now is the time to improve it. If you have a good code system, do not change it for the worse now. If you do, you still get a database all right, but not the database you expected. I can promise you that. Your code system is like the settings in the Formula 1 car. Get them wrong and – well you know the answer.

THEN WHEN YOU FINALLY GET YOUR NEW DATABASE, TAKE CARE OF IT!

The quality of your database is defined by what data you “put in” the database. Pay attention to inputting quality instead of quantity. If you want useful business intelligence, also remember this requires the business intelligence data first to be put in. No input – no business intelligence. Pay attention to maintenance and regular updating. A database of which, e.g. 20% of the information becomes obsolete every year is of no use to anyone.

Importing huge amounts of candidates from external databases may sound like a good idea. However, in doing so, you also import the updating work of the data, so maybe, this is not such a good idea after all. You can always go screen any external database when needed.

Pay attention to continuous improvement, ensuring you stay on top of things all the time. For me, continuous improvement, more than anything, is a mindset, an attitude, an approach to the work. You continuously try to improve existing systems and ways of working, including your database. You also try to look into the future, estimate what’s coming and somehow prepare for this too – in advance.

There really is a lot you can do to make your expectations come true. Should your database then not live up to your expectations, chances are, you may have only yourself to blame. Your database is usually what YOU make it be.

For those who are interested in learning in more detail about this subject, I advise reading my book How to recognise excellence in Executive Search.