5 top reasons for IT project failure and how offshoring can help5 redenen waarom IT projecten mislukken en hoe offshoring kan helpen5 top reasons for IT project failure and how offshoring can help5 Top Gründe für das Misslingen von IT Projekten und wie Offshoring helfen kann

A recent research from American project management consultancy PM Solutions identifies the top 5 causes of project failure. The research among 163 companies shows that only 47% of projects are termed ‘successful’, whereas the remaining 53% could be labeled ‘failure’ (either terminated, failed or recovered). The top 5 causes for project trouble cited by the research:

1. Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
3. Schedules: Too tight, unrealistic, and overly optimistic.
4. Planning: Based on insufficient data, missing items, insufficient details, and poor estimates.
5. Risks: Unidentified or assumed, not managed.

   Een recent onderzoek van PM Solutions, een Amerikaans project management advies bureau, beschreef de top 5 oorzaken van het mislukken van een project. Het onderzoek bij 163 bedrijven geeft aan dat maar 47% van de projecten als ‘succesvol’ gezien wordt, terwijl de overige 53% als ‘mislukt’ wordt gezien (afgebroken, mislukt of hersteld). De top 5 oorzaken voor problemen bij projecten volgens het onderzoek:

   1. Eisen: Onduidelijk, geen overeenstemming, geen prioriteit, tegenstrijdig, dubbelzinnig, onnauwkeurig.
   2. Mensen: Niet genoeg mensen, conflicten tussen mensen, hoe lang mensen hun positie behouden is onduidelijk, slechte planning.
   3. Schema’s: Te strak, onrealistisch, en veel te optimistisch.
   4. Planning: Gebaseerd op te weinig data, ontbrekende items, niet genoeg detail, slechte schattingen.
   5. Risico’s: Niet geïdentificeerd of aangenomen, niet gemanaged.

      A recent research from American project management consultancy PM Solutions identifies the top 5 causes of project failure. The research among 163 companies shows that only 47% of projects are termed ‘successful’, whereas the remaining 53% could be labeled ‘failure’ (either terminated, failed or recovered). The top 5 causes for project trouble cited by the research:

      1. Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
      2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
      3. Schedules: Too tight, unrealistic, and overly optimistic.
      4. Planning: Based on insufficient data, missing items, insufficient details, and poor estimates.
      5. Risks: Unidentified or assumed, not managed.

         Eine kürzlich durchgeführte Studie des amerikanischen Projektmanagement-Beratungsunternehmens PM Solutionsermittelte die 5 Top Gründe für das Misslingen von Projekten. Die Studie, die unter 163 Unternehmen durchgeführt wurde, zeigt, dass nur 47% der Projekte als “erfolgreich” bezeichnet werden, wohingegen die übrigen 53% als “misslungen” beschrieben werden (entweder beendet, misslungen oder wiederhergestellt). Die Top 5 Gründe für Probleme mit dem Projekt, die im Rahmen der Studie genannt wurden:

         1. Anforderungen: unklar, Fehlen von Übereinstimmung, Mangel an Priorität, widersprüchlich, zweideutig, unpräzise.
         2. Ressourcen: Mangel an Ressourcen, Ressourcenkonflikte, Verlust von Schlüsselressourcen, schlechte Planung.
         3. Zeitplanung: zu eng, unrealistisch, und zu optimistisch.
         4. Planung: basierend auf unzureichenden Daten, fehlende Elemente, nicht ausreichende Details, und schlechte Schätzungen.
         5. Risiken: unbekannt oder angenommen, nicht reguliert.
         

      Within IT departments or software firms, number 2 is in many cases the main bottleneck. Because there is a lack of skilled resources (usually caused by the scarcity of talented IT people in the market), product releases cannot be finished in time, custom projects can’t be delivered according to deadline, pressure on the IT department grows day by day.

      Although no solution can solve all of the issues, offshoring can bring substantial improvement. The key ingredient for improvement is ‘resources’ .

      Requirements

      In IT projects, getting a clear picture of requirements is always a struggle. People (specifically users) cannot imagine the outcome of a project and only when the outcome is there, do requirements get clearer. How offshoring helps here is that it forces people to invest more time in developing clear requirements + it forces people to think about process.

      People miss the frequent communication that occurs when sitting in the same room. Although this also has its disadvantages, most outsourcers understand one thing: if I don’t write down clearly what I want, my team abroad will interpret it in their own way and the outcome won’t always be what I envisioned. A client I spoke to a few weeks ago put it this way: ‘because I need to tell my programmer exactly what I need, it forces me to think deeper about what I want. This actually brings me benefits because the solutions we come up with are much stronger and it saves us time in sending results and changes back and forth’.

      A much cited software development process today is ‘agile’ or ‘scrum’. No matter what the eventual process is (it could be a process strictly adhering the agile manifesto or a custom designed process), because people have to design, document and implement a process, things change. Specifically, scrum and agile deal with the requirements definition problem: instead of aiming at 100% clear requirements upfront, projects are cut into smaller pieces and the outcome of those pieces is evaluated in 2-4 weeks intervals, steering a project more effectively towards the desired outcome.

      Resources

      This is the biggest ‘win’ for people who embrace offshoring. It becomes easier to attract high skilled people, through access to the big labor pools of the offshore country. Besides, people are not employees (unless it’s a subsidiary), which makes it easier for the outsourcer to add or remove team members according to the capacity needed. If you have a product release planned and need to speed up, you engage a few more people and making the deadline becomes more likely.

      Schedules, planning and risk

      Schedules can be made more realistic by engaging more or less people in the team. Planning is not simplified directly, but indirectly, the need to develop a strong process frequently brings about change in the planning methods too. In many cases companies move to a more agile way of developing, which automatically brings shorter development cycles, that are easier to plan and manage.

      Some might argue that offshoring brings more risk to a project. But that doesn’t need to be the case. If the work is organized in a structured way through continuously improved processes, risks can actually be lowered. Mostly, risk is not about the risk itself, but about the awareness of it. Offshoring forces people to think and plan deeper and usually also brings more brains into the equation (for example a process manager on the offshore ‘side’). While thinking through ‘how will we work’, risks can be identified before the actual work starts. And by building frequent feedback-loops (daily and weekly meetings), additional risks are identified early on during the work and effective measures can be taken.