- \n
- Requirements:<\/strong> Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.<\/li>\n
- Resources:<\/strong> Lack of resources, resource conflicts, turnover of key resources, poor planning.<\/li>\n
- Schedules:<\/strong> Too tight, unrealistic, and overly optimistic.<\/li>\n
- Planning:<\/strong> Based on insufficient data, missing items, insufficient details, and poor estimates.<\/li>\n
- Risks:<\/strong> Unidentified or assumed, not managed.\n<\/p>\n
![\"\"](\"https:\/\/www.bridge-global.com\/blog\/\/wp-content\/uploads\/2011\/03\/ProblemSolution-150x150.jpg\" "\\"ProblemSolution\\"")
<\/a>Een recent\u00a0<\/strong>onderzoek<\/strong>\u00a0van\u00a0<\/strong>PM Solutions<\/strong>, 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 \u2018succesvol\u2019 gezien wordt, terwijl de overige 53% als \u2018mislukt\u2019 wordt gezien (afgebroken, mislukt of hersteld). De top 5 oorzaken voor problemen bij projecten volgens het onderzoek:<\/strong><\/p>\n- \n
- Eisen:<\/strong>\u00a0Onduidelijk, geen overeenstemming, geen prioriteit, tegenstrijdig, dubbelzinnig, onnauwkeurig.<\/li>\n
- Mensen:<\/strong>\u00a0Niet genoeg mensen, conflicten tussen mensen, hoe lang mensen hun positie behouden is onduidelijk, slechte planning.<\/li>\n
- Schema\u2019s:<\/strong>\u00a0Te strak, onrealistisch, en veel te optimistisch.<\/li>\n
- Planning:<\/strong>\u00a0Gebaseerd op te weinig data, ontbrekende items, niet genoeg detail, slechte schattingen.<\/li>\n
- Risico\u2019s:<\/strong>\u00a0Niet ge\u00efdentificeerd of aangenomen, niet gemanaged.\n<\/p>\n
<\/a>A recent\u00a0research <\/a>from American project management consultancy\u00a0PM Solutions<\/a> 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:<\/strong><\/p>\n- \n
- Requirements:<\/strong> Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.<\/li>\n
- Resources:<\/strong> Lack of resources, resource conflicts, turnover of key resources, poor planning.<\/li>\n
- Schedules:<\/strong> Too tight, unrealistic, and overly optimistic.<\/li>\n
- Planning:<\/strong> Based on insufficient data, missing items, insufficient details, and poor estimates.<\/li>\n
- Risks:<\/strong> Unidentified or assumed, not managed.\n<\/p>\n
<\/a>Eine k\u00fcrzlich\u00a0durchgef\u00fchrte Studie<\/a>\u00a0des amerikanischen Projektmanagement-Beratungsunternehmens\u00a0PM Solutions<\/a>ermittelte die 5 Top Gr\u00fcnde f\u00fcr das Misslingen von Projekten. Die Studie, die unter 163 Unternehmen durchgef\u00fchrt wurde, zeigt, dass nur 47% der Projekte als \u201cerfolgreich\u201d bezeichnet werden, wohingegen die \u00fcbrigen 53% als \u201cmisslungen\u201d beschrieben werden (entweder beendet, misslungen oder wiederhergestellt). Die Top 5 Gr\u00fcnde f\u00fcr Probleme mit dem Projekt, die im Rahmen der Studie genannt wurden:<\/p>\n1. Anforderungen: unklar, Fehlen von \u00dcbereinstimmung, Mangel an Priorit\u00e4t, widerspr\u00fcchlich, zweideutig, unpr\u00e4zise.
2. Ressourcen: Mangel an Ressourcen, Ressourcenkonflikte, Verlust von Schl\u00fcsselressourcen, schlechte Planung.
3. Zeitplanung: zu eng, unrealistisch, und zu optimistisch.
4. Planung: basierend auf unzureichenden Daten, fehlende Elemente, nicht ausreichende Details, und schlechte Sch\u00e4tzungen.
5. Risiken: unbekannt oder angenommen, nicht reguliert.
<\/p>\n<\/li>\n<\/ol>\nWithin 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.<\/p>\n
Although no solution can solve all of the issues, offshoring can bring substantial improvement. The key ingredient for improvement is ‘resources’ .<\/p>\n
Requirements<\/strong><\/p>\n
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.<\/p>\n
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’.<\/p>\n
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.<\/p>\n
Resources<\/strong><\/p>\n
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.<\/p>\n
Schedules, planning and risk<\/strong><\/p>\n
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.<\/p>\n
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.<\/p>\n
- Resources:<\/strong> Lack of resources, resource conflicts, turnover of key resources, poor planning.<\/li>\n
- Mensen:<\/strong>\u00a0Niet genoeg mensen, conflicten tussen mensen, hoe lang mensen hun positie behouden is onduidelijk, slechte planning.<\/li>\n
- Resources:<\/strong> Lack of resources, resource conflicts, turnover of key resources, poor planning.<\/li>\n