Posts tagged project
The second semester started a few weeks ago here at the school where I teach. One of the real frustrations for me has been watching the enrollment in my second semester classes bottom out — conversations with students suggest that they are making this decision based largely on graduation requirements (they don’t need my courses to graduate). I had one particularly poignant conversation with a student this afternoon who asked, “why would someone sign up for the second semester? What do they get out of it? Are they just taking the class because they like it?”
In any event, sad though this is at a macro level, it has provided me with an opportunity to do what I enjoy most: build a project with my students. The few students remaining in my computer animation class and I are going to write, produce and animate a short film this spring. This is a project with more than a few steps, and no small amount of complexity. I’m keeping my fingers crossed that the students can do this, and I’m expecting to have to step in to pull my own weight in this project as well. And I’m kind of looking forward to that. (I’m certainly teaching this class because I like it!)
In doing this, I started to map out the steps of the project in a variety of different tools. I experimented with a bunch of online options (BaseCamp, 5pm, LiquidPlanner, Tom’s Planner) and have ended up with a tool that Adam Seldow introduced me to back when we were working on EdTags: dotProject. It’s a quirky little open source project planner, that has a fairly extensive collection of community-produced add-ons. It runs on a standard PHP/MySQL installation. It lets me map out milestones, tasks (with dependencies on other tasks), and have my students log their work (and progress) in the tool.
…and it generates Gantt charts of the project. Which turned out, to my surprise, to be a shockingly effective visualization for my students this afternoon. They haven’t exactly been coming out swinging — they’ve only been working on this project in class, while I’m there to crack the whip. But when they saw a) the complexity of the project and b) that their progress bars were behind where today’s date line was on the chart and c) that now our projected date of completion is two weeks after our last class. And they got religion.
As I worked with dotProject some more this afternoon, I’m beginning to think that the logging feature are going to provide me with some really spectacular qualitative data for assessing these students, as well as allowing them to visualize their progress in an immediate and understandable way. I’m totally excited about this: it’s authentic learning, with assessment, with intrinsic motivation! Woo hoo!
Let’s hope that this high lasts….
This post is part of a series that are components of my “Expert Plan” at my school, looking to create a shared resource for my colleagues as the school moves towards greater adoption of laptops and technology in our pedagogy.
This is actually a classic use of wikis — the one for which they were developed, in fact — and one that I have found very useful in the past. By documenting my work on a project in a public, shared space, I am both sharing information that needs to be known and inviting other participants to contribute their knowledge as well. I use wikis both for shared projects with my colleagues (as a way to guarantee that only the most current documentation is available, rather than distributing instantly out-dated paper handouts) and as a way of pushing my students to document their own work so that I can grade them on process. Additionally, wikis are a way for me to document my own thought process for both professional development and future planning purposes.
Shared Projects with Colleagues
I have found that many of my colleagues (both at [my current school] and [at previous schools]) are hesitant to edit existing documents. The most reliable contribution that I have found my colleagues make is on meeting minutes, when I invite those who did not attend a meeting to insert their contributions to the meeting as comments on the page.
When working on a project with a similarly technically-inclined colleague (say, in the Education Technology department), the process is more likely to be more collaborative, as we edit each other’s work more liberally (although even this is not a guarantee).
Student Documentation of Process
Students don’t document their working voluntarily. I have only had success in asking students to document their work when I have both assigned the documentation for a grade (usually a grade separate from the end product of their work, so that I can distinguish between process and outcome not just in narratives but also in my gradebook).
The closest that I have come to developing a true classroom culture of collaborative documentation was last spring at [my previous school] in my Application Design classroom. In this case, I worked with the students to help them select and design an open-ended project for which they had to do immense amounts of research (they were creating a computer-controlled CNC lathe). I found that there was an inverse relationship between the amount of expertise that I demonstrated and the amount of work and thought that my students contributed: when they could rely on me for answers, they were lazy about documenting their work and finding their own solutions. When I professed no knowledge (often truthfully), students were far more likely to both do much more exhaustive research and to present their findings more clearly.
One challenge of creating a truly collaborative wiki environment (whether with colleagues or with students) is to get all of the participants to read, respond, revise and/or react to each other’s contributions. For example, I am doing a miserable job, on this page, of linking to the work of others in the Laptop Leaders program. I suspect that a major part of this is simply the “drinking from the fire hose” feeling incurred by the stream of data as everyone contributes simultaneously. In a classroom, I have had some success dividing students into groups around a shared research interest. To that end, I need to sift through the other Laptop Leader documentation that refers to, say wikis.
At the basic level, my sense is that wikis represent such a shocking change in paradigm for how the web is used that the average user is either befuddled or intimidated by them. I found that I was explaining how wikis work to my classes and the students were fascinated and mildly horrified at both the ease with which they could make changes and the ease with which I could track their use of the wiki. I don’t know for certain, but I wonder if my colleague’s reluctance to update wikis is a combination of fear of the unfamiliar (editing the wiki) and fear of speaking out (publishing their words/ideas to a broader arena in a way that feels more permanent than, say, an email — more on par with a faculty meeting).
As we steam towards the end of the year here, I’m watching my next few weeks and, in fact, my summer start to disappear under encroaching project creep. Not that I object too much: most of the projects are pretty cool — in fact, some of them are projects that I’ve been dying to find time to work on during the school year.
I’m painfully aware of my propensity to put off inordinate amounts of work for my next medium-sized chunk of free time. My canonical example is the year in college that I put off about a dozen errands until my Thanksgiving break. Boy howdy, was it ever a rude awakening to realize that Thanksgiving break is only about three or four extra days on the weekend, and probably at least two to four of those days are chock full of commitments to family and friends. Not so much time.
With that in mind, I was fascinated by Steve Pavlina’s article on calculating your fudge factor: that ineffable amount that your horseback estimate of the time necessary for a project is off from reality. My fudge factor is approaching 1.0 for things like driving time — and has been for years. But for coding projects and curriculum development, it might be closer to 3-10 (as in, it takes me 3 to 10 times as long as I plan for).
I’m not convinced that I have Steve’s discipline, but I rather suspect that I can use old data to get some sense of how off I usually am in my time estimates. I have surely made lots of promises archived in my email and then documented my progress (and extensions) in that same medium. Sounds like an interesting project to work on this summer…
Although building an intelligent project monitor that used heuristics to identify project commitments and updates in my incoming and outgoing email and automatically calculated the fudge factor… Now, that could keep me off the street for days at a time. Or weeks. Depends on what my fudge factor is.