Introduction to 'why' and 'what' in Project

Understanding the 'why'

Everything you do, you do for a reason, and doing a project should be no different. Essentially, the reason you are doing something is the answer to the question 'Why are you doing this?' 'Why?' is simple and easy to ask, yet the answer can alter what you do, how you do it, and how you think about something. It is, unfortunately, a question that we do not ask enough.

In established businesses the definition of why something is done often exists in a formal document known as a business case, and may be called the business rationale or business benefit. Alternatively it might be called the business objective. Whatever it is called, you only need a concise understanding of why a project is being done – a short statement or one sentence is usually enough. The purpose is not to verify the definition of why, but to get an understanding of it.

Defining the 'why' needs to be precise. Small differences in the definition can make significant differences in what you end up doing. For example, the following two statements are quite similar, but what you would do as a result could be significantly different:

To improve our shops to increase sales per square foot.

To improve our shops to align with our high-quality brand image.

To fulfil the first, your project might fit more shelves into the shop, whereas in the second you could end up doing the opposite and having less in the shop and making it feel airy and stylish.

A word of caution: often people start out by knowing what they are going to do, because this is what they want to do irrespective of the reason. When asked the question 'why?', they make up an answer that fits the situation and which is most palatable to the person they are talking to. This is dangerous as someone else hearing the 'why' may determine to do a completely different 'what'. For example, a business colleague may say the reason he is raising his prices is to increase his margins by 10 per cent. If he really wants to increase margins and not revenues, then this could also be done by reducing costs. If he asks someone to increase margins, on the assumption they are going to increase prices, he may be surprised when he finds that instead some staff have been fired to reduce costs.

The answer to the question 'why' is fundamental and should not be engineered to fit the 'what' – 'what' must be derived from it.

It is often argued that if you are responsible for the 'what', you do not even need to know the 'why'. Many project managers only ever discuss what the project is, and never why they are doing it, which is short-sighted. You can say you don't need to understand why you are doing something and still do it quite well. This is sometimes true, but often it is very useful to understand why you are doing something. It helps to motivate and drive you and other members of your project; most people perform better not when they blindly do things, but when they know why they are doing them. Knowing why you are doing something also assists in checking what you are doing is actually worthwhile and in ensuring that you are making the best decisions as you go along.

I have seen many projects in which people have got so fascinated or bogged down in doing what they planned to do, that they did the wrong things because they didn't know or lost sight of why they were doing it. For example, I remember a project involving moving staff from an office to a new location. Responsibility for finding and negotiating a contract on offices was duly handed out. The department responsible for new offices focused excitedly on the core negotiations with landlords. They did what they thought was a fantastic deal, and got bargain-priced offices in the new location.

However, one of the reasons the project was started was to improve staff morale and retention. Staff morale and retention problems arose because of the old office location, and also because of the environment in the offices. The new offices weren't bad, but they did not live up to the expectations of an exciting new environment which had been set with the staff. By taking on cheap offices, staff morale declined rather than improved! The negotiator did a very good job if the 'why' had been what he assumed it was, 'save as much money as you can on our rent'. Had the negotiator kept his eye on the real 'why', the deal done would have been very different.

Understanding the 'what'

Once you know why you are doing your project, you need to understand what the outcome or deliverable from your project must be to enable you to achieve your 'why'. For example, if the reason why you are doing your project is to increase your company's sales, then what you must deliver must be something to increase sales – such as a new product. Alternatively, if the reason why you are doing your project is to allow your business to expand, then what you must deliver is whatever will allow your business to expand – such as new larger offices.

It is obvious that to complete a project you need to understand what it is meant to deliver. However, we don't always think the obvious and too often jump into doing things without worrying if they are the right things. If you have ever started a project without understanding what the purpose is, don't worry, you are in good company. If I was given £50 for every project I have reviewed and found out that no one really understood what the outcome of the project was to be, I would be a very wealthy man.

If you get the Project Definition right, you will make the rest of your job much, much easier. If you don't, you are risking disaster. The time to get it right is now.

Defining 'why' and 'what'

1. Complete the Project Definition

So, how do you go about defining what the outcome of your project is to be? This is what project managers call scope. The way you understand the 'why' and 'what' is by asking a series of simple structured questions and then by making sure that the answers are agreed with the relevant people.

The questions are:

The key questions you should ask are:

• Why do you want to do this project?

This needs to be a clear statement of the reason why you are doing the project – what you will be able to achieve when you have done the project that you cannot achieve now.

• What will you have at the end of this project that you don't have now?

This is the fundamental question. You are doing a project to deliver something. This may be some tangible object like a new house, or a new product launched; it may be something less tangible, such as creating a useful new piece of computer software. Finally it may be something completely intangible such as a change in people's attitudes. (If this sounds too nebulous, remember this is essentially what a marketing campaign does.)

One way to think about your deliverables is to ask yourself 'How will I know when the project is finished – what will I have that I don't have now?'

• Will you (should you) deliver anything else?

You know from the first question what you are setting out to deliver. However, is that really everything? If you think about it, there may be other things you need at the same time, or which it is sensible to do whilst you are doing the work on the main project. These need to be included in your Project Definition.

Be cautious answering this question, as the temptation can be to throw everything in and keep expanding your project. It is perfectly legitimate for the answer to this question to be 'No'. A project should not be a dumping ground for everything you might want to do. It is a structured way to achieve a specific goal. If it really makes logical sense to include other things, or if they are fundamental to achieving your original 'why', then go ahead. Otherwise say no – if your customer wants more and more put in, the response should be 'I can do anything you want, but the more you put in the more it will cost, the longer it will take, and the greater risk that something will go wrong.' That usually helps to get some focus!

• Is anything explicitly excluded from the project?

Sometimes there are activities and deliverables, which for one reason or another, you want to exclude from the scope of the project, which otherwise might be thought to be included in it. It is worth being very explicit and noting these down as the scope is as much to gain an understanding of what will not be delivered as what will be.

• Are there any gaps or overlaps with other projects – or changes to the boundaries of your project?

Often when you start a project, you find that there is someone else doing something similar or related already. Your goal is to get something done, not to do it twice. So find out if this other project will do part of your work for you. If it will, and it will do it in the timeframe you need, you don't need to do it as well.

Alternatively sometimes more than one project is kicked off at once, with the intention of the deliverables from all the projects coming together to some greater goal at the end. This set of related projects is what project managers call a programme. For example, while you are developing and launching a new product, a colleague may be re-fitting your shops to be ready to sell the new product.

The aim is that your two projects come together so your new product goes into the shops fitted out by your colleague. Unfortunately, often when two or more projects like this are finished and you try to make the deliverables from all the projects work together, they don't work or there is some gap. If there are several related projects, then someone called the programme manager – essentially a super project manager – has to look at the Project Definitions for all of them and make sure the bits add up to the overall objective you have. If not, other deliverables must be added to one or more of the projects.

• What assumptions (if any) are you making?

We all make assumptions, if we didn't, we would never get anything done because we would be frantically proving everything before we could move on. However, when you make assumptions in a project, you should do so consciously and note them down. The point about assumptions is that they can be wrong. Take an everyday life situation: when you tell your father you will visit him next Saturday you are making a series of assumptions.

For example, that nothing more important comes up that will stop you going; and that your car will be working on Saturday. Normally you would not think too much about this. If however, you were not visiting your father, but a key customer, and if you do not make it you may lose a £10 million contract, you will start to think through, verify these assumptions, and may even put some plan in place in case they turn out not to be true.

Note the assumptions and ask yourself – is it really a reasonable thing to assume? Even if it is, you need to keep it visible as the state may change which can undermine your project. Typical examples of assumptions that people make are:

• The operations department will provide the necessary resource to implement the deliverables at the appropriate time.

• Our existing supplier will provide the additional components necessary at or below existing prices.

Each of these is probably reasonable, but could in some situations be wrong, and if they are wrong, they would alter the cost, timing or approach of the project.

• Are there any significant problems you are aware of that you must overcome?

Almost every project has some problems and challenge to overcome – if it didn't you might not need a project in the first place! When you start out you should note down anything significant. This is not an attempt to get a complete list of all possible problems but you should capture the ones you are aware of, as they may impact the way you do your project.

What does 'significant' mean in this situation? A significant problem is one that will materially affect the cost or time of the project, or change the way you approach it.

• Has the customer, or the situation, set any specific conditions on the way you do this project?

If you are starting a project, it is nice to have complete freedom as to how you do it. This is rarely true. Often your customer will have a fixed time in which it must be completed, or a maximum cost. Conditions come in many forms, for example there are rules, guidelines, regulations and legislation about the way you must do some things (such as health and safety rules).

It is important to note you are not yet saying you can complete the project with these constraints – merely that you understand them.

Check your role – are you responsible for achieving the 'why' or making sure the 'what' happens?

To be successful in completing your project, you need to know what you are responsible for. Consider the simple example that– you are decorating the front room. Remember the reason for this was to get the asking price for the house you are selling. You must start by understanding whether you:

• Are only responsible for decorating the front room? (what) OR

• Are also responsible for ensuring the house achieves its asking price? (why)

Normally, as a project manager, you will be only formally responsible for achieving what you have specified, not why you are doing it. You should understand the 'why' but it is not your job to achieve it. Do check this though. Sometimes your customer may expect you to be responsible for the 'why', which in business is usually called being responsible for the business benefits, or the benefits realisation. If you are responsible for the benefits, you should pretty quickly start asking yourself some subsidiary questions, such as:

• Is decorating the front room really the best way to achieve the asking price?

• If decorating the front room does not achieve the asking price, what do I do then?

If you are only responsible for decorating the front room without worrying about whether it achieves the asking price or not your life is a lot simpler!

2. Agree the Project Definition with your project customer

Completing the Project Definition is straightforward if you are working for yourself. It takes some good quality thinking time and should not be done in a rush. Do not under-estimate how much thought needs to go into your Project Definition. If you are unclear about any of the parts think about it some more. Whenever you start a project with the definition being incomplete, you are at the very least adding to the risk it will go wrong. It is like starting to build a house without any drawings of what the end result will look like. Any mistakes you make now will be magnified by the time the project is complete – so get it right now!

When you are managing a project for someone else, completing the Project Definition can be harder. People are often surprisingly vague about what they want, other than they know they want something. Give them some time – and when you have completed a first version of the Project Definition, sit down with them and talk it through, trying to get them to understand the implications of their choices. For example, by asking questions like:

• Do you really want purple paint? Of course I can do it, but are you sure it will help sell your house?

• Do you definitely want to sell the product only in the area – won't that inhibit overall sales?

• You want me to get new offices for the existing staff but that might not be enough for the future. Don't you want me to consider our expansion plans whilst I am doing this?

However, remember that it is your job to get the project done, and if the customer knows what he or she wants, and has been given the chance to think through the implications of their choices, then as long as they are happy you should be too.

Unfortunately, people often change their minds and later say they want something different. More annoyingly, the customer may say you are not doing what they originally asked for. To avoid this, ask them to sign off the Project Definition once it is completed. This is not just about protecting yourself, but also about getting the right level of input from your customer. Experience shows that people put more effort into and take more seriously things they sign.

When you have multiple customers for one project, it can be problematic to get agreement to the definition of the project. For example, a marketing person may say 'the new product you launch must be of the highest quality to be consistent with our brand', whereas a sales manager may say, 'to shift the volumes we want, we need something cheap and cheerful'. Differing views about projects can be quite fundamental. You thought you were just going to deliver a project and suddenly you find yourself as the arbitrator in a dispute! Project managers often have to facilitate such negotiations. The best way is to get all the customers into one room at the same time. Go through the Project Definition line by line, discuss and work on it until you have full agreement – and get them all to sign it. This can take some time but it is time very well spent.

Thanks