Initiation Phase: Creating the Statement of Work

Executives generally require a documented Statement of Work that reflects strategic thinking, an understanding of the goals and objectives of the organization, and a sense of confidence that the project will be successful and beneficial to the company. The document needs to be clear and specific and keep its audience in mind, which generally means not going into too much technical detail. This document also needs to give an estimate of the duration of the project, the costs involved, and the resources required.

The initial scope of work might have changed and evolved as discussions with the executives, managers, and stakeholders reveal problems that weren't obvious and requirements that hadn't been foreseen. Although the scope started out as a "simple Exchange upgrade" it might have expanded to include an upgrade to Active Directory, the addition of new features for remote access to the messaging environment, or management and business continuity features.

The following is a standard outline for the Statement of Work document:

1. Scope of Work

2. Goals

3. Timeline and Milestones

4. Resources

5. Risks and Assumptions

6. Initial Budget

The following sections cover the different components of the Statement of Work. This document is arguably the most important in the entire process because it can convince the executives who hold the purse strings to move forward with the project ”or, of course, stop the project in its tracks.

Summarizing the Scope of Work

At this point in the initiation phase, a number of conversations have occurred that have clarified the basic scope of the project, the high-level business goals as they pertain to the messaging upgrade, and the more specific goals for each department and of key stakeholders. Armed with this wealth of information, the lead consultant on the project should now organize the data to include in the Statement of Work and get sign-off to complete the phase and move to the more detailed planning phase.

The Scope section of the Statement of Work document should answer these essential questions:

• How many Exchange and Windows servers need to be upgraded?

• Where do these servers reside?

• What additional applications need to be upgraded ( especially backup, virus protection, disaster recovery [DR], and remote access) as part of the project?

• What additional hardware needs to be upgraded or modified to support the new servers and applications (especially tape backup devices, storage area networks, routers)?

• Will the desktop configurations be changed?

The answers to these questions may still be unclear at this point, and require additional attention during the planning phase.

Summarizing the Goals

As discussed earlier, a number of conversations have been held previously on the topic of goals, so there may be a fairly long list of objectives at this point. A structure to organize these goals is suggested in the following list:

• Business continuity/disaster recovery (Clustering, Storage, Backup and Restore)

• Performance (Memory Allocation Improvements, Public Folders, Email)

• Security (Server, Email)

• Mobility (Outlook Web Access, Pocket PC and SmartPhone Support)

• Collaboration (Real-time Collaboration ”replacement for Exchange Instant Messaging ”SharePoint Portal)

• Serviceability (Administration, Management, Deployment)

• Development (Collaboration Data Objects, Managed API)

By using a framework such as this, any "holes" in the goals and objectives of the project will be more obvious. Some of the less glamorous objectives, such as a stable network, data recovery abilities , or protection from the hostile outside world, might not have been identified in the discussions. This is the time to bring up topics that might have been missed, before moving into the more detailed planning phase.

It might also be valuable to indicate what will be corrected by the upgrade ("pain points") and what new capabilities will be added.

Summarizing the Timeline and Milestones

A bulleted list of tasks is typically all that is needed to help define the time frame for the upgrade (more complex projects might benefit from a high-level Gantt chart of no more than 10 “20 lines). The time frame should be broken down by phase to clarify how much time is to be allocated for the planning phase and testing phases. The actual implementation of the upgrade also should be estimated.

Depending on the complexity of the project, a time frame of 1 “2 months could be considered a "short" time frame, with 2 “4 months offering a more comfortable window for projects involving more servers, users, and messaging- related applications. Additional time should be included if an outside consulting firm will assist with part or all of the project.

Because every project is different, it's impossible to provide rules for how much time to allocate to which phase. Experience has shown that allocating additional time for the planning and testing phase helps the upgrade go more smoothly, resulting in a happier user base. If little or no planning is done, the testing phase will most likely miss key requirements for the success of the project. Remember also to allocate time during the process for training of the administrative staff and end users.

The key to successfully meeting a short timeline is to understand the added risks involved and define the scope of the project so that the risks are controlled. This might include putting off some of the functionality that is not essential, or contracting outside assistance to speed up the process and leverage the experience of a firm that has performed similar upgrades many times. Hardware and software procurement can also pose delays, so for shorter time frames , they should be procured as soon as possible after the ideal configuration has been defined.

Some upgrades can actually take place over a single weekend ; then on Monday morning users show up for training and are up and running on the new messaging platform.

Summarizing the Resources Required

Typical roles that need to be filled for an Exchange Server 2003 upgrade project include

• Project Sponsor

• Exchange Server 2003 Design Consultant

• Exchange Server 2003 Technical Lead

• Exchange Server 2003 Consulting Engineer

• Project Manager

• Systems Engineer(s)

• Technical Writer

• Administrative Trainer

• End-user Trainer

The organization should objectively consider the experience and skills as well as available time of internal resources before deciding whether outside help is needed. For the most part, few companies completely outsource the whole project, choosing instead to leverage internal resources for the tasks that make sense and hiring external experts for the planning phase and testing phases. Often internal resources simply can't devote 100% of their energy to planning and testing the messaging technologies, because their daily duties will get in the way. Contracted resources, on the other hand, are able to focus just on the messaging project.

The resulting messaging environment needs to be supported after the dust settles, so it makes sense for the administrative staff to receive training in the early phases of the upgrade (such as planning and testing) rather than after the implementation. Many consultants provide hands-on training during the testing and implementation phases.

For larger projects, a team may be created for the planning phase, a separate team allocated for the testing phase, and a third team for the implementation. Ideally the individuals who perform the testing participate in the implementation for reasons of continuity. Implementation teams can benefit from less- experienced resources for basic server builds and workstation upgrades.

Summarizing the Risks and Assumptions

More time is spent discussing the details of the risks that could affect the successful outcome of the project during the planning phase; but if there are immediately obvious risks they should be included in the statement of work.

Basic risks could include

• Existing Exchange problems, such as corrupt database, lack of maintenance

• Lack of in-house expertise and bandwidth for the project

• Using existing hardware that might not have enough RAM, storage capacity, or processor speed

• WAN or LAN connectivity issues, making downtime a possibility

• A production environment that cannot experience any downtime or financial losses will occur

• Customized applications that interface with Exchange Server and that need to be tested and possibly rewritten for Exchange Server 2003

• Short timeline that will require cutting corners in the testing process

Summarizing the Initial Budget

The decision- makers will want to start getting a sense for the cost of the project, at least for the planning phase of the project. Some information might already be quite clear, such as how many servers need to be purchased. If the existing servers are more than a few years old, chances are they need to be replaced , and price quotes can easily be gathered for new machines. Software upgrades and licenses can also easily be gathered, and costs for peripheral devices such as tape drives or SANs should be included.

If external help is needed for the planning, testing, and implementation, some educated guesses should be made about the order of magnitude of these costs. Some organizations set aside a percentage of the overall budget for the planning phase, assuming outside assistance, and then determine whether they can do the testing and implementation on their own.

As mentioned previously, training should also not be forgotten ”for both the administrative staff and the end-users.

Getting Approval on the Statement of Work

After the initial information has been presented in the Statement of Work format, formally present and discuss it with the stakeholders. If the process has gone smoothly this far, the Statement of Work should be approved, or, if not, items that are still unclear can be clarified. After this document has been agreed on, a great foundation is in place to move forward with the planning phase.