8.2. Identifying Project Team Requirements
Let's start with the big picture. Your project team will be comprised of subject matter expertspeople who can help define and deliver project results. These folks may be from your IT department or they may be from many different departments in the company. Your project team may rely on a mix of internal staff and external contractors. It may be comprised of people locally or globally. The first step is to define the kinds of people (skills, not personalities) you need, not the specific people you need. In some companies, an initial project team works on defining these requirements and then members of the project team are added or removed as needed.
You can begin by looking at the overall environment and looking specifically at these elements:
In addition to these environmental issues, there are additional things to think about when you build your IT project team. Some of these elements may not be relevant to every IT project, but going through these elements helps you make sure you're building the most optimal project team you can within the organizational constraints. We all have experienced teams that had certain members because of politics or because of the company's organizational structure. While having these kinds of people on your IT project team is not optimal, these team members can be managed if you know what's what.
You may want to develop an organizational chart showing the relationships of potential or desirable team members so you can visualize the lay of the land. You may prefer a simple matrix or grid to depict team members and responsibilities or you may opt for the simple team roster. The key is to capture this list of current and/or future IT project team members and have an understanding of the five elements described above.
8.2.1. Roles and Responsibilities
Once you've looked at the five environmental elements, you should then begin to identify roles and responsibilities. Again, this can (and should) be done without a specific individual in mind and it's often better if you start out that way. The tendency for most people is to identify people rather than roles, responsibilities, and competencies. When you identify people, you may develop preconceived notions about roles and responsibilities based upon that specific person. Ideally, you want to identify roles, responsibilities, and competencies needed for the project then find people to fill those roles. You can then add roles, responsibilities, and competencies to your team list (org chart, matrix, or team roster). We'll look at this in a bit more detail in just a bit.
Your IT project will undoubtedly require specific competencies throughout the lifecycle of the project. These may change from one phase to another (and probably will). Defining the required competencies and mapping them to roles and responsibilities can help you identify the specific people you'll need to make your project successful. If you define a software engineer role whose job it is to define end user requirements, you'll need to identify the specific competencies for that role such as the ability to interact effectively with end users, the ability to translate functional requirements into technical requirements, or the ability to negotiate with end users to help develop requirements that are feasible and useful.
Another type of competency to keep in mind are the workstyles we discussed earlier in the book. If you have a team full of analyst types, you won't have a balanced team. This can lead to blind spots (everyone thinking in the same way) and can actually make it harder to manage the team. Whenever possible, try to create a balanced team by including people who represent the four different workstyles we discussed (see Chapter 4). By having each workstyle represented, you'll gain access to different viewpoints and different approaches to the project. This can help add to the quality of your final project and even make managing the team a bit easier. You'll be able to utilize the unique skills and talents that members bring to the team. For instance, the analyst types can help define many of the details while others who may be more interactive can help craft and manage the project communications, or work with users.
8.2.3. Staff Availability
Now that you've identified your dream team, you have to find out if they're available for your IT project. In smaller companies, it's easy to determine if people are available or to shift things around so they will be available. In larger companies, it often is a matter of competing for team members with other projects and other priorities. It also means negotiating and working within a political framework to get the IT project team members needed. If you need assistance, your project sponsor can often help out by exerting his or her influence within the organization to help you get needed staff resources. If you cannot acquire the talent and expertise needed to successfully execute your project plan, your project is in serious jeopardy. This creates a significant risk to the project (we'll discuss project risk in more depth later in the book) and you should not proceed until you've addressed this problem in a satisfactory manner.
8.2.4. Identifying Project Interfaces
Project interfaces describe all the ways your project team interacts with others. You should think about how your IT project team members will need to interact with others in the organization throughout the project lifecycle. This will help you identify contacts, liaisons, resources, and allies within the organization that will interact with your project and project team. If you thoroughly identified stakeholders earlier, you have a jumpstart on this process, though not all project interfaces are stakeholders per se. For instance, you may need someone in the Payroll department to create a project code and to work with team members to properly code timesheets or other payroll information to be submitted. That person is not a stakeholder in the IT project, but is clearly someone with whom the project team members will interface. There may be other more significant interfaces you identify at this point or they could all have been identified during your stakeholder identification process.