Section 5.11. Frequently Asked Questions

5.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: We've never used a formal project management process in our company. It seems like this will be an uphill battle.

A: Repara that throughout this chapter and this book, we're describing best practices and ideal circumstances (except where noted). Clearly, many companies use little or no formal project management processes. Some would argue that things are running quite well, but if they were to take time to examine results, they'd probably see results that track with the statistics given earlier in this book (low project success rates). If you're the IT project manager, you can begin by going through these steps yourself or with a small team. If your company is resistant to these processes, you'll have to slowly educate those around you (including those higher up) as to the benefits of taking time to plan. The information presented earlier in this book should give you ample data to present your case and even if it falls on deaf ears, your improved IT project results will, over time, win over the doubters. Yes, it may be an uphill battle, but implement as many of these steps and processes as possible and your project results will absolutely be better than without.

Q: I'm an IT project manager and I'm interested in getting better project results. I just can't realistically see me or my team implementing all of these stepslike writing a project proposalthat would never fly. Any comment?

A: One of the best parts of a simple, straightforward IT project management methodology, like the one presented in this book, is that you can use it in any way that suits you. While it's true that you will get far better results from implementing the entire methodology, it's also true that you can improve any project you're working on by implementing even just one part of the IT PM process. For instance, you will find better results simply by clearly stating the problem or by brainstorming other potential solutions besides the one you were assigned. Some people find that implementing a new process one piece at a time suits their style or the company's style betterthat's fine. The key is to make continuous improvement. Start by implementing one step that will have the greatest impact on your projects. Once that's completely incorporated into your process, pick another step. Don't be overly concerned with perfectly implementing an entire new process or methodology if that's not your style. And, if you have any of those analyst types we discussed in Chapter 4, now's the time to get them involved.

Q: I'm often handed a project with the scope, time, cost, and quality elements already pre-defined. You mentioned how to validate the project, but can you provide more advice on how to "push back" within the organization. My boss (who is usually the project sponsor) believes he has already done adequate research when he hands these projects to me.

A: Your situation is actually pretty common and if you can learn to deal with this situation effectively, you'll make real gains in improving project results. We'll discuss these four elements in more detail later in the book, but in terms of your approach to your project sponsor, it will be important to understand the environment. You might begin by reviewing past projects on your own and comparing required results (the ones your boss handed to you) to actual results. Chances are extremely high that these assigned projects' parameters (scope, time, cost, quality) have rarely, if ever, been met. Sure, you might have met a timeline if that was most important, but that probably meant you ran over on the budget or had to cut the scope. If that's the case, you can begin to look at where and how these projects varied from the required parameters. Then, you might have an opportunity to sit down with your boss and discuss these variances. Unless your boss is the type to say something like, "These projects were just never well managed," you should have the opportunity to gain agreement on the things you, your boss, and your IT team can do differently in the future to ensure the projects are more successful. If you don't try to do something differently, you'll just keep generating the same results. It's entirely possible that the time or cost overruns that happened on past projects is simply an acceptable and expected way of doing business in your company. If that's the case, you can learn these IT project management steps and implement them, even if you don't have formal approval of the various elements. If that ends up being the case, you can still create the information and data for the project and simply not bring them through the formal approval process if that's going to create more problems than it solves. Ideally, your boss will begin to see better results and will be more open to changes later on. Better results can be very convincing and worst case, you'll be a better IT project manager even if your boss never changes.

Q: Our company had a big push a few years back to implement IT project management and it basically failed. After spending hundreds of hours and thousands of dollars on training and methodologies and the like, everyone basically went back to doing things the way they'd always done them. I think IT PM is a great idea, in theory, but I'm having difficulty figuring out how we'd get this going in my company. Any suggestions?

A: You describe a very common scenario. Changing habits and behaviors is not an easy thing to do. Psychologists and behaviorists will all tell you that the best way to make lasting change is in small increments. Large, wholesale changes rarely take hold, though in some cases you do need to shake things up completely to break out of old patterns. Your company made an attempt to do something different, but it didn't stick for one of two reasons (well, there may be others, but these are the top two). Either the methodology was so radically different from how you currently did things that no one could implement the entire system successfully or there was lack of support for this change at the top of the organization. Lack of support can take on various appearances. For instance, if top executives never expected or required a project proposal before heading into a new project, then eventually project proposals stop being created. This lack of support for the new process eventually leads back to old behaviors and patterns. If you're trying to implement change in your organization now, you have a doubly tough task because you have the added burden of hearing "We tried that before and it didn't work." Instead of trying for wholesale change, pick one thing and do it differently. Small changes are often more manageable and once they take hold, you can move on to the next change. Take this process step by step. For instance, you might simply begin by crafting clear problem statement for every project that comes your way. Once everyone accepts that projects begin with a problem statement, you can begin trying to get everyone to come up with a mission statement by asking what the desired outcomes are for the project. Jamming an entirely new system down your team or company's throat without strong executive support is often the least effective approach, so start with small steps.

Q: We learned about defining the project in this chapter, but isn't there more to defining a project than just identifying the problem, mission, and solution?

A: Yes, there is and you'll learn about additional elements of project planning in the next chapter. At this point, you do have your project definedmeaning you know what problem it is trying to solve, what mission it is trying to accomplish, and what the potential solutions and optimal solution are. That's a pretty clear starting point and one from which we can now build. In Chapter 6, we'll develop more detail project information.