How to explain a failed academic project during presentation?

Question

I know this may seem a strange question, but pretty soon I have to give a presentation on my project and I'm gonna have to explain why it doesn't work as was specified. I'm worried I will lose grades due to missing the spec, and I suppose I should technically, but this project in my opinion was overly difficult for the timespan.

This is an undergraduate EE degree I am doing, and the project was to build a windows app that reads and decodes a MIDI file and then displays it in musical notation and play the file if possible. With no experience of MIDI, and good knowledge of c++ but none of the MFC this was daunting.

How do I explain during the presentation of my project that it failed to meet the spec because the deadline was unrealistic, while not insulting my supervisor since it could make it look like he had no clue? Some of the interviewers will be knowledgeable on MIDI and programming and some wont, I think its a panel of 4.

Answer 1

It's usually the professor (or supervisor?)'s job to make the deadlines and calibrate them for his course -- not yours. He'll make the deadlines with experience from previous years informing his expectations. If you can't meet his deadlines, then you'll get a lower grade in his class. That's the way it's supposed to work.

That said, you should probably play up what your program does well, and explain the progress you did make on the project with an emphasis on how much you learned and how far you came from your initial state of ignorance regarding MIDI et al. Make sure it's clear that you were working hard the whole time by having concrete things to say about the time you spent.

Answer 2

Have you tried talking to your supervisor? It sounds like the best way to approach this would be to try discussing the deadline expectation with him/her, and taking the result of that conversation (if it was positive) to your review.

The easiest way to make your case to your interviewers that the project was too complex for the timeframe is with the support of the person who set the project and timeframe. The best way to have that conversation is with a project timeline you have created that you think would have been reasonable. Present that to your supervisor and try to convince him/her that the original one wasn't workable. If that fails, you'll have to take your proposed timeline to your interview and hope you can convince them.

Answer 3

I voted this question up, partly because I always disliked when professors did things like that back in college, and partly because I have experience decoding/encoding MIDI from scratch (in C++).

The challenge you were given is rather complex and quite involved. I know, because I've attempted to do that for a personal project (I never got around to finishing it, haha). The MIDI spec isn't all that easy to understand. Perhaps it was the intention of your professor to illustrate how unrealistic deadlines can destroy projects. I'd take what you learned from this and present it in the most honest way you can. I'd suggest doing some reasarch on major software failures due to bad scheduling. It may be worth something to point out what you learned from this experience.

If you lose points in the end, though, don't sweat it. We've all lost points on things here or there back in college, and believe me, it's far better to learn a valuable lesson about the importance of good estimates than drive yourself crazy trying to finish on an unrealistic schedule (at least in college - that excuse doesn't always work in the real world, haha). Good luck!

Answer 4

What you could do is make a spreadsheet of each part of the application, how long you determine it should have taken you, and then how long it did take you.

Then you can show how much time, approximately, was remaining when you ran out of time.

This can help you explain what you did, what was remaining, what the roadblocks were and what you learned.

Answer 5

You may well lose grades since you didn't complete the work but I have two anecdotes that may help you out.

Number 1:

On one project I was involved in, we missed the deadline slightly and the quality was not up to par (that was the real issue, missing the deadline was a minor point).

We were all worried about facing the board of the company (this was a high profile project) and didn't know what the outcome would be.

We went in and our boss opened with the line, "We screwed up" which was, we thought, an interesting approach to take :-)

However, he basically went on to explain that it was our fault, that we had committed to the deadline and quality targets, and that we weren't up to the task.

The next phase of his presentation was detailing how we planned to extricate ourselves and ensure that delivery of phase 2 was going to be successful. Then an understanding of any decision the board would take regarding cancellation of the project or disciplinary action.

Basically offering our heads up to the chopping block, so to speak.

I think that the admission of guilt was basically what won the board over. When you accept responsibility for a screw-up, there's a primeval protective need in most people to say it's not as bad as you think. Or at least it certainly put them off their guard.

Number 2:

This actually was a friend of mine whose task for a third-year university project was to build a screen editor for the VAX 11/780 (this was back in the mid '80s). Because there was a wide range of terminals, the University wanted a solution that would work for them all.

It wasn't finished on time but, because my friend, clearly stated what was done and what had yet to be done, they actually got fairly good marks. They weren't developing a product for sale, this was something that could be used for the university but its primary purpose was the education of my friend.

And, it gave them a project to give to someone the following year, thus lessening the load of the lecturers in coming up with more ideas :-)

Again, I think simply because there was an admission of guilt or failure, the examining panel was willing to let it slide.

Summary:

You will find many similar situations in a real work life, real power will lie in adaptability (both yours and the company you're working for). That's because you can't foresee everything.

---

As an aside, the year following my friend's project, they tossed out all the annoying terminals and standardised on DEC VT100 and better terminals, so EVE (the Extensible VAX Editor) worked fine everywhere. I don't think that project was ever picked up and finished.

That will no doubt happen to you quite a bit in the real world as well (projects that you've poured your heart and soul into, being tossed on the scrap heap).

Don't say the deadline was unrealistic, that is an attack on somebody else and unlikely to endear you to them (or the panel).

You could be somewhat more tactful, such as "I didn't foresee the difficulty of the work when I took it on" and put in place a plan for future work (on the project, not something you have to do). Accepting the responsibility will invoke that sympathetic nature in your panel.

This is Social Engineering 101 (which is rarely taught in our institutions, just something you pick up after a decade or two of dealing with people).

Best of luck.

Answer 6

If the grade is not too horrid (some professors are less strict than one you would expect), I don't think you would suffer too much for this.

First, many interviewers don't bother to read your CV in depth, don't think that they'll read your transcript carefully enough to see your project grade. Most companies will not look at your transcript past the GPA and the list of courses that you've taken.

If it does come up, focus on what you have done correctly and what parts worked. Hopefully something in your project was salvagable and useful even if the thing as a whole was not complete. then discuss where the problems were, explain difficulty with API, and explain how you structured your code so that someone (or you in the future) with the appropriate experience could finish it.

Answer 7

I would tend to make the presentation a "lessons learned" presentation "Here is what I set out to do, and why I thought I could do it, and here is what I learned and what I would do differently next time to try to meet the deadline."

Answer 8

If you were forced to use those technologies, AND to code everything from scratch rather than doing mashups of code available on the net, then there's no way you can take the blame realistically -- James Black's suggestion is probably best, Pax's worthwhile too, etc.

If you picked those low-level technologies yourself, and/or omitted searching for parts of the solution on the web and mashing it up, then I'd focus on those aspects -- to get such a project done reasonably fast you should have chosen higher-level technologies and embarked on massive reuse, and that may be the main lesson you learned (if that's the case it will serve you well for the rest of your life!-) -- it's a reasonable error for an undergrad to make (would NOT be reasonable on the professor's part, alas), as it takes experience to understand that higher-level programming is MUCH more productive than fighting with memory management issues and MFC finickytude, AND that reusing good publically available code is far better than trying to build everything up from scratch yourself every time.

Answer 9

It's probably too late for this advice, but nearly always the best way to handle this type of problem is to not wait until the end to try to make a case that the deadline was unrealistic. Communicating that type of news earlier is almost always better - it can result in clarification of the spec (which may make it more realistic), changes to the spec, additional resources being added, or changes to the deadline. The thing is - all of that applies to the real world, too, not just academic projects.

Answer 10

I have seen statistics that approximately 2/3 of major computer projects are scrapped before they are completed. In the real world it is quite common for projects to fail to meet at least one of the tripple constraint (money, time quality).

My recommendation is to not to try and make excuses, unless there was a major factor beyond your control. Rather I would emphasise what you learned. For example did you assume you could find a certain code library that proved unsuitable?

We all make mistakes, what is important is how you learn from them.

Answer 11

Despite plenty of answers already given here, I say: This is real IT life. Underestimated projects with too little time, wrong tools and so on. Would be a nice case-study, but I guess that would not satisfy your professor due to missed topic. So the only choice would be to explain the facts. What you did and what led you in the wrong direction, wrong decisions or whatever problems came up.

Answer 12

I advise you to not blame your supervisor in front of others. If possible, talk to your supervisor before the presentation. In your presentation, focus on the positives: progress that was made and lessons learned, along with ideas and estimates on what it would take to finish it. In an equivalent business situation, your management is going to be more interested in what needs to be done now rather than hearing people blame each other. I would expect it to be similar in an academic environment.

Answer 13

It's school, show how much you learned messing up. Dig into the details and come up with one helluva knowledge gaining experience. That's what school is about, asking questions and wrestling with the answer.

Maybe your prof expected you to find some pre-existing IO for the MIDI spec and call it from your program. Explain that you tried to work the problem without any outside help and learned that it's better to determine ground rules for fair usage up front (reinventing solutions isn't very time efficient if it's public domain).

Being able to understand the format of MIDI would be necessary but starting from scratch was overly conservative.

Answer 14

I've sat on a few of those panels, and an undergrad EE project which achieves anything at all is a heartwarming experience.

Present what you have done. Start with an overview. Include the things you have achieved and the things you tried which turned out to be dead ends. Finish with a brief summary of what you'd do next if this was an open-ended job rather than a close-ended project.

Don't concern yourself with blame or otherwise. Don't bother apologizing for lack of polish, it is the nature of projects. What did you learn from this project.

Pick some examples which show off what it can do. Demonstrate those examples. Don't bother going into details of what it can't. Bring screenshots just in case the whole thing SNAFUs. Don't mess with it the night before, even if you do have version control.

Relax, Breathe, Good luck!

-----N

Answer 15

Be polite, but gather evidence to support your case. Show that what you have achieved meets the spec so far. The problem is that it is incomplete, not that it is wrong.

Answer 16

You can turn this around, and this might even be what they are after. You need to explain what you have done, how long it all took you, then what part you are stuck on (probably converting the midi file to notes?), how far you got on that, some failures you had. And best of all, a plan on how you would finish the project, and how much time you think it would take. This can be the most important part, and will really prepare you for real life.

Of course, your prof could just be an asshole as well. How does you assignment compare to others handed out?