A Soft Skills Business Case
A colleague of mine posted a question on LinkedIn a while back about how to develop a business case for improvement in soft skills for developers. I was too late to weigh in on the question there, so I’ll take a stab here.
Business cases and measurement of ROI are the holy grail for disciplined decision making in business, and proponents for almost any best-practice or new approach (and we all know how often these pop up) will cite the numbers or walk through a justification indicating that their pet approach is the one to tackle. Formal inspections studies often cite ROI numbers around 10:1, there are many reports that suggest that improvement in requirements analysis provides strong returns, while others suggest that agile approaches are the way to go. I just received an e-mail this morning suggesting that, based on the often cited and frequently maligned Chaos Report, weak configuration management practices are largely to blame for the two-thirds of software projects that fail.
For every practice, we will get justification of their value through studies or reports, even if those practices are in direct opposition to one another. And you know what? I would guess that each of those studies has a strong basis for pitching those numbers. For the groups involved in the study, for the practices that were implemented, some value was gained. In many ways, the Hawthorne effect comes into play, and the fact that groups are consciously aware of the new practices makes them better in the application, regardless of what that practice is. I would not be surprised (though I would be amused) to see a study indicating that making no specific changes whatsoever will result in an improvement in productivity. Making the practices top-of-mind, whatever those practices may be, will have some positive effect.
This is all to say that while any practice can be justified by a business case or ROI numbers, each group will get wildly different results in the application of new hard skills. While some groups may see a 10:1 improvement with the application of formal inspections, another might see a net loss in productivity due to the cultural barriers associated with exposing their work for external review. The citations might cover the mean, or the median, or sometimes the peak results from the study (depending on how rigorous the study is and how motivated and biased they are to show strong numbers), but they rarely if ever show the variability in the numbers.
Just like early-stage project estimates, it is this variability or uncertainty in the business case that is far more important than any single-point values cited. ROI for the application of hard skills massively depends on the context. That’s where the business case for soft skills begins.
If we look at all the hard skills that can improve software projects, they can almost all be bundled into the category of collaboration tools. That is, while a technique such as requirements analysis or design or exploratory testing can be done by an individual, they provide greatest leverage when used as a vehicle for increasing the shared understanding on a project. Many techniques, such as inspections or pair-programming or daily scrums, are structured such that they don’t make sense for an individual. Indeed, the more we think of software as a team sport, the more we leverage and apply techniques to coordinate the team to work together more effectively, the higher our rate of success.
The reason each individual hard skill can see such powerful value in some teams while showing almost no return in others is the difference in how the team collaborates. The stronger a team is in open and empathetic communication, in appreciating the strengths and motivations of others, in consciously working in congruence with their own values, and in resolving warranted conflict in a reasonable manner, the more effective any application of new techniques will be.
From my experience, every failure in application of hard skills has its basis in a weakness in some aspect of soft skills within the group. If Bob doesn’t appreciate Fred’s contribution to the team, pair programming is doomed to failure. If there is a history of bad interactions in the group, formal inspections can easily degrade into personal attacks. If the structure of the team has contributed to silos between different groups, specifications will be thrown over the wall rather than developed in a collaborative fashion. The ROI on the hard skills will be diminished in each case.
Here’s an exercise to run with your group. Ask everyone to complete these sentences individually: “the characteristics of my best project experience were…” and “the characteristics of my worst project experience were…”. There is a good chance that the majority of the characteristics cited are based on soft skills: “I felt I was being listened to”, “we worked well as a team”, “we had fun together”. You will encounter very little about the application of specific techniques, and almost nothing about the inclusion of tools. Based on our own experiences, we know intrinsically that it really is all about the soft skills in a team environment.
While difficult to measure, I see the business case for improvement in soft skills to be quite strong. If you are interested in increasing the likelihood of adding value with hard skills, consciously focusing on the soft skills is where to start. Beyond the improvements in communication that will serve to help you better select which hard skills to apply, you will reduce the uncertainty in your results, and improve the overall ROI as well. – JB