Dealing with surprises

I expect many of you spend some of your time managing a project – you may have small projects to manage as part of your day to day job, or you may be asked to work as a dedicated project manager for the duration of some specific project.

The main difference between a project and ordinary work is that a project has a defined time limit or delivery date and specified end results that are expected by that date. This can be a real plus – you can see exactly what you have achieved and feel a real sense of satisfaction. On the other hand, projects can be pretty stressful – things never go as smoothly as the project plan might imply.

If you look at the "management" shelf in any station or airport bookshop, you will see lots of books on project management. There is no lack of theory – some of it quite daunting. Equally, there are many software packages used in project management, each with its own jargon. Talking to people who are very familiar with any piece of project management software is a quick recipe for feeling you don't know anything.

Managing a project
What I'd like to do over my next couple of articles is to give you some clear, basic tools that will help you come to grips with all the essential aspects of managing a project. You will probably then find that whatever models and software you use they can all be related to this basic pattern and approach.

I think the first lesson everyone has to learn about projects is that you must take time to plan what is going to happen. Even apparently simple projects can involve many different tasks which themselves involve many individuals or teams. And all these activities and people need to be kept on track and to time, to deliver something that makes the originator say, "Yes, that's exactly what I wanted." So however tight the time pressure, don't rush into action; stand back and do some planning. You may remember me talking in my first article about the value of having a common, systematic approach within a working team. The planning of this approach had four stages:

• Aims
  
• Information
  
• Deciding on the main sub-tasks
  
• Planning in detail

These stages can be expanded to give a firm basis for project planning. This month, I will take you through the aims step.

Projects can be pretty stressful – things never go as smoothly as the project plan might imply

The cornerstones
Good aims-setting for a project involves looking at four things.

• Key factors: who is the sponsor, the end user, and any others who are involved in or affected by your project?
  
• Purposes: what is the project for? What will it achieve? Why is it wanted?
  
• End results: what are you supposed to deliver at the project's conclusion? What is the detailed specification of the project?
  
• Standards: what standards are you expected to meet in terms of time, quality, cost and operational standards?

Don't try to sort out the aims of your project on your own. It's important to talk to the sponsor and to the people who will finally have to use the output of your project. What are they expecting? What do they hope for? (and fear!) Don't expect everyone to have clear answers from the start – things will evolve, standards may change, and circumstances outside your project may change and have an impact on what you need to do.

Clarifying aims can take several months, particularly if there is a multiplicity of stakeholders. The old excuse that "the goal posts have been moved" doesn't work. These days, the goal posts are bound to move, and it is part of your job as a project manager to check your project aims at regular intervals. Any change request that has any relation to any of the agreed aims needs to be documented and retained. The project manager must do this.

Instances where projects have changed greatly over time because clients have changed their minds about the deliverables are legion. Often such changes result in delays that are unacceptable to the client (who is insisting on the change in the first place). The polite technical term for this phenomenon is "scope creep". The good project manager, when faced with a request for changes to the scope of the project, will always tell the client the consequences of fulfilling such requests. "This could delay the completion work," and, "this will have an impact on the drainage works," are two good examples of explanations of the consequences of change that might be offered to a client.