Better Software - January 2008 - (Page 71) or more than two years, our organization toiled to achieve the Software Engineering Institute’s Capability Maturity Model Integration (CMMI) Level 2 (see the StickyNotes for more information). When we were assigned to the team, it was struggling to get the process to “stick” and be adopted by team members. As information architects (non-subject-matter experts), we applied the tools of our trade and implemented proven user-centered design and information architecture techniques to this problem. We hope our experiences will help you avoid some process improvement mistakes and minimize your pain along the way. F The SEPG Approach: ePDQ Version 1.0 The software development department—a group of approximately sixty developers, project managers, managers, and other support staff—includes our team, the software engineering process group (SEPG). The SEPG was spawned by our manager after he had endured a painfully bad project experience that had roots in our ad hoc processes. In order to prevent others from experiencing a similar fate, he championed the cause of a more formal process. During the previous two years, version 1.0 of the electronics product development quality (ePDQ) process—our organization’s interpretation of CMMI—had been crafted and deployed. It consisted of more than fifty standalone documents describing processes the staff should use to plan and monitor projects, control a project’s work products, manage project requirements, collect project metrics, etc. These documents were typically written by managers in the software development department and were rolled out with minimal training for use by the entire department. Although the necessary information is presented in figure 1, it is not easy to follow this particular process. Imagine having to read fifty such documents to perform your daily tasks. “Headache” doesn’t even begin to describe it. You probably aren’t surprised to learn that the results of our first CMMI assessment after deploying ePDQ 1.0 reflected a significant lack of process adoption by practitioners. The practitioners struggled to learn and follow the tedious process documents and consequently stammered through assessment interviews (upset, in many cases, to have been left to face the “process inquisition” without sufficient coaching or training on the new processes). With these less-than-enthusiastic results, our manager—discouraged and seemingly at a loss as to how to tackle process adoption within the department—asked us for ideas. As information architects, we pitched some user-centered design ideas that “there hadn’t been time for” in the past. As advocates for users, the approach to such a huge change as was made in ePDQ 1.0 was troubling. Our previous project experience, coupled with our educational background, taught us how vitally important it is to actively engage users in the design of an interface they’ll someday be using. In fact, sometimes it is the only way to ensure they will use it. Users who have been involved in the design feel they have a stake in the end result and a vested interest in seeing the project succeed. Luckily, management had exhausted all of its own ideas and was willing to start thinking outside its box. We were given time to explore possibilities to make the ePDQ process more “usable,” while the jaded practitioners and discouraged managers took time to “lick their post-assessment wounds.” The User-Centered Approach: ePDQ Version 2.0 User-centered design (UCD) is a philosophy that focuses on users’ needs, preferences, and constraints during the design phase of an interface, program, system, or document. While there are a number of UCD models and approaches, they all have one thing in common—involving users in the design process to help ensure their satisfaction in the end product. Most UCD approaches use various combinations of the following activities: • Conducting user focus groups • Conducting brainstorming sessions • Surveying users • Performing task analysis • Developing use cases • Defining business and user goals and objectives • Gathering and prioritizing requirements www.StickyMinds.com JANUARY/FEBRUARY 2008 BETTER SOFTWARE 71 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.