Section 7.8. Frequently Asked Questions

7.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: Our company uses Six Sigma and it seems that it conflicts in some ways with IT project management. Is that true?

A: No, any quality management system can work side by side with IT project management. In some cases, you may want to modify the IT project management practices defined in this book simply to avoid redundancy. The point of Six Sigma is to reduce errors. The point of IT project management is to deliver a more successful project, part of which involves delivering the highest required quality at the lowest cost (time and money) possible. They are quite compatible, so if you find conflicting areas, examine them closely and resolve them in a way that meets your company's criteria. However, there's a good bet that upon closer examination, you won't find areas that are completely incompatible.

Q: I've had a long-running debate with a colleague about quality and the discussion in this chapter on quality versus grade clarified things greatly. Why isn't grade discussed more often? It's so important in decision making.

A: Quality and grade are closely related, as you saw in our earlier discussion, and, from a user's point of view, there may be no difference. If you purchase a financial software program for your personal use, do you differentiate between how many bugs you experience and the fact that it won't export your data to your favorite spreadsheet program? You probably don't, nor do most users. However, one is a quality issue (bugs) and one is a grade issue (lack of an export capability), but to you, as the frustrated user, they are both elements of quality. The distinction between quality and grade really becomes important in for the IT project team when helping to develop requirements and acceptance criteria. The reason why no one discusses the difference between quality and grade might be because so few IT project teams use a defined IT project management methodology (you may be the exception since you're reading this book).

Q: You mention quality metrics several times, but we've never used quality metrics. Can you explain how we can develop specific quality metrics for our IT project?

A: If you've never used specific metrics, you may have actually made things harder on yourselves than necessary. Think about connecting a new communications line to your office building. You might say that in order for it to meet quality requirements it must provide a fast Internet connection to the 1200 users in your building. That sounds good, but what happens when the line the vendor installs is so bad that the error rate is so high that the Internet connection for your users crawls to a halt? How do you quantify this with the vendor? You can't very well say, "It's just too slow!" One way to begin to develop metrics is to figure out what you'd want to use if this deliverable was being delivered to you and you were paying someone external for it. How would you measure it then? Most likely you'd use some sort of line speed test with a minimum speed threshold and a maximum erro threshold for the line. With a bit of digging, you can probably quantify some of the quality statements you've made and turn them into meaningful quality metrics.

Q: Our company always says it wants quality, but when push comes to shove, they want it cheaper and faster and quality goes out the window. Any suggestions?

A: The unfortunate reality is that many companies give lip service to quality and then do nothing to support it in the organization. Other companies truly value quality and don't realize the things they're doing don't support quality. These are two distinctly different corporate personalities so try to discern which it is first. If your company truly doesn't value quality, you have a huge uphill battle, but you may have success in explaining how low quality costs the company, directly and indirectly. If your company actually values quality, but has processes, procedures, and cultural practices in place that undermine quality, you have a better chance of catalyzing change in the organization. Take it one step at a time and begin by implementing processes and procedures in your IT projects that deliver quality. Since planning quality in is almost always less expensive (time and money) than trying to fix it later, your project results will begin to speak for themselves. You can also make the business case for quality and then work to change the processes and procedures in your company that undermine quality results. Start small and build momentum. Just implementing this IT project management methodology could improve your results so much that people come to you asking how you did it. Wouldn't that make changing habits an easier sell?

Q: I like the idea of planning first and creating code second, but what do I do with the developers on the project until I am ready for them? I don't want them to be bored or get "stolen" for another project, and I don't want my developers to appear idle to my management since I don't have anything tangible to show for the project during all this planning. Any ideas?

A: You are correct in your concerns to ensure your team is busy doing useful work while collecting requirements and developing the plan. Consider tasking the developers with designing the test plans to ensure customer requirements are met. Two big benefits: First, the developers gain an understanding of the bigger picture and may have some good ideas on ways to improve the process and second, by having your developers writing the testing plans, you can be sure the code will do what the customer requires. If your developers are still going to run out of things to do, consider doing a phased start up where the development team is not fully engaged until you are ready for them or ask the developers to help in designing a method to track issues found, but be careful hereyou don't want to spawn a project within a project to design and develop a whole new bug tracking system when your company probably already has a working solution for you to use.