Section 8.9. Frequently Asked Questions

8.9. Frequently Asked Questions

The following Frequently Asked Questions, answered by the author of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the "Ask the Author" form.

Q: This is a book on IT project management, but you've spent two chapters talking about teams. Why?

A: Projects don't fail, people do. As an IT project manager, if you can't successfully manage your project team, your project is in serious danger. Sometimes you get lucky and the project sort of runs itself, but the odds of that are worse than winning the lottery. We've dedicated two chapters on managing your project teamone from a more theoretical standpoint (Chapter 4) and one from a more practical standpoint (this chapter) in order to give you the tools you need to successfully manage your IT project team. Managing people is usually more complicated than managing technology and many IT project managers excel at the latter and fail at the former. Improving and honing people-management skills is part of improving as an IT project manager and will certainly be needed if you plan on moving up the corporate ladder in your career.

Q: I don't usually get to choose who's on my IT project team and who's not. How can I deal with a preassigned team more successfully?

A: Start by going through the steps listed in this chapter, including identifying roles, responsibilities, and competencies needed to successfully complete the project. Then try to map these requirements to your assigned team paras. If there are any significant gaps, bring this to the attention of your project sponsor. If your project sponsor is truly interested in a successful project, he or she will help you fill those gaps either by assigning additional people, allowing you to hire temporary outside contractors, or by providing training to assigned team paras. If you can't do any of that, make sure that the skill or competency gaps are noted as project risks (we'll discuss identifying and managing project risks later in the book) so at least no one can turn around later and say they were unaware of these shortfalls.

Q: Creating roles and responsibilities sounds like a lot of bureaucratic nonsense. Can we just get the team going?

A: It would be nice if we all could just intuitively know what to do and could instinctively get along with others, but unfortunately it rarely works that way. Creating clearly defined boundaries helps everyone. It actually reduces team stress when people know exactly what is expected (and not expected) of them. While it may take some extra planning effort on your part, it really will generate positive results once the project is underway. It doesn't have to be a long, drawn-out process by any means. See if you can reuse definitions from other (successful) projects. And, if it really works your last good nerve to create this from scratch, find someone on your team that has those strong analyzer qualities and ask them to create the initial roles and responsibilities document. Then, all you have to do is edit it.

Q: I'm not very comfortable giving public recognition or rewards to my team. Any suggestions?

A: A lot of people are uncomfortable in those situations, so you're not alone. However, managing a team involves a certain amount of public speaking. While you can talk to team paras individually and in private to let them know how well they're doing, it usually has more impact to give them that recognition in a team, department, or division meeting. So if you're uncomfortable doing that, try writing down what you would say then practicing it in front of a mirror or with someone you trust to be kind and to help coach you (dogs can be a good stand-in because they rarely laugh out loud at you). Focusing on the specific behavior will also help because then you're not saying, "Hey, that Raina, isn't' she great?" Instead, you can focus on the actual behavior such as, "Raina wrote such clean code that she was able to meet Requirements 1, 2, and 3 with just 150 lines of code. Great job, Raina, thanks!"The more specific you are and the more focused on the task, behavior and benefit you are, the more comfortable you'll probably be handing out compliments. And get used to itthe more you hand out genuine compliments, the happier your team will be.