Part 1:  Things to watch out for in your Proposal

Below is a summary of issues that are common to all projects, as well as issues specific to projects with a focus on Electrical, Software, or Mechanical Development.   The discussion on Commercial Products can also be used when designing any product which will be used by the Project Sponsor, the general public, or anyone else that is not a former member of the student team.

General Content Issues

• More planning and designing done for the proposal There are aspects of the design for your project which should be done during the proposal-writing stage, not left until January (for  459 groups).
• Not enough detail about proposed solutions (sketches, component I/D, estimated performance, specific algorithms used during the project)
• Not enough general background research. In particular, not nearly enough research on existing and state of the art techniques or solutions.
• Overambitions – too much work is required to complete all tasks, and the project scope too broad for ~120 hours of work per team member.
• Technical content not appropriate for 459/479 (either far too difficult given the time constraints, or far too easy given the skills and backgrounds of fourth and fifth-year Engphys students).
• Scheduling does not include midterm times. – allot extra time for your schedule to accommodate your other classes.

Projects with Mechanical Design

• What are your constraints? Every project has constraints (funding, time, performance, size), but you should have a discussion with your project sponsor to make it very clear what the highest priorities are for the system.  Is a fully-working system more important than having one highly developed component within the system?   Is it more important to reduce machining costs or to keep the size of the system small and light?
• Understand how well your mechanical system quantitatively need to perform. You should be able to define some clear performance metrics for your system (maximum deflection, maximum response time, maximum weight and size).   These performance metrics help set the parameters for your design.
• Identify external groups to help refine your design.   Hopefully you aren’t just reliant on your Project Sponsor (and the Project Lab) as your sole sources of information and design guidance.  Who else can you consult on your design?  How can you get some organized feedback on your system?   Can your sponsor help find others to review your designs?
• Identify expensive components and machining processes, in terms of money and time.    Find the most “expensive” parts of your system and use those to ensure your design makes sense for the project size and scope.   We have had groups with designs that rely entirely on super-expensive If it doesn’t fit in with the 80-120 hours for the project course, find some other ways to solve the problem.

Projects with Electronics Design

• Present existing circuit designs. During the proposal stage, it is highly recommended to find as many sources of information as you can for existing circuit designs, be it for signal conditioning and noise rejection, efficient power regulation, or fast digital switching designs.   Do the research during the proposal stage, and search hard for useful examples now.
• Identify the key components in your design.   If you are able to identify and select key components now, you can look through datasheets and reference guides to find out how best to use the components, and how to avoid common problems.
• How will you fabricate your electronics?We have been getting improved results with our PCB milling machine, combined with our laser cutter to make PCB stencils to mount surface-mount components.  You may want to make use of these resources, or possibly to outsource the fabrication of the boards through some fast turn-around services.

Projects with Software Design

• Often easier to start from scratch than re-use old code.We have had numerous software-development groups struggle to get old code working, only to generate mediocre results at the end of the project when students finally manage to get the system cobbled together – in the long-view, it is sometimes easier (and generates better overall results) to really understand the function of the code and build from scratch.   All points to discuss with your Project Sponsor.
• How will your code be used by your sponsor? If your code serves as a stand-alone unit for your sponsor, you might have a different focus than if your code will be used as part of a larger overall system which involves people taking and reusing your code for years to come.   Talk to your sponsor about expectations for the code, and how it will be intended to be used in the future.
• How much of your focus is on the User Interface? If your code has a substantial component which relies on user input, it is well worth the time to treat that portion of the project like a Commercial Product, and to talk to eventual users to really understand how they want to interact with the system (see the next section).
• How do you test your code? Always one of the least-developed parts of any software project.  You may want to rely on some established testing methodology for your project, or your sponsor may have their own opinions on how to verify your code functions as required, but there should be some basis for how to test your code, and ways of presenting that information to the user.

Projects to Develop a Commercial Product

• Talk to Customers –  Groups should prepare themselves by gathering input from actual potential customers and buyers of their unit.  Groups have often spent long hours developing products and demos, solved numerous technical challenges, and put together working models which are terrible in the hands of the actual customers.
• Show people non-working prototypes before spending time building a working model. Gather useful feedback on your system as early as you can by showing people a physical model, or something where they get a real sense of how an item/product is supposed to work.  Explaining how something works using words and hand gestures is far different than getting people to interact with a mock-up – even for software products, drawing up screenshots on paper and letting people pseudo-interact with an item may get you much better feedback than spending weeks on a product which ultimately fails to please the user.
• Really get to know your competition – Look at existing products, understand their shortcomings.   Far too many groups have proposed ideas on projects for which they have zero experience (It is surprising how many people want to build a complex flying machine that have never flown any toy model plane before.  I’ve also had students propose to design a new archery bow when no team member had ever fired a bow before.).   Understanding what exists on the market by talking to customers, and by trying out products to experience the shortcomings yourself really does help.

Projects with a Significant Research Component

• Be aware of the overall aims of the 459/479 courses. The overarching theme for 459/479 is on project management and engineering design and analysis; these two courses are major contributors for your Engineering Design requrements for CEAB accreditation.  These requirements make it easy to support projects where project objectives are clear at the start, the projects are feasible with the time and resource constraints placed on the students, and there are relatively few absolute risks to the completion of the project.   By their nature, research-oriented projects are meant to generate results which may not necessarily be accurately predicted during the propsal stage, making it hard to present and follow through with a proposed project work plan, set of milestones and timeline.
• Focus on the Process and not on the Results. Do your best to describe your project in terms of the actual processes and methods you will be undertaking – writing test code, performing specific experiments, and building any required experimental apparatuses can and should be described in your work plan, as these are tasks which can be planned at the start of a project.
• Avoid making any part of your project contingent on positive research results Describing a test procedure and following through with it will work for 459/479;  proposing that you will generate positive results and use those results for the 2nd half of your project is difficult, as there is always the possibility that you won’t ever get positive results and your project will have to stop.   Open-ended research projects are far better served for Honours Thesis or Graduate Thesis work, as it is understood that those have more flexible timeframes to generate results.

Writing Tips

(section material written with a lot of help from Wikipedia)

• Focus on your Executive Summary Statements

  • An Executive Summary, is a short document or section of a document that summarizes a longer report or proposal or a group of related reports, in such a way that readers can rapidly become acquainted with a large body of material without having to read it all. It will usually contain a brief statement of the problem or proposal covered in the major document(s), background information, concise analysis and main conclusions

  • An Executive Summary differs from an Abstract, in that an Abstract will usually be shorter and is intended to provide a neutral overview or orientation rather than being a condensed version of the full document.

  • “An Abstract is a brief summarizing statement … read by parties who are trying to decide whether or not to read the main document”, while “an Executive Summary, unlike an Abstract, is a document in miniature that may be read in place of the longer document”.

  • An Executive Summary is also not an Introduction, the purpose of which is to lay out the background to your project proposal.

• A weasel word is an informal term for equivocating words and phrases aimed at creating an impression that something specific and meaningful has been said, when in fact only a vague or ambiguous claim, or even a refutation has been communicated. Every claim should have a reason and evidence used to justify the claim.

  • “It has been claimed that…” (By whom, where, when?)

  • “Clearly…” (As if the premise is undeniably true)

  • “It stands to reason that…” (Again, as if the premise is undeniably true—see “Clearly” above)

  • “Questions have been raised…” (Implies a fatal flaw has been discovered)

  • “There is evidence that…” (What evidence? Is the source reliable?)

  • “It is known that…” (By whom and by what method is it known?)

  • “Studies show…” (what studies?)

  • “(The phenomenon) came to be seen as…” (by whom?)

  • “Up to sixty percent…” (so, 59%? 50%? 10%?)

  • “More than seventy percent…” (How many more? 70.01%? 80%? 90%?)

• Adjectives, adverbs – Never use unless use adds meaning to the sentence.

  • “the equipment has been fully designed” What does “fully” mean?

  • “the project has been very successful” What does “very” mean?

  • This is not a creative writing course.

• Don’t declare success

  • …unless you have met specific, preferably numerical, targets as stated at the outset.

• Use humor, but be aware of your specific readers

  • a well-placed bit of humor can be a welcome addition to your report, but do keep in mind that an ill-placed statement can make you and your group appear to be morons.

Part 2:   Elements of a Proposal

A well-written project proposal serves several purposes: ensuring that all parties agree to common goals, allowing groups to demonstrate competence in planning out the project, and as a tool for soliciting additional resources for the project.

Below are components which must be a part of the proposal for projects in the Project Lab for 459 and 479. This structure is in place to streamline the review process and to force student groups to address issues which are particularly problematic for projects in  459/479.

Suggested Size for Document

Suggested Max:  ~25 pages (excluding Summary, Figures and Appendices)

Letter of Transmittal

The letter of transmittal is used to introduce group to the reader, establishes your credentials for the project, highlight special features of the proposal that the reader, and remind the reader of the reason for the proposal.   Letters of transmittal should be included to your project sponsor.

The letter of transmittal is not bound into the proposal since it is always written to an individual person, whereas the proposal may be read by several people in order to be evaluated.

Title Page

Below is a sample of the title page used for your documents.

• The Project Number is assigned to each group at the start of the academic term.
• Feel free to include one representative image/photo of your project on the title page.

Executive Summary

The Executive Summary should be a clear summary of the entire document, and should give a clear indication to the reader of the scale and scope of the project.

The Executive Summary:

• Is a self-contained and should require no specific background in order to understand the project.
• Should contain quantitative information  (e.g. target performance values, sizes) to give the reader a clear indication of the scale and scope of the project.
• Is normally 1 page in length, and may contain several paragraphs, and should not normally exceed one page.

Table of Contents, List of Figures and Tables

For the List of Figures and Tables:

• All figures and tables should be given a descriptive title which can be used as a stand-alone description of the image or information.
• During early drafts, it is often useful to generate a list of all figures and tables BEFORE any body text is generated.   Generating this list is useful for prioritizing what information should be included and in what order, and in planning the level of testing and analysis to gather during the experimental and data analysis phase.

Background and Motivation

Background information is required so that problem is placed into context for the reader, and to demonstrate that the group has done sufficient evaluation of the problem and alternative solutions to trust their recommended tasks and work plan.

The section should answer the following questions:

• Who is sponsoring the project?
• What is the rationale for doing the project?
• What are the key issues to be addressed?
• Are there any existing solutions that can be acquired/purchased?   Why are these existing solutions inappropriate?

The Background and Motivation section is likely to contain a number of subsections, including:

• Technical background for individuals that are not experts in the field.
• Descriptions of the state of the art in commercially-available systems and in current research.
• Discussions of alternative strategies which were considered but not pursued.
• Theoretical work developed to help define the proposed solution
• Results from previous experimental work.
• Exact requirements, technical specifications, codes or standards that you must satisfy for the project.

Any technical information which may be useful as reference material for the reader but not necessary for the project can be moved to an Appendix.

Project Objectives

Project Objectives are the intended goals of the project, and should not change as a result of circumstances that happen during the project.   Project Objectives can be used to drive the methods and deliverables for the project, which are the specific ways the group intends to achieve the Project Objectives for the sponsor.

Project Objectives ideally take the form of quantitative statements of project goals.  As much as possible, include quantitative information and target values for the desired performance of the system – this makes it possible to objectively examine each part of proposed solutions, and for all parties to understand the understand the true goals of the project.

As the project progresses, individual tasks may have to be changed given any number of unexpected events. Individual tasks can be changed, deliverables can change their form, but the Project Objectives as defined in this section are targets and goals which should remain fixed throughout the project.

Proposed Method

The Proposed Method for the project describes the materials and techniques the group will use in order to meet the Project Objectives. It is useful to present an overview of the approach separate from the Work Plan, in that technical information and justification for different steps in the procedure can be discussed in detail separately from the proposed work plan.

The Proposed Method section may include:

• Theory – This can include published papers, or relevant discussions from textbooks. Theoretical descriptions which might be useful as a reference but would not be considered essential to understanding the method can be included as an Appendix.
• Proposed Design – Include drawings and sketches of any preliminary design ideas which may be the foundation of the final prototype or instrument.
• Proposed Analysis – Describe the approaches used to analyze the system during the project – analytic examinations, finite-element analysis, or numerical simulations may be appropriate tools to use at different stages of the work.
• Evaluation of Alternative Designs – It is not only necessary to identify any alternative designs, methods and techniques which might be used, but to identify how one of these methods will be selected in favour of the other alternatives. What quantitative measurement will be used to choose one method over another? (cost, strength, number of calculations, speed, minimum fabrication, etc).
• Proposed Verification Procedure –The proposal must include a description of the measurements to be taken during development and at the end of the project to measure overall performance. There should be a focus on quantitative aspects of the project, either as absolute measurements or compared to existing solutions. Please also consider measurement error and minimum required sampling data, as you have done in earlier Physics lab courses.

Deliverables

Deliverables are the tasks and physical items that the group has promised to accomplish and provide to the client at the end of the work.  Deliverables which may be a part of any particular project may include:

• Engineering recommendation report.
• Prototype device or instrument you may have assembled.
• A specific recorded demonstration of the results to a selected audience.
• Documented results from instrument testing.
• Documentation describing all components in the system.
• Software package with documentation.
• Complete set of design drawings.

Do your best to be clear on the distinction between Project Objectives and Deliverables:

• Project Objectives are the problems or issues that the client wishes to have addressed.
• Deliverables are the physical prototypes, software, specific measurements, or any item created by the team to specifically address these objectives.

Team Responsibilities and Contacts

In 459/479, different group members are assigned different managerial roles within the group. Your proposal should identify the members who have responsibility for these managerial functions.

Project Manager

• Ensures that the schedule is maintained and work is done according to schedule
• Maintains communications with the client and resource people
• Schedules meetings and resolves general problems that arise.

Editorial Manager

• Submits the Proposal and the Recommendation Report
• Delegates the preparation of these documents.
• Ensures weekly reports are submitted to the project advisors
• Records alterations to the schedule and milestones.

Technical Manager

• Obtains access to equipment and resources
• Maintains drawings, calculations, and software for the project.
• Sets up experiments and collects data with assistance from other team members.
• A 2-person group does not have a technical manager, or can be assigned to one of the two members.

Technical Contacts
It is invaluable for you to find other people to help in your project work.  This goes outside just your Project Sponsor and the Project Lab staff members, and might reach out to your own network of contacts or others in the local community for support.  It is well worth the time to search for these experts and incorporate their guidance in your project.   This might include:

• Specific individuals from the sponsoring company.
• Faculty or technical staff on campus.
• Other students that have specific expertise.
• Members of local clubs, companies, or online communities that you locate.

For ALL Self-Sponsored Groups – if your group does not have a formal Project Sponsor, you are required to give the full contact info for at least two individuals who can act as Project Advisors, who will serve the role of offering technical guidance and/or external review for the direction chosen by the team.   Contact the Project Lab to discuss whether your group needs to meet this requirement.

Some further details about Project Advisors:

• Project Advisors may not be course instructors for your current 459 or 479 project or any Project Lab staff.
• You may target one Project Advisor as a Technical contact, and another as a potential client/first customer for your product.
• You are asked to meet with each of your Project Advisors on at least 3 occasions during the project – at least once during the Proposal stage, and twice during the Project Execution stage.

Work Plan and Project Schedule

The WorkPlan is a list of tasks that describes in detail every step that will be done during the project, determining the time and resources necessary to the tasks, and providing the relationship between tasks to allow work to be done.   It is the section of the proposal to get organized and to ensure that your team members have some clear direction at the outset for how to approach the entire project.

Step 1 – Identify Tasks

• A “task” is the smallest activity that can be described non-trivially. Think of a task as being an activity which would normally take on the order of 2-6 hours to accomplish – not so small that it can be done in a single short session, but not so long that it becomes an undefined length of time.
• Be explicit as possible in describing the task. Ideally, a task describes what what methods will be used, the mini-deliverable at the end of the task, and the individual who is responsible for the task.
• Think of developing the task list as an exercise in reverse engineering.You have the starting point, which is your current understanding of the problem, and you know the finishing point, which is providing the deliverables to the client. Your work plan must bridge the gap between the starting point and the deliverables.
• Tasks should not be done concurrently unless done by different members of the team. Try your best to put together a schedule which only involves one person working on one task at one time.
• A task may have one or more precedents. Be clear about what tasks absolutely need to be done before other tasks, to help identify which tasks should come first.
• Be certain that the task list covers the entire project. Tasks that are often overlooked, such as parts sourcing and documentation, are the source of underestimating project time.
• Describe the Tasks and Procedures, knowing you may have to cycle through multiple times. It is often the case that you will go through many revisions of designing, fabrication, testing and revision.  Describe what is necessary for each step, particularly the testing, and estimate how long it may take to go through each cycle (the first cycle, second cycle, and any follow-up cycles).

Step 2 – Estimate Task Durations

• Estimating task durations is hard.It is difficult to estimate how long individual tasks should take to complete. It helps to have experience to determine the task duration but, even if you have never done something before, it is in the best interest of the project to make a reasonable estimate of how long it will take to do each task. Poor time estimates leads to delays in the entire project, inappropriate resource/time allocation, and potential cost overruns.
• Think back to previous experiences.   You’ve likely done some similar work in the past, for co-op, for previous homework assignments, or for other undergraduate courses – use those to help estimate the number of hours you need to spend on an actual task.
• Get help from experts. Find people who have done similar work and get their input on your work plan.
• Put in a contingency for things you didn’t think about or for unexpected delays. Allow for technical uncertainty or for problems beyond your control (but you are still obligated to keep the project on schedule).

Step 3 – Set the Project Schedule

• Plan on 6-8 hours per week per student  This translates to 90-120 hours per 4-month term on the project.
• Normally we use Gantt Charts but consider alternatives.   Several techniques and software packages are available to prepare a project schedule. Some of the planning and scheduling techniques are: precedence and dependency networks, arrow diagrams, critical path management, program evaluation and review technique (PERT), and Gantt or time-line charts.    Although Gantt Charts are typically used for submitting timelines in 459/479, they are not ideal for a project plan under development – a Gantt Chart provides a good snapshot of a project plan as it currently exists, but is not necessarily a useful tool for project planning during the earliest stages.     Students are encouraged to identify other project scheduling alternatives to organize and present their project timelines, either embedded into their Project Proposals or presented otherwise.
• Find a suitable software package. A list of notable packages can be found on the wikipedia entry for Project Management Software.    Several software applications have been used by 459/479 groups in the past, you are free to use these or whatever tool you prefer:
  • MS Project (Windows)
  • Gantto and Tom’s Planner (online, 30-day free or limited account)
  • OpenProj (Windows, Mac, Linux)
  • Gantt Project (Windows, Mac, Linux)
  • Gantt PV (Windows, Mac)

Milestones

A Milestone is a well-defined conclusion to an activity or series of related activities, and is the logical point where one set of activities stops and another set begins. Milestones allow progress on the project to be quantified or measured in an objective way.

For 459/479, milestones are used for two purposes: motivation for the team to proceed at a steady pace throughout the term, and as a means of tracking progress externally for the project.

Guidelines for selecting milestones for 459/479:

1. Choose 3 specific items as project milestones (no more, no less)
2. Milestones should be objective, and should not be items which can be argued as “partially” completed.
3. Select an appropriate weighting for each milestone, as shown in the example below.  The percentage value of a milestone should reflect the difficulty of the tasks leading to the milestone.
4. Do not place project milestone deadlines too close to one another, space them out throughout the term.
5. Milestones must only occur during the actual work period for the project (Sept to mid-Jan for 479, Jan to early Aug for 459).
6. Submitting the final report is not considered a milestone.

Example of appropriate project milestones:

• Client has reviewed and given go-ahead for purchase of key components.
• Completion of physical fabrication of prototype; First quantitative measurement of system initiated.
• In-person demonstration of prototype device for Project Sponsor + other external clients.

In order to gain credit for project milestones, the Editorial Manager is expected to file a Milestone Completion Report through the online tracking system.

Milestones can be negotiated and readjusted with the Project Lab during the term, but can be readjusted no more than one week before the original milestone date (i.e. no last-minute changes).

Safety Plan

Use this section to highlight any issues with regards to Safety for your project.  Every team is expected to take an active role in identifying all issues which are of any concern to the safety and well-being of team members, other people working in the shared lab space, and any lab equipment or facilities.    

These items may include:

• additional training required by some or all team members
• additional equipment which should be available during the work term.
• creation of Standard Operating Procedures to address safety issues. 

Communication Plan

Every project should include a Communication Plan to ensure that you will be able to confirm meetings with your sponsor, and with team members in your group. There have been several occasions with project groups in the past with expectations which varied from their project sponsors/clients, and other groups that did not set aside a regular time each week to meet and discuss the project.  The Communication Plan may describe several different forms of interactions

• Forwarding a copy of the weekly report to the Project Sponsor/Client
• Regularly scheduled weekly and biweekly meetings or phone calls, including specific times and locations of these meetings
• Specific meeting dates (possibly 2 to 4) laid out at the start of the term.
• It is expected that at each meeting, the student group will create an agenda for the meeting, and will produce minutes for circulation after the meeting to confirm any specific details about the meeting outcomes.
• A guide to generating useful meeting minutes can be found here:  http://www.co2partners.com/meeting-minutes-in-6-steps/ 

Location of Work, Budget and Resources

Location of Work

Many projects will be done in the Engineering Physics Project Laboratory at UBC. However, some projects may be done partially or completely at the project sponsor’s site or at some other location.
Please indicate the space/resource requirements for the project (computer, desk space, software, power, test equipment, etc) so that the necessary arrangements can be made in the lab.

Budget
Estimate the cost of equipment and materials that must be purchased from outside sources. This is particularly important for student projects that have a limited budget and a very short time-line to do the work.

Please indicate the source of funding for all items in the project budget. Several past projects have faced challenges because of confusion as to whether the project sponsor, Project Lab, or the students themselves were responsible for funding certain portions of each project. It is the responsibility of the group to confirm with all parties that the funding is available for the project. A table may be used to identify items to be purchased in the most straightforward fashion:

Resources
The proposal must state in detail what these resources are so that they can be obtained in time to do the work and so that the costs for the resources can be budgeted.

Resources might include:

• Key electronics hardware to be borrowed or purchased;
• Mechanical components such as motors or bearings or structural elements;
• Outside machine shop time to make devices, circuit board fabrication,
• Software applications or high-end computing facilities,
• Special instrumentation for obtaining data,
• Access to outside test facilities (wind tunnel, vibration isolation room, etc)

Risks Anticipated and Contingency Plan

Contingency planning is not something you improvise at the start of the emergency, but is done during the project planning stage to identify the most likely areas that will cause disruptions in the work described in the schedule.
General areas of concern include:

• Late delivery on expected orders of items It is wise to have an alternative course of action if a delivery date is missed, which may include building a temporary part in the machine shop, or having an alternative source of supply for a purchased component, or potentially pursuing a different path for fabrication / testing for the project.
• Results from specific tests. It may be that
• Anything that might happen not directly under your control such as relying on feedback from a technical resource person or broken instrumentation. You must consider all the activities or tasks in your proposal that rely on people or events outside your direct control

Contingency plans consist of:

• Identifying the condition which triggers the contingency plan into action
• Describing the likelihood and impact of the condition being met.
• Describing the changes which need to be made to the task list.
• Identifying the date or range of dates at which point this decision will be made.

Using a table to format this section may help to keep the information together.

Avoid making any part of your project contingent on positive results research-oriented activities. It is hard to work on a project for these courses when it is not clear from the outset of the project whether or not certain technical accomplishments are possible.   Such tests are the objective of research projects, where the path to successful completion is not clear from the outset and which may or may not have a high likelihood for success. The overarching theme for 459/479 is on design projects and project management, where the focus is placed on projects where it is clear from the very beginning that projects are feasible with the time and resource constraints placed on the students.

Summary of Updates to Proposal

Provide a summary of the major updates and changes to the proposal at each draft.  This should include a summary of major questions which were asked by reviewers and Project Sponsors during the review process of earlier drafts of the proposal, and how they were addressed in the current document.  This serves as a useful tool to ensure the team has attempted to address all major issues raised and identified during the review process.

This section can be kept in point form.  

Conclusion (optional)

The Conclusion section can be used to highlight any final comments or insights about the overall project.    For most projects in 459/479, a proposal document does not necessarily lend itself very well to having a conclusion section, as the points have been made clearly in other more relevant sections, and can be considered an optional element to the Proposal document.

Appendices, References

The Appendices and References for the proposal should include all details that support the technical content to support the proposal. In order to keep the Proposal concise, the Appendix may contain a great deal of the technical information that is not necessarily appropriate in the body of the proposal. This can include:

• A list of all web links with useful and potentially useful information
• Photographs of the current state of the project.
• Calculations and theory required to pursue the project
• Software and algorithms that you will be using during your project.
• Data sheets for key components of the system.
• Journal articles, publications, patents, etc.

Revision History

• 2015 Sept – Project Advisors for self-sponsored projects.
• 2014 Sept – Added “Safety” section.   Revised “Work Plan and Project Schedule” section.
• 2012 Oct 5 – Added “writing tips and weasel words” section.
• 2012 Sept 13. – major document revision.
• The previous version of the “Guide to Project Proposals: is here:  Guide to Proposals (updated 2009 Sept)