If you're a vampire, a stakeholder is generally someone you should try to avoid. If you're a software developer, then stakeholders are among the people you want to work closely and regularly with. This is easier said than done, though. Sometimes, project teams don't have an understanding of who their stakeholders are, sometimes stakeholders are difficult to gain access to, and sometimes teams don't have an effective strategy for how to interact with stakeholders. Having observed a range of relationships between IT project teams and their stakeholders, I thought I'd look into the situation with a survey. This article summarizes my results.
The survey ran from the beginning of May 2011 to mid-June 2011, and was announced in my April column in Dr. Dobb's, my blog, and on my IT surveys page, as well as posted to a user group. There were 248 respondents; 48% were programmers or agile team members, and 23% were managers or team leads; 45% had 20+ years of work experience; and 74% were North American, 18% European, and 4% from Asia/Pacific. The source data, the original questions, and a summary of my analysis can be downloaded from my IT surveys page.
Who Are the Stakeholders?
In Disciplined Agile Delivery (DAD), we define a stakeholder as someone who is materially affected by the outcome of the solution. A stakeholder could be a direct user, indirect user, a manager of users, a senior manager, an operations staff member, the "gold owner" who funds the project, support (help desk) staff member, an auditor, your program/portfolio manager, a developer working on other systems that integrate or interact with the one under development, or a maintenance professional. Although this is a wonderful definition, one wonders whether existing project teams see things this way. So one question the survey explored was who development teams consider to be stakeholders. The results are presented below in the format StakeholderType (% of Yes, % of No):
- End users (87%, 11%)
- End user management (82%, 15%)
- Senior business management (59%, 36%)
- Financial sponsor/gold owner (53%, 35%)
- Support staff (51%, 43%)
- Operations staff (49%, 46%)
- Senior IT management (47%, 47%)
- Maintenance staff (30%, 57%)
- Enterprise architects (29%, 58%)
- Regulatory auditors (18%, 65%)
- Enterprise business modelers (18%, 62%)
- Internal corporate auditors (13%, 70%)
It's interesting to note that the obvious project stakeholders, end users and their managers, are recognized as such by the vast majority of teams. About half the teams view operations and support staff as stakeholders a sign that the DevOps movement still has a long way to go. Frustratingly, although 87% of organizations had enterprise architects, and 80% enterprise business modelers, roughly one-third and one-quarter, respectively, of the respondents felt that those groups were stakeholders of their projects. This may be a sign of a lack of enterprise awareness on the part of project teams or of the level of effectiveness of the enterprise groups. Regardless, it appears that many project teams have an overly narrow view of who their stakeholders are. This puts them at risk of not properly addressing the needs of those stakeholders.
How Do We Work with Stakeholders?
The survey also asked respondents to indicate how often their team interacted with stakeholders. Sorted by paradigm, the average time between interactions with stakeholder(s), was 0.67 work days for ad-hoc teams, 0.90 work days for agile teams, 1.3 work days for iterative teams, and 4.4 work days for traditional teams. When calculating this, I had to drop two questionable responses from agile teams because the people indicated that they only interacted with stakeholders during the requirements and acceptance testing phases of the project, yet agile teams don't have such phases: Requirements elicitation and acceptance testing are so important to agile teams, they perform these activities all the way through the lifecycle. With those responses included in the calculation, the agile average rises to 2.3 days (only interacting with stakeholders during those phases was giving a weighted average of 60 work days).
Why is this important? There is clear research evidence, not to mention anecdotal evidence, which shows that regular interaction between stakeholders and project teams increases the chance of project success. Furthermore, by shortening the average cycle time between building something and asking stakeholders for feedback reduces the average cost of making changes something Barry Boehm has pointed out for decades. This, in turn, increases the likelihood that development teams will produce a solution that reflects the actual needs of their stakeholders, increasing the chance of project success.
I also wanted to explore how project teams elicited requirements from stakeholders, and more specifically, to compare by paradigm. The surveys asked how common it was for the team to directly interact with stakeholders; for the team to work with stakeholder proxies such as a product owner, a product manager, or business analyst; whether the team was given written specifications; and how likely it was for the team to create requirements on their own (perhaps to address gaps in written specifications or gaps in the knowledge of stakeholders or their proxies). I calculated weighted averages for each combination of paradigm and elicitation strategy on a range of -10 for very uncommon to +10 for very common. In the format
To be honest, I was a bit disappointed in the results of this question because the averages were so clustered near the middle. Remember that the potential range is from -10 to +10, yet the scores ranged only from -1.8 to 1.8, an indication that there isn't as much deviation in requirements practice as some of the rhetoric would lead us to believe. Yet there are some interesting differences. For example, iterative teams were a bit more likely to work directly with stakeholders than agile teams, who in turn, were more likely than traditional teams.
The likeliness of working with a stakeholder proxy was pretty much even across the paradigms, potentially a reflection of differences in location and cultural norms within organizations. Not surprisingly, ad hoc teams were least likely to work with written specifications and traditional teams most likely. Good news is that traditional teams were least likely to create their own requirements, behavior that may be motivated by the stricter business constraints placed on such teams.
In my May 2011 column, I summarized results from another survey that showed traditional teams were most likely to engage in ethically questionable behavior, so the predilection for creating their own requirements may be a further reflection of this problem.
The survey also explored which practices teams followed to elicit requirements. In the format Practice (adoption rate), the adoption levels were:
- One-on-one interviews with stakeholders (77%)
- High-level requirements envisioning (75%)
- Demonstrations of working software (71%)
- Whiteboard sketching (68%)
- User interface prototyping (61%)
- Paper-based modeling (48%)
- Detailed requirements envisioning; e.g., JADs (36%)
- Just in time (JIT) model storming during construction (18%)
- CASE tool modeling (17%)
- Structured modeling sessions; e.g., JADs (15%)
As you can see, there are a wide range of practices in use. What was interesting was that some of the more formal techniques, such as CASE tool modeling and JADs, had low adoption rates (granted, so did JIT modeling from the looks of it, sigh!). Informal, low-fidelity modeling, such as paper-based modeling, whiteboard modeling, and requirements envisioning, had much higher adoption rates all important aspects of the Agile Modeling (AM) methodology. I was glad to see that teams were twice as likely to do high-level requirements envisioning than they were to do detailed requirements envisioning, a hopeful sign that we're moving away from the questionable "big requirements up front (BRUF)" strategy. Unfortunately, the survey only asked whether teams were doing the technique, not how effective the techniques were fodder for another survey.
Towards Active Stakeholder Participation
Active stakeholder participation has been a fundamental practice of the Agile Modeling (AM) methodology since the very beginning. The practice is an expansion of eXtreme Programming (XP)'s On-Site Customer, which describes the need to have on-site access to stakeholders, or their representatives, who have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements and prioritization thereof. The AM version of the practice takes it one step further to suggest that domain and technical experts should be actively involved with modeling (yes, creating the actual models, not just giving information to a modeler), and in some cases, even with development.
Active participation reduces the feedback cycle and the bureaucracy surrounding requirements elicitation on IT projects, thereby increasing overall productivity and the chance of project success. The good news is that we're starting to move towards this ideal, with 65% of respondents indicating that they have at least daily interactions with stakeholders, and 76% using inclusive modeling tools (whiteboards and paper). Interestingly, 51% of respondents said they were doing both, an indication that stakeholders may in fact be actively involved on those software development teams. That's a pretty good start.
Results from the May 2011 State of the IT Union Survey are posted here.
The Outside-In method, described in the book Outside-In Software Development by Karl Kessler and John Sweitzer (IBM Press, 2007), has one of the most coherent descriptions of stakeholders that I've ever run across. It's a great book in general, and worth it just for it's advice around working with stakeholders.
The IBM whitepaper Disciplined Agile Delivery: An Introduction overviews the DAD process framework.
The article Communication on Agile Software Projects summarizes evidence regarding the effectiveness of communication techniques between people, including results from a survey that explicitly explored interacting with project stakeholders.
In Why Agile Software Development Techniques Work: Improved Feedback, I argue that reducing the feedback cycle time in turn reduces the average cost to act on the feedback.
My May 2011 column Survey Shows Unethical Behavior Rampant Inside IT Development Teams argues exactly what the title indicates.
My 2008 Modeling and Documentation survey explored the adoption rate of various modeling and documentation practices on software development teams.
The perils of big requirements up front (BRUF) are explored in detail here.
The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the DDJ surveys that I've run over the years.
My Agility@Scale blog discusses strategies for adopting and applying agile strategies in the complex environments.
You can follow me on Twitter.