Section 8.2. Identifying Project Team Requirements


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:

  • Organizational Which departments, divisions, or sections of the company should be represented on the project team? Is there a budget issue (hiring freeze, cutbacks, etc.) that could impact your project? What about unions or collective bargaining issues that will impact team membership (or the project itself )?

  • Technical What are the different technical specialties that should be represented on the project team? Are there different types of technologies (engineering approaches, software languages, equipment) that should be represented or that will have to be coordinated?

  • Logistical Where are project team members located? Are they local, remote, overseas? How will you coordinate their activities? Much of this should have already been defined in IT project team processes in Chapter 6.

  • Interpersonal What types of formal and informal relationships exist among team members (or potential team members)? Are there known relationships you can leverage or known issues you can avoid?

  • Political What alliances exist among various stakeholders and how will these influence your project (for better or for worse)? Are there any people on the IT project team with political clout or any members on the team that seem to be out of favor politically? How will this affect your IT project?

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.

8.2.2. Competencies

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.

Applying Your Knowledge

You may already have an established project team for your IT project and if so, that's fine. You don't need to reinvent the wheel, but do take a moment to review the items just listed and compare them to your current project team to make sure all your bases are covered. As you know, once you've identified many of your IT project elements once, you can reuse and repurpose much of that work over and over again to save yourself time and effort. Just don't fall into complacency. Check your work against your formal process as you go to make sure you don't accidentally miss something that might be new or unique to this IT project.





How to Cheat at IT Project Management
How to Cheat at IT Project Management
ISBN: 1597490377
EAN: 2147483647
Year: 2005
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net