Section 10.9. Frequently Asked Questions

10.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: In our company, our issues log discussions run on and on and I just want to run from the room. Any suggestions on how to deal with this?

A: Issues log management can be tricky because you're dealing with issues that have come up that are unexpected. If they were expected, they would have been planned into the project (assuming you planned your project). This often makes people nervous because sometimes the issues log is viewed as a scorecard as to how many issues cropped up in one area or another. When people get nervous or defensive, long discussions can ensue as people try to cover tracks or explain away problems. The best defense in this case is a good offense. The key is to focus on the outcomes. Issues log discussions often devolve into theoretical discussions or discussions of issues tangential to the core problem. Keep focused on the issue and the outcome. Don't allow discussion to get off course. If an issue cannot be quickly resolved (you could set a 5 minute timer, if needed), table it and move on. Tabled issues might require additional, separate meetings for review and resolution so that the issues log review doesn't become a painful and unproductive experience. If you're not in charge of the meeting, you might gently suggest this method to the meeting leader as a way to perhaps make more productive use of people's time.

Q: It seems that even though we plan for various risks, they always seem to sneak up on us anyway. What can we do to avoid this?

A: It's hard to keep your eye on so many moving parts, so it's understandable that some things might be overlooked. However, project management is a process that is intended to reduce errors and omissions, and you can create better project management practices to help avoid this problem. In your case, you've done a great job identifying project risks, but then no one manages the risk plan. Two possible solutions come immediately to mind (if you think of others after reading this, that's fine too). The first is that you can delegate the task of watching the risk management plan to someone on your IT project team who would do a good job at that task. Sometimes just delegating some of these tasks is all that it takes to keep better control of your project since there is only so much you, as the IT project manager, can do. Second is to add milestones to your project at the point where you've identified triggers. If one of your project risks is that a vendor might ship parts late, you should add a milestone (checkpoint) for the point at which you need to check vendor lead time, another milestone for the point at which you need to order from the vendor, another milestone at the point the vendor should ship, and another milestone at the point where you would implement your contingency plan. While that may seem like a lot of milestones to add for one risk, it will help you easily manage your project's risks as you manage your overall plan.

Q: You didn't discuss Earned Value Analysis and it's my opinion that percent complete or variance are relatively useless measurements. Any comment?

A: Yes, we'll discuss EVA in Chapter 11 for those that require a more technical analysis of project progress. While percent complete and variance can be somewhat subjective, they are useful tools in many projects that do not require more rigorous methods of evaluating project progress.

Q: It seems that in every IT project, our scope gets out of hand before we know what hit us. Typically, we get requests from all sidesusers, managers, the project sponsor, even executivesand we really don't have a choice to say "no." What can we do to better manage this?

A: Sounds like you have a bad case of scope creep. Fortunately, there is a cure, though in your case it might be a slow process. The key is to educate everyone about the impact of scope creep. You might start by reviewing past projects. Compare actual results to planned results and calculate how much extra time and money these projects cost. If possible, compare the desired (defined, planned) quality to the actual quality. Somewhere in those historical results is the answer you're looking for. You will likely find that the cost always goes through the roof or your team never meets deadlines or your project results are viewed as having poor quality. Since you now understand the relationship between scope, time, cost, and quality, you'll need to educate your executives and managers about this and work with them to understand and utilize your change management process. It also seems there may be challenges to your project definition early on. If your projects are not addressing user/customer, business, and executive needs, they will be pushed around. If they were well-defined and your company simply deals with frequent change, you should become a bit more forceful (if possible) in implementing and managing your change control process. Educate everyone about how, when, and why change will be considered, evaluated, and implemented. Help them understand what change does to the project and help determine appropriate priorities. It's possible that your firm is comfortable with a project being over budget, delivered late, or having less-than-desired quality, but once you explain how you can do a better job for less money and in less time, you might catch a few people's attention.

Q: I am really not comfortable dealing with people. I thought being an IT project manager would let me manage projects.

A: I'm assuming the question in there is that you're not sure what to do now that you've discovered that managing IT projects is really more about managing people than managing technology. For you, the excitement and satisfaction may come from the definition of the project including the functional and technical specifications, perhaps creating the WBS and the tasks. In that case, you might be better off working on the team as a subject matter expert than as the IT PM. If you're interested in improving your people skills, a project can be a great way to do that. Sit down and talk with someone who's known to be a solid project manager and talk with him or her about techniques you can use to manage your team. Managing people is a skill you can learn, especially if you continually focus on the desired outcome, but if you really don't like working with people, you're always going to find being an IT project manager a bit of an uncomfortable challenge.