Project Proposal

This document outlines the project you will pursue in this class, sets up the team, and describes the project goals, risks and resources. The user should receive a copy of this document as well. It should be about 2 pages. It does not need any technical details but is rather a very rough sketch. In business, your time would cost money, so this would be given to your company and maybe a client as a discussion document for deciding whether to put any resources on pursing the project to the next level. So, its goal is to convince people that the project is worthwhile and has a realistic scope.

Include the following sections:

Project name - Just choose a name for the project.

Team description - Include your classmates, their roles in the project (at a very high level), and the people involved outside our class. For outside people, please include their company name, position, email and phone number. Explain the time commitment you expect from each member.

Project rationale: Explain why this project is being done and who will benefit. Do include one reference to some research source that indicates such a project is helpful.

Project description: Explain what will be done in this project in some detail. Include the tools you expect to use, though you may just say that you know you will need a certain tool but want to research which one is best.

Expected challenges: Describe all the unknowns and risk factors. Having to research whether to implement an existing application or buy a new one would be mentioned here. Having to learn a new technology or tool is another risk factor to mention. Describe also the tasks that will be difficult or very time consuming to accomplish even if you do not think they are risk factors.

Resource request: List any additional resources you need from Adelphi or from your users. Describe any changes you want to make to the deliverable schedule set forth in the assignment page. Remember that I need to agree in writing to any changes.

Rough timeline: Our class has deliverable requirements, but the project may have its own needs as well, including a need to deliver some of the documents earlier. Include at least 4 decision dates or major delivery dates and the date the project will be installed at the user site.

References: Bibliography of any references used in this document. At least one must be used. Annotate the reference by describing a short summary, its credentials and why you used it. This can be done in about 4 sentences.

How to respond to my comments:

General: Your project proposal is meant to convince someone to spend money on your programming time. ( I know you are currently working for free, but that is not the eventual goal.) It needs to be a professionally written document that makes the system clear to a reader that may not be very interested in your project. The proposal should answer all the questions I asked in my comments so that if I reread the proposal I would not have had to ask the question. (In a few cases, you can ask me whether an answer may not belong in the document.) Never write "of course".

Team Description: Every team member needs a role description and contact information. Some user name is required.

Rationale: Remove yourself from the rationale. The reasons should be business reasons, not because you want to do it or will learn. (I understand why you put that in, but it does not belong. Those reasons are reflected in your personal goals.) There should be no we, I , you, us, our throughout this document, but you can use the system, a module or the system name as an actor. You can also refer to the programming team, but sparingly.

Give your user some context on what your project is about. Assume the reader has never spoken to you before. If it is a project meant for Adelphi, say so.

Your rationale should answer the business question of WHY this is being proposed.

Project Description: When I finish reading this I need to understand what you intend to create. Include the user experience at a high level. What device will they use to access the system? What will they do and then what will the system give them? No screens are needed here, but a description of the interaction is very helpful. It may be helpful to think of the system as a living being when you describe this. Use system or app or the full name of the system or name the portion of the system instead of the team or programmer. Give an idea of the most stripped down system you will deliver first and also of the final system.

What are the separate parts of the system? A separate part may be designed for a different user type, or may need to reside on another piece of equipment. What hardware are you planning to use? What operating systems are you planning to run this on? What languages and tools will the programmers use?

Challenges: The programmer team can be mentioned here. Clearly state the risk and how you will mitigate the risk or approach that challenge. These should be two separate sentences. Make each challenge a new paragraph. Do not say more problems might arise because that is not helpful information.

Resource Request - Be very clear about how often and in which time periods you need to meet with the user.

Timeline: The timeline needs delivery dates. Include the first code delivery and final code delivery, with some indication of what each delivery contains. Aim to be live May 7 at the latest so you can shake out issues. For new products, plan to assemble a room of about 5 users to test for an hour.

Citations: Need full MLA (or other guide) citations with annotation (3 sentences minimum) and in text citations.

Next step:

Redo by 2/17 - not able to hand in again after that.

Give this to your users after your resubmission.

The next system requirements document should be a natural result of your discussion with the users. You can start exploring the technologies you find to be risk factors as well to be sure that you want to include them.