Accept
In our first stage, we laid out some possible realms of interest to find a problem to solve in. Our brainstorming session was fruitful and engaging, but the problems and solutions we were laying out were actually too specific for this part of the creative problem-solving process. I feel like the other actions we performed for this step, like Picture Success, would be better suited to follow after a more general Brainstorming step where any level of specificity is allowed before being recontextualized to a rather global problem space in Acceptance. I felt that team-membership rationales would also be more useful in a different position, either at the very beginning of the process, or after Accepting the situation—if a team is being assembled to approach a potentially vast array of topics, then they should outline their general CPS fortitude before even beginning preliminary research; but if a problem space is set out ahead of time (or through Acceptance), then team members have a reference point or context to evaluate their more distinctive abilities in relation to. I liked how the content-focused aspect of Destination and Journey brought the team together through writing for one another, but I think the exercise would be better as a group-written one that organizes our brainstorming and hints at goals to come while remaining general enough to not bleed into analysis.
Analyze
My group was very enamored with the Morphological Analysis process—forcing your problem space to constrain to two axes is a quick way to start grouping concepts and thinking about iterations and permutations of ideas and how those ideas are related. I think the mind-map technique we used in this stage would have been a revelatory way to organize the Acceptance stage—the titles of large branches could easily have become problem spaces wide enough to explore. I think we could have used a more search-friendly way of organizing our research; our process and research documents are excellent retrospective catalogues, but made retracing steps and referencing important information more difficult than using proprietary project software.
Define
We distilled our nebulous analyses into some flashpoint problems, considerations, and facts in this stage, before brainstorming about a problem statement. Repeating our previous error, the group went too far into crafting solutions before we had completely codified our problem space—I think more exercises related to proper grammatical structures of problem statements would help make this stage stand out more clearly. We realized our mistake, but though we stepped back from a particular solution, our statement was still tinged with considerations related to one solution more than others: Communities with little access to public greenery are also being left out of new green roofing initiatives and public ecology projects, which are generally geared toward new buildings and well-to-do neighborhoods. Fortunately, our problem statement properly identified our constituents and the main obstacle that stood between them and the benefits we wanted to impart to them. We later revised our problem statement during Implementation, iterating on an essential piece of the Definition step.
Ideate
After we had nailed down the bounds of our problem space, we found it a lot easier to move forward with additional divergent activities. Generating many How Might We questions as a group rendered a list with several instances of overlap, but was essential to creating a cohesive, holistic prompt for brainstorming: How can we adapt unused space to provide greenery and ecological benefits to underserved neighborhoods? Brainstorming in the Ideation stage was very helpful at widening our horizons and considering many new options for addressing the problem. We combined voting with our brainstorming in most cases throughout CPS process, and in this case, it played a huge role in determining the feature set we used to synthesize three potential solutions for our central problem: modular green roofing, sidewalk microparks, and overpass parks.
Select
The tools laid out for us for selecting a solution were some of the clearest and most useful of the whole process. We Our team used the tenets of Feasibility, Viability, and Desirability, in combination with inspiration from the Kepner-Tregoe methodology to compartmentalize pros and cons of each of our solutions, and then used those bullets as the basis for a set of criteria we used to quantitatively compare our three options: Cost, Ecological & Environmental Benefits, Speed, Space, Complexity, Scalability, Readiness, Maintenance, Community, Farming, Accessibility, Aesthetic Value, Safety & Vandalism Risk, and Lifespan & Longevity. We then made a table and graded the options 1-3 based on how well they fulfilled each criterion relative to the other two. Following that step, we multiplied the scores of criteria depending on how fundamentally important they were to solving our guiding question. I would consider this Rank & Weight technique essential to Selection, as it makes it possible to qualifying a group’s solution decision with a mutually agreed upon rubric.
Implement
Filling out a Business Canvas provided us a structured, straightforward method for thinking about key attributes of the method we would use to pursue our solution. While we had previously discussed many aspects of the contents, like our main collaborators (e.g., green roofing companies), we hadn’t really formalized them in writing in any respect until this exercise. While we had to modify the sense of some of the categories due to our intent to launch as a 501(c)(3) nonprofit, the canvas was our first plunge into working out the financial details and brand messaging that we would eventually shape into the final presentation. After completing our canvas, we set out some basic metrics (e.g., slide number/number of graphics) for our slide deck, and decided we would formulate a list of team deliverables—we set out research (e.g., existing roof materials), graphics (cash flow diagram), and write-ups to eventually reformulate into slides (e.g., constituent and stakeholder journey timelines). Divvying up our deliverables would have been easier if we designed a point or priority system to select from them. We had issues coordinating, work was not divided evenly, and some team members had difficulty finishing their assignments. I think there should be a Planning stage before Implementation, where teams would complete a business document but also use powerful tools to set out a clear roadmap to follow during the Implementation stage.
Evaluate
Working on the final presentation gave us an outline of the actual content we would need to finalize and pretty up before the end of our process. We used the Jury of Peers technique, in tandem with Plan for Improvement to identify where we had fallen short, give feedback on our deliverables, and set new goals based around distilling and refining our data and products from Implementation. We followed up with iteration on some of our deliverables from previous steps in the process in order to create a cohesive timeline from brainstorming to implementation to present to the class. I think Evaluation should also include a standalone activity that pits a team’s concerns from Ideation against their final narrative; it would also be helpful to try to fit alternative solutions from Selection into the slide deck or final product form factor, to glean whether it would have been easier to develop or a better fit overall.
