hasized, they do not find or make the time to get involved until it is too late. Minimize conversions as much as possible, even if it means deploying an application in a simple out-of-box fashion as an initial deployment. Conversion is a killer. There are many IICs that have been converting away from their older systems for the past two years. This is because conversion can be like changing the tire while the car is running. Imagine trying to do a physical inventory while users are changing the network. Some IICs do not include basic OSS functionality in the early phases, but rather wait for all the features and functionality that they require. For core functions, this is a recipe for disaster. While all the development and configuration is going on, manual processes and interim solutions are running the operation as it continues to grow, making the ultimate conversion that much more complex. A better approach is to deploy a basic out-of-the-box package as quickly as possible SO that data is being captured in a proper data repository rather than in interim spreadsheets, which are invariably outdated and inaccurate. Once the basic functionality is in place, it can be gradually enhanced. Avoid big bangs. Incremental delivery provides lower risk and better results. Use both a "Top Down" and "Bottom Up" approach to process mappings. Do not believe the OSS vendors that claim they already have the business processes embedded in their packages. An enterprise view of processes and best practices is required, in addition to the detailed process assumptions within a given OSS package. The Ultimate Guide to Building and Delivering OSS/BSS Turn vendors into partners. Vendors should be part of the implementation, even if a systems integrator is used to manage the overall implementation and integration effort. OSS implementation involves a lot of players, and it is important that they are committed to the success of the implementation. Many package vendors come from a "drop ship" background, which is a mistake. These packages 