Technical or Detailed Submissions
General Comments
Detailed submissions:
- are more difficult but can ensure a better outcome is achieved
- may be better coming on behalf of a group rather an individual
- demonstrate a group's value for providing useful feedback so raising the group's profile
- good to combine with the individual submissions for numbers
Benefits of technical submissions
- Provide useful local knowledge pertinent to a project
- Correct factual errors or identify specific problems in the proposal
- Suggest additional features or points for consideration
- Provide good evidence/arguments for/against a proposal (include references)
General hints
- Identify one person to coordinate/lead the submission (s/he may not write much of it)
- Use a "buddy system" with experienced submitter to help train up a new person
- Give yourself enough time to prepare a draft for feedback by others. Time is needed for background reading, discussion, research, preparing a draft, and getting and incorporating feedback (there may be multiple iterations)
Getting feedback for a draft submission
- Some sources of help/feedback are other group members, like-minded groups e.g. CAN Technical Group, Living Streets Aotearoa
- Draft submission doesn't have to be fancy e.g. it could just be some random thoughts scrawled on an e-mail
- People often find it easier to give feedback then to start the wheel rolling or having a completely blank slate
- If submitting on a proposal/draft document read it through carefully and ask yourself, "Will this make things better for cycling and cyclists?"
Project design proposals
- Learn how to interpret plans (most for public consultation are reasonably clear but if something is not ask for clarification)
- Check on site (go for a walk or ride along the route) to envisage how it would look and identify any specific problems (e.g. service covers, utility poles, observed conflicts)
- The pedestrian and cyclist profile (Ministry of Transport, pdf) has information to help decision makers justify walking and cycling projects (useful resource for advoctes too).
- For cycling submissions, use the CAN Design Checklist as a guide*
*Better yet, give it to design staff to get it right the first time - See if the design staff for cycling projects have or are interested in attending The Fundamentals of Planning and Design for Cycling course (NZ Transport Agency approved, more than 500 people have attended already). The course is for planners, designers, engineers, & advocates to ensure best practice is used to get the design right first time.
Highlighting problems
- Ask yourself,"As a pedestrian/cyclist, how would I negotiate this site?"
- You do not have to come up with a better solution-that's what the technical people are paid and (hopefully) trained for. It's nice if you can, but the more important thing is to identify any problem(s)
Some rules of engagement
- Typed is best as its more readable (use a formal font e.g. Times New Roman). A professional appearance ensures style issues do not detract from your message.
- If there is a standard feedback form/format, answer the questions provided or in the order presented, (adding extra comments where necessary)
- Submit on time. Apologise if late. Most consultations will grant you an extension if you ask in advance
- Stick to the consultation topic. Don't rant (but let them know if you think something important has been left outside of the scope)
- Keep it above board! Use reasonably formal language, correct spelling, and good grammar. And no abuse of people or agencies. You can say that you disagree or are disappointed with a proposal.
- Make sure your submission is well laid out, both visually and logically. Check for errors-factual, spelling, and grammar. Get a couple of people to check your submission-someone who knows about the topic and someone who doesn't
- Sometimes there are multiple consultations phases.
Detailed submission structure
[see boilerplate examples provided or visit CAN & its local groups websites for submissions]
- A Submission template can be helpful
- Use letterhead if your group has it (has full contact details, group logo etc)
- Use a logo if your group has one for branding
- Front/title page of submission needs (a) date (b) name of consultation (what you are submitting on) and (c) recipient of your submission
- General Format
- Start with Introductory Information [see below]
- Follow with General Comments [see below]
- Then follow with Specific Comments [see below]
- Signed by key/senior Group Officer (e.g. Chair). Signatory should state position of person
Introductory Information
- Introduction/description of your group (esp. if unfamiliar) who you or the submitting organisation are
- Either in the text body or as a footnote
- Who you represent and how many
- State your experience-why you view is valid/relevant, why you are specially experienced to write about this and if possible back up with facts and figures
- Can add reference to a website for more information
- Note how/what you have reviewed (e.g. flyer, document, draft proposal/strategy, on site visit, group feedback, etc.) (i.e. brief information on process used for preparing your submission)
- Indicate desire or not to be heard in person (best to present if you can)
General comments
- General support (or not) for proposal. Acknowledge the good, even if not in total support
- Common issues/themes identified
- Items outside scope of proposal also worth mentioning. Should be considered at subsequent stage or additional project?
Specific comments
- Follow structure/order of the consultation document/feedback form (e.g. repeat section headings and subheadings)
- Be specific about where your comments refer to by referencing to very specific parts of the consultation document (e.g. Page x Section x.y. Paragraph n). Quote extract if necessary, or highlight location on plan
- Where possible, suggest recommended/desired change (e.g. modified wording, design amendment, if you want changes to what a bill says or want an inquiry to make certain recommendations make it clear and provide wording; if it links to a specific amendment or change try and detail that). This has more impact than vague generalizations about principles
- If you have grave concerns about the thrust of the document, then state your concerns and where possible suggest viable alternatives
Submission structure hints
- If a long submissions (> 4 pages?) have a summary of the main points up front. You can also summarise key points at the end.
- Use bold to highlight key items or points for easy scanning.
- Use photos or other graphics if necessary to help explain concepts.
- Use numbered or bulleted items for clear structure.
- Back up all assertions where necessary with suitable references (footnotes).
- Be familiar with other related agency documents or official documents so where necessary you can highlight inconsistencies with the proposal.
- Provide clear preferred contact details (phone, email, post).
- Invite follow up clarification of any points if necessary.
- Personal follow up can be important as the Policy Analyst receiving the submission is often junior, they may not understand your point.
- National Organisations - The Cycling Advocates' Network & Living Streets Aotearoa and some of their local groups, have submissions they have undertaken on their websites and these may be a helpful guide.
Conclusions
- Submissions don't need to be daunting
- Start with small steps
- Buddy up experienced and inexperienced submitters
- Get help from those who've been there
- Important to know what is coming up and a Submission Co-ordinator can help with this
- Accentuate the positive where warranted, don't just be a "whinger" :)
Good luck -good submissions can help change things!
Sources: Glen Koorey's Cycling Advocates' Network (CAN) Workshop- "Creating Effective Submissions", 2007; with a few additions from Axel Wilke's "Effective Submissions" presented to ChCh City Council, 2003, CAN User Group Handbook, & Living Streets Aotearoa User Group Handbook.
Tags:
Groups audience:
- Private group -
Attachment | Size |
---|---|
CAN Technical_Detailed Submissions Pointers (2).doc | 58.5 KB |