Introduction

Project managers create structure and reduce risk by developing clarity and removing uncertainty and ambiguity. They understand the goals, deliverables and scope of the project. This understanding is written into a document known as a project definition, project scope, project initiation document, or some similar title.

Creating a project definition can be tough. Often project customers know they want something, but they are not sure what it is, or cannot explain it in a clear way. Different stakeholders may have incompatible views of the project. Understanding how the project should be defined is made easier by asking well-structured questions.

The definition may be reached quickly and be stable for the life of the project. On the other hand, the whole project may be an exploration in which the definition continuously modifies as the project progresses.

Project definitions have to be sufficiently detailed to allow the project to progress. As the project progresses, the level of detail needed increases. This detailing of definitions as a project progresses is called progressive elaboration. If components of the project definition change, this is controlled via change control (see Chapter 10).

Determining project objectives

It is essential to have a clear understanding of a project’s objective(s), as it sets the direction for the whole endeavour. An objective should answer the question why the project is being done, but not what or how it will be done. A project should have at least one objective, written in the form of short statements, sometimes only one sentence long.

Objectives are best defined with input from stakeholders and the project sponsor.

1. Start by thinking through why the project is being done. What will it achieve? This should not be a broad intention, but a specific, unambiguous and clear goal. Discuss the objective with parties interested in the project.
2. Ask the question – if this objective was met would the organisation be different from how it is today?
3. If there are multiple objectives are they consistent and compatible? A project to increase staff satisfaction is not usually compatible with one to reduce headcount, whereas a project to improve customer satisfaction is compatible with one to improve product quality.
4. Write down the objective. If you cannot write it down it is not yet a useful or usable objective.
5. You should be able to write it in one or two sentences. An objective that takes several lines to write down is usually not one but multiple objectives. If your objective is long, separate it into its component parts.
6. Make sure that the objective is of sufficient quality. Get the wording right. A quality objective is:
   • correct
   • clear
   • meaningful
   • unambiguous
   • concise.
7. Do a common-sense check – is this objective something worthwhile for the organisation to achieve?
8. Review and confirm the objective with the project sponsor and key stakeholders.
9. Produce a final documented version of the objective(s) and put it under change control.

Exploring customer needs

Understanding customer needs can be difficult. Customers do not always know what they want, can’t explain it, and disagree among themselves. It is rarely a matter of a quick chat during which customers state all their needs. Needs have to be explored.

An understanding of customer needs supports the development of the project scope. It is not yet necessary to have a detailed definition of every aspect of the project’s outcome. In some projects the definition of customer needs will be enough to deliver the project, while in others detailed and specific definitions of what deliverables must achieve are required. These detailed definitions are known as requirements (see page 77).

1. Identify the project’s important stakeholders (see pages 56 and 166). You cannot talk to everyone who might have a view on a project, but must select those whose views are critical. Agree who the key stakeholders are with the project sponsor.
2. Start to understand needs, by asking the project sponsor and key stakeholders:
   • What are your goals in pursuing this project?
   • What will you be able to do when this project is over that you cannot do now?
   • What shape or form do you expect the deliverables to have?
   • Do you require a specific set of deliverables, or do you require the capability to do something?
   • How do you envisage the deliverables being used or applied in real life?
   • Are these completely unfulfilled needs, or are they needs that are partially fulfilled now?
   • What other expectations do you have?
3. Determine the customer needs with regard to:
   • Maximum project budgets and time frames.
   • Their level of personal involvement in the project.
   • Type and scale of resources they may be willing to provide, including project team members.
   • Risk they are willing to accept – both in terms of the project itself and of disruption that the project may cause.
   • Any other specific needs or constraints upon the project.
4. Identify any conflicts or incompatibilities of customer needs. With the help of the project sponsor, resolve them.

Discovering success criteria

The word discovering is used deliberately. Although success criteria may seem obvious, it is only after some time that they are fully understood. Success is a slippery concept and opinions on it vary.

Having success criteria enables you to answer the question – how will you know when you have achieved your objective? If you can’t answer this question, it is impossible to know if you are doing the right things. Answering this question at the start ensures that the project is designed to meet the success criteria.

It is easy to assume you have achieved an objective because you have done some tasks, but to be really successful you need to have some way of measuring the impact of the actions you have taken. Some examples of success criteria are:

• The project plan uses the planned amount of resources over the planned schedule.
• The project creates the deliverables that fulfil the defined customer needs and requirements.
• The project meets quality standards such as ISO 2000, or it works in the expected way to expected project management process, e.g. a company-defined process or a standard method such as Prince 2. (Prince 2 is a widespread process-based project management methodology, originally developed by the UK’s OGC (Office of Government Commerce). It is often mandatory in public sector projects in the UK, and it is fairly common in the private sector too.)
• The project meets its business case.
• The project achieves stakeholder satisfaction. The project delivers what is expected or needed by the stakeholders in a way that they are satisfied with.
• The project is the right project to choose. (This is a measure of success in applying portfolio management rather than a measure of success in applying project management.)

Success criteria can only be determined by dialogue with project stakeholders, who may have different opinions. The project sponsor should be the overall owner for the success criteria. Success criteria can be determined by:

1. Identifying the project’s important stakeholders. (See pages 56 and 166.)
2. Working with the stakeholders to define and agree how success is to be defined.
3. Ensuring success criteria are documented and explicit.
4. Prioritising across and balancing between success criteria. Which are the most important? Are there any levels of flexibility in some criteria, but not in others? Remove any conflicts or ambiguities.
5. Agreeing when success will be assessed. Success does not happen at one time in a project but is related to events and accumulation of outcomes over time. Will success be measured during the project, when it completes, or afterwards?
6. Agreeing who will do the measurement, if success will be measured after a project is completed.
7. Performing ongoing stakeholder and expectations management through the life of the project. Success factors should be subject to change control.

Defining a project’s scope

The project scope sets the shape for a project. It defines the boundaries in terms of what is in the project and what is not. It provides a description of the outputs to be provided by the project. It explains what you expect to deliver to your customers when the project is complete. Scope provides a collection of information you need before you can develop an activity and resource plan for your project.

Organisations and methodologies often have template scoping documents. The best way to define scope is by trying to answer a series of questions that make use of the information created through checklists – see pages 65–69.

• What is the overall objective of the project? (See page 65.)
• What are the deliverables? (See page 66.)
  • Are you working to deliver a finite set of deliverables or provide some business capability?
  • Are you working to deliver a set of independent deliverables or an integrated end-to-end solution?
  • How will the quality of deliverables be determined?
  • Are there any deliverables required by the project that it is explicitly not responsible for?
• Are you working to implement a specific solution, or to solve a problem?
  • Are you responsible for the delivery of deliverables or for achieving the business benefits?
• How is the customer going to measure success at the end of the project? (See page 68.)
• What from the customers’ viewpoint can be modified?
  • Is predictability more important, or speed to deliver?
• Are there any other constraints on the project?
  • Are there any currently known issues, risks or opportunities?
  • Are there any external considerations?
• How does your customer want to work with you?
  • How will decisions be made on the project?
  • How high is the project in your customer’s overall priorities?
  • Can your sponsor allocate all resources the project requires or do other stakeholders need to be involved?
  • Who can legitimately put requirements upon the project?
• Are there any implicit requirements, assumptions or needs that the customer has that are not defined in the scope or requirements documents?

Exploring the iron triangle of time–cost–quality

The iron triangle of project management is made up of time, cost and quality. A project takes a certain time and cost to be delivered to a given level of quality (or scope). As there is risk associated with projects, project managers may have to change one or more dimensions of the iron triangle. If something goes wrong the project usually lengthens, costs more, or delivers less. To make the right decisions project managers have to know whether time, cost and quality can be modified.

Developing an understanding of the optimal balance of the iron triangle is best achieved by dialogue with project stakeholders. This understanding underpins planning and management of a project.

1. Determine any absolute boundaries for time, cost or quality, e.g.:
   • Is there a cost at which the project’s business case is no longer valid, or a maximum amount of money available?
   • Is there a point in time after, which, if the project is delivered late makes it worthless?
   • What is the minimum level of quality or scope acceptable to customers?
2. Explore, with the project sponsor and key project customers, general preferences for flexibility:
   • If you had no other choice would you prefer to change the cost, the time or the quality of the project?
   • Try to understand the degree of trade-off preferred, e.g. would you rather the cost increased by 5 per cent or time by 10 per cent?
3. Find any limits to the three areas:
   • How much can time, cost or quality shift under the project manager’s discretion?
   • How much can time, cost or quality shift under the project sponsor’s approval?
   • What are the boundaries at which it is essential to receive stakeholder approval to exceed?
4. Factor this information into developing the project plan and making day-to-day decisions on the project, e.g. if there is a problem is it better to invest a little more resource to overcome it, let it delay the project, or avoid it by reducing the project’s scope?
5. At periodic intervals on a long project discuss time–cost–quality with the project sponsor to ensure the right balance is being maintained.

Tips for collecting requirements

Whereas a need is a general statement, a requirement is a precise definition of some facet of a deliverable. For some projects there can be hundreds of pages of requirements. In others, requirements may only be a few lines.

In complex situations, requirements collection is not the job of the project manager, but is the role of a business analyst. Business analysts have many ways of identifying requirements. This list just provides some high-level tips.

It is important to understand the difference between a requirement and a solution. A requirement defines what a customer needs, it does not define how the customer achieves this. For example, a requirement might be ‘I need to keep food cool’; a solution to this could be ‘I need a fridge’. ‘I need a fridge’ is not a requirement.

Requirements define project deliverables. They include descriptions of what a deliverable should be able to do, called functional requirements, and definitions of how well the deliverable will work, and include quality, performance and operational aspects called non-functional requirements.

Collecting requirements is theoretically simple, but in practice can be very difficult:

1. Identify stakeholders.
2. Determine requirements by interrogating stakeholders. Start early: the earlier you get requirements right, the easier it will be to manage and deliver the project.
3. Analyse requirements – explore and understand individual and cumulative requirements.
4. Document and create requirements specification.
5. Remove conflicting or contradictory requirements and those outside the scope of the project.
6. Ensure that requirements are specific. Vague requirements are not usable.
7. Review requirements:
   • It is often necessary to reduce the requirements. Requirements are prioritised relative to each other. The more a requirement contributes towards the project’s objectives, the higher its priority. Requirements can be broadly prioritised by categorising them as shown on page 77.
   • Requirements not relating to achieving the project’s objectives should be eliminated.
8. Accept requirements:
   • Stakeholders sign off that the requirements are a true representation of their needs.
   • Project manager or sponsor signs these off as the requirements the project will deliver, subject to change control.

A tricky issue is deciding when you have collected enough requirements. Stakeholders can come up with additional requirements for a long period of time. At some point, requirements collection must stop so that the project can progress. Deciding that there are sufficient requirements is a matter of judgement. If you are unsure, ask the question – if you meet this set of requirements will it produce a meaningful deliverable that will meet the original objectives?

There are various ways to determine requirements, including:

• Interviews and asking structured questions.
• Brainstorming and other facilitated group sessions.
• Showing examples and prototypes – If it looked like this would it meet your needs? What needs to change?

Requirements have to be usable to be helpful to the project. Good requirements are:

• understandable and unambiguous
• meaningful
• correct
• well structured
• traceable to their source
• testable
• comprehensive and complete
• such that they meet the objectives of the project.

Filtering and prioritising between requirements

Projects must be practical and achievable. Requirements collection usually produces more requirements than can be fulfilled in a reasonable time and cost. Some requirements must be filtered out.

The steps in slimming down your requirements list are:

1. Link requirements back to original objectives. If a requirement does not help to meet an objective it should not be included.
2. Categorise the requirements:
   • ‘Must be included’ – if these requirements are not included the objectives will not be met.
   • ‘Should be included’ – if these requirements are not included the full potential of the objectives will not be achieved.
   • ‘Nice to have’ – these are helpful requirements, but they do not achieve the original objectives.
   • ‘Should be rejected’ – these are requirements which are inconsistent with the original objectives.
3. Slim down requirements against capability to deliver.
   • Remove the ‘should be rejecteds’.
   • Remove as many of the ‘nice to haves’ as required to reach a sensible scale of project. Focus on removing the requirements that are most complex, expensive or risky to deliver.
   • If necessary remove some of the ‘should be includeds’ as well.
   • Sometimes to slim down requirements one needs to develop several versions of a plan, depending on which requirements are chosen to be included or not. (See page 86.)
4. If you find you need to reject some of the ‘must be included’ requirements, go back and revisit your objectives with your project sponsor before progressing any further.
5. Create a revised requirements specification and maintain it under change control. (See page 165.)
6. Decide what you are going to do with the requirements that have been rejected. They should be stored for future review as unfulfilled needs. If you have a corporate requirements catalogue then they can be stored there.

Turning requirements into designs

In the project, requirements have to be turned into a design. A requirement is an understanding of a need and a design is the definition of the solution to this need. The process and terminology of design are context-specific. A building project would design a solution in a different way from an IT systems development.

At the simplest level, the steps to convert requirements into a design are:

1. Convert stakeholder requirements into a technical definition. The requirements are usually specified in non-specialist language. For someone like an IT developer to convert the requirements into software, they need to be written in relevant technical language.
2. Based on the technical definition, design a solution. This is a combination of a creative exercise and looking at existing solutions to see if they fulfil or can easily be tailored to fulfil the requirements. (This has a big impact on the project plan as it is a major part of the project.)
3. Review the design with the project customers to ensure that it meets their needs. This is an optional step, as in some situations the stakeholders may not have the skills to review a design.
4. Agree how the solution will be tested against the requirements when it is developed (see Chapter 8).

Designs can be developed with or without stakeholder input. Development approaches such as Agile encourage working cooperatively with stakeholders. Solutions designers are involved in requirements capture, they help stakeholders to explore requirements and remove any impossible or impractical requirements. Stakeholders are involved in design, which ensures it meets their needs.