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.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment