CS486 - Senior Capstone Design
Guidelines for Project Mini Intro

Overview

Your first task after taking on any new project is to find out as much as possible about your client and the overall shape of the product to be built. Your skeletal starting point for this is the project description that grounds the whole project, but this is really just an outline; it doesn't really paint a complete picture. In your first interviews, you'll want to dig deeper quickly to figure out, in essence, how the client's business really runs, what the hangup is and how it impedes progress for the client, and what is envisioned for you to build that would solve those problems. This is not the place for *detailed* requirements; you'll be working those out over the next month or two in further interviews. What you are really doing here is working to understand the client's business process, and map out the broad strokes of the product...so that you'll know what areas to flesh out in future requirements discussions.

This assignment assumes that you have done this preliminary requirements analysis with your client in your first meetings, and asks you to summarize it efficiently and professionally for the rest of the class. In this way, we all have a chance to learn more about this year's projects, it provides a first chance to hone your presentation skills, and it forces you to think in a structured way about the project you are tackling.

The Assignment

Each team will create a five minute summary presentation on their project. The biggest challenge here is to keep it short and sweet, meaning just enough explanation to get the project outlined clearly, no lengthy digressions, but complete enough to cover all relevant aspects of the project. Creating this sort of "elevator pitch" is a real skill (there are competitions for it, see YouTube) and, while you likely won't be giving many of these in an elevator, being able to describe/sell a concept very compactly is an awesome skill to have.

It's up to each team to decide how to tell their story most effectively (it has to *flow* and engage us!), but here is an outline to get you thinking along the right track:

1. First quickly intro the team, the name of the project you are working on, and your CS faculty mentor. 15 seconds!
2. Next comes a critical part of the talk: you need to launch the talk and get the audience hooked. You need to be compelling...but you also need to keep it compact, so that you can get on with the meat of your talk. The key is to connect with the large "big picture" area/issue that your client's business/work is embedded in...something that everyone in the audience has heard of, is likely to care about, and can relate to. Example: your project is building a mobile app for a client that wants to use it to collect real-time data on lifestyle (exercise and eating) data for her study on obesity. Having this tool as a smartphone app will let enormous amounts of data be collected over large timespans very easily!
   • Lame intro:

     "Our client is Fuji Manchu and she is a psychologist. She needs to collect data about the lifestyle habits of obese people and we are building her an app for this".

     This is accurate, but casts the problem so narrowly that everyone is going "Who cares? I'm not obese...and this software seems like it's use-once and then throw away for this study. Not interesting".
   • Much better intro:

     "Obesity is becoming an epidemic in many 1st-world countries around the globe. In the US alone, obesity rates are approaching <do your research> percent of the population, a 5-fold increase over 1990. Obesity can have serious health effects like <name some>. Obviously, obesity is an avoidable condition, but many diets and programs fail to have any significant effect. What is needed is a comprehensive study of what psychological factors lead people into obesity-prone lifestyles. Only in this way can we better understand *why* people become obese, and thereby design programs that are effective at helping people return to a healthy weight. Our client, Fuji Manchu, is a psychologist at NAU who is working on developing this understanding. A key challenge for her is getting the high volume of lifestyle data --- meaning when/how people eat and exercise, along with other indicators like mood, attitude, energy levels. In the past, this was done using paper questionnaires handed out over time to a study cohort; this was of course quite limiting and effort intensive, feasible only for low numbers of study participants over relatively short time periods. The smartphone revolution has provided a means to easily and nearly continuously gather large amounts of data from very large study populations. Our project is aimed at creating an Android app to explore this new potential."

     This intro is *much* more compelling and interesting! It connects the work of the sponsor to the broad social issue that motivates her research. Who hasn't heard of the obesity epidemic. With this intro, you've staged your project as a valuable tool aimed at revolutionizing obesity research and thereby helping with a national level issue! How interesting!
   • An even better intro. The last one was pretty good, but why stop there? Yeah your client just cares about collecting obesity info, but your team has done its homework into the clients area, is very ambitious, and is thinking bigger: there are LOTS of studies that could be done on LOTS of population health issues: diabetes, alcoholism, depression...the list is endless. With just a bit of design cleverness, your new app could become *THE* go-to data collection tool for *any* such study! With this in mind, you could start

     "Scientific research is driven by data, and research into population health issues like obesity, diabetes, depression and other common conditions is no exception. In the past, such studies were carried out on relatively small populations, either using in-patients in clinics, or some study group within the general population. For example <sketch/mention a concrete example of a study that came out recently>. Gathering data involved interviews, questionnaires, or phone calls to participants. Obviously this sort of data collection is very effort intensive for both participants and researchers, meaning that studies have generally been small and of very short duration. The smartphone has changed all of this...(etc etc, continue on as in last example)".

     See? Now you have intro'd the tool you'll be building as not just a revolution in the study of obesity, but as a fantastic general purpose "scientific research" app that could provide data collection for *any* population health issue. You are helping your client, sure...but it goes way beyond that. Wow! Fascinating...
   In sum, your first minute after you intro the team is an absolutely critical time to "hook" your audience by showing them how important/impactful your software solution can be. Make it count! Fail here, and it won't matter how well-done the rest of your talk is...the audience just won't see why they should care.
3. As you work your way down from big picture, to how the exact work/business your client connects in within this story, you'll want to introduce your client. Say who it is, (name, company, and any relevant personal background. A headshot and a logo is nice) and connent them into the big picture discussion you just start. For example, if your client makes cloud computing infrastructure software, you will have started by painting a big picture where you talked about the huge growth and impact of cloud computing. After you've established this broad picture, you might narrow things to your client with: "Our client's company is generally in the business of providing cloud asset management services". After you've introduced what the client does overall, a concrete example is often a good way to explain this and make it real for the audience, e.g., "For example, suppose you are a small company selling widgets and you want to cloud-host your online store, but are stymied by the complexity of cloud services. You could contract our client to..." and so on. Plus, as a nice bonus: you can come back to and continue with that example in the next steps!
4. Now that we know what your client's business is, we need to know more about *how that business works*". A great tool for this is giving and information/workflow view of the client's business process. A flow diagram is great here, and you can then just walk through it verbally step-by-step, explaining the client's work process. If you intro'd a concrete example before, you could re-use it here, showing how the work process accomplishes the example task. This is critical to understand because next you're going to...
5. ...explain what is broken/wrong/deficient...what is it that made your client wish for some new/better software? Because you've clearly explained the work process, you can simply point to the part in it that is slow/broken/efficient. Give a general verbal explanation of the problem, then get specific: bullet out a few specific weaknesses/limitations of the current system that are the root motivation for your project.
6. Now intro your solution. Describe the solution in broad outline, e.g., "At this early stage of our understanding, we envision solving this problem with a sophisticated WebApp that handles the <whatever for the client>. In this app, users could log in securely, then do <x y and z>". Again, follow that overall intro through with your concrete example. If you do this right, it will be obvious to the whole room that your solution very clearly does brilliantly solve the problem/deficiency you just described. End by bulleting out the key features of your solution that specifically address the problem/broken bullets you had in last step.
7. Last, sketch us your "Plan for development" for your project. This is just a few bullet points saying how you will progress on:
   • Requirements acquisition/refinement. What is you plan for building and fleshing out requirements? Weekly client meetings? Do what? For instance, maybe each week you'll have draft of the requirements doc and/or sketches of the process data flow, the data model, whatever -- and then you'll go over that and try to refine it iteratively? What is you PLAN? Just random conversations isn't going to be very effective.
   • Technical Investigation. What are the main technical challenges or "puzzle pieces" that you'll need to design/address to do the project (e.g. RESTful API, reactive web-base front end, doing <x> on an Android platform, etc. This list will vary based on project. It's up to the team to identify what the key technical challenges and design decisions they'll need to resolve to get this done. You should boil this down to a list of 3-5 broad elements that you bullet out and intro for us. For each one, what is your PLAN for investigating and analysing choices? This is essentially the outline for your Feasibility Study, which is the next milestone!
   • Other issues. You might have issues that you will need to investigate as part of the requirements/design process. In some projects, for instance, it is critical to do an investigation on competing products to clearly see what they provide and where you can beat them. Or maybe there are legal issues to investigate and consider.
   Remember: your task here is to impress us with your insightful analysis of the problem, and confidence-inspiring plan for tackling it. This will force you to (a) really focus your initial meetings/inquiries with client; and (b) to think very carefully about what your plan/tasks are in the next months.
8. Closing. This is an often-botched area. You can't sell something if you just end abruptly with a whimper. Always have a conclusion slide where you summarize things briefly and create a sense of confidence and excitement about your team. So maybe

   In summary, we are Team Foobar, and we are working to create a sophisticated web-based assett manager for our client, John Doe who is head of <whatever> for the <whatever> division of Company X. They have some real challenges in the area of <whatever> but we are confident that we on track to provide them with a very effective solution. Whereas before it took them <x> long and cost <y> money to do <whatever their main task is>, our solution should be able to cut this to <z> dollars and <t> time. Of course, Joe Doe and Company X aren't the only ones moving to cloud-based systems; we suspect that literally thousands of companies are facing the same problem, and <explain how your product could have broad impact/makes millions, etc>"

   Note the key pieces in the above: summarize what you are doing, try to place a *value* on that for the client, and try to speculate on broader applications (if applicable).

This is a really time-limited format, so there is no particular requirement that all team members actually present (though of course all should be involved in creating the presentation). If you can orchestrate speaker changes smoothly and instantly, however, you are welcome to do so...that can often be a cool effect.

Finally, you will want relatively few slides (I usually shoot for 1-2 per minute max) but ones that really *support* what you are saying. In particular, this means lots more pics/diagrams than text. If you're explaining a system configuration, draw a diagram for it and *talk* us through that diagram. If you're describing a workflow or process, sketch it out for us and walk us through it. Bullets with text are good for academics outlining a lecture, but they should be used sparingly in a technical presentation...they don't help us *visualize* processes or system configurations.

Deliverables

Live 3-5 minute presentation in-class. Slides in pdf format must be submitted to Canvas and brought to class on a memory stick (two memory sticks are better). There will be little time between presentations so there won't be any time for storage issues.