Chapter 2: Project Planning and Scope Management

2.1 Goals and Objectives

Goals and objectives are statements that describe what the project will accomplish, or the
business value the project will achieve.

Goals are high level statements that provide overall context for what the project is trying to
achieve, and should align to business goals.

Objectives are lower level statements that describe the specific, tangible products and
deliverables that the project will deliver.

The definition of goals and objectives is more of an art than a science, and it can be difficult to
define them and align them correctly.

Goals
Goals are high-level statements that provide the overall context for what the project is trying to
accomplish. Let's look at an example and some of the characteristics of a goal statement. One of
the goals of a project might be to "increase the overall satisfaction levels for clients calling to the
company helpdesk with support needs".

Because the goal is at a high-level, it may take more than one project to achieve. For example,
for instance, there may be a technology component to increasing client satisfaction. There may
also be new procedures, new training classes, reorganization of the helpdesk department and
modification of the company rewards system. It may take many projects over a long period of
time to achieve the goal.

The goal should reference the business benefit in terms of cost, speed and / or quality. In this
example, the focus is on quality of service. Even if the project is not directly in support of the
business, there should be an indirect tie. For instance, an IT infrastructure project to install new
web servers may ultimately allow faster client response, better price performance, or other
business benefit. If there is no business value to the project, the project should not be started.

Generally, non-measurable: If you can measure the achievement of your goal, it is probably at
too low a level and is probably more of an objective.

If your goal is not achievable through any combination of projects, it is probably written at too
high a level. In the above example, you could envision one or more projects that could end up
achieving a higher level of client satisfaction. A goal statement that says you are trying to
achieve a perfect client experience is not possible with any combination of projects. It may
instead be a vision statement, which is a higher level statement showing direction and aspiration,
but which may never actually be achieved.

1
It is important to understand business and project goal statements, even though goals are not a
part of the TenStep Project Definition. Goals are most important from a business perspective.
The project manager needs to understand the business goals that the project is trying to
contribute to. However, you do not need to define specific project goals. On the other hand,
objectives definitely are important.

Objectives
Objectives are concrete statements describing what the project is trying to achieve. The objective
should be written at a lower level, so that it can be evaluated at the conclusion of a project to see
whether it was achieved or not. Goal statements are designed to be vague. Objectives should not
be vague. A well-worded objective will be Specific, Measurable, Attainable/Achievable,
Realistic and Time-bound (SMART).

An example of an objective statement might be to "upgrade the helpdesk telephone system

by December 31 to achieve average client wait times of no more than two minutes".
Note that the objective is much more concrete and specific than the goal statement.
The objective is measurable in terms of the average client wait times the new phone system is
trying to achieve.
We must assume that the objective is achievable and realistic.
The objective is time-bound, and should be completed by December 31.
Objectives should refer to the deliverables of the project. In this case, it refers to the upgrade of
the telephone system. If you cannot determine what deliverables are being created to achieve the
objective, then the objective may be written at too high a level. On the other hand, if an objective
describes the characteristics of the deliverables, they are written at too low a level. If they
describe the features and functions, they are requirements, not objectives.

2.2 Scope Definition

The scope definition section details the process of developing a detailed description of the
project and its deliverables. This can only be completed after the requirements have been
identified and defined during the requirements definition process. During the requirements
definition process three documents were created; Requirements Documentation, Requirements
Management Plan and a Requirements Traceability Matrix. You can refer to these documents
when defining the projects’ scope.

This section should explain the process you followed to develop the detailed description of the
project and its deliverables. If you used other documents such as the Project Charter,
Preliminary Project Scope Statement or Requirements Documentation you should identify them
and all other documents used. You should tie the scope definition process back to the
requirements definition as the projects’ scope answers the requirements for the project.

You should also document the tools and techniques used to define the project scope such as
expert judgment, product analysis, alternatives identification or facilitated workshops.

The scope for this project was defined through a comprehensive requirements collection process.
First, a thorough analysis was performed on the company’s current software applications based
on employee and user feedback. From this information, the project team developed the project
2
requirements documentation, the requirements management plan, and the requirements
traceability matrix for what the new software application must accomplish.

The project description and deliverables were developed based on the requirements collection
process and input from subject matter experts in software design, technical support,
programming and business applications. This process of expert judgment provided feedback on
the most effective ways to meet the original requirements of providing a new software platform
from which the company can improve its financial tracking and internal financial processes.

Project Scope Statement

The project scope statement details the project’s deliverables and the work necessary to create
these deliverables. The Project Scope Statement should contain the following components:
 Product Scope Description – describes what the project will accomplish
 Product Acceptance Criteria – describes what requirements must be met in order for the
project to be accepted as complete
 Project Deliverables – detailed list of deliverables the project will result in
 Project Exclusions – description of work that is not included in the project and outside of
the scope
 Project Constraints – lists limits on resources for time, money, manpower, or equipment
(capital)
 Project Assumptions – describes the list of assumptions the project team and stakeholders
are working under to complete the project

The project scope statement provides a detailed description of the project, deliverables,
constraints, exclusions, assumptions, and acceptance criteria. Additionally, the scope statement
includes what work should not be performed in order to eliminate any implied but unnecessary
work which falls outside the of the project’s scope.

This project includes the design, programming, and testing of a new software application for
tracking the company’s finances. The deliverables for this project are a completed software
application for finance tracking with the flexibility to modify and expand the application as
necessary in the future. This project will be accepted once the new software has been
successfully tested in each department and has been shown to be compatible with the company’s
current information technology (IT) infrastructure. This project does not include ongoing
operations and maintenance of the software. Only internal personnel and resources may be used
for this project. Additionally, the project is not to exceed 180 days in duration or $450,000 in
spending. Assumptions for this project are that support will be provided by the project sponsor
and all department managers and those adequate internal resources are available for the
successful completion of this project.

Work Breakdown Structure

The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key
elements to effective scope management. This section should discuss how the project scope is to
be subdivided into smaller deliverables in the WBS and WBS Dictionary and how these smaller
components are managed during the life of the project.

3
In order to effectively manage the work required to complete this project, it will be subdivided
into individual work packages which will not exceed 40 hours of work. This will allow the
Project Manager to more effectively manage the project’s scope as the project team works on the
tasks necessary for project completion. The project is broken down into three phases: the design
phase; the programming phase; and the testing phase. Each of these phases is then subdivided
further down to work packages which will require no more than 40 hours of work and no less
than 4 hours of work (see WBS structure below).

New Software Project

1.1 Design Phase 1.2 Programming Phase 1.3 Testing Phase

1.1.1 First Design Phase 1.1.2 Second Design 1.2.1 Programming 1.3.1 Testing Task
Phase Task #1 #1

1.2.2 Programming 1.3.2 Testing Task

1.1.1.1 Design Task #1 1.1.2.1 Design Task Task #2 #2
#3

1.3.3 Testing Task

1.1.1.2 Design Task #2 1.1.2.2 Design Task #3
#4

Figure 1.1, Work Breakdown Structure (WBS)

In order to more clearly define the work necessary for project completion the WBS Dictionary is
used. The WBS Dictionary includes an entry for each WBS element. The WBS Dictionary
includes a detailed description of work for each element and the deliverables, budget and
resource needs for that element. The project team will use the WBS Dictionary as a statement of
work for each WBS element.

Level WBS Element Description of Work Deliverables Budget Resources

Code Name

Table 1.2, WBS Dictionary

Scope Verification
Scope verification discusses how the deliverables will be verified against the original scope and
how the deliverables from the project will be formally accepted. The deliverables for the project
should be formally accepted and signed off on by the customer throughout the lifecycle of the
project and not held back as a single deliverable at the end of the project.

4
As this project progresses the Project Manager will verify interim project deliverables against the
original scope as defined in the scope statement, WBS and WBS Dictionary. Once the Project
Manager verifies that the scope meets the requirements defined in the project plan, the Project
Manager and Sponsor will meet for formal acceptance of the deliverable. During this meeting
the Project Manager will present the deliverable to the Project Sponsor for formal acceptance.
The Project Sponsor will accept the deliverable by signing a project deliverable acceptance
document. This will ensure that project work remains within the scope of the project on a
consistent basis throughout the life of the project.

Scope control
Scope control is the process of monitoring the status of the scope of the project. This section
also details the change process for making changes to the scope baseline.

The Project Manager and the project team will work together to control of the scope of the
project. The project team will leverage the WBS Dictionary by using it as a statement of work
for each WBS element. The project team will ensure that they perform only the work described
in the WBS dictionary and generate the defined deliverables for each WBS element. The Project
Manager will oversee the project team and the progression of the project to ensure that this scope
control process if followed.

If a change to the project scope is needed the process for recommending changes to the scope of
the project must be carried out. Any project team member or sponsor can request changes to the
project scope. All change requests must be submitted to the Project Manager in the form of a
project change request document. The Project Manager will then review the suggested change to
the scope of the project. The Project Manager will then either deny the change request if it does
not apply to the intent of the project or convene a change control meeting between the project
team and Sponsor to review the change request further and perform an impact assessment of the
change. If the change request receives initial approval by the Project Manager and Sponsor, the
Project Manager will then formally submit the change request to the Change Control Board. If
the Change Control Board approves the scope change the Project Sponsor will then formally
accept the change by signing the project change control document. Upon acceptance of the
scope change by the Change Control Board and Project Sponsor the Project Manager will update
all project documents and communicate the scope change to all project team members
stakeholders.

2.3 Scope Management

Scope Management is the collection of processes which ensure that the project includes all the
work required to complete it while excluding all work which is not necessary to complete it. The
Scope Management Plan details how the project scope will be defined, developed, and verified.
It clearly defines who is responsible for managing the projects’ scope and acts as a guide for
managing and controlling the scope.

Project Scope Management follows a five step process; Collect Requirements, Define Scope,
Create WBS, Verify Scope, and Control Scope.

5
1) Collect Requirements – this first step is the process by which we define and document the
requirements needed to meet all project objectives. The foundation of this process is the
project charter and stakeholder register. From these, the team can identify requirements,
collectively discuss details associated with meeting each requirement, conduct interviews and
follow-on discussion to clarify the requirements, and document the requirements in sufficient
detail to measure them once the project begins the execution phase. This documentation also
serves as an input to the next step in the process which is to define scope.
2) Define Scope – this step is critical to project success as it requires the development of a
detailed project/product description to include deliverables, assumptions, and constraints and
establishes the framework within which project work must be performed.
3) Create WBS – this process breaks project deliverables down into progressively smaller and
more manageable components which, at the lowest level, are called work packages. This
hierarchical structure allows for more simplicity in scheduling, costing, monitoring, and
controlling the project.
4) Verify Scope – this is the process by which the project team receives a formalized
acceptance of all deliverables with the sponsor and/or customer.
5) Control Scope – this is the process of monitoring/controlling the project/product scope as
well as managing any changes in the scope baseline. Changes may be necessary to the
project scope but it is imperative they are controlled and integrated in order to prevent scope
creep.

The Scope Management Plan provides the scope framework for this project. This plan
documents the scope management approach; roles and responsibilities as they pertain to project
scope; scope definition; verification and control measures; scope change control; and the
project’s work breakdown structure. Any project communication which pertains to the project’s
scope should adhere to the Scope Management Plan.

This project is for designing, programming, and testing a new software product which will be
used to track the company’s finances and improve various financial processes. This includes
design of the software, all programming and coding, and testing/validation of the software. No
external resources or outsourcing are anticipated for this project.

Scope Management Approach

It is important that the approach to managing the projects’ scope be clearly defined and
documented in detail. This section provides a summary of the Scope Management Plan in which
it addresses the following:
 Who has authority and responsibility for scope management
 How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of
Work, etc.)
 How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work
Performance Measurements, etc.)
 The scope change process (who initiates, who authorizes, etc.)
 Who is responsible for accepting the final project deliverable and approves acceptance of
project scope

6
For this project, scope management will be the sole responsibility of the Project Manager. The
scope for this project is defined by the Scope Statement, Work Breakdown Structure (WBS) and
WBS Dictionary. The Project Manager, Sponsor and Stakeholders will establish and approve
documentation for measuring project scope which includes deliverable quality checklists and
work performance measurements. Proposed scope changes may be initiated by the Project
Manager, Stakeholders or any member of the project team. All change requests will be
submitted to the Project Manager who will then evaluate the requested scope change. Upon
acceptance of the scope change request the Project Manager will submit the scope change
request to the Change Control Board and Project Sponsor for acceptance. Upon approval of
scope changes by the Change Control Board and Project Sponsor the Project Manager will
update all project documents and communicate the scope change to all stakeholders. Based on
feedback and input from the Project Manager and Stakeholders, the Project Sponsor is
responsible for the acceptance of the final project deliverables and project scope.

Roles and Responsibilities

In order to successfully manage a projects’ scope it’s important that all roles and responsibilities
for scope management are clearly defined. This section defines the role of the Project Manager,
Project Team, Stakeholders and other key persons who are involved in managing the scope of the
project. It should state who is responsible for scope management and who is responsible for
accepting the deliverables of the project as defined by the projects’ scope. Any other roles in
scope management should also be stated in this section.

The Project Manager, Sponsor and team will all play key roles in managing the scope of this
project. As such, the project sponsor, manager, and team members must be aware of their
responsibilities in order to ensure that work performed on the project is within the established
scope throughout the entire duration of the project. The table below defines the roles and
responsibilities for the scope management of this project.

7
 Name Role Responsibilities
John Doe Sponsor - Approve or deny scope change requests as
appropriate
- Evaluate need for scope change requests
- Accept project deliverables
Jane Doe Project Manager - Measure and verify project scope
- Facilitate scope change requests
- Facilitate impact assessments of scope change
requests
- Organize and facilitate scheduled change control
meetings
- Communicate outcomes of scope change requests
- Update project documents upon approval of all
scope changes

Bob Jones Team Lead - Measure and verify project scope

- Validate scope change requests
- Participate in impact assessments of scope change
requests
- Communicate outcomes of scope change requests
to team
- Facilitate team level change review process
John Smith Team Member - Participate in defining change resolutions
- Evaluate the need for scope changes and
communicate them to the project manager as
necessary
Tom Brown Team Member - Participate in defining change resolutions
- Evaluate the need for scope changes and
communicate them to the project manager as
necessary
Table 1.1, Scope Management Roles and Responsibilities

2.4 Writing a Scope Statement

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. Let’s take a look at how to write a good scope statement, its necessary
components, and the pitfalls to avoid during its creation.

The firsts step on writing a scope statement is filling in the project name, project charter, and a
listing of the project owner, sponsors, and stakeholders. 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. And 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 know where they can look should a question arise.

Clear and Concise is the Rule

8
A scope statement needs to be very clear and concise, and the project name is a good place to
start. 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. You can download an
example of a scope statement by clicking here.

A project charter needs to be drafted next. A 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.

The scope statement needs to identify the reason for the project. This is often called the project
justification. 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.

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.

The deliverables 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

9
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 are 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.

Vision and Scope Document

When the project begins, the project manager has a unique role to play. The start of the project is
the time when the scope of the project is defined; only the project manager is equipped to make
sure that it’s defined properly. Everyone else has a role to play later on: users and stakeholders

10
will provide expertise, requirements analysts will write specifications, programmers will build
the code, etc. Everyone involved in the project has some input into the scope, but only the project
manager is solely dedicated to it. Defining the scope is the most productive thing a project
manager can do to get the project underway. The Vision and Scope document is the project
manager's tool for doing that.

Vision and Scope Document

The vision and scope document is one of the most important tools that a project manager has; it
is also one of the easiest to implement. A good vision and scope document will help a project
avoid some of the costliest problems that a project can face. By writing the document and
circulating it among everyone involved in the project, the project manager can ensure that each
of the stakeholders and engineers share a common understanding of the needs being addressed—
and that the software must address them.

Vision and Scope Document Outline

1. Problem Statement
a) Project background
b) Stakeholders
c) Users
d) Risks
e) Assumptions
2. Vision of the Solution
a) Vision statement
b) List of features
c) Scope of phased release (optional)
d) Features that will not be developed

Project background
This section contains a summary of the problem that the project will solve. It should provide a
brief history of the problem and an explanation of how the organization justified the decision to
build software to address it. This section should cover the reasons that the problem exists, the
organization’s history with this problem, any previous projects which were undertaken to try to
address it, and the way that the decision to begin this project was reached.
Stakeholders
This is a bulleted list of the stakeholders. Each stakeholder may be referred to by name or by title
or role (“support group manager”, “CTO”, “senior manager”). The needs of each stakeholder are
described in a few sentences.
Users
This is a bulleted list of the users. As with the stakeholders, each user can either be referred to by
name or role (“support rep”, “call quality auditor”, “home website user”)—however, if there are
many users, it is usually inefficient to try to name each one. The needs of each user are
described.
Risks
This section lists any potential risks to the project. It should be generated by a project team’s
brainstorming session. It could include external factors that could impact the project, issues or

11
problems that could potentially cause project delays or raise issues. (The process for assessing
and mitigating risk below can be used to generate the risks for this section.)

Assumptions
This is the list of assumptions that the stakeholders, users or project team have made. Often,
these assumptions are generated during a Wideband Delphi estimation session. If Wideband
Delphi is being used, the rest of the vision and scope document should be ready before the
Delphi meeting and used as the basis for estimation. The assumptions generated during the
estimation kickoff meeting should then be reviewed, and any non-technical assumptions should
be copied into this section. (Technical assumptions—meaning assumptions that affect the design
and development but not the scope of the project—should not be included in this document. The
estimate results will still contain a record of these assumptions, but they are not useful for this
particular audience.)

If Wideband Delphi is not being used to generate the assumptions, the project manager should
hold a brainstorming session with the team to come up with a list of assumptions instead.

Vision statement
The goal of the vision statement is to describe what the project is expected to accomplish. It
should explain what the purpose of the project is. This should be a compelling reason, a solid
justification for spending time, money and resources on the project. The best time to write the
vision statement is after talking to the stakeholders and users and writing down their needs; by
this time, a concrete understanding of the project should be starting to jell.

List of features
This section contains a list of features. A feature is as a cohesive area of the software that fulfills
a specific need by providing a set of services or capabilities. Any software package—in fact, any
engineered product—can be broken down into features. The project manager can choose the
number of features in the vision and scope document by changing the level of detail or
granularity of each feature, and by combining multiple features into a single one. Sometimes
those features are small (“screw-top cap”, “holds one liter of liquid”); sometimes they are big
(“four wheel drive”, “seats seven passengers”). It is useful to describe a product in about ten
features in the vision and scope document, because this usually yields a level of complexity that
most people reading it are comfortable with. Adding too many features will overwhelm most
readers, and each extra feature adds time and effort to the project and makes it difficult or
unrealistic to accomplish.

Each feature should be listed in a separate paragraph or bullet point. It should be given a name,
followed by a description of the functionality that it provides. This description does not need to
be detailed; it can simply be a few sentences that give a general explanation of the feature.
However, if there is more information that a stakeholder or project team member feels should be
included, it is important to include that information. For example, it is sometimes useful to
include a use case in a specific feature, as long as it is written in such a way that all of the
stakeholders can read and understand it.

Scope of phased release (Optional)

12
 Sometimes software projects are released in phases: a version of the software with some subset
of the features is released first, and a newer, more complete version is released later. This section
describes the plan for a phased release, if that approach is to be taken.

This is useful when there is an important deadline for the software, but developing the entire
software project by that deadline would be unrealistic. The most common way to compromise on
this release date is to divide the features into two or more releases. In that case, this section
should identify specifically when those versions will be released, and which features will be
included in each version. It’s reasonable to divide one feature up between two releases, as long
as it is made clear exactly how that will happen.

If a project manager needs to release a project in phases, it is critical that the project team be
consulted. Some features are much more difficult to divide than others, and the engineers might
see dependencies between features that are not clear to the stakeholders and project manager.
After the phased release plan is written down and agreed upon, the project team should always
be asked to re-estimate the effort and a new project plan should be generated (see below). This
will ensure that the phased release is feasible and compatible with the company’s priorities.

Features that will not be developed

Features are often left out of a project on purpose. When a feature is explicitly left out of the
software, it should be added to this section to tell the reader that a decision was made to exclude
it. For example, one way to handle an unrealistic deadline is by removing one or more features
from the software, in which case the removed features should be moved into this section. The
reason these features should be moved rather than deleted from the document is that otherwise
readers might assume that they were overlooked and bring them up in a review. This is
especially important during the review of the document because it allows everyone to agree on
the exclusion of the feature (or object to it).

2.5 Step Wise Project Planning

In many organizations, project planning is a combination of vague generalities in terms of the

objective of the project and a rock solid completion date. That is often the only measurable
project result that is quantified. Because project managers don't know what the executives want
them to deliver, they have no ability to exercise control on the scope of the project and the
objectives change weekly. Project team member assignments are vague and are also ever-
changing which is why estimating is so inaccurate and why 70% of projects planned this way
fail.

Very often, project managers face a difficult organizational environment. The organization lacks
the processes to do project management right and the executives don't know how to play their
role correctly. In these situations, the PMs need best practices that allow them to do things
effectively even though executives and the organization's processes are obstacles rather than
assets. The project planning checklist below will help.

The intent of this intense project planning process is to make all of the decisions before we start
work. That approach of making the plan and then executing it is much more efficient than a

13
"plan as you go" process for projects. It is also difficult or impossible in many organizations. For
this approach to work, the organization, its executives and the project managers must all do
things correctly. That is, the executives must specify exactly what they want the project to
deliver. They cannot make the project assignment in vague generalities where the only thing that
is specific is the due date. The organization must have processes for evaluating and prioritizing
projects and giving them access to resources based on those priorities. Last, the project managers
must know how to do top-down project planning where they are able to take the clear acceptance
criteria, specified by the executive, and decompose it down to the level of specific assignments
for each team member. Most organizations fail to meet one or more of these criteria which is
why the project planning ideal is so rarely achieved.
The key to a successful project is in the planning. Creating a project plan is the first thing you
should do when undertaking any kind of project.
Often project planning is ignored in favour of getting on with the work. However, many people
fail to realize the value of a project plan in saving time, money and many problems.

Step 1: Project Goals

A project is successful when the needs of the stakeholders have been met. A stakeholder is
anybody directly, or indirectly impacted by the project.
As a first step, it is important to identify the stakeholders in your project. It is not always easy to
identify the stakeholders of a project, particularly those impacted indirectly. Examples of
stakeholders are:

 The project sponsor.

 The customer who receives the deliverables.
 The users of the project outputs.
 The project manager and project team.

Once you understand who the stakeholders are, the next step is to find out their needs. The best
way to do this is by conducting stakeholder interviews. Take time during the interviews to draw
out the true needs that create real benefits. Often stakeholders will talk about needs that aren't
relevant and don't deliver benefits. These can be recorded and set as a low priority.

The next step, once you have conducted all the interviews, and have a comprehensive list of
needs is to prioritize them. From the prioritized list, create a set of goals that can be easily
measured. A technique for doing this is to review them against the SMART principle. This way
it will be easy to know when a goal has been achieved.

Once you have established a clear set of goals, they should be recorded in the project plan. It can
be useful to also include the needs and expectations of your stakeholders.
This is the most difficult part of the planning process completed. It's time to move on and look at
the project deliverables.

Step 2: Project Deliverables

Using the goals you have defined in step 1, create a list of things the project needs to deliver in
order to meet those goals. Specify when and how each item must be delivered.

14
Add the deliverables to the project plan with an estimated delivery date. More accurate delivery
dates will be established during the scheduling phase, which is next.

Step 3: Project Schedule

Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each
task identify the following:
The amount of effort (hours or days) required to complete the task.
The resource who will carry out the task.
Once you have established the amount of effort for each task, you can work out the effort
required for each deliverable, and an accurate delivery date. Update your deliverables section
with the more accurate delivery dates.

At this point in the planning, you could choose to use a software package such as Microsoft
Project to create your project schedule. Alternatively, use one of the many free templates
available. Input all of the deliverables, tasks, durations and the resources who will complete each
task.

A common problem discovered at this point, is when a project has an imposed delivery deadline
from the sponsor that is not realistic based on your estimates. If you discover that this is the case,
you must contact the sponsor immediately. The options you have in this situation are:

 Renegotiate the deadline (project delay).

 Employ additional resources (increased cost).
 Reduce the scope of the project (less delivered).

Use the project schedule to justify pursuing one of these options.

Step 4: Supporting Plans

This section deals with plans you should create as part of the planning process. These can be
included directly in the plan.
Human Resource Plan
Identify by name, the individuals and organizations with a leading role in the project. For each,
describe their roles and responsibilities on the project.
Next, describe the number and type of people needed to carry out the project. For each resource
detail start dates, estimated duration and the method you will use for obtaining them.
Create a single sheet containing this information.
Communications Plan
Create a document showing who needs to be kept informed about the project and how they will
receive the information. The most common mechanism is a weekly or monthly progress report,
describing how the project is performing, milestones achieved and work planned for the next
period.
Risk Management Plan
Risk management is an important part of project management. Although often overlooked, it is
important to identify as many risks to your project as possible, and be prepared if something bad
happens.

15
Here are some examples of common project risks:
 Time and cost estimates too optimistic.
 Customer review and feedback cycle too slow.
 Unexpected budget cuts.
 Unclear roles and responsibilities.
 Stakeholder input is not sought, or their needs are not properly understood.
 Stakeholders changing requirements after the project has started.
 Stakeholders adding new requirements after the project have started.
 Poor communication resulting in misunderstandings, quality problems and rework.
 Lack of resource commitment.

Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log;
write down what you will do in the event it occurs, and what you will do to prevent it from
occurring. Review your risk log on a regular basis, adding new risks as they occur during the life
of the project.

Step wise: an overview of project planning

Planning is the most difficult process in project management This chapter describes a framework
of basic steps in project planning. Many different techniques can be used but this chapter tells the
overview of the steps and activities in each step of project planning.
A major step in project planning is to plan in outline first and then in more detail.

Following are the major steps in project planning

Steps in Project Planning

Step 0 : Select project

Step 1 : Identify project scope and objectives
Step 2 : Identify project infrastructure
Step 3 : Analyze project characteristics
Step 4 : Identify project products and activities
Step 5: Estimate effort for each activity.
Step 6 : Identify activity risks.
Step 7 : Allocate resources
Step 8 Review / Publicize pl\an
Step 9 & 10 : Execute plan / lower level of planning

Each step of project planning has different activities to perform. Following the description of
each step with its activities

16
Step 0 : Select project

This is called step 0 because in a way of project planning, it is outside the main project planning
process. Feasibility study suggests us that the project is worthwhile or not.

Step 1 : Identify project scope and objectives

The activities in this step ensure that all parties to the project agree on the objectives and
are committed to the success of the project.

Step 1.1 : Identify objectives and practical measures of the effectiveness in meeting those
objectives
Step 1.2 : Establish project authority
Step 1.3 : Stakeholders analysis – Identify all stakeholders in the project and their
interest.
Step 1.4 : Modify objectives in the light of stakeholder analysis.
Step 1.5 : Establish method of communication

17
Step 2 : Identify project infrastructure
Projects are rarely carried out in a vacuum. There is usually some kind of infrastructure
into which the project must fit. Where the project manager are new to the organization ,
they must find out the precise nature of this infrastructure.

Step 2.1: Identify relationship between the project and strategic planning
Step 2.2 : Identify installation standards and procedures.
Step 2.3 : Identify project team organization.

Step 3 : Analyze project characteristics.

The general purpose of this part of planning operation is to ensure that the appropriate
methods are used for the project.

Step 3.1 : Distinguish the project as either objective- product driven

Step 3.2 : Analyze other project characteristics ( including quality –based ones)
Step 3.3 : Identify high level project risks
Step 3.3 : Take into account user requirement concerning implementation.
Step 3.4 : Select development methodology and life cycle approach.
Step 3.5 : Review overall resources estimates

Step 4 : Identify project products and activities

The more detailed planning of the individual activities now takes place. The longer term
planning is broad and in outline, while the more immediate tasks are planned in some detail.

Step 4.1: Identify and describes project products ( or deliverables )

Step 4.2 : Document generic product flows
Step 4.3 : Record product instance
Step 4.4 : produce ideal activity network
Step 4.5 : Modify the ideal to take into account need for stages and checkpoints.

Step 5: Estimate effort for each activity.

Step 5.1: Carry out bottom-up estimates
Step 5.2: Revise plan to create controllable activities.

Step 6 : Identify activity risks.

Step 6.1 : Identify and quantify activity based risks
Step 6.2 : Plan risk reduction and contingency measures where appropriate
Step 6.3 : Adjust overall plans and estimates to take account of the risks

Step 7 : Allocate resources

Step 7.1 : Identify and allocate resources
Step 7.2 : Revise plans and estimates to take into account resource constraints

Step 8 : Review / Publicize plan

Step 8.1 : Review quality aspects of the project plan.
Step 8.2 : Document plans and obtain agreement.

18
Step 9 & 10 : Execute plan / lower level of planning
Once the project is underway, plans will need to be drawn up in greater detail for each
activity as it becomes due. Detailed and lower level of planning of the later stages will need to be
delayed because more information will be available nearer the start of the stage.

Project planning is an iterative process. As the time approaches for the particular activities to be
carried out they should be re-planned in more detail.

19