Cambridge Technical Introductory Diploma in IT

(Unit 8 - LO2)

Be able to initiate and plan projects


Part - - -

Imagine that you have been asked to project manage the development of a new website for the catering outlet at a local college. The manager has told you that it must promote the different food and drinkoffered by the outlet and the special offers which are changed weekly. As he is leaving, he tells you that the college IT manager will be happy to host the site on the college system.

Produce a list of further information that you will need to gather before you can begin to plan the project.

2.1 Initiation phase:

The project leader will produce the initiation phase documentation. It will include:

The stakeholders, clients and target audience.

The stakeholders and clients will normally be those who will be affected by the success or failure of the project and its deliverables. The target audience may be doifferent and there may be also more than one; for example. government agencies. European funding agencies or local authorities may have to be kept informed aboutnthe progress and outcomes of the project.


This is the breakdown of the tasks and actions needed to achieve the project goal. It includes the boundaries of the project; it nis important to know what the project will not do as i is to know what it will.Many projects have failed because a team became side-tracked into looking into areas which they thought were interesting rather than necessary for success. When this happens, budgets, resources and timescales almost always collapse. (Click here for more information on scope creep; large and generally unplanned changes to a project that have significant impact on the deadlines and financial viability of the project.)

An effective scope statement is necessary to guide a project to successful completion. Learn about the different sections in a scope statement, and get hints on how to minimize scope creep.

Where to Begin

A scope statement is one of the most critical pieces of a project, and writing one can be a difficult task for a project manager – no matter what type of project management methodology is being used. But, an effectively written scope statement can help the rest of the project flow along with minimal problems. It is written after the project charter, and includes everything that the project is intended to produce.

A project charter is usually used for three different reasons:

  • Authorizing the project
  • Providing a high level overview
  • Identifying the main stakeholders

The charter often includes the name of the project owner as well as project sponsors. It also identifies objectives or goals, and constraints on resources or time. Finally, the charter is used as a focal point throughout the life of the project, which can be especially useful during change control meetings for minimizing scope creep. Scope creep is a phenomenon where the scope of a project gradually increases over time.

What's in a Name?

The name of the project be very clear and concise. An effective project name reads something like 'Create a Marketing Plan For Increasing Sales of Widget X in Chicago'. This is much better than 'Marketing Plan Project', which is definitely concise but by no means clear. The aim of the project name is to document the project so that everyone involved is aware of what is expected during the life of the project. A good project name also helps provide a vision of where the project is headed.

Writing the Scope Statemment

Now that you have the project charter and the name, you can start by filling in the project name, project charter, and a listing of the project owner, sponsors, and stakeholders on the scope statement.

Justifying Your Existence

Next, A project justification will need to be identified, as well as project requirements, milestones, and deliverables. Any non-goals - items that fall outside of the scope of the project - need to be identified here.

Project justification is simply identifying the reason for the project's existence. It is usually a statement or two identifying why the project is being created. It’s important to have the project justification identified because this helps to give overall direction to the project as well as emphasizing the final goal. The project justification should be clear and precise manner so that it identifies a quantifiable measure of success for the end of the project. An effective justification might read like the following:

This project is to create a successful marketing plan for the month of August 2008, in order to increase sales of Widget X by 15% in the Chicago metropolitan area. This is a good example of an effective justification because it is quantifiable and qualitative. Distinct boundaries are set as to what is the expected result of the project so there is no ambiguity.

How Much?

Finally, cost estimates need to be provided within the scope statement. This information may be readily available or it may need to be compiled from various sources, but the scope statement is where it needs to be documented all together. This can be a cumbersome task, but it is a necessary one. As the project progresses, everyone involved knows where they can look should a question arise.

Download an example of a scope statement by clicking here.

Requirements, Deliverables and Non-Goals

The next section in the scope statement should list the requirements of the project. The requirements are objectives that must be met during the project, and often they include significant milestones or goals. The objectives need to be quantifiable and identified clearly.

Any milestones or goals need to be also clearly identified, as well as any non-goals. Non-goals are items that are specifically not going to be addressed by the project, which helps to eliminate the scope creep. By clearly identifying these as non-goals, the scope cannot include them later on without going through a change management process. Ultimately, many project managers track their milestones, goals, and/or deliverables using a Work Breakdown Structure.

Thedeliverables for a project need to be clearly identified within a scope statement. If necessary, deliverables need to be tied to specific milestones in the project schedule. The deliverables also need to be agreed upon by the major stakeholders as well as the project owner.

Deliverables may include any training necessary for personnel at the culmination of the project. Or deliverables may be a final product to be provided to the stakeholders. No matter what makes up a project's deliverables, specific details regarding them is the golden rule. The more clearly the deliverables are identified and specified, the less chance there will be for scope creep to occur later on.

Cost estimates for the project should also be included in the scope statement. This is an essential process of project planning, so the cost estimates should be as accurate as possible. If the cost estimates are too low, the project will go over budget - sometimes significantly so.

If the cost estimates are too high, resources that are allocated to the project - whether they are money, equipment or people - are unavailable for other projects and could negatively affect them. So the more on track the cost estimates are, the more efficient and successful the project will be. This can be a difficult task for the project manager to do, but effective cost management is a critical success factor for projects.

Finalization and Acceptance

The last significant section of a scope statement is the formal acceptance signatures. Once the project manager has compiled all of the documentation into a concise and clear statement, all of the major stakeholders as well as the project owner need to sign off on it.

This is a very significant step and can be a very useful tool in mitigating scope creep as well. A meeting should be held where everyone can be provided a copy of the scope statement. At that time, any discrepancies can be cleared up or last minute changes can be made.

Once everyone signs off on the scope statement, there should be agreement between all parties and the project can begin. By having everyone sign the scope statement, there is very little chance of surprises down the road. And in the event that something does pop up, there is documentation of what was agreed upon initially so that changes can be made if necessary. If anything does change down the road and the scope does need to be increased for some reason, signatures should be obtained from everyone once more.

Exhaustively detailed specifics, clear and concise language throughout, and avoiding ambiguity are the keys to making a scope statement effective and useful. It is also very beneficial to have all of this information documented in one place - even if the process of creating it is enormous.

The task of creating a scope statement can encompass a great deal of time for any project manager, but the rewards usually include more successful projects and minimized scope creep throughout. And this can be a highly desirable benefit, as scope creep is often a significant cause of project failure. So document as much as possible, as clearly as possible, and make sure everyone involved is aware of what is expected. Through clear and concise documentation, a scope statement's usefulness shines all the way to project success.

Alternatively, this website is also full of useful hints and tips for the aspirint project manager, some of which applies to project scope.

How to Write a Project Scope Statement

Project Scope

I was once part of a project which went behind schedule and over budget. In response the project manager asked the project team to come up with reasons why the project was late. Naturally the team produced several reasons, and a change in schedule and budget was approved. Everything sounded like it was back on track.

This dance happens countless times at project-based organizations as well as with internal projects.

But it’s also a certain path to poor project performance. Scope defines the boundaries of the project, and if it is not actively defined and managed the project will undoubtedly go behind schedule or over budget.

Scope in Project Management

Because a project is defined as a temporary endeavor creating a unique product, service, or result, the project scope is foundational. It defines what work is part of the project and what is not. It establishes what the purpose of the project is, what it will accomplish and how it will accomplish it. Effectively, it defines the project.

Why Scope is Important

The Project Management Institute reports that adversarial scope changes are the single biggest cause of project failure. Poorly defined project boundaries, or boundaries that move throughout a project, can be project and career killers. This is a common occurrence in almost every industry, thus strong project managers must learn to define, communicate, and control the project scope.

Scope Statement

To avoid the unpleasant possibilities that result from a poorly defined project scope, project managers need to write out good scope statements. This will make it easy to gain acceptance of the project’s scope by the project’s stakeholders. It will also put the project team in sync, but most of all it will prevent unauthorized tasks from popping up within the project, thereby sucking up the project’s time and money (the evil “scope creep“).

There really is no substitute to defining the boundaries of the project in writing, so it is clear to everyone what is part of the project and what is not.

How to Write a Scope Statement

During a marathon, runners must pace themselves in order finish at their best time. If they run too slow, they will run a poor race. But if they attempt to outrun the competition they run the risk of burning out and finishing poorly. In the same way, scope statements should contain as much detail as possible, but only to a point.

The most important thing is to be specific. The more the better. In a perfect world you could write out a list of all the work that is involved in a project, down to the last nail and screw, and have all stakeholders approve of it. Unfortunately it’s not a perfect world, so the scope statement has to stop somewhere. However, every well defined project boundary represents a slightly more bulletproof project.

The minimum length of a scope statement is that which reduces the primary risks to the project. For example, stating that your project is to “build a fence” will communicate the basic information, but it is not enough. Everyone already knows this information – there is no value. It would be better to define start and end points, fence height, post depth, fence type, weather assumptions, etc. which could serve to reduce the risk of adverse changes in scope later on.

I don’t believe there is a maximum length of a scope statement, only that which is feasible to reduce risk. The length is enough when the time being spent writing it is no longer reducing a corresponding amount of risk.

A good scope statement includes the following things:

  • Overall description of the work. This is where you state that the project is to “build a fence.”
  • Deliverables. What will be produced by the project, and what are its key features? Also, what client need is the project satisfying?
  • Justification for the project. In order to provide a complete understanding of the scope, sometimes it is necessary to dive into the justification of why the project was initiated in the first place.
  • Constraints. If the project faces certain physical boundaries, these can be a source of risk and thus should be defined further.
  • Assumptions. All projects have assumed certain conditions as part of their existence. For example, the fence building project has assumed good weather, availability of tools, etc. What are those assumptions and what impact does their inaccuracy have on the project?
  • Inclusions/Exclusions. Many projects have items that are uncertain because projects of that type/size sometimes do and sometimes don’t include those things. They need to be explicitly included or excluded from the project.

It’s also helpful to borrow from our friends in the corporate strategy department and concentrate on SMART goals:

  • Specific. The more specific the better.
  • Measurable. If you can’t measure it, you have no way of knowing if it was achieved. Sometimes the best criteria is qualitative, but use quantitative descriptions whenever possible.
  • Achievable. It’s surprisingly easy to commit to something you don’t have the expertise to complete.
  • Relevant. The scope should focus on completing the goals of the client/owner, and avoid tasks that do not add value.
  • Time Bound. A project is by definition temporary and thus has a time limit. I would consider this optional but it certainly doesn’t hurt in a scope statement.


You probably don’t know all the project boundaries when you’re writing the scope statement. For example, in the fence building project you might not know how high the fence is to be. This is okay, but just like the marathon runner who must avoid the temptation to be in the lead during the race, the project manager must be aware of the risk involved in excluding this information from the scope statement. The project manager must realize that all project uncertainties are risks to become cost or schedule issues. In an ideal world every project is completely defined, but this is an ideal that is not always possible nor necessary. That being said, uncertainties can be dealt with in several ways:

  • Accept. The project takes on the risk of the uncertainty. For example, if the owner requires a bigger fence than anticipated, you must swallow the cost.
  • Transfer. Let a third party assume the risk. For example, approach the other neighbor to see if they will chip in over and above a certain cost.
  • Mitigate. Perform actions that will reduce the risk of the uncertainty. For example, ask the owner how big of a fence they would like to build.

When uncertainties are not defined in the scope statement they can be good candidates for inclusion into the project risk register.

Examples of Scope Statements

Here are a few examples of what I would consider good scope statements:

This project involves building a fence between the house at 10 ABC Boulevard and 12 ABC Boulevard. The fence will consist of steel posts within concrete-filled holes. The fence will be built out of cedar and it will be 8 feet tall. This is anticipated to keep the dog at 10 ABC Boulevard contained within the yard at a reasonable cost. The fence will be located as close to the property line as possible and reach from the garage on the west side to the house on the north side.

This project is for the creation of a construction safety app for cell phones. There will be an app for iPhones and Android based systems. The user interface will be designed as part of the project but will contain, as a minimum, the ability to create and edit tailgate meetings, field level hazard assessments, safety inspections, and audits. Each of these will have a built-in checklist for typical projects in typical industries. There will be a corresponding web application whereby anyone using the app can log in to view and print the reports. The app must include a tutorial to make it easy to get started.

Write a Scope Statement

If you haven’t already, try writing a scope statement using the following checklist:

  • List the project’s stakeholders.
  • Write down, in point form, the boundaries of the project from each project stakeholder’s point of view.
  • Note the biggest risks to the successful completion of the project.
  • Write out the primary objective of the project.
  • Write out the important boundaries of the project as well as the most important risks.

The examiner is looking for a PID (Project Initiation Document) (P3)

This must include:

  1. who the stakeholder(s) is/are
  2. who the clients and target audience (end users) are
  3. the scope definition
  4. the purpose
  5. the objectives
  6. the deliverables
  7. the timescales
  8. the structure.

Project objectives








Timescales and milestones




Business case




Phase review


LO2 Assessment activities

Below are four suggested assessment activities directly linked to the pass and merit criteria for LO1 to help with assignment preparation.

  • P3:  Complete the documentation for the initiation phase for an identified project
  • P4:  Develop a project plan for the identified project
  • M2: Carry out and document a phase review of the project plan
  • D2:  Create a Business Case to support an identified project

This learning outcome is about learners carrying out the initiation phase and project planning phase for an identified project. It is important that the scenario and/or project that learners are provided with allows them to meet the assessment criteria in a manner that reflects working practices.

LO2 Be able to initiate and plan projects

P3: Learners must carry out the initiation phase for an identified project taking into consideration the bullet list in the teaching content under initiation phase.
They should then prepare a PID which must include, as a minimum, the stakeholders, clients and target audience (end user), scope definition, purpose, objectives, deliverables, timescales and structure. The evidence will be the completed PID.

P4: Learners must develop a project plan for an identified project. The project plan can be a follow on from the evidence presented for P3 and D2. The project plan must include the items in the bullet list in the teaching content. Although learners may not be “working with budgets”, they should still take into consideration that ‘time is money’ and therefore cost in potential value of time of those involved in the project as well as the cost of other physical resources that may be used.

M2: Learners must carry out a phase review of the project plan. The phase review must show that learners have reviewed every section of the project plan to ensure that the project can progress to the execution phase. They will need to show what they have reviewed and the results of their review. This will then be concluded by including the justification for the continuation of the project. This may also include where learners have identified that changes have to be made, etc. The evidence will be the documented review of the planning phase of the project.

D2: Learners are required to create a business case for an identified project. It can be linked to the project for which they carried out the initiation phase. The business case must give clear justification as to why the project should be carried out i.e. the reasons and why. They could present the evidence as a report or as a presentation with detailed speaker notes or a presentation of them delivering their business case to an audience.