| The development of an IT strategic plan leads to the development of corporate or department objectives and serves as the primary guideline for allocating resources. The strategic plan keeps the organization headed in a profitable direction, and long-term planning minimizes the risk that organizational resources will not support the company's overall objectives. IT management is responsible for establishing sound project management and organizational policies. The combination of the IT strategic plan, sound project management, and organizational policies reduces business risks. The lack of these controls might lead to IT management that is crisis-oriented or firefighting. IS auditors should look for evidence of a prescribed, documented IT planning process. The existence of an ongoing process indicates that the company is constantly and diligently seeking an optimal "fit" between the information technology infrastructure and the organization's goals. Establishing a sound IT management methodology through sound project management, IT organizational hierarchy, and policies ensures that organizational goals are better fulfilled and that business risks are reduced. IS Project-Management Strategies and Policies The core principles of project management include the development of a detailed plan, the reporting of project activity against the plan, and the adjustment of the plan to enable corrective action. All project plans should be assigned to a project manager who is experienced in the area of implementation, who has skills associated with managing projects, and who has a good working relationship with the staff in planning and executing the project. The following list outlines the five basic phases of the project life cycle. Although the scope and details of particular projects will differ, the phases remain the same: Phase I: Plan the project This phase includes setting the time, cost, and scope of the project. In a software project, the planning team and project manager determine the relative physical size of the software to be developed; this can be used as a guide for allocating and budgeting resources. The team can use function point analysis to measure the size of an information system based on the number and complexity of inputs and files that a user sees and interacts with. The project team identifies the resources required, including internal/external personnel, cost, and additional facilities or equipment, and identifies the particular outcome(s) of the project. The team then determines the work breakdown structure, which is the core of the project plan, and identifies specific tasks, the resources assigned to those tasks, and project milestones and dependencies. Phase II: Schedule the project This phase of the project breaks the project into logically grouped activities and creates a timetable for each activity. The team should create Gantt charts to show timelines, milestones, and dependencies. When this is complete, the team should perform critical path analysis on the project plan. The critical path analysis shows areas of risk due to resource constraints, project timelines, or priority against existing projects. Phase III: Monitor continuously The project teams should monitor the progress of the project against the baseline using planning benchmarks, milestones, and deliverables. It is important that deviations from the plan be addressed throughout the project, to ensure that the cost, time, and use of valuable resources do not exceed the expected value of the project in meeting the business objectives. Phase IV: Controlling the project The old adage that "No good plan survives contact with the enemy" is particularly applicable at this point in the project. The project will encounter a variety of constraints and changes throughout the project life cycle. The team might find that business processes have changed, that valuable resources are not available (both people and budget), or that the expected outcomes of particular tasks were not realized. To overcome these types of changes, the teams must be flexible and continually must adjust the plan to keep the project moving. These adjustments might decrease the scope of the project, extend or shorten timelines, or bring on additional resources. The skills of the project manager and the planning team, and adequate communication of the resources on the project are key to successfully overcoming obstacles during this phase. Phase V: Closing the project This phase includes user acceptance of the products and services, as well as written acceptance of all expected outcomes. The project manager should evaluate the project personnel and reassign remaining project resources. The project history should be chronicled and used to determine whether the original return on investment will be realized as the product goes into production.
As stated earlier, major projects should be submitted to and prioritized by the IS steering committee, to ensure that the project aligns with the business strategy and that resources are available for successful completion of the project. A project manager should be assigned and must have operational control of the project and all resources assigned to the project. These resources might come from within the IT department, from business units, or from external sources. The IS auditor might be included on the project team as a subject matter expert on controls or to provide independent objective review of the project. A variety of factors can negatively impact a project, its timeline, or its cost. IS auditors also can look for some indicators when reviewing the project-planning process or individual projects. Project-planning risk indicators include these: Management does not use a formal project-management methodology. Project leaders are not adequately experienced in planning or managing projects. Projects do not have senior-level executive support. Projects are taking longer to develop than planned. Projects are costing more than budgeted.
Project risk indicators include these: Project leaders have insufficient domain expertise. Project teams are unqualified to handle project size or complexity. Project team members are dissatisfied. Projects do not include input from all affected parties. Project recipients are dissatisfied with project outcomes. Projects have a high staff turnover rate. Projects are frequently aborted or suspended.
These are some of the possible risks during project planning and implementation. In reading the following scenario, you can see the actual outcome of risks that are not mitigated. The IT department's help desk is receiving an increasing number of trouble tickets regarding slow response time on an application server. The server OS is Windows NT. After a cursory review, the system administrators determine that the application server response time would improve drastically if it was upgraded to Windows 2000 server. The remainder of the IT architecture, including the servers that provide user login (authentication services) are currently running Windows NT. The entire server infrastructure is scheduled for a planned upgrade later in the year, but the systems administrators are confident that this upgrade will not affect the applications running on the problem server or the rest of the infrastructure. When the upgrade is completed, the administrators receive a higher number of trouble tickets due to login problems, intermittent outages of the applications on the upgraded server, and network connectivity issues. Table 2.4illustrates both the risks involved with performing this upgrade and the lack of planning. Table 2.4. System Upgrade RisksSystem Component | Problem | Planning Solution | Risk Type |
|---|
Hardware | The network connectivity problem is related to an incompatible network card and drivers. | A proper plan would have included interoperability testing as well as capacity testing; the incompatible card and drivers would have been discovered before being put into production. | Business risk: The critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to "roll back" the upgrade. Information risks: The information in the applications can be adversely affected because users cannot enter and update data. | Operating system | The Windows 2000 operating systems does not provide login (authentication) services to users in the old Windows NT infrastructure. | Proper planning and testing would have ensured that the correct resources were tested and reviewed authentication systems to ensure that they were compatible. | Business risk: Critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to "roll back" the upgrade. | Application | The application availability is intermittent. | Proper planning and testing would have ensured that the old applications were compatible with the new Windows 2000 operating system. | Business risk: Critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to "roll back" the upgrade. | Interoperability | Network connectivity is intermittent. | Proper planning and testing would have ensured that the communications protocols with Windows 2000 were compatible with the network infrastructure. | Business risk: Critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to "roll back" the upgrade. |
A good project-planning process and regular review reduce overall risks to the business, information, and system. During the project-planning phase, the project-management team and IT management should determine the risk as it applies to expected outcomes and determine ways to mitigate the risk.
If an IS auditor observes that project approval procedures do not exist, the IS auditor should recommend to management that formal approval procedures be adopted and documented.
|
