T3:Engaging with your Communities Theme: Writing to get your project noticed
Cloud created by:
4 May 2010
As a project manager, you will be familiar with writing reports to update others on your work. You may need to inform and engage senior managers, members of the public, the media, and colleagues, many of whom may not have your level of specialist knowledge. So, how do you ensure that the broadest possible range of audiences understand the key aspects of your project and are enticed to engage with it? This session will help you to construct a short summary of your project’s goals or achievements, allowing others to understand and appreciate the relevance of your work.
You will learn what makes good writing for a general audience, and using JISC projects as examples, find out how a well-written summary can contribute to a project’s success. Working with a partner from a project that is unfamiliar to you, you will begin to develop your own non-technical project summary.
Once completed, this can be repurposed for web pages, project leaflets, event publicity, press releases, newsletter articles etc and hence help to increase your project’s impact.
You should bring a copy of your project proposal or report and project plan with you to the session.
Judy Redfearn, Communications Co-ordinator, JISC
Clare Groom, Communications Manager, JISC
What can delegates expect to learn / gain / take away from the session?
Participants wil lhave:
- Understood why it’s worth investing time and effort on writing a short summary of their project’s goals or achievements for a non-specialist audience. Expressed the context, aims, objectives, outputs and benefits of their project fora non-technical audience.
- Prepared a bullet-point outline on which to base their project summary.
Who should attend?
Project managers and project communications staff
Live blog of the session
It's a full house for this session with a strict 'if your name's not on the list, you aren't coming in' door policy, which indicates the high level of interest in this subject among the delegates.
Judy Redfearn (a communications expert at JISC with a science background) opens the session by setting out the aims: how you can write clearly about your project for a general audience. This is an interested and intelligent reader within the sector who wants to know about the roject but is not an expert. It might be a senior manager or an adminstrator or someone in the press office or a funder or policymaker.
Judy also introduces her co-presenter, Clare Groom, Communications manager at JISC who comes from an arts background.
"We want to get you working on your own project summaries," promises Judy, so it looks like it's going to be a very practical session. Anybody not working on a project will be paired with someone who is so that everyone gets full benefit from the workshop.
Clare takes over to get everyone started on thinking about the kinds of questions we should be thinking about. "Effective communication relies on being understood," says Clare, and raises a laugh from the group with a slide showing a big yellow phone with only buttons with the numbers 1 2 3 on it - next to a 999 information sign... "Think about what people need to do with the information you're giving them!" she urges.
Now onto the ice-breaker and it's pairwork: five minutes of finding out what the other person does and is working on. Clare starts the timer and the room is suddenly filled with a hubbub of chatter as delegates frantically try to find out as much about each other as they can in the allotted time.
Time's up! Clare asks for feedback on what questions were asked and which were more effective in getting inormation out. The main response was: But we didn't ask questions! Feedback included:
- We didn't ask questions, it was more like 'would you like to tell me about your project?'
- I wanted to listen to what was naturally shared before prodding with questions
- We launched straight in and gave short summaries and then probed some more
- I tried feeding what I understood he was saying back and that expanded the conversation
- I asked what stage the project was at
- We didn't really ask questions but focused on the similarities and made connections in that way
- Questions can be useful as I needed focus, otherwise I can just prattle on
"Any questions you'd wished you'd asked?", tries Clare next. There was thoughtful feedback on this one, which included:
- How could this be applied more broadly?
- What's the context eg what kind of learning are they engaged in?
- I was asking questions of myself eg do I know anyone else doing this kind of work?
- With more time I would have asked him to demonstrate what he was doing
- Specialist terminology - did I really understand the words he was using?
- How will the project be taken forward now, what wll the outcome be and what next for it in the future, and, of course, sustainability...
- What impact will it have on the end user (do you know who they are?) and how can you demonstrate that impact?
When you write stuff you don't have that opportunity for going back and forth and probing. That piece of writing is in front of the intended audience and needs to tell them what they need to know - or at least inspire them to probe further.
Judy suggests some questions project-writers may want to ask themselves before they write about their project and many of them reflect the areas that came up, above, from the group. They include: what problem does it solve; what is the context; what do you hope to achieve; who will be using your achievements or findings; are here any wider benefits?
The practical stage is coming up - drafting project summaries - but Judy has some tips to impart first. There are sample project summaries and some top tips on the tables and the delegates start to pore over them eagerly. I'll see if I can get copies of these information sheets and attach them to this blogpost (or cloud).
Judy works through one of the sample project summaries, explaining how the summaries set out the problem at the start, moves on to the context and then goes on to show how the project provides the solution.
The other tips are general tips for good writing eg explain terms that the reader may not know (perhaps explain what it is rather than what it means); avoid acronyms (tricky in JISC world, it's acknowledged); keep to the point; keep sentences short; write in the active not the passive; think about how your writing will be used (for web or maybe emailed for background for a press release - do you need to include extra context about who you are?); you know what you mean but will a non-expert? Check with a non-expert, ask them to read over the draft and ask questions or check things.
Judy explains that she will often draft a piece and Clare will check it over and ask questions and it's a process that is repeated.
Now it's time to get working. Back in pairs, the delegates are putting Judy and Clare's advice into practice. Some are drafting summaries from scratch, others who have them already prepared are swapping them back and forth to test for readability. Mostly, judging from the noise levels, they are putting the 'asking questions' element firmly to the test.
Halfway through the practical element and the chatter has abated somewhat, replaced with tapping of keyboards and scribbling of pens as the delegates put into action what they have learnt from the workshop leaders and their discussions with fellow delegates and get down to the tough business of actually drafting their project summaries.
So what did they learn?
- It's easier to draft somebody else's than your own!
- Summaries are really helpful in making sure you are clear about what youre doing, why and where you are going. They are really handy for that purpose, even if they go no further and are ot read by anyobody else
- Important to write in a language that is as accessible to as many people as possible. You can talk about quite complex things in language that everyone can understand
- It would have been useful to do this a year ago!
Judy suggests that it might even be helpful for the project specialist to explain their project to someon else and then they write it. "It's a big ask..." comments a delegate. "Well, it could be a quid pro quo?" says Clare.
You need to write differently for different audiences - an academic audience is different to a business audience, Judy points out. These summaries are for people in the sector but they can be repurposed. Anyone in the sector should be able to read these summaries and have a handle on what you're doing.
One delegate comments: "My project is writing up a toolkit and that has its own challenges: it has to be written for people who will engage with the whole toolkit and also those who will just dip in. There is also a paper version and a web-based interactive version. Those writing styles are also diffeent. The idea is to do no more than you need to do."
"We also have tho think about how we write on screen, especially if the current climate means that we move more and more resources from print to electronic," says another delegate. "That also means we need to think about the skills in the team. We need to think about how we produce the end product if they are going to be only online. It's a diffeent scenario. And it's not one that academics might necessarily be famialir with. It's a new challenge."
Judy closed the session by thanking the workshop participants. Are these project summaries helpful, she asks. It's something JISC is working on. She also encourages the delegates to get in touch if they want any more advice or to send in their project summary for feedback.
10:33 on 28 July 2010 (Edited 11:58 on 28 July 2010)