Randomly surfing around the web this morning I stumbled across an interesting page from an Australian IT Recruitment company. One of their guys had writen a piece on the importance of using quality people on your project from grass roots to upper echelons. It’s a good read with a humourous but all too accurate twist:
The following is a pretty typical situation in the IT project world. A director decides that a new system needs to be built. He gets the go ahead and recruits an internal project manager. The project manager needs a team of developers, but the director wants to pay below market rates. The project manager puts out the feelers to a few agencies and receives some CVs. He interviews some developers and discovers that most have embellished their CVs. The agencies say that he’ll have to pay more if he wants to attract quality people, but the director won’t agree to increase the hourly rates.
Finally, the project manager picks the best of the below-average bunch of human resources that he’s been offered. He needs three people to build the system, but the director decides to train an internal person while the system is being built. So now the project manager has two sub-standard developers and a trainee to work with.
The project starts. Lots of documents are produced, but not much actual work is done. The project manager sets his staff some coding tasks, but they take a long time to complete and often have mysterious bugs in them. One of the developers turns out to be not as bad as the project manager first thought, but half her time is taken up by the trainee.
The project goes weeks past its deadline, but finally the project manager has something to show for the investment. A quick demonstration is organised for the business sponsors. The system looks okay, and it’s decided to roll it out.
The first days that the system is in use turn out to be a disaster. Bugs come out of the woodwork and it can’t be used for productive work. The live system is closed down while the developers try to sort out the problems.
The system is rolled out again a week later. There are still some strange bugs, but it is almost useable. Support calls flood in, but the developers are able to deal with most of them by walking the users through how to avoid the bugs that they can’t fix.
Just as things seem to be going well, a rogue piece of code corrupts all the data in the system, rendering it useless. The system is closed down again. The business sponsors are furious that so much time and money has been wasted. Finally, the director agrees to hire in an expert to look at the problem.
The expert is expensive, but know her stuff. She is amazed by how complicated and messy the system is. She tells the project manager that the simplest way to fix it would be to rebuild from scratch.
*** Building and maintaining an IT system is complicated work. It requires intelligence, expertise, and experience. Many projects fail because one of these factors is missing. Your chances of success are greatly increased if you get the right people for the job. What many project managers and their bosses fail to appreciate is that the most expensive person per hour can often be the cheapest per project. There is too much focus on hourly rates and not enough focus on what the project will involve.
What you want is your project delivered on time, on budget, and with the best possible design. Most of all you want it to work. These are the outcomes you are likely to achieve with a quality team.
If you’re stingy with your resources, the project is likely to drag on, be of poor quality, and require extensive support. Most importantly of all, IT projects that don’t work as expected alienate users. Delivering a poor quality system will stain your reputation and your users will not trust you any more.
Once you’ve decided to pay the rates for a good person, the next step is to screen your candidates. The easiest way to do this is to take a technical person to the interview with you. Get the internal person with the most expertise possible. Most technical people are pretty good at gauging how much another technical person really knows. Ask your candidate about projects that they have worked on, how they dealt with certain technical issues, and what strategies they used to get around problems.
You may want to give your candidate a technical test. This can be a good idea, but use them carefully. Ask very general questions about their claimed field of expertise. Avoid questions about obscure aspects of products in an attempt to catch the person out. You want to work out what they know, not what they don’t. Technical people sometimes see an interview as a good opportunity to humiliate one of their peers with questions that the candidate cannot reasonably be expected to know the answer to. Keep this in mind when devising a technical test.
So get the best people you can afford and vet them carefully. Because cheap IT workers with poor skills often do more harm than good. Forget about the price, feel the quality.
Paul Knapp from Brainbox.com.au