Section 6.10. Frequently Asked Questions

6.10. 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: Project planning in our company seems to go on and on and on. We seem to be able to plan something to death. What are we doing wrong?

A: IT projects are often managed by people who fall into the analyst category. One of the downsides to this work type is that they have a tendency to analyze things to death. They can feel as if they never have enough data to finalize the plan or make a decision. As a result, they get "analysis paralysis." Two things are important in overcoming this type of behavior. First is to acknowledge that we rarely, if ever, have "perfect knowledge" and at some point, we have enough information to move forward. The second thing is that things will change over timethey always do. Since project management is an iterative process, it means you will have to go back and tweak things later on. So, spending time to make it perfect now is a waste of time because it will more than likely change. To overcome this problem, it's often helpful to determine if you (or the team) feel you have 80% of what's needed. If so, move on. Also, set deadlines that are rigorous but achievable. Don't let the project lose momentum, find some doers and get them on the project teamthey'll get things moving if you let them.

Q: Everyone at our company thinks P-L-A-N is a four-letter word. Any time I suggest we create a project plan, eyes roll and I get a lot of sarcastic comments about sitting around in planning meetings and never getting anything done. What can I do to counteract this attitude?

A: Many companies view planning as a waste of time and that's probably because if you plan and plan and plan and never do anything, planning is a waste of time. However, the reverse is also true. If you charge ahead without a clear idea of where you're headed and why, that's also a waste of time. There is a happy mediumplanning followed by action. If you find a lot of resistance in your company to planning, try implementing one or two new practices at a time. While using the IT project management process end-to-end as delineated in this book will yield the most optimal results, implementing even one or two pieces of it will certainly help your project. For instance, maybe you start out by asking your team to help you clarify or identify the problem you're trying to solve, who you're trying to solve it for (stakeholders, users), and what the desired outcome is. You haven't used the word "planning"; instead, you've used the word "clarify" or "identify". Sometimes just changing a few words and not making a big production out of "planning" can help reduce resistance. Over time, these new habits should lead to better project results, which in turn could give you the opportunity to introduce one or two additional planning habits. Eventually, you'll have your IT project team (or company) planning without the sarcasm because you'll start with planning, but your planning will result in action.

Q: It seems that no matter how good a job we do at gathering user requirements, we always have some big change thrust upon us mid-project. What can we do that avoid this in the future?

A: Changing user requirements in mid-project is one of the most common, and most frustrating, elements of managing an IT project. The solution starts with identifying what is causing or allowing these changes in mid-project. Does your IT project team really do a good job gathering requirements? You might think so, but it's worth a second look to determine if your team can do a better job gathering requirements. One of the keys is to listen more than you talk. Listen to what users say they need and translate that into requirements. Negotiate with users only after you've gathered their requirements. Sometimes in the requirements gathering stage, someone from the project team begins to mold the requirements based on things outside the user such as the desire to use a particular technology or to implement a particular solution. Begin with listening to the user to gather the real requirements, not just the ones you and your team might like best. The other problem might be that your process for getting users to sign off on the requirements might be too weak or too ill-defined. It might be useful for you to formalize this process so users (whether internal or external) understand two key things. First, when they agree to the requirements, they are essentially "engraved in stone" and second, the cost of change goes up exponentially (while quality typically goes down) once the project is underway. Helping users to understand why it's important that the requirements be agreed to and locked in helps them understand what's in it for them. And, what's in it for them is a project result that meets their expectations in terms of scope, budget, time, and quality. In some cases, creating prototypes might help avoid mid-project changes.

Q: You defined a ton of project parameters and I get exhausted just thinking of defining all of this. Is it really necessary?

A: Each project is unique and the parameters you'll need to define for each project will also vary widely. You may not need every single parameter defined in this chapter, and you may find there are additional parameters you need to define that are not discussed here. The information listed is to give you a running start so you can define the elements that are critical to your project's success. And remember, it's about the quality of the data, not the quantity of the data. If you have a 10-page project plan or a 100-page project plan, it's only as good as the information in it, so only include the elements that will help you and your IT project team deliver a successful project. Also keep in mind that you can utilize your IT project team in the development of these parametersparse out the work so that each team member has a deliverable and come together as a team to discuss and finalize these. It will be a better use of everyone's time, it will help reduce gaps and errors, and you won't be saddled with coming up with all of this on your own. Finally, smaller, less complex projects may need only a few of these parametersdefine only what will make the project work clear and the final result successful.

Q: Our company is holding the line on technology expenditures and not all of the members of my IT project team have access to the same tools. Any suggestions?

A: That can be a tricky situation. If the technology required for the IT project's success cannot be purchased or acquired, you have to step back and ask why the company would want this project to move forward without the tools it needs for success. For instance, if you are tasked with upgrading the server infrastructure to Microsoft Windows Server 2003, but you are not authorized to create a testing lab, you have a problem. The same holds true when members of the project team do not have equal access to the tools to get the job done. Typically the most effective approach is to determine the cost of not having these tools availablethe cost in terms of real dollars and in terms of lost dollars. The real dollar cost might be overtime, hiring external help, etc.. The lost dollars might be that project team members are unavailable to work on other tasks or projects or that the project itself comes in at a lower scope or quality. If you can quantify the cost and risk of not having these tools, you may be able to get your company to purchase or acquire these tools. If you can't, you may need to seriously reassess whether it's wise to move forward with this project at this time. Finally, you and your team may need to get creative about how to use existing tools to which all team members have access. Necessity is the mother of invention and you might discover a cool new way to use existing tools to help team members on the project.

Q: Our company has some very specific processes and procedures defined for projects, but they don't really seem to help me manage my IT projects any better. How should I approach this?

A: There are two parts to this question. The first is that your company has processes and procedures that don't really meet your needs. If you believe they are "process for process's sake," you can ask that your project be exempt from one or more of these processes or procedures. Remember though, choose your battles wisely. If some of the processes and procedures don't make sense but they're easy enough to comply with, you may choose to leave those for another time. Also keep in mind that some processes and procedures are there to comply with legal or regulatory requirements or to meet the needs of the business. Assess which ones might serve a higher purpose even if they're not meaningful to you. Then, try to lobby for reducing or eliminating those processes or procedures that simply get in your way and don't produce a meaningful result. The second part of this is that you must implement processes and procedures that fit your IT project. After reviewing the corporate processes, you can then determine what additional procedures you may need for your project. Avoid adding to already existing processes and procedures if the result will be redundant or just slightly different.