1. Project Management and last year's Herald project
Mark Norman 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.

2. 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!

3. 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...)

4. 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.

5. 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)

6. 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'.

7. 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

8. 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

9. 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
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.

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