Define the Project Structure
Applies To: Windows Server 2003 with SP1
Previous Sections in This Guide
The Project Structure
The main function of the project structure is to define standards the team will use during the project. These include communication standards, documentation standards, and change control procedure standards. Program Management takes the lead in defining the project structure.
Defining Project Communications
Defining a reporting structure under which team members operate, procedures to elevate project issues, regular mandated status meetings, and any other project-specific communication standards is basic to any managed project. For an MIIS 2003 deployment, it is important to keep data owners and data source stewards informed and involved in the decision making.
Defining Documentation Standards
The project structure can also define standards on how to create training materials and documentation related to the project, including standards that prescribe the templates and applications the team should use to create documents. For an MIIS 2003 deployment, the most significant documentation is done during the planning phase and at a given point-in-time as a system baseline. Worksheets are provided with the Design and Planning Collection to facilitate the former, and third-party tools are available for baseline documentation.
Defining How You Manage Change Control
For an MIIS 2003 deployment, your team needs to manage change control over any changes that might affect the scope of the project. Typically, you can manage change control by enforcing change control on project documents. Change control helps ensure that the team is more capable of completing the project on time and within budget, and it prevents scope creep. Scope creep is defined as the tendency to add features incrementally to the project until the aggregate effect of the changes jeopardizes the project’s success.
When planning a project for an MIIS 2003 deployment, use a strict set of change control methods so that you focus on one solution at a time. During this design phase, consider following the MSF iterative process model, which allows you to assert control over scope creep.
Institute change control at the beginning of the project to help the team baseline documentation early in the project and iterate through the phases to complete the design. Controlling change throughout the process of stabilizing the solution helps in the process of capturing metrics and controlling problems as the solution nears completion.
Assigning Team Member Roles and Responsibilities
During an MIIS 2003 deployment project, certain resources on the design team are engaged at various times. The project structure should include milestones whereby team member assignments can be made. The specific responsibilities of each role should be described in a project structure document or the solution proposal.
Planning for Risks
Risk is defined as the possibility of suffering a loss, or more specifically, the possibility of a negative outcome that is assumed in order to pursue an opportunity for gain in the project. Risk is a part of every solution implementation project. Risk management involves anticipating, addressing, mitigating, and preventing risks. Prioritizing risks enables the team to address high-risk items early.
Risks for planning an MIIS 2003 deployment project include: lack of executive support; conflicts with data owners; inadequate training or lack of experience by the design team; and inadequate testing, especially for data integrity. As you step through the process to construct the solution proposal, note those areas inherent within your organization that could expose the project to high risks. During the design phase and after you select your solution, be sure to perform and document a formal risk assessment.
Initiating Your Identity Integration Project
Define the Project Structure
Start the Solution Proposal
Document Your Business Goals
Assess Your Current IT Infrastructure
Create the Project Vision and Define Scope
Assess Risks for an MIIS 2003 Project