Project Management with the IBM Rational Unified Process: Lessons From The Trenches - page 18

Summary

The key to iterative development (and, therefore, implementing the RUP) is to embrace the notion that early failure is good. An iteration that fails early in the Elaboration phase, for example, is a success, provided that the failure is for the right reasons. To illustrate, an iteration in Elaboration may have the goal of proving that a project's performance requirements can be met with a certain architecture. Yet the team is unable to achieve the required performance with the chosen architecture. At the iteration's conclusion, the team might decide to scrap the architecture or make significant changes to it. The next iteration is successful as a result of the changes made due to the lessons learned in the first failed iteration. The ultimate result is project success through lessons learned, with minimal schedule risk.

I have encountered common patterns in organizations attempting to use the RUP the wrong way. These are covered in Appendix A, "Common Mistakes Utilizing RUP."

What's Next?

Chapter 3, "Getting Started: Request for Proposals (RFPs), Proposals, and Contracts," discusses an aspect of projects many developers and other team members never see or experiencethe procurement process. I invite you to examine this chapter, because it will help you understand the factors that lay the groundwork for difficulties on projects. Practitioners who have not experienced proposals and procurement efforts will gain insight into how these activities influence the eventual success or failure of an outsourced project.

Chapter 3. Getting Started: Request for Proposals (RFPs), Proposals, and Contracts

This chapter discusses how common procurement methods can result in project difficulties or even complete failure. It shows how inadequate Request for Proposals (RFPs) and Statements of Work (SOWs) make it difficult to employ modern iterative development methodologies such as the RUP.

I decided this chapter would be beneficial based on my experiences as a consultant and project manager on numerous projects that implemented the RUP. My experiences prior to that as a developer on various outsourced projects also contributed to the need for this chapter. I strongly encourage developers to understand the proposal process, because this is where many decisions are made that shape the experience on the project.

Having served as a consultant to various outsourced projects involving the RUP, I have spent much time listening to clients, trying to understand their difficulties with software development. As I have praised the virtues of modern development processes such as the RUP with these clients, I have often heard a response that disturbs me. A typical response is, "I hear what you're saying, but our Statement of Work/contract/agreement doesn't let us do it that way." In some cases, it is easy to work around these issues. In others, the situation becomes complex. Then, the focus turns to how to use a modern iterative development process while still conforming to the letter of the contractual agreement. This is when the problems arise. Even under the best of circumstances, software development is a difficult task. For many years, the industry has focused on methodology, techniques, languages, and process. We have come a long way. But there is room for improvementespecially in the areas of procurement and monitoring methods on large outsourced projects. To see why, let's look at how software systems are procured.