Choosing the Right Pilot Project [5][5] 5 This section adapted from Kroll 2003, Chapter 11
Introducing change always brings with it the risk of undesired negative effects. A key benefit of adopting a few practices at a time is the ability to improve incrementally, hence minimizing the risks of negative effects. However, if you choose to adopt many practices in a project, you should choose your initial project, or pilot project, carefully. Here are the things to consider: Staffing profile. Choose for your pilot people those who (1) have an interest in learning something new and (2) have the ability and the opportunity to act as mentors on future projects. Having pilot team members act as internal mentors on other projects is the fastest way of transferring knowledge. Also make sure that the project manager and the architect are qualified and work together as a team, because these are the two most important roles. Importance and complexity. A pilot project should build real software that has a reasonably important business purpose. If the application isn't important enough, it may not garner sufficient resources to be successful. If not complex enough, people will say, "Well, building that application doesn't prove anything. Over here, we're building real software, and we still don't think you can do that with your process." In most cases you don't want your project to be so critical and complex that there are heavy pressures to take shortcuts on the process. That won't prove anything, except that the first time you used your process under suboptimal conditions, it did not save a doomed project. In certain cases, however, you actually want to choose a very high-profile, critical projectfor example, when you have nothing to lose, or when you must force a rapid improvement of the process and tool environment to ensure business success. The advantage of choosing a critical project is that it will be likely to employ the most talented people, the strongest management support, and the deepest pockets to pay for necessary training, mentoring, and tool support. Team size. Most pilot projects work best if you have six to eight people on the project team, that is, enough people to introduce some elements of complexity, but not so many that people are overwhelmed. The ideal number of people may vary, however, based on the nature of the practice you are trying to adopt. Certain practices require larger teams to experience their value, such as those deemed more appropriate for medium or large projects. Length and time constraints. You want fast feedback on whether the practice works for you or not. Often, you do not have to run a complete pilot project to obtain the feedback you are looking for. The ideal length of a pilot project is typically two to six months, which is long enough to allow for some complexity and short enough to allow you to move on and put your experience to work on other projects. Furthermore, you don't want the time constraints to be too tight. You need to be able to take enough time for the project to learn to apply the practices and associated tools appropriately.
| A pilot project should build real software that has a reasonably important business purpose. |
|
