Producing a timeline

Photos: JC Siller and (insert) Ante Lusina on Pexels

The material in this area of the site is currently for people with at least three years’ trust fundraising experience.

Introduction

No one in their right mind would expect a generalist trust fundraiser to accurately timetable a project. However, your generic project management experience should be good enough to have a stab, with help, enabling you to “break the back” of the work for the Services team. As a result, you may end up having to draft timelines in applications.

However, a 2018 study by the Project Management Institute (PMI) stated that poor time estimating is the root cause for 25 percent of failed projects! So, you need to be conservative and to make your estimates very accessible to the Services manager you’re working with, so they can second guess your key assumptions.

At the same time, as my editor Robyn pointed out when reading my draft, Services themselves will often do the timeline in which case your role as a critical friend may be to ensure it’s realistic, build in cushions, etc.

“Bottom up” time planning

The best way to work is to break the tasks involved down reasonably closely and assign times for each. The reason is that people tend to under-estimate what’s required (technically known as the “planning fallacy”). Breaking things down finely reduces that tendency.

• Do this part of the work some way into the planning. You need to be fairly clear about the actual shape and requirements of the project, including a sense of things like the key risks that may need time to mitigate, as well as the more obvious constraints like numbers of staff. If senior managers try to impose last minute changes, your plan is one thing to revisit!
• Start with a “work breakdown schedule” – “project manager speak” for a list of the tasks, in order. This will throw up prioritisation issues that you’ll need to check with the Services manager or include in the list of assumptions that will go with your timeline
• Identify any that might be involved and do a “drill down” into them, breaking them into smaller bits. The following is a nice way to do it with a pen and paper:

(As my editor Robyn McAllister highlighted to me, it’s important that this does match with what Services are planning to do and what’s stated elsewhere in the application.)

• Development work requires significant time (as you well know, from your own job!) So, don’t under-estimate this element of the work.
• Assign numbers of weeks to the different bits of the work and add them up to give times for the large elements that you’ll be putting on your timeline.
• If the project has a lot of interdependent elements, you may benefit from putting it on a GANTT chart (see below) and doing a critical path. (If you get to this level of detail, you probably need to bring in the Services manager to sit with you, because the assumptions you’re making will be too complex for them to unpack when they see your draft.)
• It’s worth including the outcomes in your planning work. It can take time to build up service users and time for them to actually achieve the benefits. So, time planning this work will give you better numbers. As with any target setting exercise, you need to be careful that you’re positioning it internally as checking Services’ targets, not as setting them. Services should have complete ownership of the targets.

“Finger in the air” assumptions

The following rules of thumb have been okay for me when I had no better evidence. However, they are just guesses:

• It takes three months to recruit a member of staff from when you decide to do so
• The first month is induction
• When a member of staff starts, it takes them six months to get up to speed. Across that six month period, they’ll only get through half the work of someone who’s fully up to speed
• For any project that’s brand-new work, Services are likely to want to pilot it in only one area initially. A typical time to pilot it is a year. 
• A project will grow as slowly as is realistic. So, a project that is going to work in five sites by the end should work in one in Year 1, then introduce two more, then two more again. (Personally, I’d structure the time so there’s 18 months where the last sites are operational, so that the project isn’t ruined by people leaving in the last six months, though that’s an idiosyncrasy.)
• You need to build in evaluations, initially quarterly for very new work but on a yearly basis where you’re more familiar.
• Projects work more slowly than you expect where everyone involved is finding their way. So, I’d lengthen times / cut any targets in such circumstances.
• Only 80% of the budgeted time will end up being on the project. The rest will be on sorting out unforeseen problems, staff illnesses, unexpectedly complex internal reporting, etc.
• Part time staff work a bit more slowly than full time ones, at least in their first year, because they have more challenges remembering.

“Top down” comparison to your plan

There are a few ways you can sense check your plan – which also offer “quick and dirty” alternatives to the above, but may be less reliable:

1. Ring people who’ve set up similar services, but who aren’t competition. I’ve had some great conversations over the years with staff of related services, who are usually only too happy to help. (You also learn a lot about good practice in the areas you’ve all been uncertain about. Plus, you can reference the conversations in the application!)
2. If you’ve found evaluations of related work, either online or at the British Library, these are sometimes written so as to describe the major timings. They also often mention significant delays compared to the original plans. (If you’re lucky, you might find a “how to develop your kind of project” toolkit, in which case it might well cover timings.)
3. There may be analogous projects within your own charity, that you can check against.

I wouldn’t normally recommend these methods as a substitute for the “bottom up” planning, as (1) you may not get a complete list of tasks and (2) your project might involve complications the others didn’t have to address. However, they’re a great way to “sense check” your work.

What might derail your timeline?

The key elements are probably in your risk analysis. However, there may be others to consider:

• Other tasks to be carried out by shared staff (e.g., senior managers) which will have priority over the funded project.
• High time demands of internal/external meetings.
• Contact with other customers, suppliers and contractors.
• Others priorities and schedules, e.g. if you’re reliant on statutory organisations or working with partners.

Tips for writing

• If there’s space, a good time plan includes key management actions: yearly evaluation, quarterly steering committee, etc.
• Internally, outcomes can go on but I wouldn’t put them on the external version. Outcomes can easily change late in writing the bid and it would be easy to forget to change them on the plan.
• If something happens monthly, there’s nothing wrong with saying that once at the start of the period.
• The best plans read so there’s a clear logic to them: 
  • The project builds and interventions like evaluations, dissemination of involvement of partners happen at logical points. 
  • The text is easy to relate to the rest of the application. As with everything else in a long application, the reader faces a challenge to orientate themselves and keep up with you. So, use of terms you’ve used a lot in the rest of the text, trying to reflect the structure in the rest of the writing and any other “internal signposting” you can use will help.
  • The timeline is an easy thing to look at and spot issues, so you need to “sense check” your finished results. 

Give Services a list of assumptions to check

• List all the assumptions, exclusions and constraints that you came up with. You need to make them nice and clear, so that the Services manager can unpack your work.
• Give them to Services along with your draft timeline.

A Gantt has a calendar of dates along the top, actions down the sides and bars representing the period of work. It’s a nice, clear, powerful way to think through, communicate and monitor timings.

The key practical advantage of roughing out a Gantt chart is that it helps you see how the time is ordered: where in the process there are too many demands on time and where there’s “slack” time. 

There are different ways to add sophistication to this, though as you only get occasional opportunities to use a Gantt, I’ll leave it to you to look at the very many online instructional videos and explanations. One that works well for me, with more detailed timelines, is to name the people involved in different tasks. This brings out when staff are needed / the level of demands on them at any one time. 

As you can see above, you can quickly make your own Gantt chart in Excel.

Critical path

The key possible development, in my eyes, of the chart is to add a “Critical Path”. This identifies the key things which need to happen by a specific date to enable the project to stay on track.

I like to add a critical path to my personal versions of Gantt charts. They normally highlight mistakes that don’t come out just from doing the Gantt. The following download gives you an idea:

(Having so many lines in the timeline might be a bit fine for a funding application – if only because of the challenges of getting it agreed internally!)