Posted by s.hettrick on 22 September 2011 - 2:54pm

...but somebody made me do it!

Sound familiar? Fear not! While effective project management is becoming ever-more important in delivering useful results from increasingly large and complex research software projects, it's not as scary as it might seem.

Project management has its own professional standards and methodologies - think PRINCE2 or PMP - but in its essentials it's really just common sense. While I'm a big fan of the PRINCE2 methodology for development projects, I've also learned over the years that coupling development with the research dimension common in scientific software projects demands a little more process-tailoring than usual, a greater degree of agility - a lighter touch, perhaps. Keeping project management light-touch while still maintaining control is a delicate balanching act, but it is possible. Have a plan, make sure your people know what they have to do, keep track of stuff and be prepared for things going wrong. That about sums it up!

As a project manager, it's your job to keep the big picture in your head and steer activities towards that goal. Here are a few core ideas which may help if you've been thrown in at the deep as the New Project's PM.

Create a Gantt chart at a suitable level of granularity

Not everyone finds these useful, but as a project manager you may find it's one of the most useful ways of keeping that big picture alive. And if it's a useful tool for you as the project manager, then go ahead and create one and be darned to anyone else!

By suitable level of granularity I mean break tasks down to the level of a week or so. Anything less detailed will fool you into thinking you know what's what, while hiding too much of importance. Anything more detailed may be a waste, because change is going to happen, and happen regularly.

For me, the most useful feature of a Gantt chart is the understanding it gives of dependencies between things. Link tasks wherever it makes sense. Even if your effort estimates are wrong by a factor of two, the dependency links will show you how the big picture changes when you change the estimates. By extension this single big flexible picture gives you two other useful pieces of information: which resources are overloaded at a given point in time, and how much slack exists in certain tasks.

If you know where your slack you'll have a better idea of which tasks are safer to give to busier, less engaged team members. Give these people tasks where slippage has little or no impact on the big picture; avoid the critical path.

A technique which I use and value in creating Gantt charts is PRINCE2's recommended approach of product-based planning. Don't think "what do we have to do?" but "what do we have to make?" Base your plan on breaking down the system into subsystems, components, units and use these tangible, measurable things to create your Gantt tasks. This gives you an easier handle on when a task is complete - the unit is either done (it passes its defined unit tests and is checked in) or it's not.

Create a risk and issues log

Risks are things that might go wrong, or are assumptions you make in planning - about the stability or availability of a third-party piece of software, for instance. Brainstorm the risks: write them down, along with estimates of their likelihood and impact, plus mitigation strategies to avoid or reduce them and contingency plans in case they happen.

Sort your risks by importance or exposure, usually defined as (likelihood) x (impact), and keep a weekly eye on the top ten. Manage them actively - keep the mitigation plans in mind. Bear in mind that likelihood and impact can change as the project progresses.

If a risk happens, record it as an issue and put into action the contingency plan you worked out for it. This keeps unforseen changes under control and makes it a natural part of the project. Stuff does happen; accepting and planning for it makes it much less problematic.

Review progress at management milestones

Whether or not you have concrete deliverables due every quarter, plan a "stop and review" milestone every quarter or thereabouts. Review progress, issues, risks; decide if things are sufficiently on track or whether they need adjustment. It's always good to step back from the day to day and review progress against that big picture.

Send monthly highlight reports "up the chain"

You'll have a boss. Everyone has a boss. You may find it useful to send monthly highlight reports (short emails are fine) up the reporting chain, whether you've been asked to or not. Cover progress, issues, risk changes, plans for next period. Your boss can't then say they didn't know what was going on! Flag any escalated issues that require action or a response, and be honest! One of the most common reasons for large project failure is poor communication from the coal-face to the boardroom. If one of your developers says "look, this is a big problem, it will slow us down" then don't be tempted to massage the message before you pass it on, not even a little: "this is a problem, it may slow us down some" is not the same thing!

A few simple, straight-forward techniques like this can take a lot of the pain and stress out of project management, and they don't cost the Earth to employ. You'll find that just a little bit of management discipline can really help your team deliver the right things, done right, on time.

Heck, you may even discover you enjoy it!