Group Lessons Learned

As with any group project, if you asked us what we learned you would get six different points of view. Actually, each one of our individual perspectives forms the last part of this report. However, after talking together, we did manage to reach consensus on the following common lessons. These included the differences we noticed between our community partners, some basic computer and networking skills, what constitutes meaningful training, and the important task of managing ourselves as a group. Most importantly, we were able to accomplish our main objectives, delivering the requested number of refurbished computers, making sure they were networked, and providing basic technical training to our community partners.

The Community Partners:

Our group had two community partners, Peer Ambassadors in Champaign and Teen Tech in East St. Louis. While we were able to work with successfully with both groups, we felt that we accomplished more with Teen Tech than with Peer Ambassadors. While we don’t know exactly why that is, we did come up with some factors which may have made our experience with Teen Tech more positive.

1) Understanding the purpose of the lab

Teen Tech

We had a good understanding of the goals of the Teen Tech computer lab. They told us in the beginning that they wanted it as part of an effort to teach the teens to recycle computers for sale and to compliment their existing video editing lab. It was also clear that the lab was meant to get the kids involved in technology to help them overcome the challenges they faced growing up in the difficult environment of East St. Louis. From our first field trip to East St. Louis in June, we saw several examples of Community Labs in churches and other facilities that gave us a good idea of how the lab would fit into the community. We also saw a sample video project that the Teen Tech group did which gave us some idea of what they could produce.

Peer Ambassadors

Peer Ambassadors wanted the computer lab to help the kids create literature and presentation materials to promote their organization’s goals of mentoring other youth in the community. It was also hoped that it would become a “draw” to attract kids into the program. Our group discussed potential purposes of the Peer Ambassadors lab, however several ambiguities remained about how the lab would fit into the overall goal of the group.  This might have been avoided by more frequent contact with the site coordinator, Karen. For example, we never saw examples of what the group produced and had trouble seeing concretely how the group was fulfilling their mission.  Also, seeing examples of other community labs in Champaign might have given us a better understanding of how the lab could serve the community.

2) Leadership

We also discussed the different styles of leadership between the two groups and how that may have affected the projects. While we just met Mike Adams and Karen Simons perhaps three or four times, we found noticeable differences in their leadership styles.  Karen at Peer Ambassadors seemed to be stretched thin, understandable considering the budget situation.  However, this stress was repeatedly shared with our group, causing us to wonder whether we should be focused on technology or just interfacing with the teens on issues they were dealing with.  She seemed to have a larger group of kids to supervise, and had to rely on delegating work to the older kids. She has an IT person to rely on at her facility, but we didn’t meet with him until we delivered the lab. Mike seemed to have a smaller group to work with and greater technical proficiency.  This combined with his laid back manner and general comfort with the teens led to a more comfortable partnership. Observing the differences in how personality traits might affect the success of a project was a very interesting lesson learned.

3) Kid’s motivation

We all noticed a difference in the kids motivation between the two groups, finding that the Teen Tech kids seemed to have a greater appetite for learning the technology. When the Peer kids came over to GSLIS, we had to ask them to put away cell phones and quiet down repeatedly, but didn’t run into this in working with the Teens. It may be that the Teen Tech was a voluntary group whereas Peers were paid. It may be that the church facility where made for a more serious environment. It may be the differences between the two communities, or it may just be just a function of the kid’s personalities.

The practical effect of the differences in these three factors was that when we worked with the Peer Ambassadors group we had to put more energy into directing the kids and generally focused on simpler tasks than with Teen Tech.

Computer & Networking Skills:

Given the variation in technical skill level amongst our group, what we learned individually may be quite different than what we learned as a group. We did agree, though on the following:

1) Refurbishing computers is time consuming. For example, loading windows software as we did was a tedious 12 step process, with many substeps. Needed to find a computer with an XP label, Need to load not just the OS, but all of the updates (Service Pack 2 & 3) and almost all of the security software and extra software separately. Similarly, after we had run DBAN on 6 computers for the Peer group, we found that three would not install Linux Mint, so we had to start over with them.  Shortcuts to this process were greatly appreciated, and all the pre-installed programs in Linux Mint 7 became very appealing.

2) Knowing when to get help. By the end of the process, we had a better sense of what we could do ourselves (basic trouble shooting, looking in BIOS, installing software) and what we had to get help for, such as getting scripts to have the computers auto update or auto clear, or networking the printers. As our knowledge base grew, so did our sense of autonomy.  It was also helpful when we as a group could isolate a specific open issue in the project and without solving it, still continue work on other aspects.  This allowed us to avoid getting stuck when a solution isn’t immediately apparent.

3) Technological issues versus procedural issues. Many of the technology issues were really procedural issues – such as remembering power cords, testing all of the equipment prior to delivery, making sure all of the software updates had been done, having enough car space to load all items to be delivered, and bringing tool boxes and cable-making gear. As noted below, managing ourselves was as critical to our success as mastering the technology.

4) Making technical decisions with the partners:
It is difficult to give your partner real choices about what technology to proceed with. For our group, Teen Tech preferred a Windows environment, whereas many of us thought that Linux could have been more effective. In the end, we found it better to go with our partners inclination, but provide some exposure to Linux to show them what it is capable of.

Training:

What we learned about training came revolved around two main themes. The first, was how much to plan versus how much to improvise. The second issue was how much we should let the students work on the lab computers themselves versus how much we should do. We seemed to find a happy balance with both of these issues.

1) Improvising versus Planning: This was a function of our personalities as much as what type of style is superior. As with most things, a balance between the two proved most effective for us. Improvising a lesson definitely brings more excitement to the training. The kids responded well to parts of the lessons where they got to ask questions about what college was like, or an unscripted lesson on how to upgrade RAM, or just letting them play with Open Office and Linux to see what they could discover on there own. Some of us who were less comfortable speaking up about technology matters definitely derived comfort from the lesson plans that were prepared. The synthesis of both styles worked well as a group. Following the style of our own 451 class, we found that brief lecture followed by a hands on activity worked best. Please see the appropriate page on this wiki for more detail.

2) Hands on versus Hands Off: Since we had a limited amount of time with each group and it takes a while to refurbish each computer we didn’t want the training to interfere with delivering the computers. We agreed that it would be more empowering for the youth to be involved in every step of the process of refurbishing their computers and building the network. So sometimes we chose a hands on approach, such as checking BIOS and then upgrading the RAM. Other times, such as with Peer Ambassadors, we did a hardware demonstration with computers that were not theirs so it wouldn’t disrupt our delivery plans if the machines didn’t work when reassembled.

Managing Ourselves:

As is often noted the greatest enemy is the enemy within and our group had to grapple with a participatory decision making structure where a command structure would have been more efficient. Disagreements did occur and had to be worked out. Fortunately, we were able to make enough good decisions that we were able to get our projects got completed. Some things that helped us succeed were inputs from the instructor and teaching assistant, planning, division of labor when possible and time management:

1) The value of experience: The most valuable inputs from Martin were his repetition early on of the question, “What are your priorities?” I think that helped us focus early on when we had a log of uncertainty and nervousness about what we would do and how we would accomplish it. Adam has been very helpful in guiding us not just as a go to person for technical help, but also with some good suggestions about how to run the trainings, such as having our first Peer training go back and forth to two demonstration areas to keep the lesson flowing.

2) Planning: Some members of our group had more inclination in this area than others, but we all accepted the need to have regular meetings, checklists, a division of labor where possible, and labeling things when we could. Some of us were more inclined to have a meeting, plan out what were going to do, divide the responsibilities and then start work whereas others of us preferred a more of a jump in and start working style. Neither one is wrong and both are appropriate, but it is something that we had to work through as a group.

3) Division of Labor: While I’m not sure we optimized this, people did drift towards there areas of strength. We found that having a designated contact person with the partner was very helpful, for instance. We also found that a natural division seemed to be between a more heavily technology role, training/teaching, planning/preparation, and a reporting/recording role.

What we left out:

While we accomplished our objectives within the given time frame, there were some areas that we would have liked to cover in more detail with our partners. While we did explain some of the software on the computer, we didn’t systematically go over all the programs, due to a lack of time. For example, we installed the program “Sea Monkey” on the Teen Tech computers, but we weren’t able to explain or demo exactly what it did. If we were really training the youth to run the labs, we should have spent more time on security, although it did come up in our discussion with the Teen Tech group. If time had permitted, a more systematic lesson like we learned in class could have been valuable. While we provided some documentation as noted above, we wished we could have given them more comprehensive guidelines for running the lab, such as a copy of the text we used in class or other such substantial guidelines. Finally, we wished we could follow up and see what the kids do with their labs, but we’ll have to leave that up to Martin and other 451 students to see!