Franske ITC-2900 Assignments

From ITCwiki
Jump to navigation Jump to search

Statement of Work

After your team has selected a project to work on your next objective is to develop a Statement of Work (SoW). The SoW is your opportunity to take the very high level description of the project you were given and turn it into a more detailed description of your specific goals, operational procedures and timeline for the project. In order to successfully do this you will need to meet with the instructor and/or sponsor of the project and any other involved or related parties. One way to think of the SoW is as part of the contract you, as a consulting team, have with the project sponsor and ensure everyone is on the same page.

Goals for the SoW:

  • Clearly define the purpose of the project / problem statement in your own words. Make sure that you understand what is important to the sponsor.
  • Give an overview/background of the technology involved. Make sure you have a basic understanding of the concepts you will be investigating and the problems you might encounter. Show that you have already started background research on the project.
  • Define the scope of work and deliverables. What will you need to do for the project sponsor to consider this a success?
  • Describe any resources or cooperation you believe you will need in order to be successful
  • Develop a plan/schedule for your project, this can be updated as needed but you need to know when you are going to try and have certain phases of the project complete.

SoWs should be written in a narrative (paragraph) format (with the exception of a timeline) and should typically be about three or four pages single spaced. Your SoW will be graded based on how you meet the goals for the SoW listed above as well as professionalism (grammar, punctuation, etc.)

Google "statement of work" for more information about these as well as some examples.

Project Work Log

  • Each INDIVIDUAL in your group must keep a work log indicating what was worked on, when, and for how long. This should be written in narrative (paragraph) format. It must be turned in at the end of the course but must be kept up to date throughout the course. Your instructor may ask to see a copy of your work log at any time.
  • You should also keep a separate log of the hours you INDIVIDUALLY worked on the project in a spreadsheet by date and category so that they can be graphed.
  • As a three credit course this course is estimated to require about 9 hours of work per week from each student, or about 144 hours over the entire semester. The purpose of your spreadsheet is to track how many hours you are spending on the project. The purpose of your work log is to provide a good place to save links to reference material, notes you want to remember about what you've done, and to justify (back-up) the claim of how many hours you spent. Of course, if your group does phenomenal presentations and whitepaper and everyone appears to have contributed equally we're not going to look too closely other than to see that you have kept a log. However, if there are any issues with your presentations or paper (and there's almost always something that could be better) or someone people in your group seems to have contributed much more or less than others the work logs can give important data (along with other evidence) of what went on and so can influence other areas of your grade as well. Bottom line: be thorough and dedicated to keeping good logs!
  • Tip: Keep your individual narrative log in a single word processing document so that you can submit the entire log at once and not have to combine multiple files together into one to submit it.

Group Meetings and Minutes

It is expected that your group meets at least once a week (more is always encouraged) to work on the project and to update each other about the status of your individual parts of the project, demonstrate and test systems, etc.

Someone in your group needs to take meeting minutes at these meetings and accurately capture the status of the project as well as the discussions and contributions of each team member. These written reports need to be submitted to the instructor each week as well as submitted en masse at the end of the project. These minutes should at the minimum contain a list of the group members present, the location of the meeting, the time the meeting started, the time the meeting ended, a report from each member about what they have done since the last meeting, a summary of what was discussed, and what each member agrees to work on before the next meeting.

Tip: When you submit them at the end of the project you'll want to have them all in one document so it's easiest to keep a running document with all your group meeting minutes throughout the course rather than having to put it together at the end.

Progress Updates

  • At least one representative of your group must meet weekly updates with the instructor to discuss the progress of your group.
    • You should discuss your current project status amongst your group each week before meeting with the instructor
    • Meetings should be scheduled in advance
    • Meetings may be held over the phone, by web conference, or in person
  • At least once every two weeks your entire group must have a meeting with the instructor where your progress is discussed
    • You should discuss your current project status amongst your group each week before meeting with the instructor
    • Meetings should be scheduled in advance
    • Meetings may be held over the phone, by web conference, or in person
  • Missing meetings unless it's been previously cleared with the instructor, will result in lower grades in this category for you individually and/or your entire group. Also, this is not just a participation score, the meetings need to provide valuable information about things going on in your group and show you are making adequate progress towards completion of the project.

Presentations

Your team will be presenting twice in this course.

YouTube Presentation

Your group will create and upload a preliminary results presentation to YouTube about a week and a half before your final presentation where you will be presenting broad information about what you did to an interested audience. These presentations will be about 12-15 minutes long and should be engaging, interesting, and informative to people who might be searching YouTube for information about the topic of your project. These videos should NOT just be a narrated power point presentation, that is not very engaging and interesting. Would you stop to watch someone give a power point presentation on YouTube? You should probably watch some popular technical presentations on YouTube before you create yours and try to incorporate some of the things that you think makes them more interesting to watch. Demonstrations are usually one good way to keep things engaging. Clearly explaining what you are doing and why at each step is also critical to having a good presentation.

The Open Broadcaster Software is free, open-source, cross platform software which allows you to capture input from webcams, microphones, and your screen to create videos. The Shotcut or OpenShot free, open-source video editing software programs allows you to edit and title your presentation. You can feel free to use other tools, but these are free and cross platform.

Final Presentation

At the end of the class you will give a final presentation of 20-25 minutes to an audience including other ITC students, faculty members, college administration, advisory board members, and employers. You should be prepared to discuss the background of your problem, the methodology you used, your testing, results, and conclusions. At the end of your presentation you should be prepared for a few minutes of Q&A from the audience as well. A copy of your presentation in electronic format must also be provided to the instructor.

Final Written Report

At the end of your project you must compile all your work into a technical whitepaper and submit it in paper and electronic format to the instructor. These whitepapers are typically 75-100 pages in length and include:

  • Table of Contents - Help people find the parts they're interested in
  • Executive Summary - Provide a summary of about two pages giving the highlights of everything else in the whitepaper, especially method, results, and conclusions. This should make someone interested in this topic want to read your entire whitepaper or help them find what they're interested in specifically. Hint: Write this after you finish the rest of it
  • Thank you's/dedications/etc.
  • Statement of Work - Possibly modified and updated as needed. Introduce and explain the problem/project and how you are going about it
  • Background/Research - What technologies did you look at? What important concepts are there to understand about this topic? Think of this part as a traditional research paper you might write for a composition course.
  • Methodology - how did you build your test environment, how did you do your testing, what criteria were you evaluating and why (hint, your research should tell you what criteria is important and how to measure it), lots and lots of documentation so that someone else reading this could duplicate your results
  • Results - What did you find when you ran your tests. No opinions here, don't analyze the data, just provide it
  • Conclusions/Analysis - Provide your opinions here and back them up with the results you gathered
  • Appendices - Include any critical technical documentation of your configurations, special/detailed setup instructions for tricky things, etc. in appendices at the end of the whitepaper.

These sections and exactly what each might include vary from project to project so be sure to consult with your instructor and take a look at the many sample papers from previous students to get an idea of what this might look like.

Participation and Peer Evaluation

At the end of the course you will be asked to evaluate how well each person on your team (including yourself) contributed to the effort. Do not let these evaluations be a surprise! If you are having problems with team members you should talk to them about it first and if things do not involve make sure the instructor is aware of it well before the end of the course. The quality of your peer evaluations (how well you write up evaluations of other group members and yourself) will be graded out of 20 points in the "participation and peer evaluations" section of your grade.

Because group work is a key component of this course your grade will be adjusted based on your performance as a member of the group. This is done by collecting peer evaluations at the end of the course and by observation of the instructor during progress checks. Your grade on the group portions of the course (Statement of Work, Presentations, Final Written Report) will be multiplied by a "peer adjustment factor" ranging from 0% to 100% where 100% means you were equal in your contributions to the group compared with other group members and 0% means you had no participation in group work.

For each group member, including yourself, you need to turn in a peer evaluation. Below are six categories as well as some questions to get you thinking about how well people participated in your group. You should write an evaluation for each group member (including yourself), covering each of the categories, as well as any general comments. Each category should be clearly identified and addressed in paragraph form with at least a few sentence. For most people these evaluations end up being about 3/4 to 1 page in length per group member if single spaced with category headings.

Here are the categories to discuss about each person:

  • Contributions: Did they regularly provide useful ideas, insights and research to the group? Were they a leader? How hard did they try to help the group effort? What specifically did they add to the group?
  • Time Management: Was their time well used throughout the project? Did deadlines have to get adjusted because work was not done on time? How did their ability to get things done affect the group?
  • Preparedness/Attendance: Were needed materials (VMs, equipment, etc.) that were the responsibility of this group member available and ready when needed by other group members? Was the group member on-time and ready to work during group work sessions?
  • Attitude: Was the group member unduly critical of the project or the work of others in the group or did they support the group and engage in the project?
  • Teamwork: Did they listen to, share with, and support the efforts of other group members? Did they try to keep working with others on the team or did they “go it alone”?
  • Quality of Work: How was the work done by this member? Did other group members need to check and correct problems regularly?