Identify risks in IT projects

Information technology systems are currently booming in Vietnam. Such exceptional growth not only brings benefits but also poses unpredictable challenges to enterprises. The topic was introduced in a series of articles on IT Project Risk Management – Practical Application in the Banking and Finance sector at FPT IS, aimed to provide an overview of how to identify risks in IT projects for timely prevention and remedial measures.

Project implementation requires companies to understand what project risks are. The success in project management at FPT IS offers practical experiences to tackle the following questions:

• How to identify all risks in a project?
• Are all risks included in the action plan?
• How to balance risk management and costs?
• What are the basic risk prevention measures?

1. How to identify risks?

Question: When taking on projects, the project managers desire to carry out project risk management according to the theoretical principles of risk management. However, they often have no clue where to start. So, how do you usually identify risks at the very beginning of a project?

Answer: At FPT IS, the contract will normally be the very first source where we start looking for risks, then other documents involved in the contract pre-signing stage. Moving forward, our project team and the company (hereinafter referred to as the customer) will continue to collect risk information from stakeholders in terms of project personnel in both parties, each party’s priorities given to the project, and so on. Below are details of what should be done:

• Read/study the entire project dossier. The primary document to dig into is generally the contract. Time, technical, professional, or human risks are often spotted in this document. Besides, risks can also be pinpointed in sources involved in the pre-signature stage such as pre-contract agreements, request for proposals, request for quotation, and others. Normally, these risks are posed by the discrepancy in expectations between the original request of Party A and the solution offered by Party B because most likely, those who issued initial request for proposals cannot yet picture how Party B’s solution will specifically meet their initial requirements which they bear in minds.

In addition, there are agreements signed with the customer at a broad level, even larger than the project’s implementation scope, which act as the premise for the current contract signing. There are even requirements added as fundamental items in the documents created at the pre-signature phase of the current contract. They are considered mandatory requests that must be met, and are not incorporated in the current contract and/or not specified in requirement collection/detailed requirement analysis documents. Being aware of these requests ahead of time and setting up the preventive plan accordingly can avoid risks related to system adjustments or costly changes during UAT stages or future upgrade contracts, consequently creating a broader risk management system at the organizational level for the customer who uses the offered products/services.

If you use the product purchased from a provider for your project, this provider or some other subcontractors can be hired to involve in your project implementation process. The contracts/cooperation agreements between you and this provider/these subcontractors also need to be thoroughly studied.  Identify discrepancies in the agreement between the main contract signed with the customer and the contracts/agreements signed with the provider/subcontractors. The project can only be “temporarily safe” (or in other words, we can “temporarily feel secure”) if all customer requirements are fully transferred to the contracts/agreements signed with the provider according to the principle of “in exactly the same words”, especially when you are not the owner of the technology/business/solution. It will be even safer if the scope of all agreements with the provider/subcontractors is broader than that of the contract with the customer.

I once joined the implementation of a project with a contract signed with an application software license provider.  When checking the detailed specifications of the provider’s license offering, I understood only a very small part. As I cross-checked the provider contract with the customer contract in terms of fulfilling the customer’s requirements, I reassured myself that the information I saw in the agreement could meet the customer’s requirements. However, just a few weeks before the system went live, I realized that the specifications stated in the provider contract could only partially fulfill the customer’s requirements.  Reviewing the communication with the provider to clarify the license matter during the bidding process, I discovered that the technical specifications had been discussed and clarified in detail between the provider and the bidding team, and the provider confirmed meeting 100% of customer’s requirements.  It is unclear why the customer’s detailed requirements were not transferred but written in the form of technical specifications during the contract-making process with the provider.  This incident seriously affected the project’s finances and the system’s go-live time.  That’s why until now, I’m still loyal to the principle of “in exactly the same words” mentioned above.

• Working with the bidding team is also a key to identifying risks. This not only enables the project team to quickly approach Party A’s project goals, but also helps find existing problems and risks as speedily as possible. There may be communication and clarification of uncommon points/terms carried out via email, text message, or any informal communication channels between the bidding consulting team and the customer/provider/subcontractors being omitted from the contract. Collecting all of this information gives us enough material to assess possible risks to the project in the future.  Consequently, continuously setting up working sessions with the bidding team as soon as receiving and starting to learn the contract and constantly staying connected with this team even during the implementation phase of the project.
• Talking/working with your project’s professional and technical teams to assess their expertise and management capacity, thereby finding human risks from these project team members. In-person talks (through any means: official meetings, working sessions or simply “sidewalk iced tea” gossips) also help the project manager determine their level of engagement, level of trust and comfort with the project and with other project team members. These members may be very good at their expertise, but it may ring a signal of risk if they are not dedicated to the project. The same likeliness of risk happens when one resource is simultaneously allocated in multiple projects. They may also have hidden dissatisfaction with other team members, which will also affect the overall progress and be a human resource risk. Additionally, the project team members may show us weak points in the project from their own perspectives, which can be overlooked or ignored by the project manager, or even the team leads. From this information, the project manager can identify professional, technical or solution risks.
• Talking/working with key personnel of the customer and contractors/provider also enables us to detect risks posed by their expertise (professional, technical), their level of understanding about the project and requirements. Most importantly, this helps us identify risks originating from their organization. Normally, the customer’s professional/technical personnel are regular employees in certain departments and assigned to participate in the project possibly as a part-time job in their spare time. The fact that employees’ project participation is neither considered their official work, nor calculated KPIs by the organization entails risks to the progress and quality of the product.
• Identifying the customer’s/provider’s policies/plans at the organizational level to clarify whether the project meets the basic conditions for successful operation. Many projects are forced to stop or cancel due to lack of basic conditions for successful implementation of an IT project such as: project teams of all parties do not have the same goal, absence of effective project sponsors, etc. Policies/plans of the customer (such as modifying a stably running core system that is intended to connect and integrate with the system you are deploying) or the provider (such as planning to stop support for the tools/solutions you are using to implement the project) are also highly likely to become project risks. The fact that the customer is simultaneously running another project that is more important and competing for resources with your project can pose a big risk to the timely completion or the assured quality of the project. So, if possible, take full advantage of your network to determine the importance level of the current project compared to other projects/work in the customer’s organization. This will not be easy if your role is a project manager, but it is not impossible either if you determine to learn about it.
• Checking issued policies at the industry/country level to verify if there is any short- and medium-term change in laws, circulars, and decrees on the business you are implementing in the project. Failure to identify the scope of implementation during the implementation period is one of the main reasons causing the project to be prolonged.

2. How to execute projects effectively

Question: Do you usually handle this task – identifying project risks – alone or do you ask all project team members to participate? And if you join a project with an inexperienced project manager, what would you do?

Answer: At FPT IS, project managers usually do not handle this task alone. Instead, they work together with key professional and technical personnel in the project through Brainstorming activities. We generally do not assign this task to all project members because some of them are too young and inexperienced, and it takes the Project Management Board a lot of time to filter out truly valuable information from what these members provide.

• We use Brainstorming method to quickly identify risks in a short time or in project areas where the project manager lacks expertise. We often apply this measure in 2 small stages: (1) brainstorming with key project personnel to identify all possible problems/risks 🡪 (2) consulting with experienced experts on specific type of project/product/solution.

Question: So what if the project manager doesn’t know which experts can participate in the assessment? 

• Simply, submit your request for expert review to your Project Director or the director of the project’s managing unit, and let them find the experts for you. When you need support, your organization is always there for you. In some cases, experienced experts are not available to evaluate the risks/issues discovered by the project team. These risks should be temporarily recorded, continuously monitored and evaluated during project implementation until there are clearer signals.

When do enterprises need to identify risks?

Question: Will risks only need to be identified at the early stages of the project?

Answer: Risk identification needs to be done at the beginning of the project and continued throughout the project implementation:

• The project manager needs to continuously review the project implementation status and adjust the risk list and risk remediation and prevention plans accordingly. We certainly cannot have a single, immutable risk list identified at the beginning of the project, since  risks will become more apparent or diminish throughout the project implementation process as more information becomes available, or as we implement preventive/corrective actions for one or a group of certain risks/issues.

Question: With the methods you mentioned above, are you confident that you can determine all the risks at the beginning of the project?

Answer: The approach I introduced enables us to identify the largest number of risks possible at the early stages of the project, not all of them. Therefore, the purpose of constantly reviewing the project status is to keep detecting risks that have not been discovered before. In particular, there are risks that do not exist from the beginning of the project, and only appear when the project has new factors added during the implementation process.