There are many ways to gather requirements. Interviewing — where you talk to the people who will define the new solution to determine what they need — is probably the default technique for most projects.

Interviewing can be an easy process if the person you’re talking to is organised and logical in their thought process. Since that’s not always the case, however, you have to employ good interviewing techniques in order to start and guide the interview.

There are a number of formal interviewing techniques that will make the requirements gathering process go more smoothly. Here they are.

Start off with general questions.

Typically, you don’t start the discussion by asking narrow, targeted questions. You’ll want to start more high-level and general questions. These questions should be open-ended, in that they require the interviewee to explain or describe something and can’t be answered with a "yes" or a "no". Your goal is to gather as much information as possible with the fewest number of questions.

Ask probing questions.

After you ask general, open-ended questions, you should then start to probe for details. Probing questions are probably the most valuable type of questions, since they tend to result in the detailed requirement statements you’re looking for.

Be persistent.

If you experience any difficulty understanding the interviewee’s point, ask follow-up questions. You can also ask for examples that will illustrate the points the interviewee is making.

Ask direction questions when you need additional information.

Direction questions start to take the discussion in a certain direction. They’re used to provide context and background. For example, "Why is that important to you?" or "Why do you care about that?" are questions that can provide direction.

Ask indirect questions to gain better understanding. Indirect questions are used to follow up on specific points that were raised previously. These questions are used to gain more clarity so that you can ask better questions next. For example, "Is that important because of …" or "You said everything needs to be secure because …"

Ask questions that validate your understanding.

A good interviewing technique is to restate what you just heard back to the interviewee to validate that you understood him/her correctly. For example, after hearing an answer, you could say "If I understand you correctly …"

Paraphrase.

This is similar to the prior technique except that you would take a large amount of information from the receiver and simplify it in your own words. For instance, after hearing the interviewee give a five-minute answer on how a process works today, you could paraphrase the basic points of what he/she said in a quick bulleted list of process steps. For example "So, in other words, the process you use today is basically 1,2,3,4 …"

Ask for examples.

In many (or most) cases of gathering requirements, the interviewer is not totally familiar with all of the information provided by the interviewee. Therefore, one effective way to gain more understanding is to ask for examples. This can also be utilised when the interviewee provides feedback that does not sound totally valid or totally believable. Asking the interviewee for an example helps lend a concrete and specific instance that may help make the requirements clearer. For example, "Can you give me an example of how that affects you?" can help make a statement more clear.

Keep the discussion back on track.

Sometimes the interviewee starts to talk about things that are outside the scope of the specific information you’re trying to gather. This is sometimes caused by a misunderstanding of the question you asked. Other times it’s caused by a lack of focus or a desire to talk about things that are of more interest to the interviewee. When the discussion gets off track, the interviewer must get back on track. An example of this technique would be "That’s a good point. However, can you describe how that relates to (…restate your original question…)?"

Try to stimulate ideas.

Sometimes the interviewee gives the obvious answers but isn’t thinking about other areas that may not be as obvious. The interviewer should try to get the interviewee to stretch a little and think about things that are not quite as obvious. For instance, you can ask "Can you think of a couple options for this situation?" or "Are there other ways to solve this?"

After yet more research into the various species that inhabit this working world of ours, I return with a new set of taxonomic classifications. This time, we concern ourselves with the team leader, in all his or her many guises.

As ever, there are many competent and sociable team leaders in IT departments; but they don’t make for great storytelling. Picking the worst and most dangerous types can help us recognise the signs and maybe even glean a little entertainment from them.

1: Dux Timeris

Fearful Leader

This team leader was persuaded to take the leadership job for two reasons: First, the powers that be decided that there should be a team leader so they could devolve some of their duties to someone who can’t answer back. They picked the least confident team member and tailored the promotion process to ensure that the correct candidate was appointed.

Second, this person was the last to get through the door when the call for volunteers went out. He may have been trampled underfoot in the rush and was slightly concussed when the job offer was made.

Now that this new leader is hooked, he’s too timid to ask to be re-graded and spends a lot of his free time worrying about the job. This is completely unfair, as this type is usually a good person trying to do a good job.

Favourite saying: "Can somebody help me please? Anybody?"

2: Dux Fulvus Nasus

I will leave you to translate the Latin for yourself

This leader does not think for himself but hangs on every word passed down to him from on high. If the boss told him that the sun was inhabited by pixies he would send Christmas cards to them.

He cannot believe what he is hearing when somebody on the team disagrees with a management decision; more worryingly, every critical word uttered within his earshot is reported back directly. Once aware of this, a team can make good use of it for propaganda purposes.

Consider the day of the Christmas party, for instance, when our help desk team was told that it was not permitted to attend. We weren’t expecting any calls, as virtually the whole company was at the bash. We decided, within the hearing of the Dux FN, that we would wait for the party to start and then go home. An hour later, our invite to the party had arrived, with an instruction to switch the phones over to voicemail.

Favourite saying: "I was talking to the boss this morning. Wonderful man!"

3: Dux Magnifica

The Paragon of all the Virtues

This person is under the misapprehension that he has arrived, that he or she is "Look on my works, ye Mighty, and despair!"

Yes, this jerk is full of himself. You would think he had just been appointed World President instead of a glorified tea boy. He took to wearing a pin-striped suit on appointment to the position.

He refers to the senior directors of the company as his colleagues or "fellow members of the management team." He is not a tattle-tale. The views of those under him are far too inconsequential to be listened to, much less acted upon.

Favourite saying: "Follow me lads; I know what I am doing!"

4: Dux Trogloditica

Cave Man

This leader is a technical expert who lives, eats, and breathes computers. He leaves the office at the end of the day and goes home to a techno cave where he spends his off-duty hours making his stock of computers, one that NASA would be proud to own, do things that they were never deigned to do.

When he is not thus engaged, he attends conventions dressed as his favourite character from a variety of science fiction films. D Trog is the first person to talk to about a technical problem and the last person to ask about any leadership or personal hygiene issue.

Favourite saying: "I think you’ll find that James T. Kirk never said, ‘Beam me up Scotty.’ The nearest he got was, ‘Scotty beam me up!’"

5: Dux Dictatorialis

The Dictator

You can say what you like about Dux Dictatorialis, but under him all the calls were logged on time. He (and it usually is a he) is an obnoxious person who can’t understand that people have a life outside of work and wants the world to know that HE is in charge. People who disagree with him usually disappear and are never seen again, although a trip to the media library or any other dark and dusty storage facility may give a clue as to their fate.

The worst thing about any dictatorship is that the weaker members of the team find themselves siding with the bully and become bullies themselves. Fortunately, this species is becoming rare in the wild, as there are many predators and few allies.

Favourite saying: "Come on, get with the program!"

6: Dux Nihilistica

Leader of Nothing and Nobody

D Nihilistica is an unhappy and lonely leader. He was made team leader, but the snag is that his team consists of just one person: himself. He has been doing the same job for a number of years and generally speaking, he does a pretty good job. A year ago, he was surfing a recruitment Web site and was spotted by his boss. They don’t want to lose him, as they would have great trouble in replacing him, especially at the paltry salary they currently offer.

Luckily, they persuaded him to stay by awarding him an upgrade in his status, a move that cost nothing.

Favourite saying: He doesn’t have one; there’s nobody to talk to.

7: Dux Amicus Bonissimus

The Best Mate

The Best Mate wants to please everybody all the time. Nobody ever explained the impossibility of this, so he continues trying, even though experience should tell him that he’s on a hiding to nothing. These leaders are known to go home at night wondering why everybody hates them. This is not true. We don’t hate them, we worry about them. In the futile commotion of trying to be all things to all people, they are in dire peril of going quietly mad.

Promotion is a double-edged sword that cuts both ways. When you are pleasing the bosses, you will upset the team. Stick up for the team and the bosses will blame you for not communicating their message properly.

Favourite saying: "Why does everybody hate me?"

8: Dux Reluctantis

The Reluctant Leader

The team had functioned well for a number of years, but there was a review and the question was asked, "Who is the team leader?" The answer was not what the big boss wanted to hear.

"You must have a team leader on every team." End of discussion.

People were invited to apply for the post, but nobody was keen. It was clear that the team dynamic was at risk and nobody wanted to rock the boat. Eventually, a person was picked, interviewed, and appointed. Even when the inevitable interview question was asked: "Why do you want this job?" the answer, "I don’t really want it," was not enough to put them off.

Sometimes, a D. Reluctantis is appointed because HR feels he needs a challenge to reveal his full potential.

Favourite saying: "If that’s okay with you…"

9: Dux Minoris

The Lesser Leader

This team leader is perfectly illustrated by Simon Travaglia’s Pimply Faced Youth (PFY) in his celebrated BOFH series of comic IT spoofs.

He is keen but has been led astray by a scheming and manipulative section manager. He is drawn into the various scams and schemes to do down the bean counters and is not above using the Argon-based fire systems to discretely dispose of those who stand in the way.

In reality, this character is easily diverted from his true path and finds himself in a tight corner when the schemes inevitably go wrong. He is great fun to work for, but you should always make sure that you take the key to the server room door with you if you enter alone.

Favourite saying: "Illegitimi non carborundum…" and he has the T-shirt to prove it.

10. Dux Severus

The Serious Team Leader

When some members of the team get promoted it goes to their heads.

Gone is the sociable, easy-going friend you worked with and out comes the martinet. The person who used to take 30-minute bathroom breaks suddenly starts to time your breaks and make scathing comments when you take more than four minutes. Having an upset stomach is no excuse because he knows that the loo break is often used as an unofficial break and an opportunity to catch up on office gossip with help desk colleagues.

Favourite saying: "We run a tight ship here."

This typifies the arrogance of the breed. Adopting the "Royal We" is always a sign that things are going to the bad.

Identifying, gathering, and leveraging the right mix of metrics is a way to gain better control of your large project. The value can be quantified in a number of areas including:

1. Improved performance of the overall project fulfillment and delivery process
2. Improved estimating for future projects
3. Validation of duration, cost, effort and quality objectives for the project
4. Identification and communication of best practices
5. Improved client satisfaction

In general, metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions, and guesses. Collect metrics, even if they are imperfect and imprecise. They still provide a better foundation than recollections, perceptions and guesses.

Collect the metrics you’ll use

You don’t want to collect metrics just for the sake of collecting them. Of course, you need to collect any metrics that are mandatory for your organisation. In addition, you should collect any other metrics that are needed by your particular project. However, if you don’t have a purpose for the metrics, or if your project isn’t long enough that you can really leverage the information, these customised project specific metrics are not worth collecting for your project.

Make sure the value of collecting a metric is worth the cost

Just as there is some cost associated with most project management activities, there’s a cost to collecting and managing a metrics process. Some metrics are interesting, but don’t provide the type of information that can be leveraged for improvement. Some metrics are just prohibitively expensive to collect. The cost to collect each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that your organisation requires. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.

Make sure your metrics tell a complete story

The problem with many metrics is that they’re reported in a way that doesn’t tell a complete story. The project manager and project team may know what a given metric is telling them, but other people accessing the information may not.

One way to help is to always report the metric along with the target. For instance, if you report your current expenditures to date, also include your expected expenditures at this point in the project. If you report that your project has spent $100,000 so far and your total budget is $150,000, the reader still doesn’t have the context to know whether this is a good or bad situation. Sure you’re under budget, but the work is not complete either. The better way to report this information is to state that you have spent $100,000 to date and that according to your estimate you should have spent $110,000 at this point in the project. If the trend continued, you estimate the final cost of the project to be $135,000 versus your budget of $150,000. If you report the metrics with this context, your readers can understand what the numbers are saying.

Train your team in the purpose and value of metrics

The general definition of "metrics" is not always obvious. The project manager may be trying to create a metrics program for a large project, while the project team doesn’t make the connection between gathering metrics and the business value received. This disconnect may affect the client as well. The project manager should take the time to explain why metrics are needed and how the information collected will help drive improvements. Likewise, the team should understand how to look for metrics that will provide an indication as to the state of a process or a deliverable. Educating the team and the client will help the project manager obtain better metrics with less work effort and less pushback.

In my post Four things you should know about your technical staff , I talked about some of the general characteristics of an IT project team. For example:

1. They tend to be introverts
2. They tend to think more logically than emotionally
3. They tend to be problem solvers
4. They tend to be technically creative

Knowing some of the characteristics of your technical staff allows you to better understand how to manage them effectively. Applying some or all of the following techniques will help you create a more conducive work environment where people can excel.

Give them the tools that need to do their jobs.

Establish an environment where people feel they have what they need in order to do their jobs. This includes having appropriate hardware and software. It doesn’t necessarily need to be state of the art, but it should be of acceptable quality. Because they’re in the IT field, IT people get frustrated when they don’t have the right hardware and software to do their jobs effectively.

Make sure they have the right skills and provide opportunities to learn.

IT people love to learn new things. Managers should make sure their people have the skills needed to do their jobs and that they receive opportunities to grow into new technical areas. This doesn’t have to be third-party training classes. It can include computer-based training, seminars, webinars, books, magazines, etc. Also, once someone has mastered a certain skill and they start to become bored, look for ways they can cross-train and learn new areas of the group.

Create a viable work environment.

Technical people like to understand the work processes in the group, and then they like to be creative in working within that structure. So, set the high-level rules, but don’t micromanage the details.

Give people as much information as they need to do their jobs.

Managers should strive to be proactive communicators. Remember, many IT people are introverts who like to process information internally. They may or may not come up to you and ask you what’s going on all of the time. Managers should make sure that they communicate as much as they can about what’s going on in the company, their organisation, and their group.

Shield the team from office politics

Don’t let your team get bogged down in the organisation muck. This means removing organisational roadblocks and shielding the team from organisational politics. IT people will tend to get cynical fast if they feel like a political environment is affecting their work or in decisions that affect them.

Make sure each person remembers he’s part of a team.

Even though IT people tend to be introverts, it doesn’t mean they prefer to work alone. IT staff may prefer to work independently, but they also like being a part of the team. Managers should nurture this need. For instance, they should have regular team meetings. Managers should also make sure they have opportunities to do fun stuff as a group - even if it’s just going to lunch together once in a while.

Be there when needed and respond to problems and concerns.

Not all problems can be fixed, but many times the simple act of listening and trying is enough. People will give you credit for trying, even if the ultimate resolution to a problem isn’t available.

You might note that many of these management techniques are not unique to technical staff in general or IT staff in particular, but they’re particularly applicable to the IT staff.

To many people, the focus on diversity is synonymous with the hiring of inferior quality for the sake of meeting quotas. But companies have found that there is long-term business value associated with a diverse workforce. Why is diversity awareness needed to begin with? Let’s assume your project team has an opening. You want to hire the best candidate available, right? In many cases there is a clear "best" candidate based on experience and skill level. However, if there are many such people to choose from, the hiring manager may rate a candidate’s qualifications using his own background as a measuring stick. After all, if a project manager has a certain background and ended up in the position he is in today, wouldn’t it make sense to him to look for those same traits in another person? Wouldn’t he tend to pick a person that physically looks like him as well?

Project managers also want to make sure they hire someone that will get along with the rest of the team. Again, if there are multiple candidates with close qualifications, the project team may choose a candidate who is "more like themselves".

If teams are left on their own, these two sets of natural biases tend to result in a like group of people hiring a similar candidate. In some organisations and on some projects, this results in a bias against workers of the opposite sex. In other businesses, there’s a bias based on culture and race.

Companies, especially large ones, have tried to formalise and standardise the recruiting and hiring process in a way that allows each candidate to be judged based on the same set of criteria. The goal of a standardised process is usually not to hire diverse workers. The goal is to remove as many of the subconscious biases as possible and to ensure that the most qualified candidate is hired.

Diversity awareness lets you:

1. Make better decisions. People from the same types of backgrounds can have a tendency to think alike and this can affect the decisions that people make. Project managers need a diverse set of opinions to make the best technical decisions, to communicate more effectively with all of your clients, and to design and build the most creative solutions.
2. Hire better people. Ultimately there is value in being able to hire the best person, regardless of the person’s background. In many cases, organisations that do not value diversity end up not hiring a group of people that all look and act the same. They will tell you that they are always hiring the "best". But is it really true that the best people all look and act the same as each other?
3. Running better projects. You have to be experienced managing diverse people to excel in today’s global marketplace. Can your project team really develop software that is used around the world, for instance, with an entire team that all comes from the same background? Can a project manager manage a worldwide distributed team if he has never managed people that are different from him? Can you service your diverse customer community effectively without a diverse project team?

The bottom line is that there is value in having a diverse workforce and a diverse project team. If this was an artificial feel-good idea, it would not be so important to so many companies. However, companies have found that valuing diversity results in hiring better people and provides real business benefit.