You are currently browsing the tag archive for the ‘project management’ tag.
Well, it’s project management time again! Seems to be a theme with me lately – I think I’m working on more projects, and have started to notice the potential in using project management tools to manage things that I hadn’t really thought of as ‘projects’.
I attended a course at Mimas on using the ‘One Page Project Manager’ (OPPM). This is a system developed by Clark Campbell (some time in the 90s, I think), and is designed to allow you to quickly and clearly present all the essential information about a project in one page. I thought it sounded too good to be true!
I hadn’t done any reading on OPPM before the course, and was vaguely expecting it to be some sort of theoretical guidance on what you should include in a project summary (maybe with some tips on ‘expanding margins’ and ‘what really is the smallest readable font size?’), so I was pleasantly surprised to find that the course (run by David Sommer Consulting) wasn’t theoretical at all. OPPM is a single-page template, which you fill in with the relevant information. It’s not designed to go into loads of detail about each task or stage of a project, but to provide an overview of the vital information.
You can download a pdf version of the template for free from the website www.oppmi.com, along with guidance on how to use it. If you think you like the look of it, I’d suggest that it’s probably worth paying $10 for the Excel version, as it’s designed to be used and customised within Excel.
I like the way the template is laid out – when you see how it all fits together, it’s actually a very elegant use of space. You start reading the OPPM clockwise from the objectives in the lower-left ‘hub’, and it’s pretty easy to see at a glance what each section signifies (if you disregard my frankly shocking handwriting!)
You can use multiple OPPMs in a single project, if you need them – have one for the top-level overwview, then one for each of the large tasks that need breaking down.
My impressions? That it’s a flexible system which will lend itself well to small-scale projects, and isn’t as demanding or time-consuming as some other project management systems.
I think it’s a good bet for information professionals, as it forces you to think about the vital information that is absolutely required at top-level, and doesn’t give you scope to get bogged down in details – something which I know many of us are prone to!
David also spoke about the idea of planning projects backwards. This isn’t part of OPPM – just a technique that David and his clients have found useful. I was surprised to realise that it was a system I’ve used for planning projects before, without realising that it was an actual ‘thing’.
The idea is that instaed of starting at the beginning of your project and planning forward, you start at the outcome and plan backwards. You know what you need your final outcome to be, and you know when you need to deliver it by. Use this information to then take a step backwards, and say ‘ok, if we need to have this outcome by Dec, what’s the immediate prior step? We’ll schedule that to be done by end Nov.’ (I’m finding this harder to explain that it actually seems in practice!)
I’m going to try using both of these techniques, and I think they’re simple and flexible enough to find a fairly permanent position in my ‘productivity tools’ arsenal.
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.
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!