Project Management and last year's Herald project Mark Norman 18 Jan 2008 I'm not here to talk about Herald – and repeat all the stuff about 1 GB mail store as if it were new news, but I'm going to look at the PM aspects of how the project went. There's good stuff and bad and I'll try to be honest.

Background to the project Began planning around January last year Planned in medium detail Project started in earnest March/April Original objective was Stay with SAN but investigate alt. hardware Quite a lot of unknowns Ended up having to do a lot more than originally planned (by end Sept 07) due to further SAN failures Planned in medium detail More detail than some were comfortable with, but a lot less detail than many project managers would insist upon Project started in earnest March/April That was when we had the go-ahead from UST and enough resources to spare Quite a lot of unknowns Ended up having to do a lot more than originally planned (by end Sept 07) due to further SAN failures It was the team's opinion that the SAN couldn't be relied upon – or that the risk was too great that – come the start of term, we'd have a complete failure originally plan was to upgrade the hardware by Hilary 2008!

What didn't work too well Some of the planning Maybe we should have kept things at a higher/less granular level? Some of the management Would have been useful to have a software tool Agile or planned project? Need good technical leadership We didn't have that all the time Saving the good news until last Some of the planning It would have been better to cut losses and just have conceptual to-do lists The problem with this is that the natural tendency is to be hopelessly optimistic. When you go into more detail people get more realistic about estimating times but a lot of detail that turns out to be wrong or in the wrong order is ignored later Some of the management Would have been useful to have a software tool Tried to use the wiki, but this wasn't adopted well by the team (and isn't the right tool for the job) Not all people respond well to 'new' methods and others find it easy to pick up and adopt Ditto software tools Agile or planned project? We should have decided whether we were implementing/deploying in an agile or planned manner (somewhere in between doesn't work) Need good technical leadership We didn't have that all the time – a project manager is not enough (we tried...)

What did work well Having a clear Project Brief Good communication/establishment of objectives (what and when) External communications during the project Project Board and all the help and testing we had from OUCS (and ITSS) colleagues! Let's focus on the good stuff! I'll expand on each of these right now.

What did work well (detail) Clear Project Brief Clear objectives Expressed to UST and anyone else who was interested Unambiguous Need to involve the Project Board if you have to change anything Clear Project Brief Contains the business case, objectives, time scale, names of staff, risks, high level overview of probable work Ideally 2 pages of A4 if you were to print it out Clear objectives Unambiguous It's amazing how you can chat about something for days or weeks and everyone seems to have a clear idea of what we're all going to do. However, when you come to write it down (even when it's incredibly high level) you then disagree about what we plan to deliver. If you can't write it down in 2 or 3 pages... Need to involve the Project Board if you have to change anything That sounds bad but actually we found it to be very useful indeed. (More later)

What did work well (detail) Good external communications Not just from us From all of OUCS Because the project was well-known and understood... other colleagues able to answer queries suggest announcements etc. I'd like to stand here and thank the people who fielded queries, gripes etc. on our behalf or supported us when we had to make difficult announcements. Thank you! People like: ITS3, the help centre managers, SMG members, the databases team all helped in this respect. I feel sure that more people probably put in a good word in the right places (even though we were not aware). Coming back to the methodology... I hope that this was partly because the project had been communicated well and that people understood enough to be able to say 'no, it's going to be like this' or 'no, it's going to happen at so and so date'.

What did work well (detail) The Project Board Surprisingly, possibly the very best (most successful) single thing Thanks to: Alan Gay (Mike Fraser, sub), Katherine Craddock, Andy Saunders An ideal Project board: is as small as possible contains someone who is a user, or who can represent users, a technical scrutineer, a member of SMG (or the 'sponsor' who should be fairly senior) Helps you to disseminate your progress or difficult decisions (people from another part of OUCS instantly know detail about your project). This is a huge hidden advantage. We had a few points where difficult decisions had to be made (e.g. where a lot of money had to be spent) where a technical decision (with knock-on consequences) had to be made Incredibly useful: Takes the pressure off the team Means that thoughts are usually written down and decisions are made by a group with good oversight

Some recommendations Have a project manager Have a technical lead Prepare a Project Brief (and keep it brief!) Communicate to others in OUCS Have a Project Board These are what I now think are transferable to OUCS Have a project manager Have a technical lead Ideally these are 2 separate people, possibly 1 but the two must work well together Prepare a Project Brief (and keep it brief!) 2 pages A4? If you've got your project clear in your head it should only take an hour or so to complete If it isn't clear in your head, then this will help you to get it clear Communicate to others in OUCS and beyond. The Project Brief and Project Board almost do this automatically for you. Have a Project Board The simplest most useful thing we found. Helps with comm.s as well as all the other obvious benefits. Helps keep others who are affected by - or dependant on – your service (or the project outcomes) happy

Some recommendations Project management software may be useful Need the right level of detail of tasks Team members must report Either via software or by making notes Accept that plans change Light-touch methodology (draft) is at https://wiki.oucs.ox.ac.uk/pst/PMMethodology The Project Brief is just the 1st section! I believe that dotProject is on the horizon (being tested out by Sebastian's team, and now being used by the comms team). It's quite detailed but easy for people to track progress. There are much easier (but less feature rich) alternatives. A glorified to-do list may suffice, if managed properly. Accept that plans change Relax about this idea. Many people are loathe to plan as they're certain that things will change. Known Unknowns, Unknown unknowns etc. Donald Rumsfelt Poor planning is far better than no planning. Always.

And again, a big 'Thank you' to everyone who helped us