| HOME Software Testing Data Mining and Warehousing |
|
INTRO The successful design, development, and implementation of information technology (IT) projects is a very difficult, complex, and, at times, daunting process. However, although developing IT projects can be difficult, the reality is that a relatively small number of factors control the success or failure of every IT project, regardless of its size or complexity. There is nothing esoteric about those factors. The problem is not that the factors are unknown; it’s that they seldom form an integral part of the IT development process. Of course, the recognition and management of these factors does not ensure IT project success. Understanding the factors and the part they play in successful project management is one thing; appropriately managing them is something else. In addition, there is a high potential for project failure in not recognizing the part these factors play, or failing to appropriately manage them. If these factors are so clearly important and well-known, why do they not form an integral part of every IT project? The short answer is that they should. The issue here is that because they are not used, too high a number of IT projects suffer some degree of failure. The phrase " IT project failure" often raises a specter of some colossal failure. E.g., the project never goes operational, or it’s abandoned in midstream after considerable expense. In addition, there are other, qualified IT failures, such as projects that exceed their development time and expense estimates, but ultimately become operational. There are also many projects that move to production status, but don’t meet the expectations of internal customers as defined in the project specifications. and projects may be considered failures if the applications take too long to process the data, or if they regularly fail in the operational environment. In short, many organizations don’t have a particularly good track record in IT project success. However, many IT project failures can be eliminated or mitigated by understanding and managing the nine project failure factors described in this Section. These factors should be recognized for the strength they can bring to every project, and accorded the attention they deserve. NINE CRITICAL FACTORS The following 9 factors can and do make or break IT projects:
Organizations that recognize and work to appropriately include the nine factors in IT project development are taking an important step in moving to more consistent IT project success. However, they will have to do more than recognize the factors' importance. They must also understand the interlocked nature of the factors, which together form a mosaic of strong project management. If IT project success is to improve, the role and importance of each factor must be understood. A discussion of each of the factors will provide information about how they affect IT projects. 1. SENIOR MANAGEMENT COMMITMENT When it’s clear that a particular IT project has the interest, the support, and the commitment of the organization' s senior management, everyone involved in the project will have a sharper focus. Almost all IT projects are expensive. In addition, these projects present opportunities - some of them significant - that foster organizational success. Poorly done projects can hamper the organization' s success; some can even put the organization in jeopardy. Therefore, it’s imperative that the senior managers responsible for the areas affected by a particular project become and remain involved. If, as often happens, the process is completely left to the IT department, the project is in trouble. There are numerous examples of IT projects that have considerably benefited an organization. There are also many examples of IT project failures that have seriously disrupted an organization' s business. Beyond the issue of total IT project failures, there are IT projects that are not true failures, but are less than successful. Those projects never deliver what was originally promised and are sometimes simply abandoned. IT projects are sometimes conceived, funded, and built without appropriate senior level review and involvement. This should not be seen as a failure on the part of senior management to approve a given IT project. In virtually all organizations, senior management approval is mandatory when a project reaches a certain funding level. In the majority of failed IT projects, such approval was undoubtedly granted at a high organizational level. Therefore, the issue is not that IT projects go forward without appropriate approval, but rather that the approval is too often automatic. All too often, senior management approves IT projects that carry potentially serious consequences for the enterprise, without clearly understanding the organization' s exposure or risk. Of course, one can argue that IT management is obliged to properly inform senior management of the project' s potential downside. However, in the euphoria of getting the project approved, the project' s risks may be ignored or glossed over. In fact, some organizations have a repeated pattern of project proposal and subsequent failure, yet senior management remains aloof. There is an important distinction between approval of and commitment to an IT project. In IT projects that encounter difficulty, there is usually some point at which members of senior management become involved, and their attention and commitment are in place. However, this often happens at the wrong end of the project. IT projects beyond a set funding level, which varies by organization, should never be seriously considered without senior management' s clear understanding of the project' s perceived difficulties, risks, and benefits. Too many IT projects gain approval based upon hype and an unrealistic calculation of the potential benefits. Thus, senior management, with or without an IT background, should probe for the facts. The project should be abandoned, or at least halted, until their questions can be satisfactorily answered. 2. ADEQUATE PROJECT FUNDING IT projects often require heavy financial investments if they are to be successful. However, ample project funding is not in and of itself a panacea; access to large sums of money does not ensure IT project success. Conversely, inadequate project funding will lead to delivery of less than promised, if not outright failure. Organizations must recognize that the time, hardware, software, and people components that make up an IT project are expensive. They should therefore devote ample time and attention at the project' s beginning to analyze and apply realistic costs to the components. Although good project expense analysis may not produce complete figures, the process should provide a reasonable understanding of the expense associated with the project. Once a set of realistic figures is produced, the organization should also build a reasonable amount of contingency funding into the estimated project cost. IT project funding should be seen as a continuing and flexible process. While a reasonable estimate of project expense must be made to obtain initial approval, this figure should not be considered the final project cost. After all, changes will be incorporated into the project plan as it goes forward. These will undoubtedly involve added functionality, which will in turn translate into increased project cost. As the project moves forward, its implications will be better understood. As the true scope of the project is revealed, the project manager can more accurately identify project expenses. Therefore, costs must be recalculated at several checkpoints in the project life cycle, and the new figures communicated to senior management. Senior management should view the changing project costs in a positive light, although they are more likely to rise than to fall. This is because a discussion of the changing expense offers senior management an opportunity to probe why the estimates changed. For example, the project sponsors might have requested additional functionality, which increased the cost. At this point, senior management has an opportunity to decide whether or not they want to fund these additional project expenses or forego the added functionality. Otherwise, there is often de facto approval of increased functionality (and project expense), without senior management involvement. Without interim project expense reviews, additional functions are often added, raising project expense, but such additions are not revealed until the project is completed, if ever. In addition, interim estimates provide an opportunity to reduce the project scope, if necessary, to bring the cost to a more desirable level. This might entail extending the project' s installation date, abandoning parts of the project, or curtailing some of the features. Whatever the result of the project review, it presents an opportunity to make project-expense-related adjustments in a businesslike manner. 3. WELL-DONE REQUIREMENTS and SPECIFICATIONS It’s absolutely critical to the success of any IT project that the organization develop a clear understanding of what will be delivered and what won’t be delivered within the project' s scope. In fact, it’s not unusual for the people who requested the project to raise issues part way through it about functions that are not to be delivered. This sparks arguments between the project sponsors and the members of the IT department, who both seek to assign blame for the apparent oversight. It represents poor development work to make assumptions about inclusion or exclusion of items in an IT project, and is bound to create confusion and disappointment, if not serious project disruption. Even if there are well-thought-out and documented project requirements and specifications, unforeseen events will arise as the project moves forward. Sometimes, minor additions can be made to the applications, requiring little time and expense. However, the lack of inclusion of major items can render the project inoperable. When this happens, there are two unattractive options. The project can be reworked to include what was overlooked, which is likely expensive and time consuming, and shows the IT department in an unfavorable light, even if it was not responsible for the oversight. The other option is to abandon the project. Not only must the project-related requirements and specifications be complete, they must be reviewed by people familiar with the business issues the project is to support. This review must be careful and thorough, to avoid subsequent IT development difficulties. All too often, when it’s found that additions must be made to the requirements and specifications in the later stages of the project, a workaround is attempted. In addition to the time and expense of such a solution, it often does not work, or does not work well. And, while strong project management requirements and specifications don’t ensure project success, they add considerably to the probability that the project will succeed. 4. A COMPREHENSIVE PROJECT PLAN IT project planning is not a waste of time, although many believe it is. In fact, there is a very strong correlation between the length of time allocated to project planning and the project' s ultimate success. Granted, IT planning can be overdone, but IT installations seldom exhibit excessive attention to planning. There are three benefits to be gained from strong project planning. First, planning allows the planners to present a clear, well-documented, properly focused understanding of the project. Second, the planning process raises questions that would not otherwise be considered. There is often a rush to begin the project without an adequate understanding of what will be done or the ramifications of the work. The third planning benefit is that it builds confidence in the project and its processes. As a result, when planning is finished, it’s easier to confidently begin the project. In a well-done versus a poorly planned project, then, the transition from project concept to delivery will be easier and faster. Appropriate project planning is a function of an organization' s strong IT project discipline. To succeed, IT management must make it clear that planning is an important component of project management, and that the required planning must be completed and approved before the project moves forward. 5. COMMITMENT OF STAKEHOLDERS The track record is poor in organizations where responsibility for IT projects rests with the IT department. In fact, IT projects are, with limited exceptions, developed and operated to meet the organization' s business needs and interests, rather than those of IT. The organization is poorly served when people outside the IT department can dissociate themselves from projects in which they have a vested interest. Sometimes, IT projects of significant size are completed with virtually no internal customer involvement. Their attitude might well be, " Show me the results when the project is done." If and when projects of this type are finally installed, they rarely meet internal customers' needs. IT department managers should realize that IT has a vested interest in developing a process that ensures strong internal customer involvement in its projects. A lack of customer involvement virtually ensures eventual customer dissatisfaction with some project aspect. If IT managers cannot get customers to share project ownership, they set themselves up for eventual customer criticism. Therefore, IT should not initiate or install any projects without the complete support, involvement, and attention of the appropriate internal customers. It represents a failure on the part of senior management if internal customers take no project responsibility, yet complain about the project' s content and performance once it moves into production. Because business projects warrant the investment of large sums of IT time, effort, and money, they should warrant a comparable investment on the part of the internal customers who requested the project. It’s senior management' s responsibility to make certain that everyone affected by a particular IT project has a share in the project' s ownership. It will require fortitude on the part of the IT management team to halt development of an IT project due to a lack of internal customer involvement. However, this is the correct approach; otherwise, IT is exposed to excessive risk. 6. PROJECT STATUS REPORTING It’s not enough to simply provide regular project status updates; these updates must be accurate. In fact, IT project status reports are often overly optimistic. While it might be more comfortable for departments to believe that steady project progress is being made, it’s more important that the reported status is realistic. IT projects routinely fall into difficulty. One cause is in the failure to accurately report the real project status in a timely fashion. IT might provide inaccurate project reporting in the usually mistaken belief that lost ground will be regained as the project moves forward. After all, no one will be the wiser when the lost ground is made up and the project is back on schedule. However, it’s almost universally true that once a project falls behind, the situation will only get worse without high-level involvement. and senior management won’t provide the needed help as long as it thinks things are going well. As early in the project as possible, project status reporting should identify adverse issues, as well as recommend how the difficulties can be overcome. Of course, candid project reporting can create tension for both the project team and the customer areas. Some degree of tension is desirable, because it will cause people to consider issues early on which otherwise might not arise until later in the project. And, while dealing with IT project problems and tensions can be difficult, ignoring them will only make them more difficult. Members of IT projects typically postpone the delivery of bad news, such as a delay. When this happens, senior management might be alerted to the problem by some other area, or the project manager might have to reluctantly admit to the project' s delayed status. Both scenarios have a negative effect on senior management, on everyone involved in the project, and on the project itself. 7. CRITICAL RISK ASSESSMENT An organization' s senior management should complete and publish a careful analysis of the project' s risks before it seriously considers approval. It’s not enough to recognize that the project has some risk, or to have a vague idea of some of the possible project-related risks. Risk, as it applies to a particular IT project, must be well-understood. More importantly, those who will suffer from the project-related risks must be made as aware of them as promptly as possible. Identification of project risk falls into two categories: the more usual and obvious risks, and the risks that will be generated based upon the functions and requirements of the particular project. Usual and obvious project risks include: ++ The use of software that is new, or at least new to the organization. ++ The organization' s level of IT skill and knowledge. Obviously, a seasoned, well-trained group of IT professionals will be more likely to master the project development than less experienced people. ++ The track record of the IT department in successfully managing IT projects. IT departments that have a strong development track record bring less risk to a project, regardless of its size and complexity, than an organization with a poor development record. ++ The size and complexity of the proposed project. ++ The willingness of the organization to properly fund the project. ++ The level of trust and respect between the IT members of the project team and the internal customers on the team. Risks associated with the particular project' s functions include: ++ The perceived importance of the project to the business of the organization. Obviously, an IT project that carries heavy business implications will present a considerably higher risk level than upgrading an existing system. ++ The ability and willingness of those outside the IT department who have requested the project to become and remain involved throughout the life of the project. In projects where the assistance of outside vendors is required to bring the project to a successful completion, the level of dependency on that vendor must be calculated and managed. The willingness and ability of the vendor to perform as expected must be seriously considered. In addition, circumstances within vendor organizations change. For example, part way through the project, the vendor might decide to abandon the line of hardware the project is using. Alternatively, a competitor might buy out the vendor, lowering the vendor' s level of project support. Finally, the vendor might just go out of business. ++ The quality of the project requirements and specifications. The higher the quality of that work, the more probable the project will be a success. ++ The possibility of the loss of a key person on the project, either from IT or from the internal customer side. If that person alone has knowledge critical to the project' s success, his or her loss could deal the project a fatal blow. Every IT project presents its own set of risks. A businesslike approach to project management requires carefully considering and addressing these risks with internal customers and senior management as part of the project' s approval process. If the risk analysis leads to a decision not to move forward, it’s much better for everyone involved that the decision is made sooner, rather than later. 8. PROJECT CONTINGENCY PLANS As a project moves forward, difficulties might well arise. Although the organization might be highly confident that the project will succeed, it’s prudent to consider the possibility of some type of failure. Because such a possibility exists, the organization should put a plan in place to overcome difficult situations if they should arise. Some examples of IT project contingency planning include: ++ Recognition that the planned level of hardware resources to support the project may prove inadequate when it’s moved into production. One of the common failings of IT projects, particularly in client/server environments, is disappointing processing performance when the applications move to the production environment. Although the hardware plan might seem adequate, that might not be the case. Therefore, the project plan should have a provision to increase hardware resources should the need arise. In addition, senior management should be advised of this possibility. ++ Anticipation of " surprise" additions to the project' s functionality as it moves forward. Too often, part way through a project, the project must incorporate items that were overlooked, or changes in the business needs associated with the project. This means schedule delays (with talk of " phase two" ), and additional project expense. In addition, other projects may be delayed, and business initiatives dependent upon the successful completion of this project may be delayed. Project surprises are always a possibility, despite a strong set of project requirements and specifications. It should therefore be a mandatory part of the development process to recognize this possibility and raise the issue with the appropriate people. When an IT project is of paramount importance to an organization, it makes good business sense to consider the possibility of delay. In addition, an attempt should be made to construct a plan to work around this eventuality. Developing a project contingency plan should be linked to the issues of project planning and project funding, as addressed earlier in this Section. However, while appropriate planning will identify many of the issues that may arise and that should be built into the project, no amount of planning will anticipate everything that might happen. If funding is flexible, senior management will already realize the possibility of additional expense. Obviously, the ideal is to generate a plan, the first time around, that is absolutely precise with regard to expense and functions. However, that is virtually impossible in a project of any magnitude. Believing that such a process is viable represents one of the fundamental causes of IT project difficulty. 9. A WILLINGNESS TO STAY THE COURSE All IT projects face some level of difficulty, and much of it can be mitigated through sound management approaches. However, problems must be anticipated. As they arise, people will try to find ways to reduce the pain associated with the project. At this point, pressure will likely build to modify the project. Some of the suggestions for doing so include: ++ A reduction in the features to be delivered. A phased approach to the project can be introduced, designed to shift parts of the project from the current schedule to some (often poorly defined) future date. ++ An approach that proposes that flaws or problems in the system be fixed by some workaround process. This process offers a solution to the current problem, but will often do less than what was specified in the original project plan. The idea is that the problem should be fully and correctly repaired, but there is no time to do that work now. The workaround is usually accompanied by a promise to return to the problem at some later date and make things right. When this occurs, the chance of correcting the problem at some later date will be close to zero. ++ A willingness to reduce testing standards and controls to meet project deadlines. Again, the stance is to wait to fix testing-related problems so that the schedule is met. ++ Abandonment of the project. ++ Obviously, if a project is in difficulty, some steps must be taken to correct the situation. These steps, and their ramifications on the entire project, should be carefully thought out and considered. It’s important that everyone involved in the project realize that if there are project difficulties, there may be pressure to adjust the original plan. The plan should be flexible enough to allow adjustment, if needed. Organizations must avoid overreacting to problems and adapting the wrong approach to solving them. Those responsible for the project' s ultimate success within the IT department should ensure the continuing support of the organization' s senior management for the project. If the project is of sufficient importance to be initiated, it should be adequately supported if things should go wrong. In obtaining senior management support, project managers must be willing to present an accurate picture of the potential difficulties inherent in the project. Insofar as is practical, senior management must be given a realistic assessment of the potential for difficulty and be willing to stay the course if things go wrong. CONCLUSION It’s impossible to identify and manage all the potential difficulties and ramifications associated with IT development projects. The larger the project, the greater the probability of unforeseen difficulty. In large IT development projects, it can become a massive task to coordinate the various teams working on the project. If organizations attempted to find and resolve all project difficulties and potential difficulties, it would keep projects from moving forward; this is sometimes referred to as " analysis paralysis." This Section does not strive for perfection. Rather, it tries to raise the awareness in IT installations and with the internal customer community, that the better prepared everyone is going into a given project, the greater the likelihood of a successful project. While no one wants to be involved in an IT project that is less than successful, virtually every organization has project failures. If available, methods should be implemented to alleviate some of the difficulties and, as a result, improve the levels of IT service and customer satisfaction. Of course, the nine factors outlined here create more work. However, this additional workload need not be a burden if the factors are understood and realized. When an organization incorporates the nine factors into the normal IT project development processes, the work required becomes less of a burden. If a relatively small amount of extra time and effort can improve IT projects and increase internal customer satisfaction, it’s a small price to pay. == |
| Top of Page | More PM Articles | Prev: Tips to Improve Project Performance | Next: How to Manage Project Management | Info-Source.us |