ause big setbacks in overall confidence. The time between defining requirements and rollout has traditionally been very long. Requirements will be "frozen," and additional business requirements that are identified as the organization evolves will not be captured in the deployment. This creates two problems. First, the system will be based on the "as-was" requirements not the "as-is" requirement when it is deployed SO the business will be dissatisfied with the solution. Second, the requirements that arise after the requirements freeze date may not be adequately captured and documented as change requests that need to survive the "big bang" date. The business may become frustrated with the IT department as requirements are not immediately addressed. Lastly, the idea of a "big bang" is really a misnomer. Even if an organization believes that all requirements can be addressed in a single Chapter 4 - Developing an OSS Strategy delivery, the reality is that new requirements will arise that will need to be addressed in releases after the "big bang." 5.2 Developing a Phased Approach Phasing the OSS implementation provides an IIC with incremental delivery of functionality and automation, reducing both risk and time in realizing operational benefits. A phased approach allows for more evolution and organizational learning to be incorporated into the OSS platform, thereby reducing the need to change the solution once it is in place. With smaller time increments, such as quarterly rollouts, the time between defining requirements and operational rollout is greatly reduced. This results in closer alignment between systems and business needs, even as the business continues to change. In general, a phased approach is more pragmatic and economical. With incremental delivery, the IT organization can gradually build the confidence of the business side of the house. This often results in a more amicable relationship. There are many considerations for deciding on an appropriate phasing strategy for a particular IIC at a specific point 