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 is 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
depart ment, 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 is absolutely critical to the success of any IT project that the organization develop a clear understanding of what will be delivered and what will not be delivered within the project’
s scope. In fact, it is 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 is 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 do not 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 is 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 fro m projects in which they have a vested interest.