Identify objectives

 

 

Where are we?

Well, obviously we are near the beginning of the project, but it is worthwhile remembering what comes next: after identification comes definition, not the delivery of the project. This means that the identification phase is not a huge decision point on the project. It simply allows the project manager to understand the project a little more, in order to carry out more detailed planning. The big decision comes after the definition is complete, as by that stage all the key players will have a much better understanding of the project.

The identification phase for an Olympic Games project would take months, and involve many high-powered resources. For a smaller projects we might be talking about just a few days (for a 3 month project), or 30 minutes (for a 3 day project). In all cases, however, the vital few items to understand, document and agree are the same.

Many project managers make the mistake of trying to understand everything at this early stage in the project’s lifecycle. This is not only unnecessary but also dangerous. The more detail we have now, especially about our proposed delivery approach the more we might be limiting our options.

It is most important to understand the ‘what’ and ‘why’ (and obtain agreement that your understanding is correct) before you waste any time planning what might be the wrong thing.

It can be very embarrassing to have to retract a plan issued too early. It starts to erode your credibility. So, sort out the ‘what’ and ‘why’ first, and then do the planning which will sort out the ‘how’, ‘who’ and ‘when’.

The table below shows the way in which the vital information about a project is identified and documented in a particular sequence.

 

	Phase	Technical term
Why	Identification	Objectives
What	Identification	Scope
How	Definition	Schedule
Who	Definition	Schedule
When	Definition	Schedule

 

End-date driven projects

Of course your sponsor may have already told you the when. Actually, the sponsor may have already told everybody else the when as well! Target dates are often identified and published before the project really starts to take shape. There may be excellent reasons for this. Maybe the law is changing on a particular date, and without your new website changes, or HR processes, or whatever, the organisation will be in trouble.

No amount of complaining on your part can alter the fact that sometimes the target date is outside your control, and you have to use your skills to deliver by that date. Just make sure that you discover this commitment during the project identification!

 

The sponsor

It is always useful to consider why a sponsor (your boss, for example) asks you to run a project on his/her behalf. If we forget any devious or evil intent (!) there are only two possible reasons:

• The sponsor could run the project themselves – they have the skills and technical knowledge, but not the time, so you are being asked to do the detailed work on the sponsor’s behalf.

• The sponsor does not have the skills or technical knowledge to run the project, so you are being asked to exercise your skills to run the project.

In both of these cases you should be aware that you are being asked to do two things. Obviously you are being asked to deliver the desired outcome of the project, but equally importantly, you are being asked to do the second-level thinking for the sponsor (remember, he or she either hasn’t got the time or the knowledge to do this for themselves). The role you are taking on is ‘project manager, not ‘project slave’.

This means that you must assume that whatever the sponsor tells you should not be accepted blindly but thought about, tested, validated and challenged. If you find that one of the things the sponsor wants you to deliver just cannot be done then the sooner you identify this and go back to the sponsor with some viable and effective alternatives, the better.

If you assume that ‘the sponsor knows nothing’ then this will be a safe attitude for you to take. Obviously this is not meant to be rude, but a good defence mechanism for the project manager.

Every project has two ends; a cheap end and a very expensive end. Asking questions at the cheap end may feel cheeky and dangerous, but try asking them at the expensive end!

 

Some questions to ask

Start the identification process by asking questions. You may have been given something in writing to start the ball rolling, but it is essential that you start to think not just about the immediate project but also the surrounding business environment. You may be able to go back to the sponsor to ask these questions, or, at worst, you ask them of yourself and try to find answers yourself.

The answers will be very useful in helping you to decide how to approach the project. If you ask a question and cannot get an answer this is also valuable, it shows that there is a risk in the project caused by unknown factors at the outset. Not asking the questions will be your first mistake; many more will follow as a result of your going into the unknown.

There are 11 groups of questions, with subsidiary questions in each group:

• Time constraints

• Is there an end date? Is it fixed? Who fixed it? How fixed is it? Is there a constraint on the start date? Are there intermediate dates that must be met in some way? Are the constraints on the availability of key personnel? Is it month, quarter or year end?

• Project profile

• Is the reputation of the company, division, management team or you at stake? Is there likely to be on-going high-level or external interest in the project? Will the project be accompanied by publicity?

• Costs and Benefits

• Has a cost/benefit analysis been carried out? How long ago? By whom? On what basis? Do you have to stick to it? What assumptions were made? Are the costs constrained or prioritised?

• Business risk

• How badly will the organisation suffer if the project fails, or the final end product does not perform as well as hoped? Will there be a knock-on effect elsewhere if we fail?

• Project scope

• How many business functions are involved? What has been left out? Has this been agreed? Which locations are involved? How will this project interface with other projects, and what plans exist for those projects?

• Project scope

• How many business functions are involved? What has been left out? Has this been agreed? Which locations are involved? How will this project interface with other projects, and what plans exist for those projects?

• Background

• Is this a new business area, or the first time that the business area has come into contact with the project team? Have we done anything similar in the past? What happened? Are we taking over something that has already started? Why? Are the key players up to speed with the project?

• Requirements

• Is the customer clearly identified? Is the customer different from the end user of the project deliverables? Are the requirements likely to be well-known, understood and constant during the project? Are the requirements flexible? Is the customer prepared to commit to the requirements?

• Involvement

• Is there commitment at high level? How does this manifest itself? Are the key management players aware of the potential size of their commitment?

• Technology

• Is the technology in place? Will it be installed during the project? When, in relation to the project? Has it been ordered? Is there any fall-back? Is a specification available? How many suppliers are involved? Who is responsible for connecting the components together? Is the technology new to the eventual end user, or the project team? How reliable must it be? Can reliability be established before operational use?

• Resources

• Is it possible to identify what disciplines are needed, when and how many? Are the skills available in-house? Contractors? Out-sourcing? What training is needed for this project? How likely is it that resources will be made available? Are these resources aware of the project? Will they be full-time or part-time? What other commitments will they have? What are the relative priorities? Who will resolve disputes? Who will have management authority over the resources?

• Project management

• How will the project be managed? What support might be available to the project manager? What standards and quality processes are in place? Are these understood and used by the project team?

On the Lake case study project no-one has any real idea how many fish there are in the lake, and how well they might survive the draining and refilling operation.

It may be a good idea to commission Herb Erriott (the environmental scientist) to carry out a detailed survey before you start, just to set some baselines.

Using the answers

Having asked the questions you can now begin to understand the shape of the project. For example:

• if you discover that the target is absolutely fixed for legal reasons then you might consider adding some contingency plans into the project, whereby you create a standby solution as well as the main project outcome, just in case you are delayed.
  

• you may discover that certain technology will not be fully available for your project. By realising this at an early stage you may have enough time to investigate alternative technical solutions that do not rely on the suspect technology.

 

Starting the project brief

Once you have the answers (or indeed, no answers) you can start to draft a document called the project brief. Note the word ‘draft’. You can only ever draft this document, it will never be final until the sponsor has accepted it. This is also a guide as to how to produce this draft document – talk to the sponsor as often as possible throughout this short process.

There is one other document that you should be creating and maintaining right from the start of the project identification, and that is the assumptions list. This is a vital part of your project documentation. Most people start a simple spreadsheet as soon as they start working on the brief and keep this updated as the project unfurls. The uses of such a list are described at the end of this chapter. We will examine each part of the brief in turn.

 

Project objectives

Objectives should set out what we are trying to achieve and why. There may be several objectives and, if the sponsor is on the ball, they may be prioritised.

Objectives should state measurable targets for what the project needs to deliver in order for the business to achieve the required business benefits. The actual achievement of the business benefits is normally outside the scope of small, simple projects.

For example, if your project is to create a new meetings room booking system that will save €10,000 every year for 5 years, you cannot be held responsible for the delivery of savings of €50,000 over 5 years (the business benefits).

You will not be running the bookings system, so the achievement of the business benefit will be beyond your influence or control. It will take 5 years after your project has ended to prove this benefit. This is not part of your project, but it is the ongoing business responsibility of the sponsor. He or she will need to be satisfied that the new bookings system you have created has the potential to save €10,000 per year for 5 years. You must be able to demonstrate this as part of the project closure.

Your project objectives must be detailed enough to ensure that the business benefits can be achieved.

For example, if your project is to introduce a new training record form for your department and the objective is stated as ‘to introduce a new training record form for the department’, then almost any form will do, even if it causes nothing but trouble for the department staff.

You need to know what business benefits are expected from introducing this form. These might lead to the more precise objective: ‘to eliminate duplication in the department’s training and development planning by implementing a system that records up-to-date and accurate information about staff training.’

OK, so this new objective is longer than the first attempt, but it links your project to the wider business objective of improving resource development and planning. Clear project objectives not only give you a target to aim at but will also help to direct the design of the solution.

Since your objectives should focus on what the sponsor hopes to achieve as a result of your project you cannot write the objectives without discussing them with the sponsor.

You may also ask the sponsor to prioritise the objectives, but some sponsors are reluctant to do this until the definition phase has begun. They want you to try for it all, and will only discuss compromise and reduced delivery when you can show, by your planning, that you can’t deliver it all.

The objectives opposite achieve three important things:

• We now know exactly why we are being asked to run this project

• We know what standard we have to work to

• We know how to provide independent proof that we have achieved our objectives (by conforming to ISO standards)

It may come as surprise that these objectives are short. Further detail will come in the scope and constraints sections.

 

Scope

This is an outline of what you will have to do to achieve the objectives. The list does not have to be detailed; in fact, if we make the list too detailed we may confuse people as it will begin to look like a plan and we haven’t done any planning yet.

It is also very useful to list those things which you are not going to do, in the form of ‘Excluded from scope’. It is always better to disappoint people at the identification phase (the cheap end) than to find out at project closure that they had been expecting something that you never meant to deliver.

Scope can be expressed geographically (e.g. the project will address meeting room bookings in the Manchester office), functionally (e.g. this project will only cover meetings rooms booked by the Finance department) or related to business processes (e.g. this project will not link the meetings rooms booking system to the Automated Catering System).

The scope for the Lake project may be: Included in Scope: Repairing the leak identified in the pipe under the lake (i.e. NOT leaks elsewhere) All aspects of fish and plants welfare (even though this may be delegated to the environmental expert, it is still part of the project and ultimately is the project manager’s responsibility) Restoring the water environment to acceptable standards Obtaining relevant permits and permissions associated with disposal of contaminated water and mud Excluded from Scope: All communications with the media and the Wildlife Trust (agreed that the sponsor will handle this outside of the project)

So there should be no surprises at the expensive end of the project. Everyone who reads this will be able to see what the project does, and does not, contain.

One of the interesting benefits if writing it down like this is that we may have got it completely wrong! The publication of the brief will stimulate a great deal of ‘validation’ of the project’s parameters. It is cheaper to find out now that we have misunderstood our scope than wait until we reach the expensive end.

 

Constraints

Very few project managers have a completely free hand in the way that they run the project. There are always factors that will limit the way we carry out the job and these are the project constraints.

The obvious constraints include time, money, materials, availability of team members, rules standards or processes that must be followed and availability of machinery or other facilities.

The questions you asked at the start of this process will go a long way to helping you identify the constraints. The constraints section of the brief is your way of proving to the sponsor that you heard all of the things that concern him/her.

The constraints for the Lake project are: Time: The job must be completed within the next 2 weeks There can be no noise or disruption to the Park House toilets system before 14:00 on Friday, and the works must be complete by 09:00 Monday Wildlife: The fish can live in a tank for 72 hours without feeding or aeration The plants can survive only if their roots are covered in black plastic, and then only for a maximum of 48 hours Budget: There is an initial budget of €15,000

 

Main deliverables

It can be a good idea to write down and agree the format and purpose (and possibly outline contents) of your final deliverables and any intermediate deliverables if this will help you.

For example, you may be asked to write a report about the use of business class air travel in your department. Well, anyone can write such a report, but without knowing how it will be used (the purpose) you could spend a lot of time and produce something that is useless. How about: a report into the increasing costs of departmental air travel, with a recommendation about future air travel policy.

Will the report be printed, or will it stay electronic? Is there a company standard for such reports? Will you distribute the whole report, including the detailed notes and analysis of 25 interviews, or will you produce a summary report for general distribution and an appendix to be called for by the enthusiastic few?

It might seem very early to be describing the final product, but the earlier you can get agreement about its acceptance criteria the easier it will be for you to plan how to deliver it.

Some deliverables are difficult to see or file at the end of the project, and we must resort to looking for evidence that an acceptable deliverable has been produced.

The real deliverables for the Lake project are ‘A repaired pipe’ and ‘Clean water’. Well by the end of the project the pipe will be at the bottom of the lake, so it can’t be seen, and although the water may look clean we must sure that the fish and plants agree with us.

So, for the Lake we will have to specify secondary deliverables, as follows: A certificate attesting that the pipe repair has passed ISO1234, signed by Bert Simpson, the foreman of Bodgitt & Duck, Engineers A certificate attesting that the water quality meets ISO9876, signed by Herb Erriott, Certified Environmental Consultant

These deliverables will be captured by the project manager and placed in the project file, for eventual acceptance by the sponsor at project closure.

 

External dependencies

Nowadays, in most organisations, most projects touch other projects, if only through the use of shared resources. Some projects are tightly linked together, almost as two parts of a larger project.

It is most important to understand how your project fits into the wider business environment, both as a sender (you may be producing something that goes on to another project elsewhere, and they are depending on you), or as a receiver (you may be waiting for something from another project, and you will be depending on them).

These links between projects are important. The work you do now during the project definition will set up a communication and control requirement. You must inform each other if there are delays that will affect a dependant project.

The principal source of dependencies is in shared resources. You may be promised someone to help you, but this will not usually be fulltime. The person will probably have to carry out their day job (the normal things they do from day to day) and fit in your project work alongside it. They may also be assigned to several other projects, not just yours, and it is important for you to be aware of this situation and its potential for problems later. By identifying the situation now and documenting it, you will be starting an early form of risk management.

 

An optional extra

One other thing to agree at project definition time might be tolerance, or ‘just how accurate do you need to be when running the project’.

For example, if you are running a project with a monthly budget of €10,000 will you have to stop the project if you are €3 over budget at one month end? The answer is most probably no. If you can reach agreement on some levels of tolerance with the sponsor then the project can run in a smoother manner, rather than stop/start.

Tolerance is often expressed in budget terms (e.g. €500 per month, or +5% per month), or time terms (e.g. a milestone can be 5 days delayed). It can be qualified with statements such as ‘tolerance of €500 per month will be allowed as long as the project manager can show how the project will be back on track by the next milestone’.
This arrangement can take the pressure off both the project manager and the sponsor.

 

What is the process?

Don’t refuse to start a project until the sponsor has written a brief! Remember project management law number 1 – the sponsor knows nothing. It is always best if the project manager drafts the brief.

Obviously listen to the sponsor. Go back to your desk and draft a brief. Take it back for discussion with something like: “just in case I didn’t fully understand what you asked for I’ve written it down; please take a look at it.” Once you’ve (both) developed a bit of experience at this it really won’t take long.

You will know that you’ve cracked it when the next time the boss wants you to undertake a small project he/she says “I know that before you start you will draft one of those briefs but let me have a look at it first.”

Best practice suggests that both parties should sign this document. You may not work in an environment where this is the norm; maybe you should start the process of building good habits and best practice in your organisation.

 

How long will it take?

For a small project (of say 2 weeks to 2 months, the drafting of the brief should take no more than an hour. This will be followed with a short conversation with the sponsor, at which agreement can be reached. So, for the investment of 90 minutes you can feel more confident that you are, at the very least, starting out on the right foot.

 

Assumptions

The very nature of a project is to create something new, something that didn’t exist before. This means that all management and planning activity is speculative, looking into an uncertain future and trying to guess what might happen.

As soon as you start the identification phase you will enter the realms of fantasy and guesswork. There is nothing wrong with this if you realise that this is where you are. Make a list of all the assumptions you make, and, where possible, their effects and implications.

The assumptions list will form vital input to the detailed project planning, risk management and project control.
Make sure that your assumptions are specific and reasonable. For example, an assumption that ‘everything will work according to plan’ is useless for practical purposes.

Many project management textbooks say that once a brief has been signed off by the sponsor there should not be any assumptions, as the process of discussion and agreement of the definition will clear up all of the unknowns. If only this were true. You will find that, when confronted with some of your assumptions the sponsor will look just as blank as you.

Why should the sponsor know any more about the detail of the project than you do? After all, you have been appointed to take care of the details that the sponsor doesn’t want to mess with. If you both agree that there are some unknowns in the project and you both accept that the project could start with these unknowns unresolved, then it is safe to start.

 

Summary

Most projects go wrong because the objectives and scope were poorly understood right from the start, and the project manager, eager to show just what he/she can do, jumped into the project without thinking about it.
Many bosses seem to prefer the project managers to be busy rather than sitting thinking about the project. Identification does not have to take much time, and only a fool would start out on a journey without knowing why or where they want to end up.

 

Checklist

Ask the strategic questions	Identify how the answers will shape your project
Agree the objectives with the sponsor	What the sponsor is trying to achieve with the project; why we are running this project now
Agree the scope	High-level statements of what is included and excluded from the project
Agree the constraints	Time, budget, resources, rules, etc.
Agree the deliverables	What is to be produced, and how it will be used
Agree the roles and responsibilities	Who is responsible for what (see next chapter)
Document the assumptions	And keep this list under review throughout the project

 

Further reading

Identification process

A process description for managing the identification phase in work ranging from medium complexity projects to programmes.

 

 

Thanks to Mike Watson of Obsideo for providing this book