I lost my virginity back in 2003 (to the HR software industry) when a £37m agency asked me to build them an Applicant Tracking System. My first question was: “Isn’t there anything already on the market that meets your needs?” and then to check Google, like everyone does I guess. There were loads of applicant tracking systems on the market – and I mean LOADS. There must have been in the region of 50 or 60 systems at least.
But the Client said No, there was nothing that met their needs. Sure they liked the look & feel of one recruitment database, and the workflows in another CRM, and the friendly team in yet another… but there was no single recruitment software package that they felt ticked ALL the boxes.
So through the experience of developing and delivering that system to the Client (and delivering mission critical systems over 20 years) I’ll share with you the ins and outs of everything that needs to be thought about.
1. Define a strategy.
Get together with the other stakeholders (ie. directors, owners, key users, etc) and WRITE DOWN where you are now, and where you want to be. When you get there what will it mean for the business…? More profit? Expansion? An easier life? Whatever the perceived benefits, define them (and frame them, as you will need reminding when the project comes off the rails!)
2. Be a pessimist.
The glass is half empty, not half full. The project will take twice as long as you planned, and twice to three times what you think it will cost. And that’s if you get it right first time.
3. Raid the bank!
In terms of budget, good developers will cost GBP £350-£400 per day with a decent Architect costing more. Depending on the requirements, you can expect to paying a team of 3 for anything between 3 months to a year (ie. £25,000-£100,000). Don’t cut costs by hiring inexperienced developers – you’ll pay for it in the long run fixing the bugs they create. (It is 5 times as expensive to fix a bug once it is with customers, rather than when the software is being developed.) Set rigorous tests for them to prove their capabilities BEFORE you take them on. Don’t be impressed by a CV – they could be taking the credit for someone else’s achievements.
4. Stay well clear of the word ‘AGILE’.
This is cool programming speak for “Let’s start developing your software with no plan and just see how it goes.” Do the opposite – have a PLAN. A decent specification which starts life as a simple word doc explaining in plain English what the system must do, but then get’s fleshed out into a full Scope document with details, drawings, and timescales. All this must happen BEFORE you write a single line of code. Without it you’ll surely end up where you did not want to be, and much later than you planned (it’s like taking a trip across Europe without a map! Incidentally I’ve actually done that… and end up 200 miles from where I intended to be).
5. Test each piece as it gets built.
Once it’s working, test with real volumes of data (ie. 500/5000/50000/5m records) so you know it’s up to handling the load and you know it’s limitations. You’d be amazed at how many database systems aren’t tested like this during the development phase. And don’t whatever you do start building the next piece until the last piece has been signed off as complete, tested and satisfactory… and most importantly integrated successfully with the main project.
6. Know when you’re done.
Be faithful to the plan. Don’t get carried away and allow new features and enhancements to be suggested (and believe me there will be lots of ideas during development) and implemented. Be mindful that each new piece needs building, testing, and integrating.
7. Document, Document, Document.
Imagine building a Ferrari… then not having a manual! Imagine the old mechanic leaves and some new people have to look under the hood to figure out how it works, before they stick a wrench in -perhaps where they shouldn’t stick it. Without sufficient project documentation (database structure, code architecture, etc) you’re stuffed. Anyone you get to work on the software in the future will spend the first 6 weeks just LOOKING at it, trying to work out what goes where!
8. Involve the End Users…
..through this entire process! Get them to test each piece as it’s constructed, and provide documented feedback. Get the developers to physically stand behind the users and watch them use the system, they’ll soon learn which bits are intuitive and which are not.
I hope this helps! Reading it back it comes across as a little pessimistic. However a lot can (and will) go wrong with your software project, unless you plan correctly and take these factors into consideration.
The upside is that having bespoke recruitment software can make you a fortune. So that’s worth some effort, and some pain. But remember if it was that easy we’d all be millionaires, so beware of the pitfalls.
Best of luck if you’re planning to build your own recruitment software (and yes, I’m available as a Consultant to help with the process if you need me. We also offer the Darwin 1CLICK CRM system as base for anyone that needs a headstart and wants a dramatically faster implementation time, ie. days not months/years).