Section 11.8. Frequently Asked Questions

11.8. 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: Why don't you use the PMBOK acronyms for EVA and other technical analysis?

A: The material we presented adheres to PMI standards and material presented in the PMBOK with one notable exceptionthe letters we use to indicate the various measurements. In our opinion, it's easier to remember what two letters stand for and the point of the material was to make it highly useable for you. If you're concerned with passing a formal certification exam, you should adhere to the PMBOK standards. If your concern is simply your ability to use these metrics, stick to the two-letter system so you'll be more likely to remember (and therefore, use) these metrics.

Q: If my project is under budget but behind schedule, my project could still be in trouble. Using the metrics provided in this chapter, I could come up with a ratio of close to 1 that would indicate my project was just fine. Any comment?

A: It's true that when using ratios, you're dividing one number by another and in some cases, their equal and opposite deviations from 1 can offset each other. In the case you describe, you stated that your project was under budget (ratio > 1) and your schedule was behind (ratio < 1). While these might offset, you know going into this analysis that you are under budget and behind schedule. That information alone helps you better manage your project. These numbers can't manage your project for you nor can they think for you (though we all sometimes wish they could), but they can help guide you toward understanding where your project risks are, what your overall project health is, and help you focus in on the problem areas. Using your scenario, you can look at your budget variance and assume it is because you are behind schedule. However, you may be behind schedule because of a problem making approved budget expenditures. If you can't spend your budget, you can't do your work and you can fall behind schedule. Understanding where you are helps you understand what to do to fix problems that arise and these metrics are just one of many tools you can use to manage your IT project.

Q: It never fails that our development and testing teams do a great job but completely disregard our deployment team's deadlines and deliverables. This leaves the deployment team swinging in the wind and having to deal with angry or frustrated users. Any suggestions?

A: This is a serious problem that requires resolution because over time, your company will lose credibility with users. There are a few different ways you can address this, depending on the people involved, the customers, the project, and the corporate culture in which you're working. One way to work on this is to get engineers and testers in front of users or customers. Engineers and testing engineers can become a bit isolated from the real world application and getting them out of their offices and onto a user site and be a real eye opener. Another possible solution is to bring this to your project sponsor for escalation. Remember that your testers' goals are to find issues early in the cycle and send them back for repair before the project is released to the user. Code (or other work) with lots of problems is not the fault of the tester, though the tester sometimes gets blamed for delayed or missed project deadlines. Meeting deadlines for deliverables is everyone's responsibility and the team must work together to make sure all phases run smoothly. The developer and testing teams need to be held accountable not only for deadlines and deliverables on their own work, but for working cooperatively as part of a larger team to help the company succeed. Every time your deployment team has to backpedal with the customer, your entire company suffers. While it may sound a bit dramatic, everyone's jobs depend upon satisfied customers so the developers and testers are putting everyone's jobs at risk by ignoring deployment deadlines. On the flip side of that coin, the deployment team needs to communicate effectively with the developers and test engineers. That means listening to what is and is not possible, working together to create realistic schedules and negotiating to find mutually satisfactory and realistic goals.

Q: We work with external vendors on a lot of our IT projects. Most of them don't use formal project management. Do you have any suggestions for how to get them on board with our IT PM process?

A: That's a great question. Your vendors do not need to use project management methods in order for you to work successfully with them. However, once they begin to see the power of IT PM in the way you handle your projects, they may start showing interest in your processes and procedures. Until that happens, you can clearly set up processes and procedures for working with your vendors. Those procedures may include contractual (legal) elements, but at minimum, you should specify the vendor contact, vendor deliverables, vendor schedule, vendor cost, and vendor quality metrics (scope, time, cost, quality). This will help keep communications with your vendors clear, concise, and focused. It should ultimately help them do their job better because they won't have to second guess what you want or spend an inordinate amount of time trying to figure out how to meet your needs. A good vendor relationship is a two-way street, so you may need to adjust a few of your project's processes to accommodate a vendor's needs, if appropriate. Over time, the vendor will likely see the benefits of your IT PM process and may even inquire as to what system or methodology you use. Sharing your process will help your vendor do a better job and create a positive win-win relationship.

Q: My project sponsor almost always pushes me to deliver faster, better, cheaper. Despite my repeated discussions with my sponsor, this never seems to change. Can you provide any advice to help me out?

A: Some project sponsors seem to think that if they don't put the constant squeeze on you that you won't turn in your best work. If that's the nature of this problem, you may want to have a candid conversation with your sponsor and let him or her know that you are constantly working as hard as you can and that pushing you harder only adds stress. The project sponsor may be unaware that his or her actions are perceived as pushing (they might think they're encouraging or coaching) and they may change their approach. If the project sponsor is pushing because they really do need the project faster, better, or cheaper, you may want to ask the sponsor what changed since the original project definition (which they signed off on). This may cause them to realize that the project is on target and they're just getting jumpy. You may want to communicate more proactively with your sponsor if this is the case, because he or she may not feel they're getting enough current information so they push you. Sometimes a pushy project sponsor makes us retreat because we don't want to deal with the constant push and that can result in less frequent or less meaningful project communication. This leads the sponsor to get even jumpier and pushier and the cycle escalates. Don't allow the sponsor to bully you into creating a project plan that is better, faster, cheaper, and unrealistic. If you commit to a plan, make sure you're fairly confident you can deliver. If forced to commit to the better, faster, cheaper plan, make sure you document your concerns and reservations. Document what you believe the risks to the project are in this approach. Finally, if you continually have a problem with the sponsor pushing for better, faster, cheaper on every project you do, even after he or she has signed off on the project plan, learn to ignore those pushes and continue project work at the agreed upon pace…either that or find a new project sponsor who better understands the role of project sponsor.