Due: pairs by Tuesday, April 1, 2014, 10:30
Due: Wednesday, April 2, 2014, 23:00
Presentations: in class, Thursday, April 3, 2014 and Friday, Apr 4, 2014
Project preferences: Monday, April 7, 2014, 11:30
Contents:
This assignment must be completed in groups of 2. (At most one group — the last one formed — may have 3 students.) Update the class wiki with your pairs. If you do not yet have a pair by Tuesday, then you must come to section on Tuesday to meet with other students who have not yet formed a pair.
The goal of this assignment is to develop great product ideas, thinking primarily from the customer's view but also considering feasibility; and then to present those ideas for others to think about.
A wealthy software entrepreneur is looking for ideas for new software products, and has enlisted the help of CSE 403. Your job is to pitch your idea in hopes of getting funded. You will also be pitching your idea to other team members, trying to attract them to your project. A project proposal like this is sometimes called a Lifecycle Objectives or “LCO” document.
You are allowed to propose whatever project you think is interesting and valuable. Here are some constraints.
You will produce two deliverables for this assignment:
For anything that you submit in CSE 403, place partners' names and UW and CSE netids on the first page (or first slide).
You will submit both deliverables electronically, in PDF. Each deliverable should include at least one figure or diagram (possibly the same, possibly different).
The files you submit should be
named student1-student2-doc.pdf
and
student1-student2-slides.pdf (where the student1 part is your CSE NetID), and exactly
one member of the team should actually submit both artifacts.
The two deliverables should address similar issues, though they should do so in different ways, since different formats demand different ways of conveying the same information. You should discuss your vision, your software architecture, and risks. Some of the points you should address include the following. This is not an exhaustive list; we expect you to think in this class, not just follow outlines that are provided to you.
You will present your proposal to the class. All group members must participate in some way in the presentation. You should practice your presentation ahead of time. You will have a time limit of 3 minutes, strictly enforced. Taking less than 3 minutes is perfectly OK. Padding out your presentation to 3 minutes to run down the clock is not OK.
Some projects will not go beyond the presentation stage, and others will be staffed and actually implemented.
After viewing all the proposals, you will have a chance to talk with other members of the class, to self-organize into groups, and to rank the proposals that you wish to work on. You will submit:
If you submit a list of project partners, then everyone else whom you list must submit an identical list of sorted project partners, and must submit an identical list of ranked projects. Otherwise, the staff may interpret, or ignore, all of those people's requests (and grade you down for not following instructions).
Catalyst might not permit you to change your submission, so try not to submit until after you have made a final decision. If you have to change your decision, then tell the staff.
After receiving your requests, the staff will organize all of the students into final project groups. We will use the following criteria.
Your grade is not based upon whether your project is chosen (by other students or by the course staff) to be implemented. Rather, your grade is based on the quality of your materials and your presentation. We will be looking to see that you have addressed the identified project elements, that you have made reasonable judgments concerning them, and that you have organized and presented your proposal well. Remember that this delivery is the basis for the class to decide which products to develop and deliver this term.
This section gives some tips about your proposal, based on what students have done poorly in previous quarters. Don't repeat these same mistakes! (Not all of them apply to the document you will write.)
It is essential that you clearly indicate what the problem is, and why it matters to potential users of your system. For example, how will the system change the way they they perform some task? Too often, this most important part of the presentation was not clear.
Since your proposal should focus on the problem, it's essential that at least one of your diagrams be a mockup of your proposed UI.
You have a limited amount of time and space, so use them well.
Don't make the mistake of diving into too many technical details. You can say a few words about the underlying technology, but your first priority should be to convince the sponsor that the project is interesting. Only after that is it worthwhile to say that it will be possible (or even fun) to build.
You must discuss alternatives. (When you prepare your presentation, you should spend nearly as much time understanding what already exists as you do coming up with something new.) There is no point re-inventing the wheel. Don't propose a web search engine without knowing that Google exists. No matter how many times we state this, students repeat similar mistakes.
To be funded you will need to explain clearly what differentiates your product from the alternatives. And, as a more minor point, the project should pose interesting design (or other) challenges from a software engineering point of view. For example, it would not be appropriate to build a sports discussion website whose only differentiating factor is weekly live chats with Russell Wilson.
Be concrete, and give examples — whether you are explaining a problem or a solution. For example, don't give generic risks that would be equally applicable to any project.
Do not omit competitive analysis. This is crucial. Don't belabor features that are standard in existing packages. Indicate, for each feature (or combination of features), what is novel about it.
One of the most serious risks for many projects is where to obtain the data. Some projects would only be successful with the network effects of a large customer base, and would not be compelling otherwise. In other cases, data may not be available, or is available in a wide variety of different formats. You should not assume that you're going to solve the natural language processing problem as some part of your project, and you are likely to find that screen-scraping from multiple websites is more difficult than you imagined. In any event, you need to give a clear indication of exactly how you're going to collect the data.
Make up a short, catchy title for your project and use it as the title of your document and your slides.
See Michael Ernst's advice on giving a technical presentation. Most of it is applicable to your presentation.
Common problems with slides:
The slides should be simple and readable. The last thing you want to do is to distract the audience from the content with extraneous ink on your slides. It's unprofessional, and any intelligent audience member will see it as an attempt to dress up inadequate content.
Don't read from a script. If you need a script, you don't know your material well enough.
Don't sound bored. Do look at the audience: not at the laptop, and definitely not at the slides which puts your back to the audience. You can look at the slides occasionally but shouldn't need to read from them as a script.
Don't put your hands in your pockets. It makes you seem unengaged, and by constraining your body it actually reduces your energy level.
3 slides means 3 slides, including the title slide if any.
Use color effectively. Especially if you have a lot of text (which is a problem already) then it is good to highlight the key points to draw the reader's eye and indicate what really matters about the slide. Too many of the presentations used only black.
Sample proposals from previous quarters can be found here:
3/30/2014: Reduced maximum number of slides from 4 to 3. (3 slides including the title slide should be plenty.)
4/3/2014: Changed project preferences survey to be due immediately after the grouping session, which is required for anyone who has not submitted the project preferences survey by the beginning of the grouping session.