Today I’ll return to the subject and discuss what to do when these projects don’t go according to plan. I’ll describe the major types of capstone project problems that I’ve seen on the 150 or so that I’ve indirectly supervised. I’ll also proffer some advice on what to do about them.
Before continuing, a few notes are in order. First, in this post, I’ll discuss the most common issues that I’ve faced. This won’t serve as a comprehensive list. Second, I’ll assume that these capstone project problems actually exist. That is, the students aren’t lying to me or misinterpreting the situation.
Finally, I like to think of myself as a servant leader on capstone projects. To that end, my approach is hands-off for several reasons. There’s simply no way for a professor to employ a hands-on approach on every project. For instance, last semester, I was responsible for 32 different teams in my four capstone sections. Imagine if each team routinely needed 30 minutes of my time every week. Do the math. Beyond that, students should work independently and manage their relationships with their sponsors. It serves as good experience for them.
Realize the inevitability of failure.
Before starting, let me dispel the myth these projects will all go off without a hitch. Remember that capstone projects are supposed to ape what happens in the real world. As I write in Why New Systems Fail, 60 percent of traditional IT projects fail and that number has barely budged in the decade since that book’s publication. (I suspect that the numbers are similar within the analytics realm but have yet to see a compelling study.) Put differently, those who expect perfection on any project—much less a slew of them—are bound to be disappointed.
The project sponsor substantively changes the project from its initial conception.
I’ve seen this happen a few times. The students sign up for X but the project turns out to be Y.
It’s fair for students to feel frustrated when a sponsor is being unreasonable.
Example: With one week left in my system design course last summer, a sponsor requested that her team cease development in Microsoft Azure and commence development in Amazon Web Services (AWS). This is akin to changing the foundation of the house as the buyer is doing the walk-through.
Now, in and of itself, change isn’t terrible. Students need to learn how to deal with it sooner rather than later. (Cue “Tom Sawyer.”) By the same token, not all change is created equal.
First, empathize with your students. Acknowledge that it’s fair for them to feel frustrated when a sponsor is being unreasonable. Assure them that you’ll play the role of bad cop.
Next, call the sponsor immediately and ask why s/he has requested this change. (No, e-mail is not acceptable here.) There’s a good chance that the sponsor isn’t terribly technical or knowledgeable about data-related matters. In other words, the sponsor probably doesn’t know what s/he doesn’t know. Explain that this type of change simply won’t fly and why. Remind the sponsor of the form that s/he filled out prior to starting the semester. Politely offer the sponsor the opportunity to make such a change in a future semester on a separate project.
The project sponsor is routinely unavailable to students.
This is the most frequent issue I’ve encountered in my two years of teaching capstone courses. It’s particularly acute with sponsors who take on multiple teams.
Example: Students on a website project complained one semester that their sponsor hadn’t returned their e-mails for several weeks. As a result, they had no way of gathering feedback to see if they were going in the right direction. This hindered their progress on their project.
Advise students that white-collar workers receive an average of about 150 e-mails per day. Encourage them to pick up the phone. (I insist that all sponsors provide at least a work number before approving their projects.) Employ a similar tactic to the one above.
Like the previous scenario, this capstone project problem often calls for me to put on my student advocate hat. Failing a resolution, there’s always the nuclear option: Assume the role of the sponsor. Provide the students with my own user stories. This way the students will continue to make progress. Sure, the project sponsor might not be happy with me, but my primary obligation as a professor is to ensure that my students work on a meaningful project. It is not to placate a largely absent business owner or executive.
Students don’t pull their weight.
I advise students at the beginning of the semester that I expect them all to contribute to their projects. No, this doesn’t mean that I expect each person on a five-student team to do exactly 20 percent of the work. At the same time, though, those who routinely shirk their responsibilities make for a toxic group dynamic. I consider it a violation of the school’s academic-integrity policy.
Example: Last semester one of my students routinely missed team meetings, didn’t do his share of the work, and even missed group presentations—unbeknownst to them.
Try to nip this in the bud. Tell the diligent students that they should broach their concerns with the slacker in person. If that doesn’t work, then step in. Remind the offending students that peer reviews constitute ten percent of the project grade.
If Sandy Slacker doesn’t alter his behavior, advise the remaining members that they’ll have the opportunity to evaluate their team members at the end of the semester. Also remind the others that the project is supposed to mimic real-world experiences. Unfortunately, this type of thing happens all of the time.
Simon Says: Follow this advice to solve capstone project problems.
To be sure, some problems on capstone projects are easier to solve than others. If you heed this advice, you may be able to prevent small ones from becoming much larger over the course of the semester.