You have learned in previous courses in this series that during the Discovery and Definition phases of a Web development project, it is the business and creative teams that communicate with the client. During the design phase, the technical team becomes an important link between the Web team and the client. On the one hand, the technical team must understand the client's hardware capabilities and future needs. On the other, because of the potential implications of the selected hardware on the multimedia content and other programming aspects of the Web site, the technical team must be aware of the needs of the creative and business teams.
In some ways, at this stage in the process the technical team is a bridge between the rest of the Web team and the client, trying to understand and meet both sides' needs and desires. The SlideShow below illustrates this process:

When the deployment to staging occurs, a team is assembled to perform it. Sometimes this team has all the necessary skills, but often in very large organizations the responsibilities for deployment are divided between several groups. DBAs, middleware teams, web teams, and others all take a hand in deploying the latest version of the application. Since the various steps have never been tested in staging, they often have errors. The documentation misses important steps. The documentation and scripts make assumptions about the version or configuration of the target environment that are wrong, causing the deployment to fail. The deployment team has to guess at the intentions of the development team. Often the poor collaboration that causes so many problems in deployment to staging is shored up with ad-hoc telephone calls, emails, and quick fixes.
A very disciplined team will incorporate all of this communication into the deployment plan, but it is rare for this process to be effective. As pressure increases, the defined process for collaboration between the development and deployment teams is subverted, in order to get the deployment done within the time allocated to the deployment team. In the process of performing the deployment, it is not uncommon to find that incorrect assumptions about the production environment have been baked into the design of the system. For example, one application we had a hand in deploying used the filesystem to cache data. This worked fine on a developer workstation, but less well in a clustered environment. Solving problems like this one can take a long time, and the application cannot be said to have been deployed until they are resolved. In the next lesson you will learn what the function of the Site Planner is.