Project yourself

The noun “project” (with the stress, incidentally, on proj, unlike the verb which has the stress on the ject) is a plan, scheme or proposal. It has become one of social care management’s buzzwords – rubbing shoulders with the likes of “robust” and “key”. And like all terms that are arguably over-used, the definition can easily become blurred.

There is a risk, then, that major pieces of work will be subject to a full project management process when the same outcome could have been achieved in a more run-of-the-mill way. Don’t go down the road of establishing a project board, creating a dedicated team and consulting stakeholders (which should crucially include users, who ought to be the ultimate beneficiaries of any work undertaken) unless it is truly necessary. But what is project management?

It certainly isn’t an exclusive occupation. Almost any activity that involves carrying out a non-repetitive task can be a project. So we are all project managers. We all practise project management.

We all remember doing projects at school: invariably something scarily scientific or recreating life with the Greeks, Romans or Egyptians. A project was something that was linked to what we were doing generally but slightly detached. And despite there being

national occupational standards of competence (131 pages of it) and an association of project management with 13,000 paid-up members, project management is basically a joined-up writing version of a school project.

It is, as is much of the produce grown in the field of management, less reliant on skilled husbandry than salt-of-the-earth common sense. So why are so many projects managed badly? Is it that when faced with the actual project, common sense flees leaving us victim to reactive management or panic even? This is where some very simple guidelines usefully pop their heads around the door.

So fear not. We will not bombard you with pompous jargon engineered to make the whole caboodle sound technically impressive. Thus you are spared “milestones”, “norming” (the team-building stage where conflicts are largely settled and a group identity starts to emerge, apparently), “critical path analysis” or the “precedence diagram method”, which has little rhythm for us. Let’s keep a clear head here.

Indeed, clarity is an essential component of project management. (This is not, by the way, to suggest that fogginess, confusion or obfuscation can be virtues in other aspects of management despite what you may consider the better efforts of your seniors to prove otherwise.) It should be defined as a significant piece of work that stands outside the organisation’s main activities and has set objectives. Simply put – you need to know why you’re doing it, how you are going to achieve it and what you can expect as a result of it. Too easily a project can be fuddled because its objectives originate from poorly defined or vague needs.

Equally it is almost as crucial to determine what the project is not about as to outline what it is meant to achieve. For example, installing a new IT system to carry out a specific function within your organisation will almost certainly have strong connection to other areas of

activity. Once the project has kicked off, you may well realise there are other technological deficiencies elsewhere. The temptation will be to attempt to solve them at the same time by drawing them into the project. This would be a mistake because it obscures the original objectives the project sets out to achieve.

You should then take some time to prepare your business case for the project. This is what someone who is really important (either in reality or in their own perception) would call, without so much as a bat of an eyelid or a by your leave, the “strategic justification”.

The case for the project should include the cost, time and people involved, potential pay-back, risks (what could go wrong and how can you counter or limit this), options (with your preferred choices) and the operational impact. Once the case has been made and agreed you should prepare the project brief (and “brief” should be your watchword). This should be done in consultation with stakeholders – including those identified to be part of the project team. How do you like your stakeholders?

Break down your project into manageable actions and decide in which order things should be done. Map out time scales: time lines can be a useful visual aid for this. Set targets and review regularly. There are a number of useful software packages available to help, although remember that computer programmes are not project management in themselves: they are tools for project managers to use.

This is where, particularly for larger projects, the value of a strong “project board” really shines through. By bringing together a group of senior managers to give vision and leadership to the project, organisations can ensure their project teams see the wood, not the trees, and that their full objectives are met. It’s also useful to have the team evaluating its own performance.

Thus the key to robust project management is effective leadership, user involvement and a structured approach.

John Belcher is chief executive, Anchor Trust; Claire Smart is purchasing manager, Gloucestershire Council social services department.

Top tips

• Set out clear objectives and stick to them.
• Make a start – planning can become a project in its own right if you let it.
• Be realistic about what’s achievable.
• Get a rich mix of people in the team – projects needs crazy artists as well as obsessive/compulsive types.
• You can never refer back to your objectives too often.
• Make sure that project team members are given enough clear time to carry out the task.

Rubbish tips

• Do it all yourself.
• Accept anyone who puts themselves forward (or departmental “odd gloves” who are put forward).
• Agree to additional project objectives as you go along – it’s good to keep in senior managers’ good books.
• Let computer software do all the work.