63.3, August 2016

Improving the Information Development Process: A Refined Iterative Development Model

By Tina M. Kister, Nanatoo Communications, LLC

Abstract

Purpose: This article presents a refined iterative development model that may be used to improve the processes related to information development. Specifically, the model is designed to facilitate rapid and incremental delivery and increased quality and efficiency.

Method: The refined iterative development model is based on an analysis of models from across a range of industries. The analysis was designed to clearly define what a development model is, the basic phases it contains, and various common uses. The approach to this project was from the perspective of a practicing technical communication professional and project manager.

Results: The analysis revealed that development models are visual, conceptual, representational, process-oriented, inventive, and both sequential and iterative. The basic phases common to development models are, generally speaking, Discovery, Planning, Implementation, Review, Refinement, and Release (or Deployment). Common uses include sharing knowledge, facilitating success, enhancing credibility, and demonstrating progress.

Conclusion: The analysis and comparison allows for a deeper understanding of what a development model is and how a refined iterative development model can be used to improve processes related to information development.

Practitioner's take-away:

  • The proposed refined iterative development model is designed to facilitate rapid and incremental delivery and increased quality and efficiency through adequate planning and preparation.
  • The refined iterative development model includes three distinct types of iteration: Progressive Elaboration, Feedback, and Validation.
  • The refined iterative development model includes three new phases: Synthesis (designed to facilitate innovation), Preparation (designed to facilitate quality and efficiency), and Delivery (designed to facilitate closing processes and to definitively end the project).
  • Successfully implementing the model requires taking an expert-level approach, understanding the intent and assumptions of the model, adopting an overall vision of success, getting started to create impetus, documenting and communicating the model, and closing the gaps between the processes outlined by the model and actual processes in use.

Introduction

Professional communicators have many tools and systems that can be used to improve the processes related to information development, such as standards (style guidelines), templates, terminology lists, content repositories, process documentation, and more. One such tool is a development model.

The purpose of this article is to introduce a refined iterative development model for information development—a model that can be applied in a business setting to meet fundamental business goals, such as increased productivity and overall profit. The proposed model is designed to allow for both rapid and incremental delivery and for increased quality and efficiency through adequate planning and preparation.

Because iteration is a very important aspect of development (as discussed in detail later), the proposed refined development model specifies three distinct types of iteration (Progressive Elaboration, Feedback, and Validation). The model also includes three new phases: Synthesis (designed to allow for innovation), Preparation (designed to both increase the overall quality of the final deliverable and to improve efficiency during the Implementation phase), and Delivery (designed to facilitate closing processes and definitively end the project).

Approach

My approach to this project was from the perspective of a practicing technical communication professional and project manager, rather than an academic. Many managers base important strategic business decisions on trends as they are presented in mass media, rather than on in-depth scholarly research; therefore, the development models analyzed consisted primarily of those found in non-scholarly sources, such as Google.

My decision to focus on non-scholarly sources is an intentional reflection of the position in which many technical communicators find themselves, in which the people who make decisions regarding the information development process are not academics and, often, are not even trained or experienced technical communicators. Instead, they may be program managers, engineers, software developers, marketing managers, or professionals with other areas of expertise. While often concerned and conscientious, they are not likely to have the time, resources, or opportunity to dive into sometimes-obscure academic texts.

Methods

The first step I took was to carefully analyze several existing development models from a wide range of industries. My goal in this analysis was to more thoroughly understand exactly what a development model is and to formulate a clear definition for the purpose of this article. I analyzed more than 50 models from across a range of industries, including health care, instructional design, industrial design, manufacturing, employee retention, user-centered design, software development, building construction, science, engineering, process improvement, Web design, content strategy, conflict resolution, land management, quality assurance, project management, business analysis, and marketing.

I qualitatively assessed each model against a list of simple descriptive terms suggested by the models themselves—terms such as visual, conceptual, complex, and sequential. The process was a simple, systematic form of descriptive classification based on common dictionary definitions. (See Saldaña, 2009, pp. 70–73 for a discussion of descriptive coding.) The purpose of this assessment was to progressively narrow the definition of development model and to distinguish development models from other types of models. The results of this analysis are discussed in the Defining A Development Model section of this article. The analysis was both a process of discovery and a process of refinement; if a term did not apply to any of the models, then I discarded it. (This analysis was a form of progressive elaboration, which is discussed in detail later in this article.)

I also referred to scholarly (peer-reviewed) sources in an attempt to better understand the history and intent of specific models and how and why models are important in a development setting. I also searched for previously published development models specific to the information development process, such as the model of the information design process, published by J.C. Redish in 2000 (Figure 1).

My sources included Google Scholar and the online academic library at the University of Florida (George A. Smathers Libraries). Within the Smathers Libraries, I used search tools such as WorldCat, EBSCOhost, ingentaconnect, and JSTOR. My searches were conducted between November 2014 and April 2015.

Defining a Development Model

The analysis of models across industries allowed me to articulate what a development model is for the purpose of this article and to distinguish development models from other types of models. The following sections outline some of the characteristics, phases, and uses that are common to development models across industries. These, in turn, provided a foundation for the refined iterative development model presented later in this article.

Figure 1. Model of the information design process. (Reprinted with permission from Redish, 2000.) Original caption: “A model of the information design process. This is a visual of information design in the broad sense of doing what is necessary to develop information that works for users. The dotted arrows indicate that the process is iterative, not strictly linear. A dotted arrow should also connect the Drafting and Testing box back to the box on Selecting Content/Organizing/Designing Pages or Screens. Model © 1999, Janice C. Redish, based on versions of a similar model developed between 1978 and 1999 at the American Institutes for Research and at Redish and Associates, Inc.”
Figure 1. Model of the information design process. (Reprinted with permission from Redish, 2000.) Original caption: “A model of the information design process. This is a visual of information design in the broad sense of doing what is necessary to develop information that works for users. The dotted arrows indicate that the process is iterative, not strictly linear. A dotted arrow should also connect the Drafting and Testing box back to the box on Selecting Content/Organizing/Designing Pages or Screens. Model © 1999, Janice C. Redish, based on versions of a similar model developed between 1978 and 1999 at the American Institutes for Research and at Redish and Associates, Inc.”

Common characteristics

The word model is used broadly across industries, and can refer to a wide range of tools, from three-dimensional objects (in architecture, for example) to conceptual diagrams that use symbols and text, to product prototypes.

By examining models from a wide range of industries, it is possible to elucidate a few defining characteristics and to clarify what distinguishes a development model from other types of models. These characteristics are overlapping and interrelated. They are also cumulative, in that each of the characteristics listed below progressively narrows the definition.

The analysis revealed that development models are:

  • Visual
  • Conceptual
  • Representational
  • Process-oriented
  • Inventive
  • Sequential and iterative

Visual Most models are visual. While some models may be tactile, as well as visual (such as architectural models), development models are two-dimensional and rely on graphic elements to convey the interrelation of processes. While they can be described using text, the concepts and relationships that they describe are more easily conveyed using graphic elements.

Some models, such as the Information Process Maturity Model (IPMM) developed by JoAnn Hackos and based on previous work to define “organizational maturity in the software industry” (Hackos, 2007, p. 33), are, perhaps, better described as matrices (that is, tabular displays of information in columns and rows). Interestingly, over time, these matrices are often simplified and presented as visual models in online sources (e.g., Geocent, n.d.). Such matrix-type models contribute valuable knowledge to our understanding of the processes and organizational structure related to information development. For the analysis described in this article, however, the term model is restricted to graphic representations and does not include such matrices.

Conceptual A conceptual model is a visual representation of abstract ideas that often focuses on the relationships between components of a system. In the natural sciences, for example, conceptual models are often used to show the relationships between different elements of an ecosystem (Figure 2). Like ecosystem models, development models visually represent the relationships among components of a system (a system focused on development).

Figure 2. Coastal wetlands resilience. This model is a conceptual diagram showing the resilience of coastal ecosystems in the Chesapeake Bay. Conceptual models often focus on the relationships between components of a system. (Reprinted with permission from the Integration & Application Network, 2013.)
Figure 2. Coastal wetlands resilience. This model is a conceptual diagram showing the resilience of coastal ecosystems in the Chesapeake Bay. Conceptual models often focus on the relationships between components of a system. (Reprinted with permission from the Integration & Application Network, 2013.)

Representational Models are also representational; that is, they depict an idealized state that is representative of an actual state. Development models are representational in the same way that art is representational. In painting and sculpture, representational refers to “images that are clearly recognizable for what they purport to be . . . such images need not be true to life” (Collins, n.d.).

This is an important concept that relates to the practical implementation of development models—because they are representational, they cannot be used as a literal step-by-step guide to daily practice. Instead, they can be used to guide the overall direction of a development process.

This concept is illustrated beautifully by mathematical models. A mathematical model of a parabola, for instance, may show an arc that perfectly models a statistical trend (Figure 3). However, if you examine the data points that are used to generate the arc, not all of the data points actually fall on the arc. This same concept relates to development models—while they are intended to describe the general shape of a development process, the detailed and daily steps that make up that process may not fall directly within the model.

Figure 3. Mathematic model of a parabola. This mathematic model of a parabola is an example of how models are representational; that is, the specific data points that are used to generate the parabolic curve are not always on the curve itself. Similarly, development models are intended to describe the general shape of a development process.
Figure 3. Mathematic model of a parabola. This mathematic model of a parabola is an example of how models are representational; that is, the specific data points that are used to generate the parabolic curve are not always on the curve itself. Similarly, development models are intended to describe the general shape of a development process.

Process-oriented Development models are also process-oriented. A process is a series of actions or steps taken to achieve a specific outcome. While most models show the interrelation of complex elements, not all models are related to processes. Competency models, for example, are primarily descriptive and show the relationship between different distinct attributes, or competencies, that are necessary to ensure professional success (Figure 4). While complex and interrelated, the competencies are not components of a process.

In contrast, process models, also called business process models and process maps, specifically describe a series of actions or steps designed to achieve a specific outcome, usually related to business operations. The term business operations describes processes or workflows that are completed multiple times to achieve the same or a similar outcome, such as fulfilling an online order for a retail product. (See Object Management Group, n.d., for several examples of business process models.)

Inventive Like process models, development models depict a series of actions or steps that are taken to achieve a specific outcome. However, while process models show the steps involved in business operations, development models are inventive; they are specifically related to the design or creation of something new, such as a software application or a suite of training materials.

Sequential and iterative The important distinction that development models are inventive leads to another defining characteristic of development models: They are both sequential and iterative.

According to the characteristics defined to this point, process models depict a series of actions or steps taken to achieve a specific outcome. They are also sequential because the actions or steps are performed in a specific order. However, while process models are sequential, they are not always iterative; that is, they do not necessarily include a repetition of steps that leads to improvement.

Development models, in contrast, do include a repetition of steps that leads to iterative improvement: “Iteration is a fundamental of good design” (Hasso Plattner Institute of Design at Stanford, n.d., p. 6). From a practical point of view, this makes sense: It is simply not possible to create something new that functions properly without some form of collaboration, prototyping, testing, validation, or other iterative process.

The iterative nature of development models is evident if we look more closely at two pairs of development models in the fields of software development and instructional design.

These two pairs of development models are:

  • Waterfall and Agile (in software development)
  • The Analyze, Design, Develop, Implement, Evaluate (ADDIE) model and the Successive Approximation Model (SAM; in instructional design)
Figure 4. Advanced manufacturing competency model. This competency model is descriptive, rather than process-oriented, and shows the relationship between different distinct attributes, or competencies, that are necessary to ensure professional success. (Reprinted with permission from the U.S. Department of Labor, Employment and Training Administration, n.d.)
Figure 4. Advanced manufacturing competency model. This competency model is descriptive, rather than process-oriented, and shows the relationship between different distinct attributes, or competencies, that are necessary to ensure professional success. (Reprinted with permission from the U.S. Department of Labor, Employment and Training Administration, n.d.)

In both fields, a newer model is presented as iterative and contrasted with an older model that is presented as purely sequential. This opposition is false—research into the origins of the older, so-called sequential models reveals that they are, in fact, highly iterative. The prevalence of these false oppositions also reveals the need for a deeper, expert-level understanding of what development models are and how they can be used.

Waterfall and Agile In the field of software development, Waterfall is often characterized as rigid, cumbersome, risky, and entirely sequential (e.g., Base36, 2012; Chandler, 2012; Hughey, 2009; Mikoluk, 2013; Rasmusson, 2015). The typical visual representation of the Waterfall model shows a simple series of linear steps (Figure 5; e.g., Hughey, 2009; Ramsoft Consulting, 2004; Zelfond, 2013). At the same time, Agile is characterized as collaborative, flexible, and iterative (e.g., Base36, 2012; Chandler, 2012; Hughey, 2009; Mikoluk, 2013; Rasmusson 2015). The typical visual representation of the Agile model is explicitly iterative (Figure 6; e.g., GlobalTeckz, 2015; NextGeneration, 2013; Reich, 2012).

These characterizations are so common that, at the time this article was written, a Google search reveals several similar examples (e.g., Figure 7). However, research into the origins of the so-called Waterfall model (the source of the name is unclear) reveals that the authors often cited as the originators of the model described a highly iterative approach and explicitly warned against a purely sequential approach (Benington, 1983; Royce, 1970).

Figure 5. Waterfall model. A typical visual depiction of the Waterfall model shows a series of linear steps with no iteration. Waterfall is often characterized as rigid, cumbersome, risky, and entirely sequential (e.g., Ramsoft Consulting, 2004; Hughey, 2009; Mikoluk, 2013; Base36, 2012; Rasmusson, 2015; Chandler, 2012).
Figure 5. Waterfall model. A typical visual depiction of the Waterfall model shows a series of linear steps with no iteration. Waterfall is often characterized as rigid, cumbersome, risky, and entirely sequential (e.g., Ramsoft Consulting, 2004; Hughey, 2009; Mikoluk, 2013; Base36, 2012; Rasmusson, 2015; Chandler, 2012).
Figure 6. Agile model. A typical visual depiction of the Agile model shows a process that is explicitly iterative. Agile is often characterized as collaborative, flexible, and iterative (e.g., GlobalTeckz, 2015; NextGeneration, 2013; Reich, 2012). (Reprinted with permission from GlobalTeckz, 2015.)
Figure 6. Agile model. A typical visual depiction of the Agile model shows a process that is explicitly iterative. Agile is often characterized as collaborative, flexible, and iterative (e.g., GlobalTeckz, 2015; NextGeneration, 2013; Reich, 2012). (Reprinted with permission from GlobalTeckz, 2015.)

The Waterfall model is often attributed to a group of software engineers working for the Department of Defense in the 1950s (e.g., Goodchild, 2012; Rabe, Spieckermann, & Wenzel, 2008; “Waterfall Model,” n.d.) and to a paper presented by Herbert D. Benington at a symposium on advanced programming methods in 1956 and republished in 1983. In the paper, Benington warns that attempting to “know precisely what our objectives are before we produce one line of code . . . can be terribly misleading and dangerous” (Benington, 1983, p. 352). However, many sources characterize Waterfall as “a linear approach” (Neelson, 2014, para. 5): “ . . . for example, requirements must be reviewed and approved by the customer before design can begin” (Neelson, 2014, para. 7). In fact, Benington’s paper presents a highly iterative approach and explicitly acknowledges the need for iterative testing (Figure 8; 1983).

Figure 7. Waterfall and Agile models in opposition. The Waterfall and Agile models are often presented in opposition to one another. Waterfall is typically presented as a purely sequential process, while Agile is presented as explicitly iterative (e.g., Choudhury, 2012; Neo Globe Consulting, 2014; Reich, 2012). (Reprinted with permission from Choudhury, 2012.)
Figure 7. Waterfall and Agile models in opposition. The Waterfall and Agile models are often presented in opposition to one another. Waterfall is typically presented as a purely sequential process, while Agile is presented as explicitly iterative (e.g., Choudhury, 2012; Neo Globe Consulting, 2014; Reich, 2012). (Reprinted with permission from Choudhury, 2012.)
Figure 8. Benington’s program production model. This visual depiction from Benington’s article, which is often cited as one of the original sources of the Waterfall model (e.g., Goodchild, 2012; Rabe, Spieckermann, & Wenzel, 2008; “Waterfall Model”, n.d.), includes steps that are explicitly iterative. (Reprinted with permission from Benington, 1983, p. 360.)
Figure 8. Benington’s program production model. This visual depiction from Benington’s article, which is often cited as one of the original sources of the Waterfall model (e.g., Goodchild, 2012; Rabe, Spieckermann, & Wenzel, 2008; “Waterfall Model”, n.d.), includes steps that are explicitly iterative. (Reprinted with permission from Benington, 1983, p. 360.)
Figure 9. Royce’s implementation steps to develop a large computer program. A 1970 article by Winston W. Royce, often cited as one of the original sources of the Waterfall model, includes this image, which closely resembles typical visual representations of the Waterfall model (Royce, 1970, p. 329). However, in the article, Royce warns that this approach “is risky and invites failure” (Royce, 1970, p. 329). (Reprinted from Royce, 1970, p. 329.)
Figure 9. Royce’s implementation steps to develop a large computer program. A 1970 article by Winston W. Royce, often cited as one of the original sources of the Waterfall model, includes this image, which closely resembles typical visual representations of the Waterfall model (Royce, 1970, p. 329). However, in the article, Royce warns that this approach “is risky and invites failure” (Royce, 1970, p. 329). (Reprinted from Royce, 1970, p. 329.)
Figure 10. Royce’s summary model. Royce’s 1970 article ends with a model (p. 338) that summarizes the steps that he recommends “to transform a risky development process into one that will provide the desired product” (p. 335). The model is visually complex and highly iterative. (Reprinted from Royce, 1970, p. 329.)
Figure 10. Royce’s summary model. Royce’s 1970 article ends with a model (p. 338) that summarizes the steps that he recommends “to transform a risky development process into one that will provide the desired product” (p. 335). The model is visually complex and highly iterative. (Reprinted from Royce, 1970, p. 329.)

The first formal description of Waterfall is often cited as an article written by Winston W. Royce in 1970 (e.g., Cram, 2011; Ji & Sedano, 2011; “Waterfall Model,” n.d.). Near the beginning of the article, Royce includes a model that resembles the typical visual representation of the Waterfall model, with a series of linear steps (Figure 9; Royce, 1970, p. 329). However, directly beneath the model, he writes, “ . . . the implementation described above is risky and invites failure” (Royce, 1970, p. 329). He goes on to modify the model and explains that “The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps . . .” (Royce, 1970, p. 328). As the article continues, Royce elaborates on the model and, at the end of the article, presents the model that he recommends, which is visually complex and highly iterative (Figure 10; Royce, 1970, p. 338).

Despite what the original authors intended, Waterfall is almost universally characterized as purely sequential. This is important for two reasons: 1) It supports the premise that all development is, in fact, iterative, and 2) it exemplifies the need for a deeper understanding of the development process—by focusing on this false opposition, rather than on the iterative nature of all development, we fail to work toward more successful implementation of development models in daily work life.

ADDIE and SAM A similar opposition exists in the field of instructional design. The two models that are presented as oppositional are the ADDIE model (Figure 11) and the SAM (Figure 12). Typically, the visual representation of the older development model (ADDIE) is explicitly iterative (e.g., “ADDIE Model,” n.d.; Chico State Instructional Design & Technology Society, n.d.; Clark, 1995; My Ed Tech Resource, n.d.). Despite the explicitly iterative representation, sources that promote SAM characterize ADDIE as requiring “perfectly executed giant steps” and as a “linear process” (Allen Interactions, 2015, para. 2). SAM is presented as a “different approach . . . that addresses the performance need through iterations, repeated small steps . . .” (Allen & Sites, 2012, para. 2).

Again, research into the roots of the ADDIE model, often attributed to educators working at the University of Florida in the 1970s (e.g., “ADDIE Model,” n.d.; Clark, 1995; Juneau, 2013) reveals that the original model included several iterative steps. The ADDIE model is based on the Instructional Systems Development (ISD) model (Figure 13), which originally contained 5 general phases and 19 detailed steps, several of which call for iterative review and refinement (Branson, Rayner, Cox, Furmanm, & King, 1975). While SAM may offer significant new ideas that improve the processes related to instructional design, in terms of iteration, it is not fundamentally different from the ADDIE model.

Figure 11. Analyze, Design, Develop, Implement, Evaluate (ADDIE) model. A typical visual depiction of the ADDIE model shows a process that is explicitly iterative (e.g., ADDIE Model, n.d.; Chico State Instructional Design & Technology Society, n.d.; Clark, 1995; My Ed Tech Resources, n.d.)
Figure 11. Analyze, Design, Develop, Implement, Evaluate (ADDIE) model. A typical visual depiction of the ADDIE model shows a process that is explicitly iterative (e.g., ADDIE Model, n.d.; Chico State Instructional Design & Technology Society, n.d.; Clark, 1995; My Ed Tech Resources, n.d.)

Summary To summarize, a deeper analysis of the false oppositions between Waterfall and Agile and between ADDIE and SAM suggests that the concept of iteration should be taken into account in formulating a refined development model for information development.

Some may find the idea of iteration alarming, believing that it adds to development time and, thus, expense. Those not familiar with the iterative nature of the creative process may wish to “get it right the first time,” so to speak. However, if “right” is already known—that is, if you have already determined what works and what doesn’t—then the process is not, in fact, an inventive (that is, development) process; instead, it is either a business process or production work.

The risk of unnecessary expense occurs when decision-makers do not understand the iterative nature of development and fail to plan for it. As most formally trained project managers agree, the later in the development process that issues (usually called defects in project management) are discovered, the more costly they are to remedy (Boehm & Vasili, 2005; Greene & Stellman, 2009). Factoring in the iterative nature of development ensures that projects can be proactively planned and that the healthy iterations that lead to improvement are seamlessly integrated into the project lifecycle.

Figure 12. Successive Approximation Model (SAM). SAM is presented as a new, iterative alternative to the ADDIE model (Allen & Sites, 2012).
Figure 12. Successive Approximation Model (SAM). SAM is presented as a new, iterative alternative to the ADDIE model (Allen & Sites, 2012).

The preceding analysis is a first step to understanding, at a fundamental level, what most development models have in common and, therefore, what a refined iterative development model should contain. Explicitly defining these characteristics provides a precise definition of what development model means in the context of this article and also provides a valuable framework for assessing the value of the proposed refined iterative development model and for adapting the model in the future.

Figure 13. Instructional Systems Development (ISD) model. The ISD model, often cited as the origin of the ADDIE model (e.g., “ADDIE Model,” n.d.; Clark, 1995; Juneau, 2013), originally contained 5 general phases and 19 detailed steps, several of which call for iterative review and refinement. (Adapted from Branson et al., 1975. Reprinted with permission.)
Figure 13. Instructional Systems Development (ISD) model. The ISD model, often cited as the origin of the ADDIE model (e.g., “ADDIE Model,” n.d.; Clark, 1995; Juneau, 2013), originally contained 5 general phases and 19 detailed steps, several of which call for iterative review and refinement. (Adapted from Branson et al., 1975. Reprinted with permission.)

The analysis demonstrates that development models are visual, in that imagery, rather than text, is best able to depict the complex relationships between steps. They are conceptual, in that they represent abstract ideas and relationships. They are representational, in that they depict an idealized state. They are process-oriented, because they depict a series of actions or steps. They are inventive, in that they are specifically related to the creation of something new. Finally, they are both sequential (outlining a series of actions or steps to performed in a specific order) and iterative (requiring repetitive elements to ensure improvement).

Common basic phases

In addition to the descriptive characteristics outlined in the previous section, the analyzed models contain, essentially, the same basic phases. Development models are typically presented either as a series of steps or as a series of phases that contain detailed steps. While each model may use different terminology, and many models do not clearly differentiate between each phase, the same basic phases are present. Hamilton describes the basic phases common to all development models as “Requirements, Design, Implementation, Test, Deployment, and Maintenance” (2009, p. 95). (I have used terminology that is slightly different from Hamilton’s to ensure parallel structure and to use more generic terms that allow for different types of deliverables.)

The basic phases of development models can be characterized as:

  • Discovery: Obtaining the information necessary to begin, plan, implement, and refine the deliverable.
  • Planning: Determining the best form or structure for the final product, defining goals and criteria for success, and deciding on processes for implementation.
  • Implementation (or Development): Creating the deliverable.
  • Review: Evaluating the deliverable and measuring the deliverable against the criteria for success.
  • Refinement: Implementing the results of review to more successfully achieve defined goals and meet the criteria outlined during the Planning phase.
  • Release or Deployment (sometimes called Implementation): Delivering or installing, in some form, the deliverable.

Often, an additional phase, related to the maintenance of a product or service, is also part of a development model. For example, in software development, a model may include a maintenance phase to indicate the provision of updates, bug fixes, and more. For the proposed refined iterative development model, I have categorized maintenance as an on-going business process outside of the development process. (See the Assumptions Underlying the Model section for more information.)

Specific models may also contain a single phase or step that reflects more than one of the basic phases listed here. For example, in a model of engineering development (Figure 14; Science Buddies, n.d.), the fourth step (“Brainstorm, evaluate, and choose solution”) contains elements of the basic phases of Discovery, Planning, Implementation, Review, and Refinement. Brainstorming is a form of discovery that produces new ideas and ways of solving problems. Evaluation is clearly related to review, and the implication is that, after evaluation, the results will be refined. Choosing a solution is indicative of both planning and implementation—the results of the brainstorming and evaluation are used in formulating the plan for moving forward.

Understanding the basic phases common to all development models facilitates the creation of an effective, refined development model. Within the overall framework of the basic phases, specific phases can be defined, and then the steps required for each phase can be defined in accordance with a particular industry, organization, or project.

Common uses

The analysis of development models across industries also demonstrates how they are typically used.

In general, development models are used for:

  • Sharing knowledge.
  • Facilitating success.
  • Enhancing credibility.
  • Demonstrating progress.
Figure 14. Engineering method. Many models contain a single phase or step that reflects elements of one or more of the basic phases. For example, in a model of engineering development, the fourth step (“Brainstorm, evaluate, and choose solution”) contains elements of the basic phases of Discovery, Planning, Implementation, Review, and Refinement. (Reprinted with permission from Science Buddies, n.d.)
Figure 14. Engineering method. Many models contain a single phase or step that reflects elements of one or more of the basic phases. For example, in a model of engineering development, the fourth step (“Brainstorm, evaluate, and choose solution”) contains elements of the basic phases of Discovery, Planning, Implementation, Review, and Refinement. (Reprinted with permission from Science Buddies, n.d.)

For example, a Web-design company may publish a development model on its website (e.g., Wyrostok, n.d.). The model can be designed as a form of content marketing in which knowledge regarding best practices is shared with potential clients, other businesses, and internal personnel. The model also serves as a form of process documentation, which facilitates the success of the members of the company who follow the model. The model enhances the credibility of the Web design company by demonstrating that their approach is detailed, careful, and planned. In addition, a timeline can be added to the model so that each phase coincides with a unit of time and then used to both estimate project length and demonstrate progress during development. A model “… shows the major steps involved throughout developing a site, and roughly how much effort is involved in each phase and from which side of the Designer/Client partnership the effort originates” (Wyrostok, n.d.).

Potential benefits There are many potential benefits associated with using development models, and these benefits are outlined in both scholarly and non-scholarly sources. A well-documented and shared development model is a form of knowledge sharing and management, which is an important factor in organizational success: “Knowledge management is especially important in product development and innovation projects that are relatively complex . . . ” (Solli-Sæther, Karlsen, & van Oorschot, 2015).

Proper use of development models can facilitate:

  • Greater employee engagement through unity, a shared vision, clear expectations, and increased success (Stoehr, 2012; Weinzweig, 2010). Employees who clearly understand what is expected of them are more engaged, and clear expectations require “a detailed understanding of how what one person is supposed to do fits in with what everyone else is supposed to do and how those expectations change when circumstances change” (Wagner & Harter, 2006, p. 4). Development models can help clarify expectations.
  • Business continuity in the form of transitions that are seamless and, therefore, cost-efficient, because “a good process model provides the foundation for documenting procedures” (Berg, 2011, para. 6). Development models can help ensure that new team members and leaders have a clearer vision of the overall process and where in the process the project is at any given time.
  • Increased efficiency as a result of revealing points of congestion in the development process (that is, points at which development is slowed or stalled) and sources of duplicate work (Berg, 2011).
  • Increased quality as a result of revealing the sources of defects and by enhancing consistency (Berg, 2011).

Development models can also be used as a communication and management tool to demonstrate:

  • Quality: Because iterative development models are based, in part, on the premise that a deliverable will need improvement after initial development, the model can be used to demonstrate that, despite the need for additional improvement, quality expectations are being met for a given stage in the process.
  • Efficiency: Development models can be used to show where a project is in the development lifecycle, and demonstrate that tasks are being completed efficiently and in accordance with expectations.
  • Trajectory: Development models can communicate to others what will happen next. “A process model answers two main questions: What should be done next? For how long should it continue?” (Boehm & Hansen, 2000, p. 4). (The question “How long should it continue?” depends on the parameters within which you are working. You can use a model directly to depict timeframes [e.g., Wyrostok, n.d.], and you can use a model in conjunction with supplementary project management tools, such as Gantt charts. )
  • Accountability: A development model can also be used as an aid in project assignments, as each phase and the tasks within it can be assigned to specific people and/or teams.

The Refined Iterative Development Model

The refined iterative development model presented here (Figure 15) is designed to incorporate the characteristics and phases common to other development models and to be useful in meeting strategic business goals, such as increased productivity and overall profit. The model is intended to improve the information development process by allowing for rapid and incremental delivery and for increased quality and efficiency through careful planning and preparation. My intent is to present a methodology that is general enough that it can be adapted to specific fields, organizations, and projects, yet specific enough to account for each necessary phase.

What’s new?

The refined iterative development model contains four components not typically found in other development models.

The four components are:

  • Three distinct types of iteration (Figure 16), which are:
    • Progressive Elaboration: A type of iteration in which continuous improvement occurs as new and more detailed information becomes available. This form of iteration extends across all of the initial phases of development.
    • Feedback: A type of iteration in which collaboration leads to incremental improvement. This form of iteration can occur at any time in the development process and is concentrated in the periods when one phase transitions into the next.
    • Validation: A type of iteration in which the deliverable is systematically compared with a pre-determined set of guidelines and standards and then changed as needed to align with the guidelines and standards. Validation is represented in the model as two distinct and interdependent phases (Review and Refinement) near the end of the development process.
  • A Synthesis phase: Designed to facilitate innovation and improvement.
  • A Preparation phase: Designed to streamline the Implementation, Review, and Refinement phases by creating standards, templates, repositories, and other tools that reduce duplicate work and increase consistency.
  • A Delivery phase: Designed to formalize processes related to ending the project, such as implementing final refinements, obtaining formal acceptance, and documenting lessons learned. (Lessons learned refers to important information discovered during the development process that can be retained as part of a knowledge-management system to improve future projects [Project Management Institute, 2008]).
Figure 15. Refined iterative development model. The refined iterative development model contains three specific types of iteration (Progressive Elaboration, Feedback, and Validation) and three new phases (Synthesis, Preparation, and Delivery).
Figure 15. Refined iterative development model. The refined iterative development model contains three specific types of iteration (Progressive Elaboration, Feedback, and Validation) and three new phases (Synthesis, Preparation, and Delivery).
Figure 16. Three distinct types of iteration. The three distinct types of iteration in the refined iterative development model are Progressive Elaboration, Feedback, and Validation. Progressive Elaboration occurs across multiple phases at the beginning of a project, Feedback occurs multiple times throughout the project, and Validation occurs near the end of a project.
Figure 16. Three distinct types of iteration. The three distinct types of iteration in the refined iterative development model are Progressive Elaboration, Feedback, and Validation. Progressive Elaboration occurs across multiple phases at the beginning of a project, Feedback occurs multiple times throughout the project, and Validation occurs near the end of a project.

Iteration

Iteration is a fundamental component of the development process (as demonstrated by the earlier discussion of the oppositional relationships between Waterfall and Agile and between ADDIE and SAM).

Iterative processes are often difficult to explicitly define and control. The best methods for dealing with iterative processes depend on many factors, including the availability of subject-matter experts; the availability of data related to the customer experience; the level of expertise and experience of those providing input—both in the subject matter and in reviewing techniques; the technology and systems used to gather information and implement, monitor, and measure improvements; and more.

The processes associated with iteration tend to be inherently and intentionally critical (that is, focused on assessing merits and finding defects), and cultivating a high level of courtesy and professionalism is imperative. As most technical communicators know well, there are many important soft skills associated with obtaining useful and relevant input. Respect, politeness, active listening, humility, and a sense of humor are invaluable and are difficult to prescribe using a development model. As with all phases of the development process, managing iterative input must be approached with clearly defined goals and a willingness to adapt to circumstances in order to meet those goals.

Progressive elaboration One of the most important concepts to understand when implementing the refined iterative development model is the form of iteration called progressive elaboration. In the field of project management, progressive elaboration is a method for dealing with the fact that, at the beginning of a project, it is impossible to know every detail of the requirements, schedule, budget, and the many other factors that are important to success. Progressive elaboration involves refining, improving, and adding detail as more information becomes available (Project Management Institute, 2008).

Progressive elaboration is a form of iteration that is so intrinsic to the model that it cannot be shown as a discrete phase; it is an on-going process that occurs continuously throughout the early phases of development (Figure 16). Ideally, by the time implementation occurs, this form of iteration is complete, though this is not always the case; with any inventive process that includes many stakeholders, new information can be discovered at any time.

In progressive elaboration, the goal is to have the highest level of detail early in the Implementation phase so that goals and standards are clearly defined and documented and can be used during the Implementation, Review, and Refinement phases.

Feedback Feedback refers to collaborative refinement that takes place throughout the project, particularly as it transitions from one phase to another (Figure 16). For example, as the Research phase comes to a close, feedback is useful in defining what information should be included in the Analysis and Synthesis phases. Feedback provides an opportunity to present the results of incremental progress and to get input before moving forward. Feedback can be facilitated in many ways, such as through meetings, informal conversations, online forums, usability testing, and the exchange of documents with tracked comments.

Feedback is an important element of progressive elaboration in that feedback yields a high concentration of new information that can be used for improvement.

Validation Validation includes the phases of Review and Refinement, which are the most formal and systematic iterative processes and are depicted in the refined iterative development model as discrete, yet interrelated, phases (Figures 15 and 16). Review involves systematically measuring the deliverable against the guidelines and standards outlined during the Preparation phase, and Refinement involves implementing any changes required to align the deliverable with the guidelines and standards.

Reviews are conducted in accordance with standard operating procedures, and review documents are retained and used to implement future process improvements. Standard operating procedures explain what to review; how to word review comments so they are courteous and effective; how to exchange review comments; how to verify that corrections have been made; and, of course, which guidelines, standards, and tools are used to identify a defect.

Note that, from a quality-management perspective, it is also important to validate the validation process; that is, it is important to measure the effectiveness of the Review and Refinement phases by measuring whether the two phases result in the alignment of the final deliverable with the standards and guidelines created during the Preparation phase. It is not sufficient to assume that, by having the Review and Refinement phases in place, they are necessarily effective.

Phases

The following section describes each of the phases in the refined iterative development model and includes possible activities, questions, and potential interim deliverables. These are intended to provide specific examples of what each phase might include and should be modified for each specific development project.

The description of each phase includes:

  • Activities: Specific tasks that can be performed during each phase
  • Questions: Specific areas of focus that can elicit useful information for improvement
  • Potential interim deliverables: Documents, templates, repositories, and other products related to the development process that can be used to communicate the project’s progress and value to both internal and external stakeholders. Interim deliverables can be delivered informally through a verbal conversation, or formally through a presentation, a body of information, lists, schedules, reports, and more

Research Research involves gathering together all available information related to the project. Official sources can include existing documentation, interviews with subject-matter experts and customers, and functional tests (user and usability tests) of previous versions and/or similar products. Often, important information can also be gathered from customer support and marketing departments within the company.

There are unofficial sources of information that can be used as well. For example, to gather customer input, you may be able to consult third-party online forums related to the product or service. These can be valuable sources because customers may discuss the difficulties they encounter while using the product or service, and are often more candid than when approached directly. You may also be able to gather the notes and improvised training aids that people—both inside and outside the organization—have created for their own use.

Activities may include:

  • Gathering all existing documentation, including notes and job aids created for individual use
  • Interviewing subject-matter experts and customers
  • Obtaining information from customer service and marketing departments
  • Using the product or service
  • Conducting user and usability tests of previous versions and similar deliverables
  • Researching similar deliverables produced by competitors
  • Visiting relevant third-party forums and discussion groups

Questions may include:

  • Is the information relevant?
  • Is the information accurate?
  • Is more information needed for a particular topic?
  • Does this information support the customer in completing tasks and making decisions?

Potential interim deliverables may include:

  • Research report summarizing progress to date, areas that require further research, general research goals, and gaps in information
  • Repositories of content and other assets, such as photos and graphics
  • Lists of resources, including documents, subject-matter experts, other departments, and third-party resources
  • Lists of potential information categories (topics)
  • Graphic representations, such as diagrams, depicting categories and quantities of information

Analysis Analysis is the process of classifying, sorting, and verifying the information gathered during the Research phase. For example, when analyzing information related to an instructional design project, the analysis can help organize information into courses, lessons, topics, and learning objectives. Analysis can also help in sorting conceptual information from task-related information. Sorting the information also facilitates consolidating redundant information and discarding irrelevant information.

Activities may include:

  • Reviewing the information in detail
  • Classifying and sorting the information
  • Verifying the accuracy of the information (testing existing documentation against the product or service)
  • Consolidating redundant information
  • Discarding irrelevant information

Questions may include:

  • Can the information be sorted into groups that relate directly to the completion of specific tasks?
  • Do the categories of information make sense to subject-matter experts?
  • Is the information task-based or conceptual?
  • Which categories of information are most important in terms of facilitating customer success? Which categories are least important?
  • What content can be reused?
  • What content can be discarded?

Potential interim deliverables may include:

  • Refined list of information categories (topics)
  • Graphic representations, such as diagrams, depicting categories and quantities of information
  • Flow charts showing user workflows
  • Refined lists of prioritized resources identifying those that return the most information and the most accurate information
  • Report summarizing progress to date, areas that require further research, specific research goals, and gaps in information

Synthesis While analysis is typified by separating something into smaller, more manageable components, synthesis, in contrast, refers to combining elements together to form something new. The spirit of synthesis is akin to what is often called design thinking, a solution-based, creative approach that emphasizes empathy and user-centeredness, reframing all possibilities, and prototyping (Hasso Plattner Institute of Design at Stanford, n.d.). Design thinking is not objective-oriented, “it is people-oriented” (English, 2006, p. 5). The advantage to adding this step to the process is that it provides an opportunity to innovate and to move away from patterns that have been repeated simply to avoid disrupting the status quo. It also supports one of the underlying assumptions behind the refined iterative development model—that the fundamental measure of success is whether information facilitates a positive customer experience.

User-centered design models, which are strongly rooted in human-computer interaction, software development, and other fields (Ritter, Baxter, & Churchill, 2014), often reflect the principles of design thinking and can provide a valuable framework for projects focused on the user experience. (Several different versions of user-centered design models can be found through an Internet search.)

Activities may include:

  • Considering every possible approach for the final deliverables
  • Considering new technologies and media for creation and delivery
  • Researching the techniques used in other fields and for other subjects
  • Researching the methods used by competitors
  • Questioning whether the requirements are legitimate and necessary and whether the requirements can be met in new ways

Questions may include:

  • Is there a better way?
  • What assumptions have been made? Are the assumptions valid?
  • Are the requirements legitimate and necessary?
  • Is the planned deliverable easy to access and use?
  • Do users have a high level of control over what information they can access and when?
  • Can using a different technology improve the final deliverable or the development process?

Potential interim deliverables may include:

  • Summary report of options considered and the advantages and disadvantages of each option
  • General plan for implementing the recommended approach
  • Example of or detailed description of the final deliverable

Planning Planning refers to the process of establishing goals, defining general criteria for measuring success, formulating a structure for the final deliverable, and creating a plan for the subsequent phases (Implementation, Review, Refinement, and Delivery).

Establishing goals and defining general criteria for success is an important component of the planning phase that makes it easier to make decisions during subsequent phases; the consequences of each decision can be assessed against established goals and criteria.

The structure of the final deliverable can be used to create a work breakdown structure that supports meeting deadlines. Creating a work breakdown structure is the process of dividing “project deliverables and project work into smaller, more manageable components” (Project Management Institute, 2008, p. 116). In developing a manual, for example, a table of contents can be used as the deliverable structure, and topics within the table of contents can be designated as components of the work breakdown structure. Depending on the specifics of the information development process, there may be additional ways to translate the deliverable structure into a work breakdown structure.

Having both the structure of the information deliverable and the work breakdown structure allows for more successful iteration based on discrete portions of work and also makes it easier to collaboratively decide if specific elements need to be delayed or abandoned in order to meet deadlines. As deadlines permit, topics can be included or excluded, taken through the subsequent phases, and delivered incrementally. This approach can also make it easier to ensure quality, because a condition of inclusion is that quality-related activities are part of the development process and a precondition of delivery.

Activities may include:

  • Defining and documenting the overall goals of the project
  • Defining and documenting general criteria for determining if the goals have been met
  • Formulating the structure of the information deliverable
  • Creating a work breakdown structure based on the information structure

Questions may include:

  • What are the goals of the project? What criteria can be used to demonstrate that the goals have been met?
  • What information structure parallels the customer experience? (In other words, can the information be presented in the order in which the customer is likely to need it?)
  • How can the task of completing the final deliverable be divided into discrete, manageable subtasks (a work breakdown structure)?
  • Which topics are essential, and which topics are optional?
  • Which topics are needed sooner, and which can be delivered later?

Potential interim deliverables may include:

  • Outline of topics (such as a table of contents or other type of content-based structure)
  • Work breakdown structure
  • Project schedule
  • Prioritized list of topics and/or tasks that will be included in the final deliverable
  • Contingency plan (demonstrating how deadlines can be met by making alterations to the project based on approved priorities)

Preparation While planning is a very common phase in development models, the term planning is a very general term and does not explicitly allow for the many tools that can be created to speed up and improve the subsequent Implementation, Review, and Refinement phases. The Preparation phase allows for a specific type of planning that involves creating tools, such as style guidelines, templates, terminology lists, and more. The Preparation phase is critical in terms of quality—without clearly documented standards and correct examples, there is no way to objectively evaluate whether the information deliverable conforms to quality requirements. Consistency, a core component of quality, is also easier to maintain with a careful Preparation phase because guidelines, templates, etc. can be developed as a cohesive group.

The time invested in the Preparation phase also saves time during the Implementation, Review, and Refinement phases. By adding Preparation as a discrete phase, proper resources can be dedicated to ensuring that information development tools are in place, functional, reviewed, and approved. Doing so reduces the need for time-consuming discussions and decision-making about non-variable elements of design during implementation. For example, in software development, preparing a repository of carefully worded error messages can reduce the amount of time that developers, quality assurance specialists, and other stakeholders spend on writing, reviewing, and editing the messages.

There are massive bodies of work that already exist regarding guidelines and best practices for information-related design projects, and these should be used as a starting point. For example, the Microsoft Developer Network outlines best practices in software development and is available to the general public (https://msdn.microsoft.com/en-us/default.aspx). In terms of style guidelines, there are many comprehensive style manuals to choose from, such as the Chicago Manual of Style or Scientific Style and Format: The CSE Manual for Authors, Editors, and Publishers. When choosing such tools, it is important to consider the origins, audience, and intent of the tools to ensure they are suitable. After determining which of these types of existing tools to use, then additional standards and exceptions specific to your industry, organization, or project can be documented.

The Preparation phase also has important consequences in terms of managing human resources (that is, talent retention); studies have shown a clear correlation between the level of achieved quality in the workplace and employee morale: “There is a very direct link between an organization’s decision to implement excellence and its’ [sic] impact on employees” (Stoehr, 2012, para. 5). Including a Preparation phase is likely to increase employee morale and have additional related benefits that support strategic business goals.

Activities may include:

  • Investigating and adopting existing tools created by other organizations and adapting the tools as needed
  • Clearly defining quality by creating standards and tools (such as style guidelines, terminology lists, templates, and asset repositories, such as user-interface kits, images, etc.)
  • Creating additional job aids (such as standard operating procedures, quick-reference guides, style sheets, etc.)

Questions may include:

  • Which elements of the final deliverable are non-variable?
  • Do the standards reflect industry best practices?
  • Do the templates provide for a wide enough variety of circumstances?
  • Are the standards and tools easy to access, understand, and use?
  • Is training required?

Potential interim deliverables may include:

  • List of approved resources developed by third parties
  • Customized style guidelines, templates, terminology lists, quick-reference guides, and other tools
  • Clear guidelines regarding quality and quality assurance processes (for the Review and Refinement phases)
  • Instructional documentation and training for using the tools
  • Record of approval of the guidelines and tools

Implementation Implementation involves the actual creation of the deliverables. Because standards, templates, and other tools have been created during the Preparation phase, the Implementation phase has the potential to proceed more quickly and efficiently than if these tools were simultaneously created during implementation. Developers have the freedom to focus on their areas of expertise, rather than on mundane, non-variable details.

Activities may include:

  • Creating the deliverable
  • Refining the standards and tools created during the Preparation phase

Questions may include:

  • Can any of the information gathered through progressive elaboration in the previous phases be used to streamline the Implementation phase?
  • Are the standards and tools created during the Preparation phase facilitating successful implementation?

Potential interim deliverables may include:

  • The final deliverable or components of the final deliverable
  • Refined guidelines, templates, and other tools

Review The Review phase includes the processes related to testing, validation, and quality assurance. For this phase to yield the highest returns in terms of improvement and meeting requirements, it is imperative that standards and other tools from the Preparation phase are in place. Such tools allow reviewers to assess quality more objectively and to quickly point to the solutions documented during the Preparation phase. In software development, for example, having a standard set of phrases and terms that should be used in the software means that the review process consists of comparing the final deliverable with the standard set and identifying discrepancies.

Activities may include:

  • Verifying that the standards outlined during the Preparation phase have been applied
  • Verifying that graphic and other elements from the repositories have been used properly
  • Editing
  • Testing functionality and user and usability testing

Questions may include:

  • Can any improvements be made to the review process or to the tools created during the Preparation phase?
  • Are the changes being requested consistent with the standards and tools created during the Preparation phase?
  • Is training required for reviewers?

Potential interim deliverables may include:

  • Review comments, responses, and approvals
  • Recommendations for improving the tools generated during the Preparation phase
  • Refined guidelines, templates, job aids, etc.
  • Refined documents related to the Review and Refinement phases
  • Metrics related to how closely the deliverables match the guidelines

Refinement Like the Review phase, the Refinement phase is highly dependent on the previously created standards and tools. Using the standards and tools has the potential to make correcting defects a process that proceeds quickly, as the standards and tools provide guidance for making corrections. The main activity during this phase is to use the standards and tools to ensure the alignment of the final deliverable with the guidelines and other tools created during the Preparation phase. From a project-management perspective, the questions to ask at this time are not whether the information deliverable needs to be revised (the Review phase should provide that information) but whether the standards, tools, and review processes themselves are providing an adequate basis for refinement.

Activities may include:

  • Correcting defects in the final deliverable in accordance with the standards and tools
  • Making recommendations for improving the tools generated during the Preparation phase
  • Making recommendations for improving the processes related to the Review and Refinement phases

Questions may include:

  • Do the standards and tools need to be modified in any way? Are they providing an adequate basis for refinement?
  • Are the review processes effective in facilitating refinement?

Potential interim deliverables may include:

  • The final deliverable or components of the final deliverable
  • Review approvals
  • Metrics regarding quality
  • Recommendations for improving the tools generated during the Preparation phase

Delivery A Delivery phase is included in the refined iterative development model for two reasons. First, it clearly indicates the end of the project. Some development models do not include a Delivery phase, and some visually depict an endless cycle of development, which makes it more difficult to see when the project is complete. Having a discrete end phase helps ensure that the goal of delivery is specific and defined. Second, the Delivery phase provides an opportunity to define the detailed steps specific to ending the project and delivering the final deliverable.

In project management, the Closing phase is an important part of the project management process, and includes processes related to lessons learned, official acceptance documentation, reallocating resources, reusing assets, and getting paid (Project Management Institute, 2008). A discrete and clearly defined Delivery phase allows for such closing processes.

There are also opportunities for iterative improvement during the Delivery phase. However, if the previous phases are implemented successfully, the amount of iterative improvement during the Delivery phase should be minimal.

Activities may include:

  • Delivering the finished deliverable, or components of the finished deliverable
  • Performing closing activities related to general project management (See Project Management Institute, 2008, for more information)
  • Gathering information that might help improve the deliverable and the development process

Questions may include:

  • Are there any remaining improvements required for the deliverable?
  • What can be done to improve delivery of the next project or component?

Potential interim deliverables may include:

  • The final deliverable or components of the final deliverable
  • Acceptance documents, lessons learned, and other documents related to closing processes
  • Recommendations for improvement during the previous phases of the project
  • Report on the effectiveness of the Review and Refinement phases

Concepts important to successful implementation

As demonstrated by the earlier analysis of the false oppositions between Waterfall and Agile and between ADDIE and SAM, having a deep understanding of the intent of a development model is important to successful implementation. This section is designed to explore concepts that can aid in successfully implementing the model.

These concepts include:

  • Obtaining an expert-level understanding
  • Clarifying the guiding vision: Understand where you are, where you’re going, and why
  • Getting started
  • Documenting and communicating the model and associated processes
  • Narrowing the gap between the processes outlined by the model and processes actually being used
  • Understanding the assumptions that underlie the refined iterative development model

Expert-level understanding To use a development model successfully, it is important to have a deep understanding of the overall intent of the model, as well as the detailed steps. As demonstrated earlier in this article, by its very nature, development is iterative and dynamic, and, in a business environment, many factors can influence the direction and requirements of a project. Having an expert-level understanding makes it possible to adapt to changing requirements while consistently working to achieve larger goals: “Experts use models … by first looking at them to understand the intent of the model and see the recommended processes, then by making adjustments when applying the model to their specific circumstances . . .” (Hannum, 2005, p. 10).

Interestingly, both Benington (often cited as a source for the Waterfall model) and Hannum (an author of the ISD model, which evolved into ADDIE) published retrospectives many years after their original work, and both note the misapplication of their approaches (Benington, 1983 and Hannum, 2005, respectively). Hannum notes that, “ . . . criticisms of ISD seem to arise from a lack of understanding of the ISD model, especially the underlying theory and principles, as well as the intent of the model” (Hannum, 2005, p. 10). Hannum warns against a novice-level approach and writes that applying the model in an effective manner requires an expert-level approach: “ . . . developers who are relative novices . . . may cling to the model and treat it as a paint-by-numbers approach. Novices in any field have a tendency to latch onto any guidance and follow that guidance in a literal, step-by-step manner. Only later, when they become more proficient, do novices adapt [sic] a more flexible approach” (Hannum, 2005, p. 10).

As described by Karl Weick, professor of psychology and organizational behavior, “ . . . if you want to preserve your ability to adapt to change,” then the “the act of understanding progresses through three stages: superficial simplicity, confused complexity, and profound simplicity” (Weick, 2007, p. 10). Only with a deep understanding of the intent of the model, as well as the detailed steps, can the model be applied with a profound simplicity.

While the false oppositions described earlier can be understood as rhetorical tools for promoting one model over another and interpreted as a positive indication of a desire for improvement, the misrepresentation of the older models indicates a lack of understanding and leads to the expenditure of time, effort, and other resources on unfounded criticisms—resources that could be better spent on creating an adapted approach that facilitates successful projects.

The misinterpretation and misapplication of development models can also lead to a great deal of unnecessary expense as companies invest in large-scale, systemic changes that aren’t necessarily warranted—a subtler and more expert-level approach, in which a model is adapted based on concrete circumstances, is likely to be less expensive and more effective.

Vision Defining the overall vision and larger goals associated with using a development model is also critical to successful implementation. A vision is “a picture of what success looks like . . . at a particular point in the future” (Weinzweig, 2010, p. 98). Defining success ensures that everyone is working toward the same goals. Most importantly, having a clear and shared vision helps inform and guide the decisions that are required on a daily basis to deal with difficult and changing situations.

A well-crafted vision includes an assessment of the current situation, a clear picture of the future situation, and a clear explanation of why the transition is beneficial. Ideally, before beginning to implement a new development model, it is best to have a thorough understanding of existing processes. This allows you to identify specific improvements and establish a baseline for measuring those improvements. However, this is not always feasible or worthwhile; when no processes are in place, or if processes are too chaotic, it may be wiser to invest available time and other resources in moving forward. Whether to document existing processes depends on the resources available, the level of organizational support, the overall goals in terms of process improvement and metrics, and other factors.

Getting started Often, the best way to begin to implement a development model within an organization is to start teaching it, either informally (to interested colleagues) or formally (to organized groups). As stated by Ari Weinzweig in the essay “Creating Recipes for Organizational Success,” “ . . . in the theoretical organizational world you have to . . . define it before you can teach it. But I’ve also learned from 25 years of doing this stuff that if we don’t commit to teaching our recipe we’ll probably never make the time to define it” (Weinzweig, 2010, p. 73). Committing to teaching the model imposes a deadline, ensures accountability, and begins the process of collaborative adaptation. Making a commitment to teaching the model provides impetus for documentation, communication, adaptation, and refinement.

Documentation and communication Documenting and communicating the model, the detailed steps in the processes, and the overall vision are essential to successful implementation. “You really need to write your vision down to make it work . . . Yes, if you want your vision to be effective, you have to not only document it, but actually tell people about it” (Weinzweig, 2010, p. 98).

Documenting and communicating help to clarify the steps, facilitate adaptation and refinement, and ensure accountability—it’s more difficult to deviate from a process when everyone has the same expectations of what the process entails.

Closing the gaps A critical element in successful implementation is to close the gaps between the processes depicted in the model and the processes that are actually used in practice. Espousing a model that is not followed can be more damaging that not using a model at all because it creates dissonance, mistrust, and a sense of futility. It also undermines the authority and credibility of those responsible for promoting the model and leading its use: “I would suggest very strongly that the more we tolerate gaps . . . the lower our credibility as leaders . . .” (Weinzweig, 2010, p. 82).

To close the gaps, it is important to identify what gaps exist and why. Then training, support, and tools can be provided to make it easier to follow the model. If necessary, the model can be revised to reflect the existing processes.

Assumptions underlying the model The refined iterative development model is based on several assumptions regarding the purpose of the model, who is responsible for ensuring quality, the user (customer) experience as the ultimate measure of quality, the scope of the development process, and the supportive nature of most information development. Understanding these assumptions is key to implementing the model with an expert-level understanding.

Purpose The purpose of the model is to serve as a tool to enable success and to increase quality—the quality of both the final deliverable and the development process. At the most general level, the quality of the product depends on how useful and accessible (easy to use) it is for the customer. The quality of the process refers to how efficient it is and to what degree it enables the success of the people involved in development.

The model should be implemented as a methodology, rather than an ideology; that is, it should be implemented with a healthy degree of skepticism based on its practical value, rather than adopted as an end in itself. While the model is representational, rather than literal, its value is grounded in its practical application, rather than in theoretical and political ideals. The model should be modified and adapted to facilitate the highest levels of quality and success.

Quality responsibility In many development environments, products are delivered at a low level of quality with the implied expectation that quality issues will be addressed after delivery as a result of customer evaluation. The refined iterative development model is built on the assumption that the organization, rather than the customer, is responsible for defining and ensuring quality.

Customer experience The refined iterative development model is built on the premise that the ultimate measure of quality is whether profitability and value have been maintained while ensuring a positive customer experience. At the most fundamental level, the highest quality information design is invisible; that is, the customer is able to access the information he or she needs to perform a task or to make a decision, without the design of the information interfering.

Scope of the development process The refined iterative development model focuses solely on the processes directly related to development. Because all information deliverables require maintenance and updating (due, in part, to the fluid and dynamic nature of language itself), the refined iterative development model does not include an explicit phase for maintenance and updating. The model is focused instead on the development (or inventive) process. The actions that ensure the deliverable is kept up-to-date are classified as business (on-going, or operational) processes and, therefore, are outside of the model.

The supportive nature of information development In some cases (such as with many instructional design projects), an information deliverable is the final product intended for a client. However, information development often occurs in support of a separate, primary service or product. An example of this might be help documentation in support of a software application. As such, it is critical that the information development process coincide with and support the development processes that underlie the primary product and/or service (Hamilton, 2009).

Within some companies, information development is viewed as a necessary cost, rather than as an important component of a revenue-generating product or service. As described by Hamilton (2009), in his book Managing Technical Writers: A Real World Guide to Managing Technical Documentation (which is focused on working in an engineering environment), “ . . . technical documentation is viewed with disdain by many engineers and lives at the bottom of the power hierarchy in most companies. A significant amount of your time as a documentation manager will be spent working to gain respect, power, and leverage so you can do your job” (Hamilton, 2009, Preface).

Hamilton refers specifically to how this affects scheduling: “ . . . documentation managers usually find themselves fitting their work into an existing schedule, rather than creating a schedule that fits their work” (Hamilton, 2009, p. 14). The concept of fitting the information development process into the framework of the primary development process extends beyond just the schedule and includes everything from larger business goals to available resources: “In the real world, you will probably have little input into the development methodology chosen by your project managers; you will need to fit into an existing structure” (Hamilton, 2009, p. 99).

The refined iterative development model is designed to be both flexible enough to support working within an overarching development process and to function as a primary framework.

Conclusion

The analysis and comparison of models across industries reveals that development models, like all models, are visual, relational, and representational. Development models are process-oriented, depicting a series of actions or steps taken to achieve a specific outcome. Development models are inventive, resulting in the creation of something new. Development models are also both sequential (outlining steps that performed in a specific order) and iterative (outlining steps that are repeated to ensure improvement). The basic phases of Discovery, Planning, Implementation, Review, and Refinement are common to most development models. Development models are used to demonstrate credibility, increase quality, streamline communications, facilitate business continuity, and more. As tools for process improvement, they can have tremendous value.

Applying these principles and concepts, it is possible to create a model (the refined iterative development model) specifically adapted to facilitate rapid and incremental delivery and increased quality and efficiency. The refined iterative development model specifies three different types of iterative processes (Progressive Elaboration, Feedback, and Validation) and includes three phases typically not found in other development models (Synthesis, Preparation, and Delivery).

Successfully implementing an iterative development model requires an expert-level approach that ensures a deep understanding of the intent of the model, an overall vision of success, getting started to create impetus, documenting and communicating the model, and closing the gaps between the processes outlined by the model and actual processes in use. It also requires a basic understanding of the assumptions that underlie the model.

Future directions

It would be interesting and useful to conduct case studies by implementing the refined iterative development model and measuring its effectiveness in different development environments. While I have successfully followed the model for developing technical training documentation (personal observation, 2013–2015), conducting formal case studies would likely yield results that could be used to further refine and improve the model.

The components of the refined iterative development model are based on study, training, and personal experience in different fields. The Synthesis phase, for example, is based on principles from the fields of fine art and design—particularly an area of study called design thinking. The Preparation phase is based on principles from fields that require hands-on creation, such as construction and furniture-making, in which a lack of preparation can result in the tangible loss of material, as well as in the loss of less tangible resources. The Preparation phase is also based on experience in the fields of instructional design and software development, where thoughtful preparation can lead to greater consistency and efficiency. The Delivery phase is largely based on best practices from the field of project management and the processes related to project closure. The specificity of the three forms of iteration reflect best practices in scientific communication, in which precise definitions are vitally important. Because the model is based on an inter-disciplinary approach to development, I would like to see ongoing discourse about the model from those working in different fields and with different areas of expertise in order to find the model’s strengths and weaknesses and further refine and improve the model.

References

ADDIE Model. (n.d.). In Wikipedia. Retrieved July 17, 2015 from https://en.wikipedia.org/wiki/ADDIE_Model

Allen Interactions. (2015). Iterative e-learning development with SAM. Retrieved from http://www.alleninteractions.com/sam-process

Allen, M. & Sites, R. (2012). Leaving ADDIE for SAM: An Agile model for developing the best learning experiences. Alexandria, VA: American Society for Training and Development.

Base36. (2012). Agile & Waterfall methodologies – A side-by-side comparison. Retrieved from http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/

Benington H.D. (1956, June). Production of large computer programs. Paper presented at the Symposium on Advanced Programming Methods for Digital Computers, 28–29 June, Washington, D.C. ONR Symposium Report ACR-15. Washington, D.C.: United States Office of Naval Research, Navy Mathematical Computing Advisory Panel.

Benington, H.D. (1983). Production of large computer programs. IEEE Annals of the History of Computing, 5(4), 350–361. Retrieved from http://csse.usc.edu/TECHRPTS/1983/usccse83-501/usccse83-501.pdf

Berg, R. (2011). Why Process Modeling? Journal of Insurance Operations. Retrieved from http://www.jiops.com/06/2011/why-process-modeling/

Boehm, B., & Hansen, W.J. (2000). Spiral development: Experience, principles, and refinements. Spiral Development Workshop, 9 February 2000, University of Southern California. Report No. CMU/SEI-2000-SR-008. Pittsburg, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/reports/00sr008.pdf

Boehm, B. & Vasili, V. (2005). Software defect reduction top-10 list. In B. Boehm, H.D. Rombach, and M. V. Zelkowitz (Eds.), Foundations of empirical software engineering: The legacy of Victor R. Basili, (pp. 426–431). Berlin: Springer-Verlag. Retrieved from http://dspace.utamu.ac.ug:8080/xmlui/bitstream/handle/123456789/98/%5BBarry_Boehm,_Hans_Dieter_Rombach,_Marvin_V._Zelko(BookFi.org).pdf?sequence=1&isAllowed=y#page=433

Branson, R.K., Rayner, G.T., Cox, J.L., Furman, J.P., & King, F.J. (1975). Interservice procedures for instructional systems development: Executive summary, phase I, phase II, phase III, phase IV, and phase V. Tallahassee, FL: Florida State University Center for Educational Technology. Retrieved from http://www.dtic.mil/dtic/tr/fulltext/u2/a019488.pdf

Chandler, Z. (2012, December 12). Agile developer, Waterfall
client [Web log post]. Stanford Web Services Blog. Stanford University. Retrieved from https://swsblog.stanford.edu/blog/agile-developer-waterfall-client

Chico State Instructional Design & Technology Society, (n.d.). ADDIE model. [Graphic]. Retrieved July 17, 2015 from http://www.csuchico.edu/idts/addie.php

Choudhury, A. (2012). Agile vs. Waterfall. [Graphic]. Software Development Life Cycle (SDLC) Tutorials. Retrieved July 22, 2105 from http://www.sdlc.ws/agile-vs-waterfall/

Clark, D. (1995). ADDIE timeline. Big Dog & Little Dog’s Performance Juxtaposition. The Performance Juxtaposition Site. Retrieved from http://www.nwlink.com/~donclark/history_isd/addie.html

Collins, N. (n.d.). Representational art. Encyclopedia of Art. Retrieved from http://www.visual-arts-cork.com/representational-art.htm

Cram, W.A. (2011, January). Aligning organizational values in systems development projects: An empirical study. In System Sciences, 2011 44th Hawaii International Conference on System Sciences (HICSS) (pp. 1–10). Washington, D.C.: Institute of Electrical and Electronics Engineers (IEEE) Computer Society. Retrieved from http://www.computer.org/csdl/proceedings/hicss/2011/4282/00/09-09-02.pdf

English, S. (2006, November). Design thinking – value innovation – deductive reason and the designer’s choice. Paper No. 0180. In K. Friedman, T. Love, E. Corte-Real, and C. Rust (Eds.), WonderGround: Design Research Society International Conference, 1-4 November 2006 (pp. 1–4). Lisbon, Portugal.

Geocent. (n.d.). Capability Maturity Model Integration (CMMI®). [Graphic]. Retrieved July 17, 2015 from http://www.geocent.com/how-we-do-it/processes/cmmi

GlobalTeckz. (2015). Agile development methodology. [Graphic]. Characteristics of Agile methodology in software development. GlobalTeckz – Official Odoo Partners. Retrieved July 20, 2015 from http://blogs.globalteckz.com/characteristics-of-agile-methodology-in-software-development/

Goodchild, M.F. (2012). The future of digital earth. Annals of GIS, 18, 93–98.

Greene, J., & Stellman, A. (2009). Head First PMP (2nd ed.). Sebastopol, CA: O’Reilly Media, Inc.

Hackos, J.T. (2007). Information development: Managing your documentation projects, portfolio, and people. Indianapolis, IN: John Wiley & Sons.

Hamilton, R.L. (2009). Managing writers: A real world guide to managing technical documentation. Fort Collins, CO: XML Press.

Hannum, W. (2005). Instructional systems development: A 30 year retrospective. Educational Technology, 45(4), 5–21. Retrieved from http://dose.wallacehannum.com/ISD%20Retrospective.pdf

Hasso Plattner Institute of Design at Stanford (n.d.). An introduction to design thinking: Process guide. Stanford, CA: Hasso Plattner Institute of Design at Stanford, Stanford University. Retrieved from https://dschool.stanford.edu/sandbox/groups/designresources/wiki/36873/attachments/74b3d/ModeGuideBOOTCAMP2010L.pdf

Hughey, D. (2009). Comparing traditional systems analysis and design with Agile methodologies. University of Missouri, St. Louis. Retrieved from http://www.umsl.edu/~hugheyd/is6840/waterfall.html

Integration & Application Network. (2013). Coastal wetlands. [Graphic]. How healthy is your ecosystem? Chesapeake Bay – Overview: 2013. University of Maryland Center for Environmental Science. Ecocheck: Retrieved from http://ian.umces.edu/ecocheck/report-cards/chesapeake-bay/2013/overview/

Ji, F. & Sedano, T. (2011, January). Comparing extreme programming and Waterfall project results. In 2011 24th IEEE-CS Conference on Software Engineering Education and Training (CSEE&T), 22–24 May, 2011, Honolulu, HI (pp. 482–486). Washington, D.C.: Institute of Electrical and Electronics Engineers (IEEE) Computer Society. Retrieved from http://repository.cmu.edu/silicon_valley/57/

Juneau, K.R. (2013). A reflection on the history of educational technology and evolving pedagogies. In S. Wang and T. Hartsell (Eds.), Technology integration and foundations for effective leadership. Information Science Reference (pp. 18–40). Hershey, PA: Information Science Reference, IGI Global.

Mikoluk, K. (2013). Agile vs. Waterfall: Evaluating the pros and cons [Web log post]. Udemy Blog. Retrieved from https://blog.udemy.com/agile-vs-waterfall/

My Ed Tech Resource (n.d.) The ADDIE model. [Graphic] Retrieved from http://www.myedtechresource.com/addie-model.html

Neelson, D. (2014). Waterfall vs. Agile: Which is the right development methodology for your project? Segue Technologies. Retrieved from http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology

Neo Globe Consulting (2014). Why go Agile? Understanding the benefits of the Agile method of development. Retrieved from http://www.neoglobeconsulting.com/blog/2014/3/23/why-go-agile-understanding-the-benefits-of-the-agile-method-of-development

NextGeneration. (2013). Waterfall vs. Agile. [Graphic]. Agile vs. Waterfall – Who builds the better house? Retrieved July 21, 2015 from http://www.nextgeneration.ie/Expert-Advice/agile-vs-waterfall-who-builds-the-better-house.html

Object Management Group. (n.d.). Business process model and notation. Examples. Object Management Group. Retrieved from http://www.bpmn.org/

Project Management Institute. (2008) Project management body of knowledge (PMBOK® Guide) (3rd ed.). Newtown Square, PA: Project Management Institute.

Rabe, M., Spieckermann, S., & Wenzel, S. (2008, December). A new procedure model for verification and validation in production and logistics simulation. In Proceedings of the 2008 Winter Simulation Conference, 7–10 December 2008, Miami, FL (pp. 1717–1726). Retrieved from https://www.simplan.de/images/stories/download/Fachartikel/2008_WinterSim_EN.pdf

Ramsoft Consulting. (2004). Traditional Waterfall methodology. [Graphic]. Methodology. Retrieved from http://www.ramsoft.com.au/methodology.php

Rasmusson, J. (2015). Agile vs. Waterfall. Agile in a Nutshell. Retrieved from http://www.agilenutshell.com/agile_vs_waterfall

Redish, J.C. (2000). What is information design? Technical Communication, 47, 163–166.

Reich, M. (2012). Agile vs. Waterfall: How to approach your web development project. CommonPlaces. Retrieved from http://www.commonplaces.com/blog/agile-vs-waterfall-how-approach-your-web-development-project

Ritter, F.E, Baxter, G.D., & Churchill E.F (2014). Foundations for designing user-centered systems: What system designers need to know about people. London: Springer-Verlag.

Royce, W.W. (1970, August). Managing the development of large software systems. In Proceedings of Institute of Electrical and Electronics Engineers (IEEE) WESCON, 26(8), (pp. 328–388). Retrieved from http://www.serena.com/docs/agile/papers/Managing-The-Development-of-Large-Software-Systems.pdf

Saldaña, J. (2009) The coding manual for qualitative researchers (1st ed.). Sage. Retrieved from http://www.slideshare.net/mrsnazlan/johnny-daldaa-the-coding-manual-for-qualitative-researchers-2009

Science Buddies. (n.d.) Engineering method. [Graphic]. Comparing the engineering design process and the scientific method. Science Buddies. Retrieved from http://www.sciencebuddies.org/engineering-design-process/engineering-design-compare-scientific-method.shtml

Staples, K. (1999). Technical communication from 1950–1998: Where are we now? Technical Communication Quarterly, 8, 153–164.

Stoehr, A. (2012). The link between excellence and happiness at work. Excellence Canada. Retrieved from http://www.excellence.ca/en/knowledge-centre/articles/the-link-between-excellence-and-happiness-at

Solli-Sæther, H., Karlsen, J.T., & van Oorschot, K. (2015). Strategic and cultural misalignment: Knowledge sharing barriers in project networks. Project Management Journal, 46(3), 49– 60.

U.S. Department of Labor. (n.d.) Advanced manufacturing competency model. [Graphic]. Competency Model Clearinghouse. Retrieved from http://www.careeronestop.org/CompetencyModel/competency-models/advanced-manufacturing.aspx

Wagner, R., & Harter, J.K. (2006). 12: The elements of great managing. Washington, D.C.: Gallup Press.

Waterfall Model (n.d.). In Wikipedia. Retrieved July 17, 2015 from https://en.wikipedia.org/wiki/Waterfall_model

Weick, K.E. (2007). Drop your tools: On reconfiguring management education. Journal of Management Education, 31, 5-16. Retrieved from http://www.delaney.typepad.com/files/drop_your_tools.pdf

Weinzweig, A. (2010). Zingerman’s guide to good leading, part 1: A lapsed anarchist’s approach to building a great business. Ann Arbor, MI: Zingerman’s Press.

Wyrostock, S. (n.d.). Web design timeline. [Graphic]. Wyrostock Creative. Retrieved from http://www.wyro.com/web-design-timeline

Zelfond, G. (2013). Waterfall. [Graphic]. Waterfall methodology is dead. Retrieved from http://www.scrumhint.com/waterfall-methodology-is-dead/

About the Author

Tina M. Kister is a Senior Technical Information Designer and founder of Nanatoo Communications, LLC, a company dedicated to taking a multi-disciplinary approach to improving information development processes. She is currently a graduate student at the University of Florida in the Web Design and Online Communication program. She is available at tmkister@gmail.com.

Manuscript received 24 July 2015, revised 19 January 2016; accepted 1 March 2016.