Section 9.11. Frequently Asked Questions

9.11. 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: The information described in this chapterin this entire book so faris very enlightening, but I know I'm never going to be able to implement this level of planning in our organization. Should I just toss this book out?

A: First, no, don't toss the book outthere's a lot more good information to come. Second, you don't have to implement all of these processes at once. Granted, that would be idealto start a fresh project and build it from the ground up using these IT project management processes. But that's just not how the real world works. Most people approach change one small chunk at a time. If you have ever tried to make any kind of change in your life, you know that if you try to tackle too big a change, you'll simply revert to your old ways. Instead of giving up, finish reading through this book, then go back and find the one process or procedure you think will have the greatest impact on your project's success. Choose that one process or procedure and use it for a while. Then, just begin to work your way through all these processes until, slowly but surely, you have a full-blown IT project management process implemented. If you can't implement all of these steps at once, don't worry about it. Anything new that you do implement will help improve project results. For instance, in the past, you probably created a detailed list of work to be done (your version of a WBS). So, this time, have task owners create completion criteria so everyone will know when a task is successfully completed. That's a fairly easy change to make and what you'll probably discover is that your team latches on to these things because completion criteria (for example) make team members' jobs easier. Any time something makes life easier, we tend to use it. So, look for processes you can add that will make your IT project team's job easier and you will probably find very little resistance. Finally, keep the word kaizen in mindit means small, incremental, continuous improvement. That's what this is all about.

Q: I've never used a network diagram before, but it looks interesting. How can I create one if I don't have a project management software program?

A: One method taught by a prestigious project management program suggests using sticky notes (often referred to by the trade name "Post-Its"). If each task is written on a note and the duration and float are added, you can create a network diagram on any surface to which sticky notes will stick. Some people prefer index cards. A whiteboard can be helpful, but remember that you probably don't want to erase and re-draw over and over as you move things around, so the white board can be useful either as a surface for the sticky notes or as a place to record your final version of the network diagram before transferring it to paper or electronic format. A whiteboard (or blank wall) can be very helpful in looking at the network diagram as a whole. Some people who are visually-oriented may spot problems with the diagram immediately. Others may find the sequencing tasks easier if they are more tangible (using paper rather than the computer).There are plenty of ways to create the sequence (and thus, the schedule) without using project management software; get creative. You will find, however, that once you have your sequence and schedule that you may want to find a PM software tool to manage the schedule unless you have a fairly small project.

Q: I've used Microsoft Project in the past but with mixed results. Any suggestions?

A: Yes, two comments. First, having Microsoft Project doesn't make you a good project manager any more than having Adobe Photoshop makes you a graphic artist. Project and Photoshop are tools to help those who already have some level of expertise. So, your experience with Microsoft Project may be the result of not having the project management skills needed to effectively use the tool. Second, Microsoft Project is one of many different project management tools available. Each tool has some wonderful, unique features and some inherent limitations. You may need to look around at your choices to determine which tool is most appropriate for your project, your team, and your budget. You can install enterprise or desktop applications or you can use Web-based applications, all depending on your needs. Now that you've learned more about IT project management, you may want to go back and give Microsoft Project another try (it sounds as though you already own it so you might as well try using it again).You might be surprised by how differently you approach the tool now that you have new skills under your belt.

Q: Our company's Finance department creates our project budgets for us, so I'm not inclined to want to create a budget or a cash flow projection. Is there any reason I should?

A: If you're comfortable with the way in which your IT project budgets are created and that works for you, feel free to leave well enough alone. On the other hand, if you ever go to work for another company, having experience creating and managing IT project budgets might be helpful or required. It's up to you whether or not you want to take on creating your budget, but you might want to get your feet wet so you gain experience in this area. If you're held accountable for a budget you don't create, that can cause some strange problems, so that's another reason you might want to get involved.

Q: It seems you could plan for risks of risks of risks. What's a reasonable point at which to draw the line?

A: You're right that you could probably spend the rest of your life trying to plan for and avoid risk, but you'd never get anything done. It would be like saying, "There are risks involved with travel"that statement is true, but some travel is more dangerous than others. Flying in a poorly maintained single engine aircraft is far riskier than flying on a commercial airliner. Riding a motorcycle without a helmet at top speeds in traffic is riskier than driving in a mid-sized sedan. Everything we do has risk, the question is how much risk are you willing to accept? Companies typically have different "risk personalities", meaning that some companies are willing to accept more risk than others. The same holds true with IT project managers. Some IT PMs love the adrenaline rush of running around trying to solve some big problem; others avoid those kinds of situations. So, there is no single, right answer, but you should look at your own tolerance for risk (as well as your company's) and plan accordingly. Avoid analysis paralysis and do draw the line on risk planning at a reasonable point. If you feel that you're beginning to spin your wheels, find someone on your project team (or in close proximity) that has some of that doer personality. He or she will help you cut to the chase and get moving.

Q: I usually work with the same project sponsor and she never wants to review any part of the project plan until I submit the final project plan for approval. However, she always wants major changes at that point. How can I manage this?

A: That is a tough situation because you seem to lose on both ends. One suggestion is that you might bring less detail to your project sponsor more frequently. It's possible you are providing so much detail each time that she doesn't have time to review it, so she's created a process to limit the amount of detail she has to manage. The higher up one is in an organization, the more this is likely to be true. Rather than assume your project sponsor doesn't want information before the final project plan, try providing far less detail. Think of providing sound bites for your project sponsor throughout the defining, organizing, and planning phases. That way, you can keep her up to date without inundating her with details. Many successful IT project managers find a balance between getting things done and working on detail work (the doer versus the analyzer) and you may need to modify your communication style a bit to work more effectively with your project sponsor. In addition, you may want to take a look at past projects and see if there is a pattern to the types of changes required by your project sponsor. Does she always want a change in scope, time, cost, or quality? What are the reasons for past changes? It's possible that she consistently wants projects that have tighter timeframes or higher quality. If you can see where the disconnect is by looking at past projects, you may be able to come in more closely aligned on this and future projects. Finally, if you use the methods discussed in this book, it's possible that your project sponsor will not have as many changes. For instance, it will be very quick and easy to get her to sign off on the project problem statement. Once you agree to the problem, you can agree to the mission. Once you agree on the mission, you can agree on the selected solution, and so forth. These small checkpoints throughout the project planning process are designed to gain agreement and maintain alignment so changes don't come at the end of the planning phase.