IT Project Success Rates: 2018 Open Research
 |
This open research into IT project success rates was performed during January 15, 2018 to February 28, 2018 under the title 2018 IT Success Rate Survey. There was 149 respondents. The survey was announced my Twitter feed, and several LinkedIn discussion forums. |
The Survey Results
The aim of the survey was to explore the success rates of IT delivery teams following various paradigms. Unfortunately, we didn’t get a suffient number of responses from non-agile teams, this is the first time this has happened to us, to be able to compare the paradigms on an individual basis. Based on results from previous research we’ve decided to group traditional and ad-hoc together in Figure 1 and the more advanced strategies, continuous delivery and lean, together. We also asked about various way of working (WoW) tailoring factors such as team size, geographic distribution, and so on across IT delivery teams.
Some findings include:
- Figure 1, compares the percieved success rates across: all teams; traditional or ad hoc teams; iterative teams; agile teams; and continuous delivery or lean teams.
- Figure 2 depicts the type of work being done on agile teams, showing that roughly half of teams are working on enhancing existing functionality and one in ten are working on package implementations. Across all teams 72% were doing new development, 53% sustainment/enhancement, 12% marketplace experiments, and 10% package implementations.
- Figure 3, depicts the success factors that we explored across all types of teams. Figure 4 does so for just agile teams.
- Figure 5, compares the percieved success rates for IT delivery teams and the effect of team size. We usually see a lower success rate for larger teams, but in this case two things happened: The sample size was small for 31+ (which reflects previous studies, there just isn.t that many large teams in practice) and all of those teams were following modern strategies (agile, lean, or continuous delivery), which typically have higher success rates in practice.
- Figure 6, compares the percieved success rates for IT delivery teams and the effect of geographic distribution of team members. More to come.
Figure 1. Perceived IT project success rates.
Figure 2. What do agile teams do?
Figure 3. Success factors on all IT delivery teams.
Figure 4. Success factors on agile teams.
Figure 5. Perceived IT project success rates and team size.
Figure 6. Perceived IT project success rates and geographic distribution.
Downloads
|
|
|
What You May Do With This Information
You may use this data as you see fit, but may not sell it in whole or in part. You may publish summaries of the findings, but if you do so you must reference the survey accordingly (include the name and the URL to this page). Feel free to contact me with questions. Better yet, if you publish, please let me know so I can link to your work.
Discussion of the Results
- As noted earlier, we didn’t recieve a sufficient number of non-agile responses to fairly compare paradigms. Ideally I would need 4-5x responses at least.
- It’s difficult to get a good estimate of project success rates because there isn’t a standard definition of success (nor will there ever be). So, if I define success specifically, for example as “reasonably on time, on budget, to specification” that definition will be applicable for some projects but not others. So, I could presumably get an accurate estimate of how well we’re doing against that criteria but it wouldn’t be the actual industry success rate. If, however, I define allow people to define success in terms of how it was defined for the actual projects then I’ll get a much more accurate estimate of project success rates but I won’t know exactly
- 93% of respondents had 10 or more years of experience in IT, and over half had 20+ years. Everyone had at least 2 years IT experience.
- This survey suffers from the fundamental challenges faced by all surveys.
Links to Other Articles/Surveys
Why Share This Much Information?
I’m sharing the results, and in particular the source data, of my surveys for several reasons:
- Other people can do a much better job of analysis than I can. If they publish online, I am more than happy to include links to their articles/papers.
- Once I’ve published my column summarizing the data in DDJ, I really don’t have any reason not to share the information.
- Too many traditionalists out there like to use the “where’s the proof” question as an excuse not to adopt agile techniques. By providing some evidence that a wide range of organizations seem to be adopting these techniques maybe we can get them to rethink things a bit.
- I think that it’s a good thing to do and I invite others to do the same.