First of all - thanks Mike for the sparkly new space!!
And now I need some help. I'm writing a proposal and I need some ballpark IT costs to put against my potential savings.
I work in recruitment, and I want to improve our internal and external websites, to allow CVs and screening documents to be submitted and then searched. Here's what I think needs doing:
Enhance content on internal website.
Enhance search capabilities of vacancy database.
Create email notification of vacancies for both internal and external candidates
Create database for internal and external applicants
I know that's really simple, but can anyone give me some ballpark figures and some timescales? Do I need to give you more information and if so what?
Thanks for your help in advance.
I won't be able to give you figures and timescales as web design isn't my area of expertise. However, I think that some technical information would be of help to someone costing this out for you.
For example, do you have a content management system for your internet and intranet sites? If so, what is it? Do you have internal staff responsible for maintaining this system that recharge their time? Do you use an external company?
What platform do the databases use? e.g. SQL, Oracle, Access, Sybase, etc.
If you're creating a database for internal and external applicants, what information will this need to hold? Who will need access to it? Consideration needs to be taken for data protection etc.
Will you want these separate databases you have mentioned integrated so the process flows through them? If so, possible case for consolidation.
I'll leave the rest to someone who knows what they are talking about in more detail ;)
See if you can find a service online that will do what you need. Unless your business is in the business of HR portals, find a package out there that does what you need before thinking about building.
I usually check in this order: Online, hosted solutions, Niche commerical packages (<10k), Open source software packages, commerical packages (>10k), in house development.
I like online hosted solutions because you don't have to worry about procurring infrastructure.
There are sites like LinkedIn, Jobster, Monster.
Check out for more packaged sites. http://dmoz.org/Computers/Software/Human_Resources/Recruitment_Management/
Hope this helps
I would second Noah's comments. Building something like that yourselves should be a last option. You can find all levels of solutions (and costs) from people who do this for a living. Go with one of them.
I have experience with one local mob - [url=http://www.pageup.com.au]PageUp[/url] - I have met the CEO and the company has a great ethos IMHO.
I usually check in this order: Online, hosted solutions, Niche commerical packages (<10k), Open source software packages, commerical packages (>10k), in house development.[/quote]
I third this - we follow this in our organisation and stay well away from in-house development where possible because it isn't our core business. At the end of the day working on anything that isn't your core business takes money away from that; and there are companies who specialise and can produce something far superior at lower cost to you than you'd achieve in house.
Apologies for not thinking to say so (thanks to those above!).
Guys you're fab! This is really helping me understand what I need.
Noah, I checked the link you gave, and we do have Bond Adapt as one of our backend systems. We definately also have SQL and Oracle and probably the others too!
So perhaps my question is not so much about creating databases as creating the interface to them? And the starting point to answering that would be to answer itilimp's questions:
[i]do you have a content management system for your internet and intranet sites? If so, what is it? Do you have internal staff responsible for maintaining this system that recharge their time? Do you use an external company? [/i]
I'll go find out the answers before I come back with more questions.
Thank you so much for all your help.
[quote="itilimp"]I third this - we follow this in our organisation and stay well away from in-house development where possible because it isn't our core business. At the end of the day working on anything that isn't your core business takes money away from that; and there are companies who specialise and can produce something far superior at lower cost to you than you'd achieve in house.
Apologies for not thinking to say so (thanks to those above!).[/quote]
Its been slow and I'm reading some things from the past - my apologies for bringing up a dead thread, but I felt like something had to be added to this.
Disclaimer - I come from a software development background, so its possible that I might have a slanted view.
What Wendii was asking about is the build/buy decision. My reaction to these three suggestions is that it is NOT always cheaper and better to buy your software. The more features you want to add and the more you'd like to customize it, the more you'll pay for pre-built. The more complex you're asking for now, the more likely you'll wind up buying a lot of extra features to get the ones you want and the development of those extra features cost money. I have seen a five year software install that cost over a billion dollars for a major package + customizations. A billion dollars equates to 10,000 man-years of work or 2000 people working for 5 years. The customization and installation costs can wind up costing much more than the original product.
Don't compare the cost of developing an equivalent product. Compare the cost of this product against what it would cost for you to develop what you want. When you get into development areas that you don't understand, get help. I've led a lot of software projects, but if you asked me do construction, all the project management experience in the world wouldn't help me estimate the construction costs.
Even when you're absolutely sure it would be cheaper to buy, you still have to analyze the build option.
I have to agree, while my organization isn't directly responsible for developing software tools, I have found it necessary to look to developing software from scratch or use opensource tools to "get the job done."
Some organizations, like mine, get too big and lose sight of the big picture. My success has been automating what previously had been manual processes. This largely has been in Data Center environments.
I strongly encourage other managers to move out of their comfort zone, sometimes solutions are not on a shelf, or with an established development organization.
I've been involved in both in-house development and the installation of bought packages, ranging from 5-user small business systems to 5,000 user ERP systems costing tens of millions of dollars. Build or buy? The answer is, of course, "it depends." The pros of both approaches are always put forth. Here are a couple of cons of each that are often overlooked.
In build, beware two things: unexpected ongoing maintenance costs and turnover on the development staff. You will always have to maintain, upgrade and modify a system you build yourself no matter how many people protest this is a "build it and forget it" system so you ned to factor in that cost. No, really you will have to do this. I promise. Also, the buy option actually becomes more dangerous as fewer people involved in construction, as the loss of one or two key people takes all the real-world experience with that system away. When that happens, you have the equivelent of a purchased system where the vendor went bankrupt (i.e. you are on your own without a clue.)
In buy, you are at the mercy of the vendor to keep current not only with technology but with business trends and regulations. If your vendor gets complacent and doesn't keep the innovations coming, you could find yourself making this decision all over again in far too few years. Also, if your vendor goes bust you are in trouble and if your vendor is acquired you could be in trouble if the new owners decide to orphan the product.
It's all really a matter of risk management and which set of risks you are willing to assume. And the first thing to ask in making that decision is "which will meet my needs to an acceptable level." As a general rule, I've come to the conclusion that "buy" is preferable to "build" if you can find something you can afford that is good enough. But having said that, I have seen far too many organizations assume that purchased software is always better than home-grown and end up spending huge amounts of money on sofware that does not fill the needs of the organization.