Project Management for Information Systems - Essay Example

Table of Contents Introduction. 2 Purpose: 3 Background: 3 Scope: 4 System Overview: 4 Approval Flow Chart 5 Change Request Assessment 5 IT Report: 6 ISN CRA Entities: 7 CoPaX Board of Directors: 7 ISN Operations: 9 Configuration Identification: 10 Selection of Network: 10 ISN Physical Layout: 11 ISN Configuration Change: 13 Classification: 14 Evaluation: 15 Modelling and Testing: 16 Implementation: 17 References: 18 Introduction This is a final version of the Integrated Switched Network (ISN) Change Request Assessment. This document incorporates comments and feedback received from the Information Technology (IT) Project Manager on the draft ISN Change Request Assessment delivered on 15th Jan 2007. Purpose The purpose of this document is to identify and describe a Change Request Assessment (CRA) process for the Integrated Communication Network (ISN). This plan describes in simple, straightforward terms the processes required to ensure that the inevitable network changes occur within an identifiable and controlled environment. This document is intended to be a living document. As implements the components of this assessment, and to facilitate the every changing state-of-the-art, the (ISN) CRA process may need to be refined. Consequently, the final version of this document should itself be placed under change management and the respective changes managed accordingly. Background CoPaX decides to expand its economic territories by buying a French Company, which does a similar job to CoPaX but in France. To support a homogeneous network the department of IT has decided to roll out 10pcs on trail to their head office in Paris (5pcs) and hub, on the outskirts of Paris (3pcs) and a Delivery Office in Lille (2pcs). Considering the change of Project Indentification Document. The IT Project Manager identifies the need for the Change Request Assessment to the (ISN) During emergencies, the ISN must rapidly reconfigured to support the establishment of Fields Offices. Currently, informal operational process followed by each entity invloved with the ISN is the primary means of controlling ISN changes. These processes are frequently undocumented; consequently, the IT Project Manger cannot determine the status of current CoPaX architecture, network component configuration and proposed changes. This assessment addresses this deficiency. It establishes a consistent, cross-organizational I process for the SN architecture and its components. It provides both SN managers and technical personnel the information they need to implement the ISN CRA activities and their flow. Scope The scope of this document is the identification of a top-level Change Request Assessment for the ISN. This Assessment presents Change Request activities for the data portion of’ LAN/WAN (e.g., switches, routers, and hubs). Specifically excluded from this Assessment are network server hardware and operating systems. System Overview The ISN provides LAN/WAN connectivity for the entire organization. It links Cisco routers, T-1 lines, and I-Muxes provides WAN connectivity. Cisco 7000 routers linked by dedicated T-1 lines provide high-bandwidth connectivity between, and sites with heavy WAN traffic (e.g., the Denton NTC). Cisco 4000, Cisco 3000, and Cisco 2500 routers linked by T-1s and I-Muxes support sites with lesser traffic requirements. Approval Flow Chart Change Request Assessment Components. This section describes the components of the ISN CR process. These components are presented using the conventional CRA framework – configuration identification, configuration change control, configuration status accounting, configuration reviews. Change Request Assessment involves identifying the configuration of a network system at given points in time, systematically controlling changes to the assessment, and maintaining the integrity and trace ability of the change throughout the lifecycle. The items placed under Change Request Assessment include the software and hardware products (e.g., routers and switches) that comprise the network as well as items required to create or maintain these products (e.g., initial routing tables and switch configuration data). The (IT) Project Manager will be involved in configuration management activities for the: Chief Executive Operations Director Financial Director Sales Director Marketing Director Human Resource Manager IT Manager Accounts Manager Depot Manager Coventry Depot Manager London Depot Manager Norwich Depot manager Newcastle Depot Manager Manchester IT Department. IT Project Manager is responsible for the ISN implementation and its components. It tests and deploys ISN components, lay down network physical components, and identifies potential ISN enhancements. Only the IT Project Manager has the authentic Rights to change the ISN and its components. The IT department is responsible for the establishment of the Component Folders. Operations Manager (Edward Meivem) is responsible for the day-to-day operation of the SN. It maintains the deployed components of the ISN and ensures that the ISN is up and operational. The Operation Group Help Desk is the initial point-of-contact for reported network incidents. Finance Director is responsible for the deployment of monetary support for the realization of the field office network hardware and integrating them into the ISN. ISN CRA Entities. The ISN Change Board of Directors (CBD) and the CoPaX Operations will provide cross-organizational Change Request control and coordination. CoPaX Board of Directors The CoPax Board of Director (BoD) will be established as a formal approval authority for changes. It primarily exists to control changes to the ISN layout (e.g., deployment of a new piece of hardware); however, any ISN issue with significant cross-organizational impact should involve the ISN BoD Written Change Requests (CRs), Impact Assessments (IAs), and meeting minutes will document the BoD’s consideration of an issue. A Change Request (CR) form will initiate BOD consideration of a change. Typically, the IT Project Manager is responsible to originating most CRs, but any depart in the CoPaX organization may also may submit a CR to the CCB. Upon receipt of a CR, the (BoD) should request each member CoPaX organisation to research the incident and record its analysis on an IA. These IAs will document the data upon which the ISN BOD will have based its decision. The SN CCB will identify the appropriate change resolution activities and will authorize the affected organizations to perform them. The SN CCB will be notified immediately when the actual change has been completed and the configuration status information will be updated accordingly. The decision of the SN CCB and its rationale will be recorded on the CR. The CR will be closed and copies distributed to each member organization. Section 4 presents this process in greater detail. Appendix A contains sample Change Request and Impact Assessment forms. ISN BoD will be comprised of representatives from the CoPaX Chief Executive Financial Director Operations Director IT Operations Manager Each representative has the authority to commit his or her organization. Since the ISN BoD will consider and resolve cross-organizational issues, its Chair should be a person with the authority to mandate actions to the IT organizations. In addition, since final responsibility resides with the BoD Chair, this person will have the authority to mandate or override decisions made by the BoD. Typically, the BoD Chair is a representative from the next level of management. ISN Operations The ISN operations under the auspices of the operations Director and the Operations Director undergo a moreless formal change request organization assessment that coordinates minor ISN changes (e.g., changing settings on a particular router) between the Central Office and its outlets Architecture Group and Operation Group. The ISN BoD delegates this authority to the ISN Operations Manager to provide a more streamlined Change Assesment control mechanism for those changes that do not affect multiple CoPaX departmental Offices. Although this is less formal than the BoD, all requests and decisions must still be documented. Networking Request (NR) form submitted to Chief Executive (Peter Massing) will initiate Operations Directors consideration of a change. Typically, Operation’s Director will originate most NRs, but any CoPaX department may submit an (NR). Upon receipt of an (NR). The Marketing Director and his department will research the request and record its analysis on the NR. If the request only involves component-level changes, then Operations Director will authorize the changes and the Operations Director will document the decision. If the incident involves more significant physical layouts and hardware changes, then the Operations Director will originate a CR, and the CR Control Number will be recorded on the ER for traceability. The ER will be closed and returned to the originator. The ISN Operations will consist of the Directors of the CoPax and Operation group organizations or their designated representatives. The ISN Operations group may be considered a mini-BoD. Configuration Identification Configuration identification (CI) involves identifying the components of the network, uniquely identifying the individual components, and making them accessible in some form. A proper configuration identification schema identifies each component of the network and provides traceability between the component and its configuration status information. Proper configuration identification answers the following questions: The major activities of configuration identification are: Selecting network components to be placed under CM control Creating an identification scheme for the components to uniquely identify each individual component Selection of Network Components This plan addresses the CM of the ISN network infrastructure – switches, routers, and hubs. Specifically excluded from this plan are network server hardware and operating systems. The IT Department, in conjunction with the CCB, will determine the network hardware components to be placed under CM. The following is a preliminary list of SN network hardware items to be controlled: Cisco 7000 Series Routers Cisco 5000 Series Routers Cisco 4000 Series Routers Cisco 3000 Series Routers Cisco 2500 Series Routers Ascend MAX Inverse Multiplexer I-MUX Dialup CDDI/FDDI Concentrators Networth 4000 Concentrators Bay Stack Hubs Acculan Hubs IT Department, in conjunction with the ISN BoD, will determine the network software components to be placed under CM. The following is a preliminary list of the SN network software items to be controlled: ISN Physical Layout At the ISN-physical layout level, only the ISN BoD will have the authority to approve and make changes to the components of the ISN physical baseline. Before considering any change, the potential change must be documented using a ISN Change Request (CR) form. This form describes the desired change, the justification for the change, the impact of implementing the change, and the eventual CCB decision regarding the change. CRs normally document network changes originating from, but any ISN IT Project Director or organization may submit a CR. The CR will be submitted to the Chair of the BoD who will route the CR to each department of CoPaX on the ISN BoD. Each department will fill in an ISN Impact Assessment (IA) form documenting the impact of the change upon their organization. If an organization will be affected by the change, the IA will be returned with notations or comments documenting the organization’s technical analysis, the impact on the organization’s schedule, cost, and labor resources, and any suggested alternatives to the proposed change. If an organization will not be affected by the change, the IA will be returned indicating “no impact”. The BoD will meet either in person or by teleconference to discuss the change. The BoD will use the IAs and the meeting discussion to decide whether to approve or disapprove the proposed change. The BoD meeting minutes will clearly document its decision and the rationale supporting its decisions. These BoD minutes will be distributed to all BoD organizations and retained in the ISN project files. At the ISN-component level, a larger number of persons will be able to make changes. Architecture Group, in accordance with the CCB, will identify the specific ISN personnel authorized to make changes and the specific changes that each person is authorized to make. The CR process will be used to request and approve changes to this authorization list, but no IAs will be required. Each ISN component will have an associated ISN Component Folder (CF) which will be used to track component level changes. Any change, no matter how minor, made to that component must be recorded in the CF. The CF will be started when a component is deployed into the ISN and will depict the initial configuration of the component. Subsequent changes to that component will be recorded by the entries in the CF. The CF pertaining to a component may be either hardcopy or softcopy -- the critical factor is that the CF is readily available to network personnel. (If it is difficult to enter and update information in the CF, the CF becomes a hindrance rather than a tool and probably won’t be maintained) ISN CM Process Overview Classification is a triage phase. It begins when a ISN incident or change is identified; typically, when the Help Desk receives a trouble report. Operation Group evaluates the report and determines whether it can resolve the incident itself (e.g., a modem needs to be reset) or whether the solution requires a change to the ISN (e.g., a router configuration needs to be modified). Operation Group resolves the incident itself, it updates the Component Folder (CF) to record its actions and the report is closed. If Operation Group cannot resolve the incident or it requires a change to ISN, Operation Group originates an Engineering Request (ER) which formally transfers the incident to Architecture Group for resolution. Evaluation is an analysis phase. It begins when the IT Department receives an ER request from Operation Group (or any other ISN organization) documenting an ISN incident. Architecture Group analyzes the incident and identifies a potential solution. If the solution only involves minor changes to existing ISN components, then Project Director presents the incident and solution to the ISN Operations Department for approval. If the solution involves significant component changes or SN architectural changes, then Architecture Group originates a Change Request (CR) and presents it to the ISN BoD. Modeling and Testing is a research phase. It begins when a CR is under consideration by the ISN BoD. Architecture Group will model and test the potential solution to determine its impact on the ISN. Other ISN organizations will research the potential solution to determine its impact on their organizations. Each organization will document the results of its research using an Impact Assessment (IA). The ISN BoD will use these IAs as the basis for approving or disapproving the potential solution. Implementation is a deployment phase. It begins when the ISN BoD or Operations Department approves a solution. IT Department under the auspice of the Project Director will implement the change and deploy it. If the change performs properly, IT Department creates and/or updates the Component Folders (CF) to record its actions and the ER or CR is closed. Classification. Classification begins when ISN incident or change is identified; typically, when the Help Desk receives a trouble report. The incident or change is documented in the trouble ticket system Operation Group evaluates the trouble ticket to determine whether it can resolve the incident itself or whether the solution requires a change to the ISN. If Operation Group can resolve the incident itself and is authorized to do so (e.g., a modem needs to be reset), then Operation Group solves the incident, records its actions in the CFs, and closes the trouble ticket. If Operation Group cannot resolve the incident or is not authorized to do so (e.g., a router configuration needs to be modified) then it originates an ER and formally transfers the incident to IT Department for resolution. The flow then enters the Evaluation phase. Evaluation Evaluation begins when IT Department receives an ER request from Operation Group (or any other SN organization) documenting an ISN incident. First IT Department determines if the ER is a valid request; then it analyzes the ER to determine the extent of its impact. Not all ISN changes are major (e.g., replacement of a defective hub with a good hub of the same make and model) and may need only Architecture Group to effect the change. These minor changes will proceed directly to the Implementation phase. If the ER may require significant changes to the SN architecture or its components (e.g., a router needs to be reconfigured), then Architecture Group determines whether the potential solution requires SN architectural-level or component-level changes. A potential solution may require a combination of architectural and component-level changes; however if the potential solution involves any architectural considerations, then the entire incident shall be considered an architectural change. For Physical Layout-level changes, IT Department originates a CR and presents it to the ISN CCB. Marketing Department also performs preliminary research to assist the BoD is determining whether the change is plausible. If the BoD disapproves the potential change, then the CR is closed and the flow ends; if the BoD decides that the potential change should be implemented, then the flow proceeds to the Implementation phase; For component-level changes, IT Department performs preliminary research which it then presents to the ISN Operations Department. The Operations department reviews the incident and potential solution and determines whether the change is plausible. If the Operations department disapproves the potential change, then the CM process is exited; if the Operations Department decides that the potential change should be implemented, then the flow proceeds to the Modeling and Testing Network Modeling and Testing begins when a potential solution is under consideration by the ISN BoD or Operations Department. IT Department will develop and document a modeling or testing strategy, configure the evaluation environment, and execute the test. Data from the test will be analyzed and the impact on the ISN documented using an IA. The Other ISN organizations will also research the potential solution to determine its impact on their organizations. These organizations will also document their research using IAs. The IAs forms the basis of the ISN BoD’s decision regarding the potential solution. The ISN BoD will consider the test results, the impact on the ISN, and any organizational effect and either approve or disapprove the solution. If the solution is approved, then the flow proceeds to the Implementation phase. If the solution is disapproved, then Architecture Group reevaluates the incident and potential solutions and the flow returns to the Evaluation phase. Implementation Implementation begins when the ISN BoD or Operations Department approves a solution. IT Department will plan, execute, and deploy the change. The IT Project Director will therefore monitor, verify, and document that the change produces satisfactory results. If the change performs properly, the IT Project Director creates and/or updates the Component Folders (CF) and other ISN documentation to record the new baseline. If ISN personnel require new skills to support the change, Architecture Group will conduct training. The ISN BoD will close the ER or CR and Operation Group will assume operational maintenance. The flow will end. If the change does not perform properly, then the IT Project Director will reevaluates the incident and potential solutions and the flow returns to the Evaluation phase. References: Cadle and Yeates (2001) Project Management for Information Systems - Murch, R (2001) Project Management: best practice - Mochal and Mochal (1997) Lessons in Project Management - Journal (2003) Project Manager Today - Online Journal, Accessed 6th Jan 2007.Project Management Journal Reiss, G (2000) Project Management Demystified Yardley David (2002) Successful IT Project Delivery’ – Learning the Lessons of Project Failure Turner, JR (2000) The Handbook of Project Based Management. Read More