Monday, November 5, 2007
Recruiting Database: Build it or Buy It?
Over the years, contact database technology has changed, especially with so many off-the-shelf options out there. In the early-mid 1980s and 1990s had most search firms building their own systems - at a huge cost. Today, build-your-own is a more viable option with prices coming down in both categories thanks to competition and access to talented developers. My question to you is, "Build or Buy - and why?"
Subscribe to:
Post Comments (Atom)
7 comments:
I think the main difference is to look where your firm is today and where you expect it to be in say, five years. If it's significantly different (offices, people, markets) I think a proprietary system is a better choice because it can grow and change with you. Often the off-shelf providers hook you and then dictate what you can change, when.
With over 16 years experience in the recruiting and staffing software business, I'd like to take a shot at responding to the question, and apologize in advance for its length.
First, let me touch on a few of the pros for developing your own recruiting database:
1. Customized and configured for your supposedly unique business needs, processes, workflows and other application integrations -- this is a powerful draw, and the one most often voiced when going down the "do-it-yourself" path.
2. Developed in close coordination with the company's users, managers and other stakeholders, the software should be more responsive to the firm's business strategy and foster improved productivity across the entire organization.
3. Newly emerging technologies should enable the development, implementation and maintenance of custom developed software more cost-effectively than in the past.
Next, let's address some of the cons of developing your own recruiting database:
1. According to published studies, at least 40% of all such projects fail outright due to inexperience, management failures and the inappropriate use of technology. A good example is the estimated $50+ MILLION that Manpower had to write off in the late 1990's when it finally dropped the three-year development of its own solution.
2. Bringing in so-called "outside experts" in the form of IT consulting firms, such as Accenture, actually INCREASED the potential for failure according to one survey of thousands of custom software projects.
3. Again according to studies, fully one in three (33%) of all custom software projects were delivered late, over budget and/or with significantly reduced functionality and features than originally envisioned.
So, knowing that the overall odds for successfully developing a custom database are daunting at best, there are two questions that follow. Who can best afford to take the risk? And how can you improve the odds of success?
In answer, I would suggest that firms at the very small or very large size are those who can best afford the risk entailed with custom software development.
Why? For the very small firms (under 5 users) database needs are simple, development tools are inexpensive and relatively easy to use and overall risk to cost/benefit is typically not a "bet the business proposition". At the other extreme, very large firms (1000 or more user) theoretically have the management structure, business strategy vision and access to appropriate resources to successfully create a custom application for their needs. Recruiting and staffing firms in the large middle ground in size, in my opinion, are often ARE faced with developing a "bet the business" database, yet often lack the resources and structure to reduce the risk/cost of failure.
In answer to the second question of how to reduce the risk of custom database software development, studies and experts suggest that there are five keys to success.
1. Establish database development goals based on business strategy and management vision -- think five years out at a minimum.
2. Establish concrete budgets, timelines and specifications for features, functions, performance, scalability, support, maintainability, etc.
3. Establish project milestones that, if not met, enable you to cut your losses and/or re-direct resources. In other words, have a "Plan B".
4. Avoid "feature creep" at all costs. Once you've got a plan, specifications, budget and timeline, work it til it's done. Don't add to it. The time to do that will be after you've implemented it and get feedback from the field. Trust me, there WILL be a version 2, 3, 4, etc.
5. Get warranties and guarantees if dealing with outside experts or consultants. No brainer, here. Get it in writing and protect yourself and your business. Have a "Plan B".
So let's look at the alternative to the potential failure of such a custom software development project: Buying or subscribing to an off-the-shelf recruiting or staffing software.
The pros of buying off-the-shelf software include:
1. Faster, more cost-effective implementation. The software is ready now -- you'll gain significantly faster ROI -- often in months vs. years. This can give the business immediate gains in productive profitability that a custom database can only marginally improve upon.
2. Faster development cycles and lower total cost of ownership. The cost of building and maintaining an off-the-shelf package is spread out over a far greater user base. As a result, user feedback and their business strategies drive ongoing development by the vendor. Support and maintenance costs are reduced due to the economies of scale.
3. Keeping the business focused on its core competencies of recruiting and staffing -- not software development.
On the flip side, the cons of buying an off-the-shelf recruiting solution are essentially the same as the pros for building your own. That is, the perceived need for significant customization, configuration and complete internal control over the database.
To that I would suggest that there are now off-the-shelf recruiting and staffing software database applications that can address those business needs and strategies with a level of cost-effectiveness and competency unheard of even five years ago.
Build or buy your recruiting or staffing database? Hah! There are more than 130 firms offering recruiting and staffing software solutions. In the final analysis, it's important that you look at all of your options -- what fits your firm and more importantly, your business strategy and goals, before taking the leap either way.
An executive overview of an article on ZDNet from 2005 is a little long in the tooth but still hits most of the major points.
Buy vs build: The pendulum swings
David Braue, ZDNet Australia
24 February 2005 10:18 AM
We used to have a small healthcare staffing division and their needs did not fit well with any of the commercial products we were using at the time. Rather than purchasing a healthcare specific product we decided to build one in house.
What we ended up building was a simple Access database. It was by no means a complex multi tier application; however it was exactly what they needed. I think this is one of the big advantages to building your own. You only build what you need. Here are a couple of the pros and cons that we ran into:
Pros:
1. Since it was built specifically for what the users wanted, there were fewer moving parts and as such fewer bugs.
2. If something broke or there was a bug, the developers could immediately fix it. There was no waiting for support, waiting for a patch, etc.
3. If the users wanted some additional functionality, it could be added fairly quickly and easily. (Keep in mind that the can also get you in trouble. Like Michael's post said, you have to keep the scope creep to a minimum. You do not want your developers spending all of their time chasing / adding features that do not necessarily add value to the application.)
Cons:
1. It took quite a while to get the application into the hands of the users. Even though it was a relatively simple application, there was still some serious development time involved.
2. Even though small bugs could be fixed quickly, some of the bigger problems took considerably longer to address. One of the things you can get with a commercial product is not only the expertise of the vendor but the expertise of other users.
3. Lack of documentation. We made the mistake of not creating a comprehensive set of documents covering all aspects of the application. Most of the knowledge was in the head of one developer, so when that person left so did the knowledge.
In the end, we used the application for a couple of years and when that division was spun off into their own company they immediately purchased a commercial product. The upkeep of the application became an issue as well as the fact that they just outgrew the simplicity.
Do I think we should have purchased a commercial product to begin with? No, not really. That division was small (4-5 users) and a commercial product would have been overkill. I think the in house application filled in nicely until they were at the point where a more feature rich commercial solution was necessary.
Having been through the joy and pain of both let me simply say BUY don't build. This technology (ATS) has been around long enough now and there are a wide variety of options scaled to almost every users size and needs, many of these products have been around for a while upgraded and revised so you will benefit from lessons learned and feedback from early users and developers. Most today are web based and integrate well with other common (MS) technologies without costly re-configuration.
Build your own can be a long and expensive engagement that will rarely produce a system/product as elequent as what is available off the shelf today and certainly not as quickly. If you're simply looking for bacis resume storage and contact management with search capability you can construct a basic store and retrive system using access, may be good for a single user/consultant working alone.
Define what you want and expect from a system, shop around and buy only what meets your needs and is currently available - stay away from promises i.e: "that feature is in development and when we roll it out you'll get it for no additional cost". And understand like anything else technical you'll probably turn it over in 3-5 years.
I have worked in environments with both types of databases. The best ones I have worked with were the build kind, they facilitated searching of contacts in a variety of ways that really supported my way of thinking. On the con side - this database was so time consuming to input data into that it literally had a 25 page binder of codes to input for different meanings. Management of the data input rules and codes was a full-time job.
I have used several build DBs too and in many cases the query function was not as intuitive as I would have liked. They however were much easier to input the data into therefore more up to date with information.
Depending on the size of your organization having a build database could be costly to maintain from an infrastructure stand point as well. Many of the buy databases these days come in an ASP model which frees you from that responsibility.
In addition to the two options 'buy' or 'build' the third option to quick start is 'buy half cooked and get it customised to suit your needs'.
Post a Comment