Better Software - January 2008 - (Page 74) ware development department taking part. The results indicated that 76 percent of participants preferred viewing and accessing information via the Web page mock-up. Step 4: Developing Functional and Usability Requirements Once the results of the usability test were compiled, we began categorizing and assimilating the ePDQ users’ requests into the following functionality and usability requirements for the redesigned process documentation: • Printing capability: implement one-click-to-print and ensure readability in printed format • Search-within-page capability: a “Find” function • Apparent information hierarchy: exhibit structured, explicit relationships between information subsets • Explanatory table of contents: provide a succinct yet informative synopsis of document contents before actually delving in • Hyperlinking capability: capitalize on HTML capabilities via links to glossary terms, other documents, sections within documents, etc. • Agile navigation: “quick and speedy” information access, decreased scrolling • Outline attributes: serving the same function as numbered sections, providing ease of reference We presented these requirements to our users and asked them to verify and rank them according to importance. This confirmed the validity of the requirements and indicated that all of them were of equal importance to the users. Our next step was to employ these “usability” requirements in the design of a Web-based solution for process documentation. print content, a significant effort was undertaken to “tighten up” the process content from ePDQ 1.0 by eliminating the redundancies that so often sneak into exhaustive process documentation. We organized information into hierarchical modules (the “What” and the “Howto”) and made use of chunking, multiple headings, and white space for readability. In addition to setting up the visual architecture and layout of the Web content, great care was taken in selecting supportive visual elements to aid in user exploration as shown in figure 2. Previously, key terms had been defined within the process documents themselves, taking up valuable space. In ePDQ 2.0, we employed separate Web pages for a glossary, acronym list, and a role and responsibilities page. Icons were used to distinguish between different types of links (to role descriptions, key terms, documents, or an external Web page). Supporting, interactive documents (e.g., templates, checklists, forms) were clustered into a “toolbox” area at the top of the process Web page so that users could find quickly the documents they needed to complete process tasks. pected to adopt the process right away. The amount of information for the intended practitioners of the process was tremendous, and most team members ignored it altogether. As frustrating as this was for the authors of all the process documentation, it was not surprising that the users responded less than enthusiastically. We learned that process definition and description do not guarantee process execution. Another contributing factor to the lack of adoption by practitioners was simple: They were not consulted. Their managers, armed with their own experience from when they were “in the trenches,” brought their own views into authorship of the process descriptions. The definitions looked great on paper, but, as evidenced by the users, they were not realistic or practical. PITFALL 2: THE HEAVY-HANDED APPROACH TO INSTITUTIONALIZATION The “define and dump” method of the first release of ePDQ was not met with enthusiasm from the users in the software development department. They felt that a process was being imposed upon them with little or no regard for how they actually accomplished their day-to-day tasks. This disregard bred feelings of dissent, preventing learning and adoption from occurring. A learning environment was not nurtured, because the primary motivation of the definers of the process was not that their subordinates learn, but that they “just do it.” Little did the managers know they were skipping a critical step. Success! Incorporating information from the users, coupled with the strides taken by management to re-emphasize the importance of the process improvement initiative within the department, ePDQ version 2.0 was rolled out in November 2006. Little more than five months later, the software development department was formally appraised at CMMI Maturity Level 2. Pitfalls to Avoid Step 5: Filling in the Details The following details some of the mistakes our organization made during ePDQ 1.0. Avoiding these will leave you and your own organization better positioned for successful process-improvement initiatives. PITFALL 3: INCONSISTENCIES IN COMMUNICATING THE IMPORTANCE OF THE PROCESS While we focused on determining users’ needs and preferences for accessing process content, our manager spearheaded the effort of nailing down among department managers what their collective stance on process would be. Eventually, department-wide goals were communicated and enforced. Once everyone’s performance was judged—in part, based on whether or not he abided by the process—our jobs as information architects became easier. Now we weren’t Now that we had a Web-based template describing how process information would be organized and presented, we began revising the actual content of the ePDQ process documents. Knowing that Web content has rules different from PITFALL 1: DEFINING THE PROCESS IN A VACUUM The first, and ultimately unsuccessful, attempt at implementing the ePDQ process was defined primarily by managers. Once “complete,” documents were released, and project teams were exwww.StickyMinds.com 74 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.