How to Interview - Administration

Your goal when interviewing potential team members (or team members who have been assigned to your project) is to determine what their role in the implementation may be. Any project is only as good as the people completing the work. Your team will be a direct reflection on your own abilities, so this task is one of the most important you’ll have on the entire project.

When interviewing potential team members, you’ll need a job description for each open team position. A job description is needed for two reasons:

• So that you may share with the prospect what role needs to be filled

• So that you can focus on the attributes of the ideal team member

A job description is more than a title for a role on the team. A job description details the activities of the role, the scope of the position, the responsibilities, and the working requirements of the team member. A job description should be clear, concise, and easily summarized. For example, here is a job description for the role of a team member responsible for creating logon scripts: Logon script creator—This team member will be responsible for the creation, testing, and implementation of logon scripts for several thousand users. The logon script creator will be responsible for following the logon guidelines as assigned by management, updating current logon script procedures, and documenting the various logon scripts created.

You will also need selection criteria to determine which prospect is the best fit for the team role. The selection criteria will stem from the job description, as it should be a set of requirements that, if met, indicates the individual would be able to wholly complete the tasks of the job description. Selection criteria can include

• Education

• Knowledge on the tasks

• Experience with the tasks

• Skill sets applicable to the tasks

• Accomplishments within the company

• Other essential qualities such as aptitude, leadership, and the ability to work with others

Many project managers balk at completing interviews. Don’t. They are not difficult if you’ve prepared. Interviews can help you properly assign tasks to team members during resource assignment and scheduling. To prepare for an interview, develop good questions. When interviewing, there are several question types that you should know and use:

• Closed question These questions must be answered with a yes or no. For example: “Have you ever created a batch file before?”

• Essay questions These questions allow the candidate to tell you information—and they allow you to listen and observe. For example: “Why are you interested in working on this project?”

• Experience questions These questions focus on the candidate’s behavior in past situations, and they allow you to see how a candidate has acted to predict how he may act in future situations that are similar. For example: “How did you react when a teammate did not complete a task on a past project and you had to do his work for him to complete your own? How was the situation resolved?”

• Reactionary questions These questions evolve from the candidate’s answers. When you notice a gap or an inconsistency in an answer, use a follow-up question that focuses on the inconsistency without directly calling it a lie. This gives the candidate the opportunity to explain herself better or flounder for an explanation. Reactionary questions also allow you to learn more information that may be helpful on your project. For example: “You mentioned you had experience with Visual Basic. Do you also have a grasp on VBScript?”
  
• Questions not to ask In the United States, it’s illegal to ask candidates questions that aren’t related to their capacity to do a job. Basically, avoid questions that center on child care, marital status, religion, racial background, or physical disability. Use common sense, and this area of the interview should not be a problem.

Interviews are a great tool for learning about your potential team members. They are also an opportunity for potential team members to learn about you. Invite the candidate to ask you questions about your role on the project and the importance of the project. When conducting an interview, allow the candidate to do most of the talking so you can do most of the listening.

Without a doubt, people will fight. Fortunately, in most offices, people are mature enough to bite their tongues, try to work peacefully, and, as a whole, strive to finish the project happily and effectively together.

Most disagreements in IT project management happen when two or more people feel very passionate about a particular IT topic. For example, one person believes a network should be built in a particular order, while another feels it should be constructed from a different approach. Or two developers on a project get upset with each other about the way an application is created. Generally, both parties in the argument are good people who just feel strongly about a certain methodology of their work. Figure 6-5 demonstrates how arguments over technical implementations take a project off schedule.

Figure 6-5.  Arguments take a project off schedule and increase costs.

There are, of course, a fair percentage of contrary and pessimistic people in the world. These people don’t play well with others, and are obnoxious at times. They don’t care about other people’s feelings, and much of the time they don’t care about the success of your project.

Unfortunately, you will have to deal with disagreements, troublemakers, and obnoxious people to find a way to resolve differences and keep the project’s momentum.

In most projects there will be instances when the project team, management, and other stakeholders disagree on the progress, decisions, and proposed solutions within the project. It’s essential for the project manager to keep calm, to lead, and to direct the parties to a sensible solution that’s best for the project. Here are seven reasons for conflict in order of most common to least common:

• Schedules

• Priorities

• Resources

• Technical beliefs

• Administrative policies and procedures

• Project costs

• Personalities

So what’s a project manager to do with all the potential for strife in a project? There are five different approaches to conflict resolution:

• Problem solving This approach confronts the problem head-on and is the preferred method of conflict resolution. You may consider this approach as “confronting.” It calls for additional research to find the best solution for the problem, and is a win-win solution. Problem solving can be used if there is time to work through and resolve the issue, and it works to build relationships and trust.

• Forcing With this approach, the person with the power makes the decision. The decision made may not be best for the project, but it’s fast. As expected, this autocratic approach does little for team development and is a win-lose solution. Forcing is used when the stakes are high and time is of the essence, or if relationships are not important.
  
• Compromising This approach requires both parties to give up something. The decision is a blend of both sides of the argument. Because neither party really wins, it is considered a lose-lose solution. The project manager can use this approach when the relationships are equal and it’s impossible for one party to “win.” This approach can also be used to avoid a fight.

• Smoothing This approach “smoothes” out the conflict by minimizing the perceived size of the problem. It is a temporary solution but can calm team relations and boisterous discussions. Smoothing may be acceptable when time is of the essence or any of the proposed solutions will work. This can be considered a lose-lose situation as no one really wins long-term. The project manager can use smoothing to emphasize areas of agreement between the stakeholders within a disagreement, minimizing the areas of conflict. Smoothing is used to maintain relationships and when the issue is not critical.

• Withdrawal This approach is the worst conflict resolution tactic because one side of the argument walks away from the problem—usually in disgust. The conflict is not resolved and it is considered a yield-lose solution. The approach can be used, however, as a cooling off period, or when the issue is not critical.