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 is 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 is not enough to simply provide regular project status updates; these updates must be accurate. In fac t, 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 is 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 is almost universally true that once a project falls behind, the situation will only get worse without high-level involvement. And senior management will not 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 is 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 is 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 is 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 is 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 organizatio n, 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 chapter. 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.