Reflection – Mind Mapping

Challenge of As-Built software documentation

Page 1 of 3  October 27, 2016

Challenge

The challenge I have accepted is to design a method to record descriptions of how software was

configured to deliver new software functionality. This documentation is often called As-Built  documentation:  it describes technical changes made to deliver new functionality into a software  system. When new software functionality is created, technical support staff benefit from descriptions of  what was changed in the software, why it was changed, and which software functions have been  changed as a result. Technical support staff benefits from this knowledge by preventing defects in the  software and fixing problems when the software is used. This As-Built documentation is also the basis  for training new support staff on the latest software features.

Previous attempts to record this information have relied on creating and maintaining word

processing documents:  this approach was problematic. These documents might not be completed or  contained useless information:  either, too few details were in the document or too many screen  captures which explained the mechanics of making a change but not the reasoning about how those  changes triggered new software functionality. When the As-Built documents were created, they rapidly  became obsolete as new changes were made to the software.

Selection

The tool I selected to help with my design challenge is the Mind Mapping tool as this tool seems

to be the best for getting a fresh perspective on the best method to record As-Built information. There is  a long history of different strategies used for recording As-Built information. These strategies were  developed by technical people making the system changes; however, the documents did not improve  results. The Mind Mapping tool provides a method for capturing new insights and fresh perspectives;  incorporating incomplete information in the design process in a time effective manner.

Participants in the Mind Mapping exercise review the information captured in the “What-Is”

phases of the design thinking steps and record insights they find. I believe the Mind Mapping process  allows for incomplete or less than comprehensive amounts of information collected in the “What-Is”  steps of design thinking, because participates can contribute insights based on any information they see  displayed in the initial review. This provides for a very time economical tool and it is important for my  design challenge as I have been given a fixed deadline for completion.

Mind Mapping was also chosen as it is a method which seems to encourage equal participation

from a diverse group of team members. For my challenge, I have chosen a group of individuals who do  not support the same software as the As-Built documentation is intended for. This was done to get a  fresh perspective of the challenge. The Mind Mapping activity also seems to avoid some team dynamic  issues I have often seen when groups work together in a design. Mind Mapping might prevent the  ‘loudest voice in the room’ dominating the design process by having participants work independently  and then come together as a group to review insights, group them, and create connections between  items. It is hoped that everyone contributing will create a very comprehensive review of the challenge.

Reflection – Mind Mapping

Challenge of As-Built software documentation

Page 2 of 3  October 27, 2016

Application

I applied the Mind Mapping tool for this challenge, by leveraging on the data collection work I

performed for this challenge in the first steps of Design Thinking. I collected a large amount of “What-Is”  information to form a picture of the processes followed by technical staff when creating As-Built  documentation. This “What-Is” research included: screen prints of how the software configuration was  changed, examples of documents used to request and process the migration of these changes from  development to production landscapes, examples of previous As-Built documents, and many interview  notes. An attempt was made to create a Journey Map of the process technical people following when  creating the As-Built document:  we met with staff to walk through steps they did when documenting  changes. This mapping was not completed as participants became frustrated when mapping out the  steps. The Mind Mapping exercise however might benefit even from this incomplete Journey Map.  Similarly, a short interview was held with managers to document scenarios in which they had  encountered issues with As-Built documents. The intention for the Mind Mapping exercise is to display  all this “What-Is” research on a wall, complete or incomplete, creating a gallery for Mind Mappers to  review and record their insights.

One difficulty in applying the Mind Mapping tool is scheduling my coworkers to participate in

the exercise. I have had to rebook the Mind Mapping sessions, and am booking an extra participant to  ensure I have enough people attending.

While preparing for the exercise, I have had some new ideas for possible solutions to my

challenge. This seems to demonstrate the iterative nature of design thinking: going from “What-Is” to  “What-If” steps. I have not yet shared these ideas with my Mind Mapping design team, but am keeping  a separate list of possible solutions as they are discussed.  Once we complete the Mind Map, we will be  able to use the insights and associations in the map to help evaluate possible solutions.

When creating the Mind Map, I will start with the center of the mind map having a label titled

“Configuration of As-Built Documentation”. Each participant will then attached a two by four inch card  to the page on which is written their insights from their early review of the “What-Is” research. The goal  is to build up clusters of like insights, and as we do that, give the cluster a name and connect clusters of  insights using logical connections such as: i.) an action which can become a section of the document: i.e.,  “manager approves”; or ii.) a principle for documenting As-Built information such as “document why not  how to”, “reviews”, “point out configuration items changed”; or iii.) preposition indicating ownership  such as  “possibly with”, “that are”, “require”, “have applications in”, “that enable”, “that supports”,  “of”, “through”, “contains”, “naturally have”, “can be removed from”, “contains”, “solves”, “is a solution  for”, “customers say:”, and “business development”.(*)

(*) Video 4 of Lesson 3, with Vanessa Herrera, describes this process at 3:47 to about 9:45 of the video.

Reflection – Mind Mapping

Challenge of As-Built software documentation

Page 3 of 3  October 27, 2016

Insight

The big insight gained by selecting the Mind Mapping tool is the importance of knowing which

tool to select based on the nature of how the design team or other participants work together. The big  challenge of design thinking seems to be to engage participants productively in the design activity.

Getting people to engage in the design activity can be difficult when the challenge touches on

sensitive areas of how people do their work. The initial assumption on this challenge is that everyone  intends to create documentation and that it is good documentation. The As-Built documentation is used  to capture subject matter expert’s knowledge and then share this knowledge in a common and standard  method. Not all subject matter experts might be enthusiastic to align to a standard until they are  convinced of the benefits of this and they are often not convinced of these benefits, nor enthusiastic to  participate in the design, until they have reviewed the final design of the solution.

To be aware of this mindset has been beneficial when selecting data capturing methods and

tools to pick ones which do not require much effort from the subject matter experts and can be used in  a time efficient manner. The Mind Mapping process seems to be a good fit for this.

Approach

An alternative way to apply the Mind Map to this challenge would be to review how people use

technical information provided in documentation vs. the approach I have taken, which looks at the  challenge from the perspective of how the documentation is created. This would change the initial  “What-Is” process by focusing on collecting examples and stories of when people used technical  documentation to solve problems. The Mind Mapping technique could be used to obtain insights into  how people then used the documentation and from this surface the design criteria on what to capture  this As-Built information.

The collection of “What-Is” information from this perspective might be based on outputs from

different tools. The initial create of technical documentation is more of a structured process:  i.e.,  determining which technical changes have been done and then building documentation to describe that  build and the expected new functionality coming from it. Later, when this documentation is used, the  process of applying the knowledge it contains will often be a very different process. A random event  might trigger people to look for past technical documentation and its content might be synthesized into  a problem solution in a random way. To capture “What-Is” details for random events, a technique of  capturing stories or logs of events might be best. Participants can maintain the story log over time, then  the Mind Mapping exercise could be used to review logs and extract themes or common threads of  events or beneficial information gained from documentation. Mind Mapping would be useful as it seems  to provide an opportunity to obtain insights from imperfect information.

