Better Software - January 2008 - (Page 72) Figure 1: Process documentation before user-centered design • Creating prototypes • Testing the usability of prototypes Step 1: Information Gathering Our first step in applying user-centered design to process improvement was to gather as much information as possible about ePDQ users to understand their needs. In sharp contrast to the approach the managers took when they initially authored the process, we started by focusing not on the process itself but on the people. By “mingling with the people” and learning more about them—what their concerns were, what their frustrations were, what they spent their time on—we became students instead of telling the practitioners how to perform a process. 72 • Brainstorming Session. Our first information-gathering effort was to host an open-ended brainstorming session with key would-be practitioners of the ePDQ process. The session was an avenue for users to vent frustrations with the existing process, helping us to understand—from their perspectives—what was working and what wasn’t. The results indicated that the main reasons practitioners were not fully using the process were as follows: They couldn’t understand how it applied to them, management wasn’t consistently communicating its importance, and work required by the process itself was not seen as a valuable use of their already-precious time. www.StickyMinds.com • Individual Interviews. For our next step in soliciting feedback, we conducted one-on-one interviews with the principal users of ePDQ— the software project managers. Our specific goal was to determine why their project metrics (a deliverable in ePDQ) were not collected and reported within the agreed-upon timeframe. Although this particular goal was directed by senior management, we believed it would benefit our cause, as well. We understood that unearthing reasons for not completing this process requirement would provide valuable insight into why our primary users were not using the processes in their entirety. So as not to offend our users, it was extremely important to conduct these interviews with an investigative, “non-fingerpointing” approach. We performed an analysis of the reasons identified, and the results indicated that the factors that had the greatest impact on not meeting the process requirement were lack of support offered by management and the team as a whole, low perceived value, and poor planning. Without consistent and effective support and communication by management, the users were unable—and often unwilling—to strive to meet the defined requirements. • User Satisfaction Survey. Our third information-gathering activity was to conduct an online survey that polled key ePDQ users about the specifics of accessing the ePDQ process documentation. Many of the users said the documents were too long and that they never read them. Others indicated their difficulty in finding the exact document they needed in order to get the information they sought. The overall results indicated that no one reads the process documentation, process work is still a side activity and always falls by the wayside when project work competes for resources, and adherence to the CMMI-based processes is not communicated as a priority. BETTER SOFTWARE JANUARY/FEBRUARY 2008 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.