by dbward | Sep 23, 2019 | Tools 101
As part of our ongoing commitment to experimenting and communicating, we recently put together this little “video tour” of the Innovation Toolkit.
In a mere 9 minutes, we present detailed introductions to the six tools listed below (with handy links to the starting points in the video for each one)
- Problem Framing (2:15): Build clarity and consensus about the problem they are trying to solve
- Rose, Bud, Thorn (3:11): Assess the Positive, Negative, and Potential aspects of a project or topic
- Journey Map (4:14): Understand the user’s process, pain-points, and challenges
- PreMortem (5:15): Explore the future and establish a shared understanding of what success looks like
- Lotus Blossom (6:12): A structured ideation method for rapidly creating an organized set of creative ideas
- Trimming (7:25): A simplifying tool to experimentally reduce complexity or streamline a project, product, process, or plan
We hope you enjoy the video and share it with your friends!
by dbward | Aug 5, 2019 | Success Stories, Tools 101
Last year I had the opportunity to serve on a National Academy of Sciences committee. We were chartered to help NASA improve its innovation ecosystem, a truly awesome experience. One of my main contributions was to lead several Premortem sessions, where participants imagined a future scenario where NASA has failed completely. As always, the Premortem produced several moments of insight & honesty. It continues to be my favorite tool in the kit.
If you’re not familiar with Premortems, the objective is to build clarity and consensus about what success looks like. Although a lot of the discussion is focused on describing a hypothetical failure (making the description as stark and dystopian terms as possible), the key question in the Premortem canvas is actually “If the only thing we do is ______, that’s a win.” We don’t start with that question, but I always make sure we get to it before the Premortem is complete.
Here’s a short excerpt from the National Academy committee’s report, describing the consensus these groups came to during the Premortems:
…one of the answers that popped up in all three sessions was “to build strong collaborative partnerships with industry and internationally.”
In particular, a number of session participants acknowledged that NASA is no longer the only game in town and argued that the agency’s continued presence as a relevant leader in space and aerospace will thus depend on its role as a collaborative partner rather than an independent actor. One example that a number of participants mentioned is the existence of civilian space companies such as SpaceX that are increasingly accomplishing missions that were previously done by NASA alone. As long as NASA is recognized as a valuable partner in these missions… then the agency will rightfully receive some of the credit for successes in this area.
…three main things that participants identified as being important for avoiding a dystopian future: developing strong partnerships with industry
and internationally, continuing the learning culture at NASA and building on it, and improving communication across NASA and with those outside of the agency. NASA is already doing many of these things, the session participants said, but there is room for significant improvement in each area.
If you’d like to learn more about how NASA used the Premortem and how they answered the “If the only thing we do…” question, or even if you just want to see what NASA’s senior leaders are doing to help the agency improve, check out the full National Academy committee’s report, now available as a free PDF (see the “Download Free PDF” link on the right of that page).
by dbward | Jul 29, 2019 | Facilitation Tips
We’ve all been in meetings where one person talks too much, haven’t we? As facilitators, this can be a challenging situation to manage. On the one hand, we want to honor each person’s contribution and willingness to participate. Shutting someone down can have a chilling effect, not just on the individual but on the group as a whole.
At the same time, it’s important to make sure everyone gets to participate, and if one person is dominating the conversation, the whole group misses out on hearing from other voices.
To paraphrase Sun Tzu, the best way to deal with this situation is to prevent it from happening in the first place. Be sure to set some ground rules in every workshop’s introductory comment. Make it clear that everyone in the group has a role to play and something to contribute. Encourage people to be mindful of sharing the stage and inviting others to speak.
I’ve even been known to do a little public math: “We have 20 people in the room for a one-hour meeting. If everyone speaks for 3 minutes, that’ll be the whole meeting.” For some people, it helps to hear the actual numbers explicitly called out.
And of course, despite the best preparation and guidelines, it still happens. Someone goes off on a tangent, unrolls an endless story, or otherwise monopolizes the group’s time and attention. They might have a good point or a useful observation, but it’s just gone on a bit longer than necessary.
Or maybe they’re just rambling and someone needs to stop them.
Here’s what I do when that happens: With a big smile and a nod or two, I hand the over-talker a pen and a stack of sticky notes. I say something along the lines of “Hey, that’s a really important point – could you write it down in your own words? I want to make we make sure we really capture it before we go much further.”
Depending on how much the talker is paying attention to the other people in the room, I might have to stand up and/or move closer to them, physically intervening to get their attention and create a pause in their monologue. I’m always amazed how a little shift in my posture or my location can help change a room’s dynamics.
This technique does several things simultaneously.
First, it solves the immediate problem of one person speaking too much, because it’s really hard for most people to talk and write at the same time. Putting a pen in someone’s hand basically turns off their mouth.
Second, it affirms the person’s contribution to the discussion. This is the opposite of “Shut up and move on.” Instead, it’s “Keep going, but do it in a different mode.”
Finally, it gives the person a chance to really clarify their point and distill it into a more focused package. They may discover that they weren’t really saying much worth writing, or they may uncover their actual point in a more cogent fashion. Everyone wins.
Got a facilitation tip? We’d love to hear it! Leave your suggestions in the comments section, or drop us an email at ITK@mitre.org to continue the conversation!
by dbward | Jul 22, 2019 | Uncategorized
Our Story From Last Week Continues…
Day Two: Brainstorming and Prioritizing Actions
At the end of the first day, the facilitation team met and affinitized the feedback we’d heard, grouping it into topics for the next day. Our intent was to form the participants into persistent teams of 5 or 6 people; these teams would move from topic to topic throughout the day.
We also noted which people had been helpful or disruptive in furthering group cohesion, and strategized how to ameliorate this. One of the VIPs, whose mere presence as a VIP was hampering conversation, solved our problem by recognizing that he should not be present for the second half.
The other critical tactic we used was to intentionally mix up the teams, so that each team had representation from two or more roles. Because folks had naturally sat with their ‘friends’, this was relatively easy to accomplish—we went around the room, table by table, and had everyone count off 1, 2, 3, etc. as their group assignment. This shuffled the groups nicely, resulting in a much more varied mix of people in each.
The Lotus Blossom encourages participants to brainstorm subtopics, and then dive into each subtopic to generate related ideas.
To gather ideas for possible actions, we used the Lotus Blossom method. The Lotus Blossom is a structured brainstorming tool that enabled the teams to ideate multiple solutions to the problems identified. Facilitators used “How Might We?” statements to help elicit ideas, shifting the focus from constraints to possibilities.
Using this method, we were able to generate around 40 potential solutions for each topic area in 50 minutes, successfully staying on-task without going too deep into any one topic or rat-hole. Because ideas are immediately written down on the Lotus Blossom worksheet, all participants can see what was brainstormed, and think laterally, rather than getting stuck on a particular topic.
Each table had a MITRE facilitator who helped fill out the diagram. This helped teams understand the context when coming to a new topic. Facilitators also kept the conversation moving, recording and reflected ideas back to the group.
We also wanted the teams to prioritize their ideas. To do this, we used the Impact/Effort Matrix method, sometimes also called the “2×2 matrix” method. (See, e.g. https://www.groupmap.com/map-templates/impact-effort-matrix/ for more details).
The Value/Effort matrix is a technique from the Six Sigma toolbox that helps
The axes we chose reflected our conflicting populations: impact, which would be specified by end users, and effort, specified by the development teams. The resulting priority was a function of both inputs: high impact/low effort actions would obviously be prioritized above low impact/high effort.
Time Pressures = Progress
The last piece of our method was to use the clock. We had an abbreviated schedule on the second day: about 4 hours of work time available. We knew we wanted groups to rotate between topics, with later groups building on the work of earlier groups. But by the third or fourth rotations, groups would be coming to a large amount of context; in this situation, brainstorming often begins to dry up and get less productive.
We eventually settled on an accelerating schedule. Groups had 30 minutes to brainstorm and prioritize actions for their first topic; then, 20 minutes on their second, then 10. After each round, groups reported out to the entire room, to help promote coherence, but also to help the participants feel invested in these ideas.
When we noticed they were unengaged or seeming reticent, we asked or volunteered individuals to represent ideas to the group at large. This was extremely helpful; in some cases, people who had been ‘floating along’ and letting the rest of the group do the work ended up pulling out an idea and making it their own. This vastly increases the likelihood of it being actioned in the future. For example, a sysadmin realized that, even though her office had solved lots of process problems, other offices might not have, and that she could share her experience with other offices for an overall improvement.
>After three rotations, all topics had a sufficient number of ideas brainstormed and prioritized, and we stopped and reflected back our key findings to the group as a whole; we then let the group break up into social groups, to continue to build common ground.
Results
The data—captured both as notes and as pictures – became the input for a response document delivered to the sponsor, which was met with strong approval; we were able to reflect the pains and opportunities in the current system, and provide potential actions, all using the words and ideas of the sponsor’s own people.
An equally important outcome was the increase in team cohesiveness across locations and constituencies; folks left with an air of “we can do this together”, which was a desired but not guaranteed outcome. Breaking down silos of knowledge, and teaching developers and users how to communicate, are key means of improving the overall user experience of a system.
The work with the sponsor is currently on hiatus, but we have already been asked to run a similar session with additional sponsor representatives in the future.
Big thanks to guest bloggers Alex Feinman, Tom Seibert and Tammy Freeman for sharing this story!
by dbward | Jul 15, 2019 | Uncategorized
Today’s post is the first in a series by guest bloggers Alex Feinman (with Tom Seibert and Tammy Freeman)
Sometimes, you have to mix and match methods to get the results you need. This story is example of how important it is to be able to modify and adapt the plan in response to new facts and constraints.
MITRE was called in to facilitate a conversation about replacing or upgrading a COTS piece of software that a sponsor was using. We put together a session that began with knowledge elicitation, to understand their domain; then focused on establishing user requirements; finally some progress toward conclusions and agreements on actions.
The sponsor sent close to 30 people to the two-day event. MITRE brought in a team of facilitators to help manage the large number of people.
While our team had some experience with the software in question, we also had more experience with other, better software. Hence, we were expecting to elicit the sponsor’s needs, as a step toward potentially guiding them toward a better option.
This plan, as they say, did not survive contact with reality.
The Map is Not the Terrain
We were expecting our participants to be a mix of end users, ops/sysadmin folks, and program administrators. Instead, on arrival, we discovered that the bulk of attendees were developers—some sponsor-based, and some who were contractors.
The two sets of developer were working on competing systems, both used by the sponsor. End users had to switch between these systems to get their work done. In addition to this, we had only a few actual end users, plus a number of sysadmins, who sat between those two populations.
The group was on the edge of fracturing, with finger-pointing starting to become more apparent—the makers of each system were defending their turf and jobs, and beginning to think about bad-mouthing the other “team”. It was time to help these developers understand how things looked from the user’s perspective, and fast.
Day One: Finding Common Ground
After a quick consult, the facilitators decided to continue to gather data on the work context—getting a sense for what things were on everyone’s minds about the systems. Concerns by most users centered around ease of use issues, responsiveness (or lack thereof) from development teams, and annoyances related to switching between two different systems with similar purposes. Concerns from sysadmins and developers centered on deployment and provisioning, and licensing of third-party data sources.
We used dot voting to identify which concerns were foremost. This backfired slightly: nearly everyone voted for “merge the two systems”—a solution masquerading as a pain. Additionally, some near-duplicates needed to be merged. In retrospect, we could have used a round of affinitization or Stormdrainingto reduce the number of issues prior to voting.
Based on this finding, we decided to dive into understanding why the systems were currently separate, and whether there were any benefits there. A subgroup worked to put together a rough system diagram on a whiteboard wall. This revealed a huge amount of complexity hiding behind the user interface and helped legitimize the current split situation. One of the systems had strong processing capabilities, while the other had a much stronger UI. With this brought to light, we worked to help the group see that there might be a double-win involving pieces from both systems.
Armed with this data, we gave the group six areas to focus on, ranging from user workflows and UI issues to system administration, data ingestion, and data processing. This allowed the group to break up naturally by role, which was both helpful and harmful—helpful in that each group made progress, but harmful in that it did not work toward building group coherence. However, it was a necessary step toward group formation—letting the folks there understand that we were intending to listen to them, understand their situation, and help them prioritize their concerns.
Informal discussions, such as those happening over lunch, were critical to getting folks to buy into MITRE’s role as an unbiased facilitator. These conversations helped cement their trust that we weren’t there to put half of them out of work, weren’t there to promote one system over another, and certainly weren’t there to sell them on software we created.
We also invested time with particularly reticent folks to bring them around to seeing other people’s perspectives, and give them hope of open lines of communications. While often overlooked during use of ITK “methods”, these informal conversations can make or break a long event such as this one!
By day’s end, we had a commitment from everyone to keep working together and keep talking—a great start given where we’d begun.
Stay tuned for the rest of the story in next week’s episode!
