Information System Project Management

The development of new information systems is a complex task and often falters due to unforeseen problems. Despite the tools available for project management, all too many information system projects fail to meet one or more of the criteria for success by being significantly behind schedule, drastically over budget, or by failing to meet the technical specifications of the system. To help ensure the success of an information systems project, it is essential that the project manager be involved in risk management on an on-going basis. In addition to the use of project and risk management tools, it is important to ensure that the project personnel have four types of knowledge: Process, domain, institutional, and cultural. In addition, projects should be monitored for signs of failures so that short- and long-term recovery methods can be applied in a timely manner and projects can meet their goals.

State of the art information technology allows businesses to exchange data and information faster and more accurately than ever before. As advances in information technology continue, the ways that it is combined into information systems that support organizations also proliferate. However, the development of new information systems is a complex task and often falters due to unforeseen problems. By some estimates, although approximately $255 billion is spent every year on the development of information systems in the United Sates, only one third of the projects meet all three criteria of success (i.e., on time, within budget, and technically adequate) while the rest are considered "troubled." Although some reports indicate that the success rate for information systems projects is increasing, project failure is still a major concern. In addition, many information systems projects are becoming increasingly ambitious and complex, so concerns about success continue to be an issue.

System Development -- Project Management

One of the ways to help keep information systems development projects on track is through project management. The art of project control is an often interactive process of keeping the project within technical scope (i.e., not adding work to the project outside that which was originally planned), within the budget negotiated for accomplishment of the project tasks, and moving along according to the predetermined schedule. In addition, project management requires balancing the risks associated with changes in any of these areas and how they affect the accomplishment of the overall goal of the project. This task is accomplished through a constant focus on three major aspects of the development activity: The project and its goals, the process of how these goals are met, and the performance of individuals and organizations to accomplish these goals. If a project is managed well, its goals can be accomplished on-time and within budget, not only giving the organization a profit in the short-term, but enhancing its reputation for good work at a reasonable cost, thereby enhancing its ability to continue to make a profit in the future.

Stages of Information System Development Problem Recognition -- Requirements Determination

There are several stages in the development of information systems. First, before a new business application can be developed, it must be recognized that a new application is needed. During this phase, the problem is defined and investigated and its feasibility is determined. If management decides that the project is feasible and its potential benefits outweigh its risks, a detailed requirements analysis needs to be performed. This analysis comprises a research study in which data are collected and analyzed to determine how best to proceed within the constraints set out by the organization (e.g., constraints of time, budget, personnel, or other resources). The next step in the process is to plan and design the new system. During this step, the requirements determined in the previous phase of the process are translated into design specifications.

Systems Design/Prototype Development

After the preliminary design has been approved, a full-scale, working model of the new system is built. This model -- called a prototype -- is used to help designers clarify the requirements that need to be included in the system. A working prototype can reveal flaws in plans much better than can be done by a review of written requirements. Too often, what looks good on paper can be awkward or untenable in reality. A prototype allows various design features to be tested to see if they will meet the requirements for the system or if the design needs to be changed or refined. Figure 2 shows the steps in prototype development.

Development -- Construction

After the project team has tested the prototype, the next step is to develop a detailed physical design of the application or system. During this step, any necessary modifications revealed by the prototype are made to the design. After the completion of the detailed design, the system is actually developed. During this phase, software and services necessary for the project are acquired either in house or through the purchase of contract labor or off-the-shelf applications. When the code is written, it must also be tested to determine whether or not it meets the requirements of the specifications, performs in a way that users expect it to perform, and detects errors that either stop processing or produce erroneous results. Once the system passes testing, it is implemented in the field. This phase of the project includes training the users in system operation and functions as well as conversion from the old system (if any) to the new system.

Evaluation

To help ensure the success of an information systems project, it is essential that the project manager be involved in risk management on an on-going basis. This requires a risk reporting structure so that those working closely on the at-risk activities can report problems to management in a timely manner and appropriate action can be taken to correct problems. Large information systems projects typically build in periodic formal reviews held between both the contractor and the customer to jointly determine the status of the project and whether or not mid-course corrections are needed. These typically include a preliminary design review (PDR) and critical design review (CDR) as well as a number of smaller reviews depending on the nature and scope of the project.

Preliminary Design Review

The PDR is conducted to determine whether or not the project team understands the preliminary design well enough to start work on a detail design and is attended by representatives of all the significant stakeholders in the project. Some of the issues addressed at PDR include factors driving the system design (e.g., customer requirements, performance, reliability, hardware or software limitations) and their prioritization, tradeoff analyses between performance and costs have been done to determine the most efficient way to meet the requirements of the design specification and to determine the impact of one section of the design on the rest of the product, critique of the design alternatives, discussion of how the system will be tested, and discussions of schedule, milestones, problems, and risks. PDR also may include a live demonstration or other proof-of-concept to support the proposed design.

Critical Design Review

The second major design performed on large hardware or software projects is the critical design review (CDR). This review is conducted before the design is released for manufacturing to make sure that it is at a point where it is good enough to begin implementation. Participants in the CDR are from the same functions as those in the PDR. The CDR may include discussion and justification of any major changes that have been made to the design since the PDR, a demonstration or discussion of the results of prototyping efforts, specifics of the testing strategy, and discussions of schedule, milestones, problems, and risks.

Difficulties in Controlling Information System Projects

Information systems projects can be notoriously difficult to control. Although the systems development process can provide a framework in which to try to control information system development, when one tries to control innovation -- the development of products or processes that are new or significant improvements over previous products or processes that have been introduced in the marketplace or used in production -- many factors can cause schedules to slip or budgets to be overrun. Lack of input from the user, insufficient resources, insufficient development professionals on the project, and lack of management support are just a few of the factors that can scuttle a development project. Project management systems can help track and monitor progress and keep the project controlled.

Applications

Despite the tools and techniques for project and risk management that are available to information systems project managers, information systems projects all too often fail on one or more of the three criteria of project success. The literature repeatedly offers several pieces of advice for those engaged in project management for information systems projects. Specifically, it is important to increase the support of executive sponsors, reduce the scope and duration of the projects, apply the principles of sound project management, and carefully manage requests for change. In addition, increasing emphasis is being given in the literature to developing frameworks that can help project managers deliver technically responsive systems that are both on time and within budget. One of the vectors on which frameworks vary is the consideration of factors that are important to the prevention of problems in information systems projects and factors that need to be considered in order to rescue a project that is failing on one or more factors of success. Examples of these approaches are discussed in the following sections.

Knowledge -- Learning Management for Information Systems Projects

Based on a review of the literature and data gathered in the field, Reich developed a conceptual framework of knowledge and learning for information systems projects. In this context, knowledge management is the application of principles and processes necessary to make the necessary knowledge for project success available to the project team. This approach includes the facilitation, creation, and integration of knowledge, minimizes the loss of knowledge, and fills in knowledge gaps throughout the life of the project.

Four Types of Knowledge

Specifically, Reich found that there are four types of knowledge that are important to the success of information systems projects.

• Process knowledge is the knowledge of the project teams and sponsors concern the project's structure, methodology, tasks, and time frames. Process knowledge allows team members to understand their role within the project and what is necessary so that the project can meet the three criteria of success. Process knowledge is also important to help the team organize itself so that the work can best be accomplished.
• The second type of knowledge essential for successful information systems project management is domain knowledge. Domain knowledge includes business knowledge (e.g., the industry; the organization in which the project is being done), technical knowledge (e.g., knowledge of information technology and systems; programming skills), and product knowledge (e.g., knowledge of the situation, problem, or opportunity; knowledge of potential solutions). Although this knowledge is helpful or even necessary for project success, each member of the team does not need expertise in each of the type of knowledge. Domain knowledge can be spread throughout the project team and the other people associated with the project (e.g., sponsors).
• The third type of knowledge that is important to the success of information systems projects is institutional knowledge. This is an understanding of the relevant history and background that can affect the success of the project, the power structure within the organization, the project team (particularly if there are multiple organizational team members), and the customer. This knowledge is usually shared through conversations with various insiders and observers of the relevant organizations.
• Finally, it is also important that the project team has cultural knowledge. For example, project managers need not only to be good general managers, but also need to understand the cultural norms of information technology professionals and how to manage within that environment. Further, there are other cultural dimensions on which team members can differ, including differences between different professions (e.g., web designers vs. programmers), as 1 as different international cultures. The successful information systems project manager needs to be able to effectively manage in this multifaceted environment.

Four Areas of Knowledge Risk

Reich found that there are four different areas of knowledge risks in information systems projects: inputs, governance, process, and outputs.

• Input risks center on the failure to learn from past projects or to develop a team that will have the depth and breadth of knowledge necessary to successfully complete the project as discussed above. Among the specific input risks are the failure to articulate and apply lessons learned from past projects, and the failure to build a team with sufficient knowledge to be able to make the project a success.
• Governance risks involve those involved in governing the project, in particular, the executive sponsor, project champion, project manager, and the project steering committee. Specifically, a project may become at risk if there is volatility in the governance team (particularly if the project manager is replaced) and a lack of role knowledge among the governance team (particularly lack of knowledge on the part of the project sponsor).
• Risks also may come from projects in operational processes, that is, the planning, designing, building, and implementing of the project. A number of specific risks can accrue in this area. Inadequate integration of cross-functional knowledge within the team, incomplete transfer of knowledge (e.g., from vendor to contractor or from consultant to internal project members), instability of project team membership (i.e., team members leaving for other opportunities, particularly between phases of a project), failure to specify a knowledge map so that team members know to whom to go within the team for specific kinds of knowledge can all contribute to the failure of a project.
• Finally, the most important knowledge risk occurs at the conclusion of the project if lessons learned are not articulated and passed on so that the problems cannot be corrected in the future.

Troubled Information System Project Recovery

Despite the best intentions, information systems projects can still become troubled. In many cases, however, it can be possible to recover and still have a successful project. Havelka and Rajkumar examined research in the areas of software project management, de-escalation of project commitment, and crisis management to develop a framework for both short-term and long-term project recovery for troubled projects. In the short-term, the authors suggest that an assessment be conducted to determine the exact nature of the problem then building a recovery plan based on the assessment. As part of this process, the goals and objectives of the project should be reviewed and agreed to by all the major stakeholders. The recovery plan should include achievable objectives and specific milestones to track progress as well as specific processes for tracking progress against the milestones.

Troubled Project Recovery Framework

As shown in Figure 3, Havelka and Rajkumar's Troubled Project Recovery Framework comprises four states: problem recognition, immediate recovery, sustained recovery, and maturity.

The first stage of recovery for a troubled project is the recognition that a problem exists and the decision to recover. Although this may appear to be stating the obvious, due to the complex and creative nature of information systems, it can be difficult to recognize that a problem with major impact has occurred. In many cases, a small "glitch" may mean that a little more time needs to be given to the current task but once the problem is fixed, the remaining work will go fast enough that the schedule is not negatively impacted. However, it is not always possible to tell in the middle of a problem whether or not it will be easily fixed or not. Sometimes a seemingly small problem will become insurmountable and scuttle the entire project -- or at least the project as originally conceptualized. Therefore, it is important that there is a good flow of communication between the project manager and the other team members. This will help all the players determine whether there is a major problem or not. Since information systems are, indeed, systems, a problem in one functional area can have impact on other areas as well. For example, in a computer-aided training system, if the programming function is having difficulty writing code that will do what the training specialists have envisioned, not only will the programming function be quickly behind schedule, but the training function also may run into difficulties if they have to scramble to come up with a different concept to train that particular task and rewrite their courseware to meet the changing system design. Denying that there is a problem is almost never a good coping mechanism.

Once the project team has become aware of the situation and admitted that there is a problem, the next step is to honestly assess what the problem is and get the help necessary to recover. This assessment needs to be objective and performed as soon after the admission that there is a problem as possible. At this point, the project manager, sponsor, and other major stakeholders can make the decision whether or not it is worthwhile to try to recover from the trouble or not.

If the decision is made to proceed, the next step is to develop a plan for recovery from the current problem. As part of this step, the problems being experienced on the project need to be triaged and the decision made as to which problem is major and necessitates a recovery plan and which problems are minor and will take care of themselves.

The fourth stage of recovery for a troubled information systems project is sustained recovery. This comprises the development and implementation of a long-term plan to get the project back on track. Problem recovery steps also need to be prioritized: What steps need to be taken first, how will these steps impact the rest of the schedule, where will the money come from to implement the recovery plan, and will the steps be sufficient to fix the problem area to meet the specifications for the project and how will this changes impact the technical acceptance of the rest of the project?

The final stage of recovery comprises documenting what was done and why (including any lessons learned) so that both the team members and the organization as a whole can prevent the same type of problem in future projects.

Terms & Concepts

Design Review: Any of a number of reviews of the product design, usually held between the customer and the contractor to determine the completeness and feasibility of the design at a given time in the contract. Two of the most common design reviews are the preliminary design review (PDR) -- held after the completion of the preliminary design but before the start of the detail design -- and the critical design review (CDR) -- held before the design is released for production.

Information System: A system that facilitates the flow of information and data between people or departments.

Information Technology: The use of computers, communications networks, and knowledge in the creation, storage, and dispersal of data and information. Information technology comprises a wide range of items and abilities for use in the creation, storage, and distribution of information.

Project Management: The process of planning, monitoring, and controlling a unique set of tasks that have a discrete beginning, end, and outcome. The project management process is performed within the three constraints of time, costs, and scope, with the goal of producing a technically acceptable product that is both on-time and within budget.

Prototype: A full-scale, working model of a new information technology application or a new version of an existing application.

Risk: The quantifiable probability that a financial investment's actual return will be lower than expected. Higher risks mean both a greater probability of loss and a possibility of greater return on investment.

Risk Management: The project management process of analyzing the tasks and activities of a project, planning ways to reduce the impact if the predicted normal course of events does not occur, and implementing reporting procedures so that project problems are discovered earlier in the process rather than later.

Schedule: A planning and tracking document that specifies the project tasks, how long each takes, and the order in which they must be accomplished in order to meet the project goals. Tools for scheduling include the PERT technique, Gantt chart, and CPM.

Stakeholder: A person or group that can affect or be affected by a decision or action. In marketing, stakeholders may include the organization's employees, suppliers, distributors, and stockholders.

Systems Development: The process of developing a new business system including performing a needs analysis, designing a solution to meet the needs, acquiring the resources necessary to support development efforts, and developing and implementing the solution.

Bibliography

Hajek, V. G. (1984). Management of engineering projects (3rd ed). New York: McGraw-Hill Book Company.

Havelka, D. -- Rajkumar, T. M. (2006). Using the troubled project recovery framework: Problem recognition and decision to recover. E-Service Journal, 5(1), 43-73. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=25738580&site=ehost-live

Lucas, H. C. Jr. (2005). Information technology: Strategic decision making for managers. New York: John Wiley and Sons.

Reich, B. H. (2007). Managing knowledge and learning in it projects: A conceptual framework and guidelines for practice. Project Management Journal, 38(2), 5-17. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=25532326&site=ehost-live

Senn, J. A. (2004). Information technology: Principles, practices, opportunities (3rd ed.). Upper Saddle River, NJ: Pearson/Prentice Hall.

Suggested Reading

Davis, C. K. (2007). Two information technology classroom minicases: Benefits assessments and implementation issues. Journal of Information Systems Education, 78(1), 15-20. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=25262814&site=ehost-live

Dyerson, R. -- Roper, M. (1992). Large scale information systems in United Kingdom. In V. J. J. M. Bekkers, P. H. A. Frissen, -- B. K. Brussaard (eds.), European public administration -- informatization (pp. 299-328). Fairfax, VA: IOS Press. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=11633185&site=ehost-live

Glass, R. L. (2006). Looking into the challenges of complex IT projects. Communications of the ACM, 49(11), 15-17. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=22938916&site=ehost-live

Mitchell, V. L. (2007). Knowledge integration and information technology project performance. MIS Quarterly, 30(4), 919-939. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=23113027&site=ehost-live

Richmond, A. -- Skitmore, M. (2006). Stress and coping: A study of project managers in a large ICT organization. Project Management Journal, 37(5), 5-16. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=23858908&site=ehost-live

Summer, M., Bock, Douglas, -- Giamartino, G. (2006). Exploring the linkage between the characteristics of IT project leaders and project success. Information Systems Management, 23(4), 43-49. Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=22291666&site=ehost-live

Taylor, H. (2006). Risk management and problem resolution strategies for it projects: Prescription and practice. Project Management Journal, 37(5), 49-63, Retrieved August 7, 2007, from EBSCO Online Database Business Source Complete. http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=23858912&site=ehost-live