The Development Process

Once organizational strategies are already aligned with sustainable goals, sustainable development becomes much easier since every decision about better environmental, social, and financial performance is already supported at the highest levels of the organization. The very products, services, and events (and the infrastructure and platforms that support them) will already start to be reshaped in favor of sustainable goals. For example, if the strategies are set correctly, the projects that head for de­velopment should not only be more sustainable solutions (perhaps, focusing on cleaning rather than a particular cleaning product), but they should also automatically support the organiza­tion’s efforts to become more sustainable in a unified way. See Figure 16.3.

Once organizational strategies are al­ready aligned with sustainable goals, sustainable development becomes much easier since every decision about better environmental, social, and financial performance is already supported at the highest levels of the organization.

Synthesize

strategy ф

ruperitnCC

e Development

FIGURE 16.3. /Ш http://flickr. com/photos/rosenfeldmedia/3273331820 As with the strategic phase, the development phase involves an analysis phase of widening possibilities and a synthesis phase in which decisions are made regarding the solution.

However, even if the company’s strategies aren’t yet infused with sustainable goals and more appropriate offerings, the development phase offers the opportunity to make these of­ferings, whatever they are, more socially, envi­ronmentally, and financially sustainable. Find­ing a sympathetic and supportive ally among an organization or client’s leadership can be critical as well. The more support you have making decisions, the more likely your solu­tions are to be chosen and implemented.

Using any of (or a combination of) the frame­works outlined in Chapter 3, development teams can infuse sustainable values into their work alongside whatever the other values ex­pressed by the organization may be.

Biomimicry, in particular, should be used in the conceptual and prototyping phases of the back­end or technical solution (engineering). Look­ing for analogs and lessons in nature will have a huge impact on the technical solution. While it can be an important source of inspiration for the customer experience solution—particularly in appearance—because nature doesn’t share many of society’s values, it may have less of an impact here.

Frameworks of evaluation, like Life Cycle Analysis, may be difficult to employ in the conceptual and earliest prototype phases since there are so many unknowns. Very rough es­timates can be made, and the further along the development is, the more that can be mea­sured. However, other frameworks, such as Datchefski’s Total Beauty, may be more helpful in developing innovative concepts and solu­tions in these early phases.

To some extent, teams may have leeway to redefine criteria and requirements. Usually, the details of a product or service’s implementation are sufficiently loosely defined that there is a lot of room to interpret and develop a sustainable agenda. These may be justified to managers under the guise of issues outlined previously (such as risk mitigation, efficiency, brand dif­ferentiation, customer loyalty and connection, and so on), or they may go unnoticed by senior management altogether. Whether acknowl­edged and appreciated or not, the goal is to reduce environmental, social, and financial impacts nonetheless, and designers, engineers, and other developers have a lot of influence on achieving these reductions since the develop­ment of the solution is almost entirely in their hands.

This is the phase where all of the strategies de­scribed in Chapters 4 through 16 come to bear. Each one of these should be considered in the conceptual parts of development, as well as in prototyping and testing. The entire team should be acquainted with these strategies, even shal­lowly, and it would help to use a checklist, like the one in Appendix A, to check against prog­ress throughout the development process.

In order to move effectively and efficiently through development, the strategies more im­portant to address in each subphase are shown in Table 16.1.

TABLE 16.1 MOST USEFUL FRAMEWORKS AND STRATEGIES BY SUBPHASE Subphase Frameworks Strategies Concept and Natural Capitalism Localization Planning Sustainability Helix Transmaterialization Cradle to Cradle Informationalization Design for Effectiveness Design for Systems Design, Pro- Total Beauty Design for Use retyping, and Specification Cradle to Cradle Dematerialization Biomimicry Substitution Natural Step™ Design for Efficiency Natural Capitalism Localization SROI (Social Return Transmaterialization on Investment) Informationalization Design for Durability Design for Reuse Design for Disassembly Close the Loop Design for Effectiveness Design for Systems

MOST USEFUL FRAMEWORKS AND STRATEGIES BY SUBPHASE (CONTINUED)
Production	LCA (Life Cycle Analysis) SROI (Social Return on Investment) Cradle to Cradle Total Beauty	Dematerialization Substitution Design for Efficiency Localization Transmaterialization Informationalization Design for Durability Design for Reuse Design for Disassembly Close the Loop Design for Effectiveness Design for Systems
Testing	LCA (Life Cycle	Design for Durability
	Analysis)	Design for Reuse
	SROI (Social Return on Investment)	Design for Disassembly
	Cradle to Cradle	Close the Loop
	Total Beauty	Design for Effectiveness
		Design for Systems
Launch and Support	LCA (Life Cycle Analysis)	Design for Use
	SROI (Social Return on Investment)

All of these strategies and frameworks should be viewed as a set of potential tools. Not all of them will be useable in all projects and contexts. Some teams will have expertise and find it easier to use and implement some over others. At the very least, they should be considered periodical­ly by the development team, at least at the start of each subphase, in order to address whether they can add value to the process. If they can’t add value at the moment or on a particular proj­ect, then perhaps they can be used on the next project or at the next phase.

At the very least, development teams should represent the needs of the market (marketing), the customer (design), and the operation (engi­neering), as well as those responsible for man­aging the development (project management). This is the minimum list to develop, and it defines skills and priorities as much as job titles or departments. Expanded teams might in­clude representatives from manufacturing, law, finance, customer service, engineering special­ties, material science, biology, customers, part­ners, community, and so on, but the basic set of four outlined here is critical. Without repre­sentation of the needs and requirements from these four areas, a project runs the risk of fail­ing any one of these important requirements.

Any team member should be allowed—and encouraged—to offer suggestions across the entire project. Sometimes, someone not im­mersed in the day-to-day details or assump­tions of a discipline has the clearest perspective on innovative solutions. This doesn’t, however, mean that everyone is responsible for every decision. A clear distinction should be made between sources of ideas and responsibilities for deliverables. The former should be open to everyone willing to participate. The latter must be clearly defined and communicated, both in terms of authority and in terms of schedule. Every decision and deliverable must be some­one’s responsibility to make (though, hopeful­ly, not before adequate and open opportunity for fresh approaches and exploration).

Any team member should be al­lowed—and encouraged—to offer suggestions across the entire project.

One way developers can approach these issues with clients or within their own companies is to begin with evaluations and analyses of cur­rent products, services, and events in order to raise the awareness about these issues and set a baseline for improvements. This might be done officially or unofficially, paid or not. The benefit of these evaluations is that they educate all involved, and they create the opportunity to discuss specifics instead of generalities. They should be approached as a “stake in the ground,” in order to calibrate solutions rather than as a threat for further action. In addition, using the Sustainability Helix to evaluate the organization itself can help elevate these issues beyond the offering level and into the strategic level. These evaluations can be rough to begin with, but the expectations of their process, measure, and accuracy should be set accord­ingly in order to eliminate misconceptions about progress or intent.

Despite the potentially dire need for new so­lutions to make a revolutionary process in terms of minimizing social, environmental, and financial impacts sustainably, there are no perfect solutions and any gains are important gains. Most projects will fall far short of the desired and needed gains. It’s easy for devel­opment teams to focus on what they weren’t able to accomplish instead of the gains that were made. This isn’t to say that the focus must be on inspiring big change and exponential gains. Now, more than ever before, we need vast advancements in all areas of sustainabil­ity (reference the first two chapters again), and these only come with sustained focus and inspirational—and aspirational—leadership. But the world doesn’t change overnight, and turning and moving in the right direction a little is preferable to continuing in the wrong direction.

Most projects will fall far short of the desired and needed gains. It’s easy for development teams to focus on what they weren’t able to accomplish in­stead of the gains that were made.

CHAPTER 17