Key to successful software projects - Mitigate model

Arvis Zeile
Arvis Zeile
16 November, 2022 | 8 mins

The level of technical knowledge required to read the article: ⭐⭐⭐⭐⭐ (low)

Software development is not only our business, but also our form of creative expression. This is how we add value to this world, so it is important for us, also emotionally, that the projects are successful! We are proud of the fact that we have completed all the projects we have undertaken and started. It might sound unambitious, but in fact, according to statistics, only 2.5%* of IT companies worldwide can boast of such a thing. At the same time, a completed project is not always considered successful, because the budget and deadlines may be significantly exceeded or the intended functionality may not be executed. For this reason, we decided to dig deeper and find a solution.

Each project can be classified as a success, a debatable success, or a failure!

Admittedly, the global statistics are not flattering. The results of a large-scale study (CHAOS Report: Beyond Infinity) show that out of 10 projects, 2 will not see the "light of day", another 4-5 projects will be questionably successful and the remaining 3-4 will be successful. What is important: in the last 20 years, trends in these statistics have not changed significantly.

IT Project Outcomes Based on CHAOS 2020: Beyond Infinity Report

When we evaluate our projects and results, we see that we look good against the background of the overall statistics, but we know we can do better, so we dig further.

Our statistics

Why are there failed and questionably successful projects at all? The simple answer involves 4 points:

  • Every project always has a beginning and an end. Regardless of the number of stages, iterations or deliverables. A contract starts somewhere and ends somewhere.
  • Each project has several phases. These can vary, but one example would be: We conclude a contract, plan, draw a design, develop and implement.
  • At each of these stages, there is a whole series of things that can go wrong. We call them risks. If the risk does not occur, then everything is fine. If it occurs, then it becomes a problem.
  • The more risks there are, the more likely the project will be a questionably successful. If one is not lucky and acute risks occur, then the project is stopped.

Project Roadmap

The most common risk categories have long been known to industry players. They are basically classics:

  • inaccurate estimation
  • change of requirements
  • project status reports do not reflect the true status
  • third party integrations were not available, etc.

New topics which affect the outcome of the projects are added every year:

  • meaningful work
  • work-life balance
  • sustainable environment and relationships
  • remote employment
  • the rapid development of technology, etc.

These topics are mostly driven by the younger generation of specialists and these topics are important because they also have to be dealt with during the project.

An equally important question is "Why do projects succeed?" After our research, we give you a simple answer again:

  • There is a good project sponsor - these are customers.
  • There is a good team - they are developers.
  • There is a good environment where they all work together. The environment also includes processes and support mechanisms.
  • and...
  • It all goes through - discipline.

The central claim of the Mitigate Model is “Lack of discipline is the root of problems”. We identified that today’s person lacks the capacity and motivation for true discipline. There are simply too many surrounding factors to keep in mind. And the routines, that are the cornerstone of discipline, are demotivating. To be disciplined and transparent, we have all the necessary information and tools, because there is no shortage of regulations, methodologies and standards in the IT industry. There are hundreds of active standards and it is a collection of best practices from industry professionals.

In order to make our approach more transparent and disciplined, we’ve created the Mitigate Model, where we included operational methods (which fit us and work for us) from classic methodologies, guidelines, standards, etc. We synthesized the methods that did not work for us.

The Mitigate model consists of:

  • 8 stages.
  • 78 topics, each of which is subordinate to one of the stages
  • and 624 activities (the number is variable every quarter after refactoring the model), where each is subordinate to one of the topics

Each topic and its subordinate activities should be clearly measurable. With that in mind, has this activity been done in the project? How it's done. If it has to be done regularly, when is the next time it should be done?!

Appropriate potential risks, templates, preferred tools to be used and metrics to measure the performance of the activity are defined for the activities. There are currently 624 activities in the Mitigate Model, and the number will likely grow over time, so this is the moment when I have to repeat myself: “person lacks the capacity and motivation for true discipline. There are simply too many factors and tasks to be done". Therefore, the Mitigate Model is a digitally living structure. It monitors itself, it reports gaps in the progress of the project and it asks for human involvement where necessary.

A large number of metrics are created with relatively simple algorithms based on available data, but there are metrics that are measured with complicated and smart algorithms and thus claim unprecedented automation in project and risk management. These algorithms make the model come alive.

For example, a significant benefit is provided by the already implemented algorithm, which analyzes the content of the project's work tasks and the time required for the work. Based on historical experience, it classifies each task as real or risky. Of course, if there are 10 tasks, then a person can do it, but what if there are 200 tasks?

Summarizing what has been said so far, I offer 2 project scenarios:

  1. A project scenario where the Mitigate Model IS NOT BEING used and one relies on luck. If luck is not on the side of the project, then when risks occur, the result will be questionably successful or even unsuccessful. Mitigate Model is not being used in the project
  2. A project scenario where the Mitigate Model IS BEING used. In this way, already preventively handling possible risks. The project will be successful. Mitigate Model is being used in the project

The project will be successful. This is our promise to existing and future Mitigate clients. If you want your project to be successful, feel free to send us a message or call us.

* “A study by PricewaterhouseCoopers, which reviewed 10,640 projects from 200 companies in 30 countries and across various industries, found that only 2.5% of the companies successfully completed 100% of their projects” - (