Project management in action

I’m delighted to be involved with the project board for the CILIP Future Skills project. It’s a really important project: to make sure that CILIP’s qualifications, Body of Professional Knowledge, and Accreditation and Seal of Recognition schemes are meeting and reflecting the needs of CILIP members from all sectors, and at all stages of their career.

The project board’s role is to advise on the project at high-level, while the project team at CILIP will be doing the really hard work – research, talking to members, implementing suggestions etc. That’s not to say the project board aren’t working hard, too! I’ve now been to two meetings, and found them both to be interesting and productive.

I knew that getting involved with this project would be great for my professional development, as well as a brilliant opportunity to help guide the future of CILIP: a chance to get to know the CILIP framework inside out; learn about areas and sectors I didn’t know much about; represent new professionals, people who’ve recently chartered, and those in non-traditional roles; meet and work with some lovely and fascinating people. What I didn’t realise was that it would also be a crash course in project management!

Most of the project work I’ve done so far has either been with no defined methodology (such as working with Voices for the Library), or projects at Mimas where I’ve been doing the work, but haven’t been involved in high-level strategy or planning. But I’ve just started managing a project for the Archives Hub, so I’m really keen to get some tips and see a great project in action.

And I’ve been really impressed by the way the project is being run. Project Manager Simon Edwards obviously has a lot of experience making things run smoothly, and other project board members seem to know their way around PRINCE 2, too! It’s odd to see things that I’d only ever read about in theory in action, such as the time: resources: quality triangle. When someone says ‘well, we can’t increase resources, and we’re not willing to compromise on quality, so we’ll need to extend the time axis if we can’ it suddenly all makes sense! (well, (in theory) it made sense in theory too, but it’s much more real when it’s, umm, real)

So, for project management noobs like me, here’s some of what I’ve learned so far:

1) Gantt charts don’t have to start on Mondays. This is one of those things that seem blindingly obvious once you’ve seen it, but that I’d just never have thought of for myself. The Gantt charts for this project have the week end date in the date columns, meaning the focus is on deadlines. I also find it useful this way – as the project board is meeting on Fridays, it means I can easily associate activities and deadlines with project board meetings. I’m sure you could use any interval or period you liked – meetings on a Weds? Start your weeks then! Meetings every 10 days? Make your date periods 10 days instead of 7. I don’t know to what extent these latter tweaks would be considered good practice, but I think it’s something I’d find useful.

2) The time you block out on a Gantt chart doesn’t have to be solid. The Gantt charts I’ve always seen/produced have had sections of time blocked out in solid lumps, like this:

Now, this is fine if each of those tasks really is going to take the whole week, but that’s often not the case! It might be that there’s just a single day’s work to be done, or nothing can be done until the second half of the week. How to indicate that? Here’s Simon’s method:

Simple and effective! And if you start using different colours, your Gantt chart could become a thing of beauty! What colours might you use?

3) RAG everything. No, that doesn’t mean wild and wacky fundraising activities – it stands for ‘Red, Amber, Green’, and is a way to visually represent progress and status of a project. Green means everything’s ok; amber is an activity at risk; and red means that something has gone wrong – a target not met, or a resource not available.

I’ve used similar colour-coding systems in the past, but I’ve never come across a project where basically everything has a RAG status. It means that it’s easy for us to see at a glance where the potential problems are – and (hopefully!) to deal with them before they become actual problems. And all of this is recorded in the…

4) Project Journal. Again, not an entirely new concept – various school/college/uni projects have involved keeping a diary of progress – but one I’ve never actually used before. (I used to make all of my project diaries up. I’m sure everyone did. And for those of us who were schooled before the ubiquity of word processing – remember writing some entries in different pens so it looked less like you’d written it all the night before it was due in? Fun times.)

But when you’re working in a group, on a large-scale project, suddenly you realise that your teachers might actually have been right: there is a need to keep a record of what’s been done, when and by who. It’s a place where all project members can be kept up-to-date with what’s going on in various areas of the project, and everyone has a chance to learn from everything that’s been done.

Combined with the Lessons Learned Log (the space for reflective practice about the project) it will also help with the planning of future projects, recording not only the methodology but the reasons for that methodology and how successful it was. Simon describes the reasoning for the documentation: ‘using a combination of the Project Journal (the story), the Highlight report, (the latest headlines) and the Project Plan (the map) literally anyone should be able to come in and pick up from where I left off’

There’s still a long way to go on the project, and I’m sure I’ll be learning loads more as it goes along!

If you’d like to know more about the Future Skills project, or get involved, you can contact the project team.