Section 8.4. Defining Roles and Responsibilities

8.4. Defining Roles and Responsibilities

Once you've identified the people with various skills and talents you need represented on the IT project team and you've worked to acquire those folks for your project, you need to organize them. By defining clear roles and responsibilities, you will create a framework within which team members can work. Most people like to have clear roles, responsibilities, and boundaries so they know what they should (and should not) do, what is and is not acceptable, and how to interact with others on the team. Clearly defined roles and responsibilities are absolutely essential for project success. You may have created some of the needed framework when you defined project processes; there may be additional information needed to help team members work in the most productive manner possible.

Rather than working with people's organizational titles, you may choose to define roles and responsibilities within the team structure. This can help create a sense of being part of a team and can help reduce problems based on organizational rank or title. For instance, if you have three people on the team that will all fill the same role (software engineer, for instance), call them "software engineer" for the project even if each of them has a different official title within the organization. As with the project itself, it may be helpful to define what is and is not included in each role. Setting role boundaries will help avoid overlap, conflict, and confusion later.

Once you've defined roles, you also need to define each role's responsibilities. Sometimes it's helpful to work on this with the team, other times a group discussion may simply lead to conflicts and arguments. Depending on the nature of your team, you'll have to decide the best course of action. If you define roles and responsibilities for the team, you will need to run this by team members for two reasons. The first reason is that you may have inadvertently overlooked important information for roles and responsibilities. The second is that by asking the team for input (and then using it), you'll help build the team's ownership in the project. If you simply define roles and responsibilities and hand them out, the team will have a much lower stake than if they can provide input and ideas. Usually this process also yield more clarity because team members can ask questions and clarify any gray areas.

Defining responsibilities typically includes defining deliverables or what each team member will be responsible for accomplishing. Again, the more clarity you start with, the better the result. Working with each member of the team to establish clear, well-defined responsibilities also helps ask and answer questions about conflicting roles, responsibilities, and deliverables. Avoid overlapping responsibilities and work with the team to clarify any issues before getting started on the project work itself. These responsibilities and deliverables also become part of the performance review proccess at project closeout (see Chapter 12 for details).

Another area to look at is required competencies. We discussed identifying required competencies at the higher project level, but once you've begun looking at specific people, you need to check your competencies requirements to make sure that you're getting the people with the skills you need.

Enterprise 128 …
Hot Projects and Hot Shots

Putting together a project team can sometimes be a very easy, pleasurable taskespecially when the project has high visibility or involves working with cutting-edge technology. On the other hand, there are more utilitarian projects that people will go to great lengths to avoid. These projects often need the same skills, talents, and enthusiasm, but putting together a project team for a mundane IT project can be a challenge. Here's your mission: don't go for the low hanging fruit. You may be tempted to grab just about any warm body you can for these lower priority, lower visibility projects, but that may put your project at risk. Taking whoever's available is the path of least resistance and yields the results with the least luster. Some IT project managers don't want to expend the energy required to sell a less exciting project to their talented IT staff (or to others outside the immediate environment), but that's a mistake. Ideally, you should try to ensure that assignments to exciting, highly visible projects are based, at least to some degree, on past participation on the mundane projects. By establishing a link between participation in mundane and exciting projects, you can help ensure you get a good, talented, enthusiastic mix on all your IT projectseven your brightest stars should spend time working on less exciting projects. Of course, things in the real world aren't always ideal, but you have to start someplace.

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

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: