Blog

Surefire Questions

by Lane Development and Technology

13sept

Weinberg

Excerpt

In this excerpt from Gerald M. Weinberg's "A Surefire Question" essay in his book Rethinking Systems Analysis and Design, he discusses an approach to the design of systems that he felt was already too overlooked back in 1982. He suggests an approach where the software or network designer spends time utilizing the system already in place. In any company approaching an IT specialist for help automating a manual process, developing new software, or anything else that computers and the Internet can be seen to help make easier, there is always the temptation to assume that once some descriptions have been emailed back and forth and a few discussions have taken place, the IT personel can simply jump right in and solve the problem.

This is an issue that has only grown worse with time, as IT departments and outsourcing companies drift further and further away from the other branches of enterprise. In many companies, the solution is simply to add more documentation, try new development processes, throw more oversight at the IT professionals. But this cannot improve the quality of the solutions that Information Technology can deliver -- as long as IT and non-technical staff see themselves as parts of different worlds, the solutions that IT can deliver will necessarily be disconnected from what it is that the end users actually need.

Instead of more process, more oversight, the approach that Weinberg points to is to re-integrate the "techies" with the rest of the company. If a software developer is to develop a solution automating part of a regular paperwork process, instead of sitting down in a series of meetings discussing what the software should do, after which the developer is expected to magically churn out a perfect solution, the developer should first take the time to experience the paperwork process firsthand. This is easy enough to do -- the developer can spend a morning or three shadowing the various staff members who generally participate in the process to be automated. Paralleling the writing adage "show, don't tell," a developer can achieve a far greater intuition for what exactly the system to be developed must be capable of and achieve by participating in the system to be replaced.

Once this has been done, any meetings can be far more productive, and any requirements and specifications hammered out will be far more mutually satisfactory, as both the developer and the other staff members will be coming at the process and the new system from a place of more mutual understanding. As Weinberg points out, it is not until the IT professional knows the right questions to ask that he or she will get the right answers. And without asking the right questions, no number of answers will lead to a system that is truly a solution.