Communications of the ACM
The Impact of Subversive Stakeholders on Software Projects
Studies of software project failure factors frequently appear in the software literature.2,3 Failure factors commonly include unstable requirements, faulty (under-) estimation, and inadequate project management.
The literature in the field of project management, especially the literature about risk, is particularly rich in advice about addressing software failure.1,4,5,6
For all the discussion of failures, however, there is one factor that is rarely included: failure caused by subversive stakeholders. It is the purpose of this paper to focus on this failure factor, to discuss its prevalence, and to present ways of overcoming it.
Stakeholders, for the purposes of this paper, are persons who have any interest in, and influence over, the software project (such as developers, leads, consultants, managers inside and outside the project, patrons, customers, and users). A "subversive stakeholder" is someone who wants the project to fail and is actively working toward that end. Stakeholders who are incompetent, or who are not aware of the consequences of their actions, are NOT considered subversive.
This article reports on a survey that sought to explore this issue. This is, so far as the authors know, the first formal study of subversive stakeholders as failure factors.
The survey involved contacting software practitioners and presenting them with a series of questions about their experiences with subversion. Candidate respondents were identified by using Google to search on "project manager" or "team lead," and the online bios of those candidates were screened. Those to whom the instrument was sent were authors of relevant papers, professors with practitioner experience, industry "gurus," and a large number of practitioners. Identifying a sufficient number of participants, and the participant response rate, were both problems (see "Limitations"). The candidate population may be considered random and thus bias-free, since it was selected without consideration of the topic of subversioin.
The questionnaires were distributed, and the responses made, by email. Because of this, it was possible to ask for additional information from respondents when necessary. Consideration was given to collecting the data via a web interface instead. However, there were some angry early responses (such as "your questions feel like an attempt to collect... competitive information" about my company), leading to the fear that someone might want to sabotage the study's web site.
The survey questions pursued the existence of subversive activity, the frequency with which it occurs, the motivations of those who engage in such activities, the frequency of failures caused by such activity, the methods by which the subversion was detected, and approaches projects can use to defend themselves.
Quantitative Results
Here, the quantitative questions are presented, followed by an analysis of those responses.
Have you ever encountered subversive stakeholders in software projects?
Some 54 participants (slightly over 50%) reported that they have encountered subversive behavior in software projects; 38 (35%) said they have never seen this problem; 15 (14%) responded but refused to answer the questionnaire (follow-ups suggest that some of them were precluded from doing so by corporate policy, and others felt they had insufficient experience for their input to have value). Note that these reasons for refusing participation are important for several reasons, including the fact that the low response rate was not an indicator of bias in the study.
The findings are presented in total and broken down by experience level of the respondents. See the table here for details. The figures in the cells of the table are the number of participants in that respective group. (21 respondents with more than seven years experience have never seen this problem).
How frequently do projects include subversive stakeholders?
The median of all responses to this question is that 20% of projects involve subversion. However, many participants gave qualitative answers rather than a percentagefor example, "once or twice in 10 years of experience," or "one out of seven projects."
The responses showed various levels of frequency of subversive behavior: 16 are aware of subversive activities but consider them rare (<5% of the projects); another 31 felt they were common (580% of projects); and seven reported that this problem interferes with their projects rather frequently (> 80%). Thus about 40% are acquainted with the problem of subversive stakeholders, and have encountered it in a significant part of their projects (> 5%), while the other 60% considers subversion a minor problem or one that has not confronted them at all.
These results raised an interesting question: Why have a significant fraction never encountered subversive behavior, while others reported this problem as "rather frequent?" To clarify this issue, additional questions were sent to those who had rarely encountered subversive activity. Here are those responses:
- Some organizations are more "political" and therefore prone to subversive activity than others.
- Some persons are more sensitive to political processes and subversion. 8 participants considered it paranoid to search for subversion behind behavior which might simply be incompetence or mishap.
- Subversive activity is less conspicuous to those in certain roles, such as developers.
- Eight participants admitted the reason they had rarely encountered subversion might be that they are lacking experience, or that their projects had properties that make subversion unlikely.
- Four seasoned project managers wrote that they know potential sources of subversion, and when they notice mildly subversive behavior they have enough influence and experience to fix the problem.
Qualitative Results
The study led to a number of qualitative, as opposed to quantitative, findings. Here, we present a summary of those results, derived from the remarks and anecdotes received. In each case, we provide the question which prompted the qualitative response, and a summary of those responses.
What were the motivations and goals of the subversive stakeholders?
Responses to this question were grouped informally into a number of classes (derived bottom-up from the responses, and identified in bold font). Under each class are some of the responses that caused that class to be invented.
Competition between departments and organizations (34 responses)
Quite often, motivation was organizational. Power and control struggles were at the heart of this motivation. Competition for resources was frequently the underlying motivation. Some responses concerned seeking the benefits of competing incentive plans, or pushing others toward being scapegoats if the project fails.
Individual vs. corporate goals (28)
Often individual project members thought that the project should be conducted differently from the way in which it was actually conducted, or would have preferred project outcomes to be more in keeping with their own personal wishes. Sometimes a junior project person wants to undermine those in authority. Occasionally, revenge was a motive.
Job security; resistance to change (26)
Defending one's own position was a motive for subversion. Respondents noted concerns about things like the successful project eliminating or drastically changing their job. Some were also concerned about having to learn something new.
Technological disagreement (17)
Strong feelings about technical issues happened fairly often. Technical people, mainly programmers, sometimes become saboteurs when they wanted to use a different tool/technology/methodology than the one(s) mandated for their project, or they wanted to eliminate constraints/standards that they saw as counter-productive.
Competition between individuals, rivalry and animosity (15)
Less often than at the organizational level, motivation was sometimes at the individual level. Some responses concerned battles over whose idea the project was, or conflict between backers of new ideas vs. older ones.
Disloyal partners (9)
Subversion can also arise outside the enterprise (such as, partner firms, contractors, and outsourcers who want to improve their contractual position, or who want to win a culture clash).
Split in upper management (6)
Sometimes it is the senior people in the enterprise itself (such as, the upper manager nurturing the project may have enemies who want the project to fail, sometimes simply because of who is nurturing it!)
What was the percentage of cases where the subversive stakeholders finally achieved their goal (at least partially)?
Even though the subversive stakeholders constitute a small minority, they can make a lot of trouble, causing incredibly high costs for their organization. There is a broad consensus that most attacks are at least partially successful. A number of participants confirmed that the attack always causes delays, additional costs and/or may motivate good people to leave. Most respondents agree that only a smaller fraction of subversive attacks are fully successful. No numerical response to the question could be gleaned from these qualitative answers.
How were the subversive attacks discovered?
Once again, there were several classes of responses, grouped in bottom-up chosen categories. A sampling of those responses is given below.
It is not a single event it is a process (30 responses)
Often it is hard to identify a single event that can be called subversion, it comes from patterns of behavior over time. Because of that, it may take awhile, through careful observation, to discover that subversion is happening. Such subversion rarely rises to the level of project progress reports.
Communal attacks (28)
Subversive activity may emerge from a cadre of people, via (for example) passing along faulty information, or via groups intimidating those who might report the subversion. Sometimes the discovery happens because another cadre, of loyalists, spots the subversive cadre's activities.
Overt attacks (8)
Perhaps surprisingly, not all subversive activity is carried out in secret. Respondents spoke of subversive activity being in the open, in meetings or via email, at least at the technical level (it was kept hidden from management). Some reported subversive stakeholders who boasted openly of their success.
Case-specific
Subversion may be discovered by processes unique to the project ... senior management intervention, project audits, and so on. Subtle subversion, such as withholding information, reporting progress where little or none is being made, or reporting none when the project is moving forward are difficult to detect via standard processes.
How can projects be defended against subversive stakeholders?
Here we present the bottom line on the subject of subversion: what can be done about it? This sampling of responses is about solving the problem.
Quality project management (27 responses)
A hopeful and fairly frequent answer to the problem is "good management will win out in the end." Techniques suggested include a robust development process, project audits, and the use of appropriate checks and balances. One respondent noted that "in a well-managed company this sort of political infighting does not happen."
Quality communication (20)
Another hopeful answer is that communication is the key. Such communication should be open, honest, inclusive, and focused. Methods include project reports, audits, and less formal involvement of all project players.
PsychoSocial factors (7)
And then there's the hopeful answer that common sense will prevail. Improve the hiring/firing process, particularly focusing on psychological/sociological and not just technical factors. Make a priority of identifying/keeping cooperative and capable people.
Support from senior management (5)
Sometimes it's necessary to call in higher powers. Move up the management ladder when necessary to solve problems, involving senior management if the problem is sufficiently severe.
Taming (8)...
Other times one can tame the subversives. Involve and include them, seek their cooperation, convince them if possible, comfort them if they need help.
... or fighting back if taming fails (6)
But in some cases, the opposite must happen. Eliminate them, work around them, fire them if possible.
Pessimistic opinions (8)
And, unfortunately, sometimes nothing will help there are no hopeful, or psychological/sociological, or taming approaches. Respondents said things like "You can't fully defend any project against sabotage," "There was probably nothing I could have done, except perhaps to get everything in writing," "If the subversive stakeholder is quite powerful, the loyal stakeholders may lack countervailing power," "There is no solution, not in the environment I work in," "I have tried several alternatives. However, I must admit that they never worked thoroughly because the subversiveness was not evident enough to fight against"
Conclusion
The strongest conclusion one can draw from this study is that incidents of subversive stakeholder activity on software projects are all too frequent. Over 50% of respondents have encountered such activity. With respect to how frequently the problem occurs, the median for all respondents indicates that perhaps 20% of software projects are contaminated by subversive activity.
Regarding motivations of the subversive stakeholders themselves, several categories of such goals were presented. Organizational power/control struggles were the most common, but individual job security/resistance to change was close behind.
Regarding how subversion was discovered, once again there was a variety of responses. Most often, subversion is a process, not a single event, which makes it hard to detect. Perhaps surprisingly, sometimes subversion is overt and easily discovered.
Regarding what might be the most important question in the survey, that of what can be done to defend against this activity, there were seven categories of responses. Several, the most numerous, had to do with management, such as applying quality management approaches, keeping lines of communication open, seeking support from senior management, and the use of positive psychology/sociology. Some respondents suggested what to do if all else failed (workaround or dismissal of the subversive person), and several respondents expressed the belief that very little could be done.
Limitations
The biggest limitation of this study pertains to the response rate. As is typical with practitioner surveys, this rate was disappointingly low, less than 5% (because the survey was announced in some mailing lists, it is impossible to give an accurate response rate). There were, as seen in the table, 107 responses (out of more than 2000 contacts).
Regarding subgroups of respondents, there is probably an over-representation of industry "gurus." Geographically, the majority are from the U.S. and Germany. Interestingly, results broken down by these subgroups tended to be the same as for respondents as a whole (which also supports the notion that the population was bias-free), with the exception of "years of experience" (the effects of which have been seen in Table 1).
References
1. Charette, R. N. Managing the risks in information systems and technology. Advances in Computing 44, (1997)158.
2. Ewusi-Mensah, E. Software Development Failures. MIT Press, 2003.
3. Glass, R. L. Software Runaways. Prentice-Hall, 1998.
4. Jones, C. Assessment and Control of Software Risks. Yourdon Press, 1994.
5. Moynihan, T. Coping With IS/IT Risk. Springer-Verlag, 2002.
6. Ropponen, J., and Lyytinen, K. Components of software development risk: How to address them. A project manager survey. IEEE Transactions on Software Engineering 26, 2, (Feb. 2000).
7. Verner, J. A study by the National Information and Communication Technology Institute of Australia (NICTA), conducted by June Verner, as reported in the Software Practitioner newsletter, July 2006.
Tables
Table 1. Have you ever encountered subversive stakeholders in software projects?
Table 2. How frequently do projects include subversive stakeholders?
©2009 ACM 0001-0782/09/0700 $10.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.