Now what? 1

 I have short-listed projects I am interested in  I know the types of projects I would like to pursue  I have an idea of the resources available to me for the Case Study I intend to use  I have an idea of the timeline for deliverables 2

1. Deliverable #1: PROJECT PROPOSAL DUE DATE: 28/08/12 2. Deliverable #2: LITERATURE REVIEW DUE DATE:20/11/ Deliverable #3: INTERIM REPORT / DRAFT CHAPTER DUE DATE: to be announced 4. Deliverable #4: FINAL REPORT & SOFTWARE PRODUCT DUE DATE: to be announced 3

4

5 Title of Project Choose a good title for your project MY PRODUCT? Is it original? Does it adequately demonstrate my research theory? WHO ARE THE STAKEHOLDERS? Who will benefit from your research? WHY THIS PROJECT? Why have you selected this project? WHAT’S THE PLAN? Objectives? Tasks? Activities? RESEARCH? RESEARCH? Where do you start? DEADLINES? DEADLINES? When are the key deliverables due? Am I on schedule? WHAT DOES THE PROJECT SEEK TO DO?

6 Title of Project MY PRODUCT? WHO ARE THE STAKEHOLDERS? WHY THIS PROJECT? WHAT’S THE PLAN? RESEARCH? RESEARCH? DEADLINES? DEADLINES? WHAT DOES THE PROJECT SEEK TO DO?

I HAVE A PLAN

8

 A project proposal is the first important document that you will produce for your project  Defines the specifics of a potential project to persuade your Supervisors to “buy-in” and approve research project  Concise, efficient writing  Format – refer to template  Outcome – convince Supervisors that your research project is justified  Wording needs to be both informative and persuasive  It includes your plan of how you will go about your project 9

 The project proposal demonstrates that:  you have thought the proposed project through  it is achievable in the time available  it is of at the right academic level  it is has the right content for your programme 10

 A Title, your Name and Programme  A list of Key Words or Phrases  A Brief outline of the Project (the Aim) Describe in half a page what you plan to achieve in your project; remember the basic breakdown into three tasks “What will I research”, “What will I build”, “How will I evaluate it”.  A set of Objectives Break down your Project into smaller objectives 11

 A list of lecture courses you have taken that are directly relevant Web Engineering …  List all needed resources hardware, software, …  Your references Useful books and journal articles.  Critical success factors What are the critical activities, people or resources that can make or break your project ? 12

 Your research and reading will help you identify a list of keywords that are directly relevant to your project e.g.  Database integration, native XML databases, security, access control, hotel management systems ….  Once you have a good keyword list you can easily construct a title by making use of the really important keywords 13

 Tell the story of the project in a concise logical way – think of how you would describe it to a friend over a coffee.  Focus on the essentials of your project – those things that your project will deliver.  Check back on this once you have written down your objectives (next …) 14

the SMART acronym reminds you that objectives must be:  Specific – An Objective can't be vague – be specific  Measurable - Define a method of measuring the objective so you know when it is achieved  Agreed-To/Achievable - you and your supervisor need to agree to the objective, and it also must be do-able  Realistic/Rewarding - It must be a realistic objective, and it must make sense to do it  Time-related - without a schedule and due date, it will just keep going, and going, and going... Courtesy Wikipedia 15

 All your Objectives should have clear titles e.g.  “Research current hotel management systems systems that attempt database integration”  Objectives should all have deliverables, i.e. they can be measured – (how far have I got?)  you will know when the objective is achieved because you will have the deliverable ready  Objectives should be agreed with your supervisor  (but you will do all the work )  Objectives should all contribute directly to your project and getting a good grade  Objectives should all have a time schedule 16

Anything complicated benefits from being split into smaller pieces; (divide and conquer).  Your Research objective could split into  background ideas, requirements analysis, problems, technology review, data gathering (e.g. on similar products, applications, sites) …  Your Build objective could split into  visual design, functional requirements, UML diagrams, implementation issues …  Your Evaluate objective could split into  testing, usability, security … 17

 You choose sensible objectives use verbs like: to investigate, to study, to develop, to analyse and so on  “One objective is to read that ASP.Net book”. “Investigate use of ASP in “topic area” websites”  Each objective or task must  Have a set of known activities (e.g. using electronic databases, creating UML or code, testing …)  Have a set of deliverables (e.g. the background section of the introduction chapter, a set of Use Case, a Class Diagram …)  Once you have defined an objective, estimate how long it will take you to achieve it (i.e. have all the deliverables)  Add all your timescales together into your Project Schedule. 18

 A good proposal will include a schedule showing how all the individual objectives fit together and timescales add up  A Gantt chart is a good way to do this  If the total time is too long then you need to reduce the scope (how much you will do) of some of the time-consuming objectives 19

 A project proposal should be consistent  So look carefully at all your objectives and their deliverables  When they are all complete you should have finished your project with something researched, built and evaluated.  When you have completed all the objectives you should have achieved your Project Aim! 20

 Whenever you are uncertain as to whether something should or should not be included in the project, refer back to the Project Aim.  Ask yourself whether a proposed activity supports the Project’s Aim. If it doesn’t then decide whether you really need it. 21

Yes! For your project to have a high probability of a success, you must have produced a good proposal and have  defined a good set of objectives  identified how these objectives will be met  made an assessment of the resources required to complete the project  and have shown it to your supervisor 22

 Work on your project proposal (outline + objectives + schedule)  Show a draft to your supervisor and get his/her comments  Submit it as a word document via the Project web pages  A plan can always be modified and improved, but always discuss changes with your supervisor 23