Introduction


The idea for this book came from my experiences as a consultant and project manager. As a consultant, I was focused on mentoring, training, and providing services associated with best practices in the software industry. These services centered mostly on the Rational Unified Process (RUP)® and the associated tools from IBM Rational.

During these consulting engagements, I had the opportunity to work with many software teams in government, commercial companies, and academia. I learned much from each engagement, and they all contributed to and shaped my knowledge and thinking.

At that time, I also developed quite a collection of books that I read cover to cover. These also helped hone my knowledge. I read many excellent books that discussed the RUP. As a consultant I was always interested in hearing new perspectives on the RUP and its application.

During this period, I managed several projects that were outsourced to the companies where I worked. It occurred to me that I had never seen a book that combined the RUP with project management on outsourced projects. In addition, I felt the book should provide something useful to managers of the outsourcing organization (in other words, my customers). The idea is for each side (customer and contractor) to gain a better understanding of each other, and of the issues with software development.

This book does not cover every aspect of the RUP. Many excellent books cover the RUP in great detail. Some of them are listed in the bibliography.

This book focuses on projects that are conducted as a business arrangement between a procuring organization and a contracting organization. The book assumes that these two organizations are different companies, although this is not always true. The common term used for this situation is outsourcing.

Outsourcing Versus Offshoring

I am somewhat hesitant to use the term outsourcing because it has become synonymous with offshoring. In my view, offshoring is a subset of outsourcing. My definition of offshoring is that the procuring organization and the contractors are located in separate companies, each residing in a different country. The main point is that offshore projects have additional challenges. This book touches on some of these challenges, but the primary focus is on the more general outsourcing situation. In other words, the outsourcing organization and the contractor are separate companies but are located within the same country, perhaps even down the street from each other.

When the procuring organization is a legally separate entity from the contracting organization, factors come into play that place pressures on the software development process. These pressures are nonexistent, significantly reduced, or simply different altogether than when projects are conducted in-house.

One of two major premises in this book is that projects conducted as part of an outsourcing arrangement have special risks that must be addressed to be successful. I identify and discuss these throughout this book.

Procuring Software Services for Outsourced Projects

The advancement of best practices in the software process is well known within the software development community. But one aspect of outsourced software development has changed very little in the past 25 yearsthe process of procuring software development services.

As best practices for software development have been adopted, the lack of a sound, disciplined development process is no longer the root cause of failure for many projects. Instead, the cause can often be attributed to the procurement of the services needed to accomplish the project's goals. The traditional customer-contractor relationship is often dysfunctional.

Procurement processes commonly used today seem to assume (and, in many cases, actually impose) the use of traditional Waterfall-style software development lifecycle models. This is contrary to current best practices, which emphasize iterative lifecycle models. Furthermore, many outsourcing organizations remain completely detached from any involvement on the projects. They simply deliver a pile of requirements documents to the contractor and expect good results. As the contractor conducts the project, he often learns information that invalidates initial assumptions. This frequently necessitates changes to the contract, Statements of Work, or other parameters. Yet, particularly on fixed-price projects, outsourcing organizations refuse to negotiate these changes. The contractor, in an effort to avoid financial loss, cuts costs. These cost-cutting moves introduce technical risk to the project. The second major premise of this book is that these behaviors (for both the outsourcing organization and the contractor) cause many of the failures so endemic in the industry today. The way to change these behaviors is to change the procurement process. Projects should be conducted as a partnership between producer and consumer, rather than as a simple customer-supplier relationship. This book identifies and suggests practices to move in this direction.

Target Audience

The first target audience is project managers and procurement professionals in outsourcing organizations. I hope this book will give you insight into the issues surrounding outsourced projects. If the material in this book helps shape your procurement processes and how your projects are conducted, I would consider this book a major success.

The second target audience is project managers and contracting professionals for contracting organizations. Persons in this role may recognize many of the situations discussed in these chapters.

Other people who might benefit from this book are quality assurance professionals, software process professionals, consultants, and anyone interested in project management in an outsourcing/contracting context.

Finally, I hope this book will encourage outsourcing organizations and contracting organizations to work together more closely. The most successful projects are those in which both organizations work in close partnership, sharing both risks and rewards.

Chapter Summaries

The following is a brief summary of the chapters in this book.

Chapter 1, "Introduction to Outsourcing"

This chapter defines the term outsourcing as it is used in this book. Four scenarios common in outsourced projects are discussed. Some of the challenges commonly faced by software teams are covered for each scenario. The first goal of this chapter is to set the stage for this book. It also identifies high-level issues encountered by the software team in these environments. The second goal is to raise awareness of these issues in the hope that they can be addressed on current and future projects.

Chapter 2, "Overview of the Rational Unified Process"

This chapter starts with a review of traditional Waterfall-based lifecycles. It identifies characteristics of projects that are suited to Waterfall-based lifecycles (sometimes called SDLC). Next, the chapter introduces best practices, such as those introduced by the Unified Process. It introduces iterative development and compares and contrasts it with Waterfall lifecycles. The four phases of the Unified Process are identified and discussed. Some common difficulties that software teams experience implementing the RUP are covered.

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

This chapter discusses how common procurement methods cause difficulties on projects. I show how decisions made in the proposal process for projects set the pattern for difficulties on outsourced projects. A typical procurement process is described. I also present the ideas of R. Max Wideman, who originally published a series of articles in The Rational Edge e-zine for a progressive procurement model. This model is better suited for the iterative processes used on projects today.

Chapter 4, "Best Practices for Staffing the Outsourcing Organization's Project Management Office (PMO)"

As stated earlier, successful projects involve close collaboration between the outsourcing organization and the contractor. This chapter describes the roles needed in the outsourcing organization to foster a close partnership between the organizations.

Chapter 5, "Best Practices for Staffing the Contractor's Software Project Team"

This chapter describes the major roles on modern, high-performance software development teams. It is not meant to proclaim that all teams must have all these roles. Instead, the purpose is to describe the roles that high-performance teams seem to have in common.

Chapter 6, "Establishing the Software Development Environment"

Establishing a software development environment using modern, state-of-the-art tools is expensive. Often the cost is shared between the outsourcing organization and the contractor. In addition, sometimes the outsourcing organization has certain standards dictating the kinds of tools that should be used. This chapter describes the kinds of tools needed to establish a modern software development environment.

Chapter 7, "Inception: Kicking Off the Project"

This chapter describes the purpose and goals of a project's Inception phase. In particular, it focuses on the "soft" skills needed for a successful project.

Chapter 8, "Identifying and Managing Risks"

This chapter explains the importance of identifying and managing risks. The different types of risks are identified, and examples are given from actual projects. The goal is to help project managers recognize and address the risks affecting their projects.

Chapter 9, "Navigating the Requirements Management Process"

The need for documented requirements is well understood. However, proper requirements collection takes on added levels of complexity in an outsourcing environment. Furthermore, it is difficult to balance added and changed requirements with the fixed-price nature of many contracts today. This chapter discusses these complexities and solutions for them.

Chapter 10, "Construction Iterations: Staying on Target"

The Construction phase is a period of time when the contractor is often "heads down" implementing the software. It is also the period within the project when the bulk of the project resources are consumed. Accordingly, it is vital to verify that the project is ready to move into the Construction phase. This chapter gives some checklists to help you determine whether the project is ready to move into the Construction phase. It also discusses the factors involved in planning and structuring iterations.

Chapter 11, "Testing"

Everyone agrees that testing developed software is important, yet testing is often poorly done or incompleteespecially when the Waterfall lifecycle is employed. This chapter discusses the different types of testing and the importance of each type. You also learn why Waterfall-based lifecycles inhibit thorough testing. Finally, you learn how to integrate testing results with iteration planning for subsequent iterations.

Chapter 12, "Transitioning a System into Service"

Transitioning a new system into service for the first time is a major event, particularly if a legacy system is being deactivated at the same time. This chapter covers the activities that take place during the Transition phase. You will learn about the following:

  • Managing end user expectations at the most critical point in the project lifecycle

  • How to leverage the relationships developed during requirements elicitation to ease the system into production

  • The data migration challenge: preparing to migrate data from a legacy system

  • The issues involved in training end users

Chapter 13, "System Operations and Maintenance Issues"

Interestingly, a project's maintenance phase is not covered by the RUP. This chapter considers some of the issues arising in a project's maintenance phase. Many software projects never make it into the maintenance phase; they fail before they reach this stage. Other projects manage to complete the development cycle, only to discover that the product is unsuitable for production work. This chapter covers the following:

  • Identifying what is important for proper maintenance

  • Setting up and using a change control system to best advantage

  • When maintenance is not enough: how to recognize product failures that are beyond the scope of typical maintenance

Chapter 14, "Using Consultants Effectively"

Using consultants on a project can be an effective way to solve certain problems. Care should be exercised, however. Consultants cannot and should not solve every problem. In this chapter, you learn about the following:

  • How to determine what is appropriate for a consultant (with examples)

  • How consultants can derail your project

  • Monitoring consulting work

  • Effective knowledge transfer techniques when working with consultants

Chapter 15, "The Project Postmortem"

For an organization to improve its ability to develop software, it must reflect on the project's successes and failures. Even failed projects have some successes. Projects considered successful often have some failures. The purpose of the project postmortem is to collect the lessons learned and instill them in the organization's memory so that they can be applied to the next set of projects. This chapter discusses the best practices for this process.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net