Intact GmbH | Parkring 6 | 8403 Lebring | Austria |

Photo: Chess figures on chess board facing each other

Mastering IT Projects with Project Risk Assessment

Starting a project is always a challenge. Do we know what we want? Does the vendor understand what we want? Are they capable of delivering what we want? Are all persons required available and qualified to deliver what is needed? Will the project sponsor stay committed to the project until the successful end? Projects involve many doubts and risks. However, starting a project does not have to be a departure into the unknown like Christopher Columbus‘ expedition in 1492, which led to the European discovery of the Americas.

Many practitioners and researchers have analyzed uncertainties of projects and found that most projects—be it IT or non-IT—face very similar challenges. If addressed early in a project, risks can be mitigated and even turned into an opportunity or advantage. Neglected risks („hope“ principle), on the other hand, can torpedo even the best efforts. Based on state-of-the-art scientific literature and a large set of status reports from a world-leading IT service provider (not Intact), 6 common project risk factors can be identified.

6 Common Project Risk Factors

A project is typically influenced by the following 6 project risk factors that should be considered at the start of every project (initiation or planning stage). A thorough screening of those risk factors is crucial for the success of a project.

1. Requirements Uncertainty

The scope and requirements of a project point to WHAT needs to be produced or achieved in a project (deliverables, improved work behavior, improved processes, etc.). Early clarification will help you keep project cost within planned limits and assure that the timeline is met.

Key Questions:

  • Is the scope of the project clearly defined (in the contract)?
  • Are the requirements unambiguously stated in breadth and depth?
  • Is there a mutual agreement and understanding of the project change control process?

2. Executive Commitment

The commitment of top management stakeholders or lack thereof can drive or break a project’s success.

Key Questions:

  • Is there a clear project sponsor on the client side (responsible for financing) and is he or she motivated to conduct this project end-to-end?
  • Is there a clear project owner on the client side (responsible for delivering) and is he or she motivated to conduct this project end-to-end?

3. Non-Executive Commitment

While the commitment of top management is crucial for the sufficient provision of project resources in terms of budget and manpower, the dedication of lower management and operative team members is needed to get the project off the ground and achieve the results defined.

Key Questions:

  • Is the client project manager motivated to conduct this project end-to-end?
  • Are the relevant key users as well as the lower and middle management (business department, support team, etc.) motivated to conduct this project end-to-end?

4. Quantity and Quality of Internal Staff

The availability and skill set of the project team members on the client (beneficiary) side have great influence on the project’s progress.

Key Questions:

  • Is the client’s staff (or contractor’s staff on its behalf) available in sufficient quantity (available person days over time)?
  • Is the client’s staff (or contractor’s staff on its behalf) available in sufficient quality (right skills)? Is a project manager, implementation specialist, data migration specialist, developer, tester, etc. available?
  • Is the resource plan known to and committed by the responsible department leads?
  • Is the resource commitment checked on a regular—for example monthly—basis?

5. Quantity and Quality of External Staff

The same is true for the availability and qualification of external project team members who are not employed by the client company but who need to make a vital contribution to the success of the project.

Key Questions:

  • Is the service provider’s staff available in sufficient quantity (available person days over time)?
  • Is the service provider’s staff available in sufficient quality (right skills)? Is a project manager, implementation specialist, data migration specialist, developer, tester, etc. available?
  • Is the resource plan known to and committed by the responsible team leads?
  • Is the resource commitment checked on a regular—for example monthly—basis?

6. Political Diversity

Political diversity refers to the number of companies involved in the project. Typically, there are at least 2 parties with clear economic objectives. Having more than 1 external company involved can lead to conflicts of interests which can harm the achievement of project objectives.

Key Questions:

  • Are there any 3rd party providers involved in the project, such as contractors, external staff, interface providers, etc.?
  • If yes, is the project governance clearly defined? Are the roles & responsibilities clearly defined?
  • If yes, is the project communication plan and steering committee level clearly reflecting the 3rd party involvement?

The Practical Impact of Neglected Project Risk Factors

Neglecting these 6 project risk factors and omitting to ask the key questions related to them significantly increases the probability of project failure. Let me illustrate this on a real-life example involving:

  • High requirements uncertainty (risk no. 1)
  • Low non-executive commitment (risk no. 3)
  • High political diversity (risk no. 6)

Important Notice: Intact was not involved in the project described below and has no relation to the program concerned.

How Not to Do It

The case, which I am going to examine below, happened a few years ago in a very important project of a 100+ FTE (full time equivalent) program in Central Europe. It was a software implementation project that lasted approximately 1 year. The top management was highly committed (risk no. 2) and both internal and external staff had excellent skills (risks no. 4 and 5) matching the project’s requirements. In spite of all that, the project failed and delivered a poor outcome.

How can a project like that—professionally planned and richly equipped with resources—fail? In retrospect, the answer is simple:

  • Internal staff was unwilling to support the project
  • The scope of the project was not specific but vague
  • A third-party vendor followed a „hidden agenda“ that undermined the project
  • The project/program governance was not sufficient with no sanctions being imposed on persons who jeopardized the success of the project

A thorough and early project risk assessment could have contributed to the early identification and mitigation of these risks. Let us now take a closer look at what caused the project to fail and determine what needs to be done to ensure that these risks do not become problems in your next project.

How to Mitigate High Requirements Uncertainty

The project scope was outlined in a requirements document that included all the relevant parts. However, the requirements detail was utterly superficial and contained sentences like „The interface XY needs to be built“. The contractual effort estimate was based on such level of detail. Even worse, the project owner of the business department deliberately risked this level of „detail“ in order to hide what he actually wanted to build for his department!

A project scope this vague is unacceptable. As a delivery responsible, you have to stand up against this as soon as possible. You need to claim a more detailed requirements specification/evaluation in order to arrive at a more realistic plan for the project (cost, time, scope)—even if the contract is signed already. You need to know when and how to get the project done, regardless of how and by whom it is financed.

How to Mitigate Low Non-Executive Commitment

The project had more than enough project team members assigned to it (12+ FTE) and all of them had the skills needed. However, about a third of the team—both internal and external staff—was little motivated or unwilling to support the project. Instead of working to achieve the official project goals, they tried to channel all relevant information exclusively into their hands and use the project budget to build their „own system“. They were motivated to please the project owner for the sake of a good long-term (business) relationship.

The risk of low non-executive commitment can be mitigated by ensuring that project work is a legally binding part of staff contracts. If staff members are not obliged to work in projects, they will only focus on their normal job requirements if they dislike a project.

How to Mitigate High Political Diversity

The project involved a third-party vendor, a small IT service provider that ha worked with the (business) project owner and his department for many years and acted as an extended IT department. The vendor was threatened by the new program, which was supposed to replace „its“ system. As a result, the vendor still acted on the sole behalf of the project owner, who used the project budget to build a system to his liking regardless of the project objectives.

The program management, which financed all that work, was not able to establish a strict project/program governance. The business department torpedoed all attempts of the program management to re-align the renegade team members with the program’s objectives and scope. Even after internal project fights, upon which the team leader of the third party vendor quit his job, the project/program governance was not reinforced to 100%. The project ended with a 20% budget overrun while delivering only 40% of the original scope—a disaster.

In general, there is no problem with projects involving many different companies. However, it is crucial to define clear roles and responsibilities as well as objectives for each project team member. If this is neglected, people/companies will fall back to their own, particular interests which may not match the project objectives.

How Intact Leads Your Project to Success

Intact’s experienced Project Management team follows recognized project management standards and best practices to ensure the best outcome possible. Identifying risks early and tackling them as soon as possible in the project is only one part of that. At the end of the day, a successful project is the result of a clearly defined scope with specific goals, accurate and clear communication, full commitment from both client and service provider, and thorough planning.

Also see my article: A Practitioner’s Guide to Change Management

Write a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.