As a means to learning “best practices” on future projects, I have been assigned to write a project post-mortem about a personal or professional project that was not successful. (“Defining the scope of the project: Blog assignment”)
I decided to write about an instructional design project that I have discussed previously in this blog. The project actually went quite well, but it definitely had its rough spots. The need for the project became apparent when I decided to try using Facebook as a tool to give ESL students experience using English. The attempt to use Facebook failed because the students lacked the basic skills to use a computer. I created a seminar to teach basic computer skills to adult ESL students, with a focus on using computers for social networking. (Lloyd , 2010)
In his eBook “The Project Management Minimalist: Just Enough PM to Rock Your Projects,” (Greer , 2010) Michael Greer suggests conducting a project “post mortem” involving asking of team members to find out their opinions of the success of the project, and brining respondents together for a “lessons learned” meeting. Greer suggests general questions that are appropriate for a post mortem, and then suggests “phase-specific questions.”
Below are my answers to some of Greer ’s questions related to the seminar I created for my students:
The single most frustrating aspect of the project was the amount of material I wanted to cover, versus the time that was allowed to cover that material. In the future, I would plan a series of at least three seminars to cover the material I attempted to cover in one evening. However, the primary objective of giving students the confidence to continue to learn to use a computer was clearly achieved. Students who had never used computers previously, expressed the intent to purchase computers and to continue learning to use them on their own. The “hands on” activities that were planned to give students immediate experience using a computer worked well. Students who attended the seminar left with new skills that will benefit them for life. The discussion portion of the seminar was difficult to evaluate because discussions happened in Spanish, and I do not speak Spanish. The interpreter participated in the discussions and concluded the discussions by interpreting summary comments.
The planning of needs and feasibility tended to err on the side of providing too much material for a one-session seminar, however the material that was planned was necessary in order to accomplish the goals of the seminar. The only change I could recommend for the seminar would be to allow for more sessions in order to cover all of the material. I would not change the seminar content.
Original estimates of the time required to accomplish project goals were not realistic. The focus on physical skills effectively overcame much of the potential communication difficulty of an English-speaking teacher working with Spanish-speaking students. Materials were effectively translated, and although the language barrier hindered classroom discussion, the social learning aspects of the plan worked effectively with the use of a translator.
The time estimate was off because the educational diversity of participating students, and the effect of that diversity on the flow of classroom activities was not anticipated. Testing and timing of classroom activities was done with students who understood instructions, and were already familiar with using a computer. None of the actual students had ever used a computer. Some of the adult students had less than three years of education in their own language, while other students had some college-level training. More focus on knowing the students would have enabled more accurate planning of time required to complete the seminar.
References:
EDUC-6145-3 project management in education and training. (n.d.). Defining the scope of the project: Blog assignment. Walden University
To those who need to comment on this post, I apologize for posting late. I dated the entry on its due date Thursday, but it was actually posted Saturday, two days late. A separate email was sent to the instructor so she knows when the assignment was posted.
ReplyDeleteDavid,
ReplyDeleteI think the hardest item we as ID have is defining the topics and time for training. The overall scope is not something we can read or be taught, except through experience.
As you found out, the amount of material can be deceiving, especially to someone who is an SME in the topic. It sounds like you had a very diverse population, where some of the items you mentioned would still be a problem unless class was restricted based on skill level.
I am very happy that the project worked out for you! It sounds like you learned about some of the finer points in project planning and I hope you are able to advantage of those in your next endeavor!
David,
ReplyDeleteIt sounds like you tried to accomplish way too much in a short period of time. Your idea of planning 3 seminars to cover the material sounds more reachable. You are very brave to attempt to teach a class to spanish-speaking only students when you yourself are not bilingual. All in all, you may not have accomplished all your goals but it sounds like you planted a seed for learning more in your students and sometimes that is a huge achievement. I mean isn't that what teaching is all about?
Hi David,
ReplyDeleteYour intentions were good and I liked your resources. Maybe an initial needs analysis and computer test may have refined your expectations. I bet your help is greatly appreciated. Maureen
Online reading is not my thing. But after reading your blog I am really pleased. I don’t know about other blogs but this I will definitely keep coming back to.
ReplyDeleteProject Post Mortem
The project debrief, or Project Post Mortems, is one of my favorite parts of a project because I learn as much from a negative project experience as I do from a positive one.
ReplyDeleteWhat contributed to the project’s success or failure? The positive and negative drivers of this project were closely enmeshed. What follows is my pro and con post-mortem list of PM actions that drove the project to failure.
Probably the most important reason for undertaking a Project PRE-mortem is the least obvious; its to engage technical staff, to ask them how they felt about the project. Far too often programmers feel they have been rail-roaded into doing things they didn’t want to do during a project, for example; cutting features, following technology choices made by management, having to work over-time because of poor time planning, etc. You must listen to people – that doesn’t necessarily mean you enact the ‘nerf guns for everyone’ policy your zaniest programmer requests, it just means sincerely listening to what they have to say.
ReplyDeleteThe unfortunate reality with Project Post Mortem (also called Project Debriefing or Lessons Learnt) is that everyone thinks they are a great idea, but they rarely ever get done. I would say the main reason for this is because upper management generally doesn’t think its worth the commitment of resources.
ReplyDelete