Why Subject Matter Experts Matter


Have you noticed that the hardest people to get and keep on a project are the subject matter experts (SMEs)? It's as if managers think that general programming or testing skills should suffice, or that the right development and testing tools are all you need. Linda Hayes observes that lately it seems the single biggest challenge has been getting quality time to define requirements and test cases from experts who understand the business domain of the application. If this is happening to you, Linda explains what you can do about it.

Getting quality time from SMEs to define requirements and test cases is especially difficult when you move from manual to automated testing. Even when documented—which is unfortunately not the rule—manually executed tests can get away with statements like "Enter valid data and verify that results are correct." What makes the data valid? What makes the response correct? What response is valid for which data? The answer for a manual test is that the person performing the test decides, which is fine if they are application experts. For someone trying to convert a manual test into an automated one, this knowledge is not native. Trying to explain why you need explicit data values can be an exercise in frustration.

No doubt, much of this exasperation is due to the over-enthusiastic cost-cutting fever that swept the industry when the Internet bubble burst, which caused the offshore wave. The problem is that, while you can find programmers in other countries who know coding languages or you can apply brute force to testing with higher offshore headcounts, you can't find foreign experts in US insurance, healthcare, brokerage, and other arcane, regulated industries. Furthermore, this type of knowledge is not easily acquired or transferred. The best SMEs and business analysts gained their expertise through years of hands-on, front-line experience. As a result, SMEs are in high demand and short supply.

I have struggled to explain to management why this is so important, but now I have validity for my argument: a research report from Quantitative Software Management Inc. (See www.qsma.com for more information.)

This study was based on a sample of 563 IT software development projects completed between January 1, 2000 and December 31, 2004. The study was based on actual schedule and effort expended from business requirements definition through the initial delivery and stabilization phase. The typical project release was 30 thousand new or modified source lines of code or 600 function points and took place over thirteen and one-half months, consuming fifty-five people months of effort.

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.