Project Management

Project Planning

LESSON 3
Content

• Project Initiation
• Overview of Project Planning
• Weighted Decision Matrix
• Financial Considerations
• Scope Planning
• Project Requirements
• Scope Inputs
• Work Breakdown Structure
Project Initiation
• The project initiation phase is the first phase within the project management life cycle, as
it involves starting up a new project.

• Within the initiation phase, the business problem or opportunity is identified, a solution is
defined, a project is formed, and a project team is appointed to build and deliver the
solution to the customer.

• A business case is created to define the problem or opportunity in detail and identify a
preferred solution for implementation.
Project Initiation
• The business case includes:

• A detailed description of the problem or opportunity with headings such as

Introduction, Business Objectives, Problem/Opportunity Statement, Assumptions, and
Constraints

• A list of the alternative solutions available

• An analysis of the business benefits, costs, risks, and issues

• A description of the preferred solution

• Main project requirements

• A summarized plan for implementation that includes a schedule and financial analysis
Project Initiation
• The need for establishing clear project objectives cannot be overstated.

• To check if an objective lacks clarity, show it to 5 people. If it is interpreted in multiple

ways, then there is no clarity.

• Ideally, if an objective is clear, you can show it to five people who, after reviewing it, hold
a single view about its meaning. The best way to make an objective clear is to state it in
such a way that it can be verified.

• Building in ways to measure achievement can do this. It is important to provide

quantifiable definitions to qualitative terms.
Project Initiation

Figure 1: Project Management interpreted differently

Project Initiation
• To ensure the project’s objectives are achievable and realistic, they must be determined
jointly by managers and those who perform the work.

• Realism is introduced because the people who will do the work have a good sense of
what it takes to accomplish a particular task.

• In addition, this process assures some level of commitment on all sides: management
expresses its commitment to support the work effort and workers demonstrate their
willingness to do the work.

• Imagine an office manager has contracted a painter to paint his office. His goal or
objective is to have the office painted a pleasing blue colour. Consider the conversation
that occurs after the job was finished.
Project Initiation
Overview of Project Planning
• The project planning phase is a challenging phase for a project manager, as you need to
make an educated guess about the staff, resources, and equipment needed to complete
your project.

• You may also need to plan your communications and procurement activities, as well as
contract any third-party suppliers.

• The purpose of the project planning phase is to:

• Establish business requirements

• Establish cost, schedule, list of deliverables, and delivery dates

• Establish resources plans

• Obtain management approval and proceed to the next phase

Overview of Project Planning
• The basic processes of project planning are:

• Scope Planning – specifying the in-scope requirements for the project to facilitate
creating the work breakdown structure

• Preparation of the Work Breakdown Structure – spelling out the breakdown of the
project into tasks and sub-tasks

• Project Schedule Development – listing the entire schedule of the activities and
detailing their sequence of implementation

• Resource Planning – indicating who will do what work, at which time, and if any
special skills are needed to accomplish the project tasks
Overview of Project Planning

• Budget Planning – specifying the budgeted cost to be incurred at the completion of

the project

• Procurement Planning – focusing on vendors outside your company and

subcontracting

• Risk Management – planning for possible risks and considering optional contingency
plans and mitigation strategies

• Quality Planning – assessing quality criteria to be used for the project

• Communication Planning – designing the communication strategy with all project

stakeholders
Overview of Project Planning

• Users will often begin describing their objectives in qualitative language. The project
manager must work with the user to provide quantifiable definitions to those qualitative
terms.

• These quantifiable criteria include schedule, cost, and quality measures.

• In the case of project objectives, these elements are used as measurements to

determine project satisfaction and successful completion.

• Subjective evaluations are replaced by actual numeric attributes.

Overview of Project Planning
Example 1
• A web user may ask for a fast system. The quantitative requirement should be all
screens must load in under three seconds. Describing the time limit during which the
screen must load is specific and tangible. For that reason, you’ll know that the
requirement has been successfully completed when the objective has been met.

Example 2
• Let’s say that your company is going to produce a holiday batch of eggnog. Your
objective statement might be stated this way: Christmas Cheer, Inc. will produce two
million cases of holiday eggnog, to be shipped to our distributors by October 30, at a
total cost of $1.5 million or less.

• The objective criteria in this statement are clearly stated and successful fulfillment can
easily be measured. Stakeholders will know that the objectives are met when the two
million cases are produced and shipped by the due date within the budget stated.
Overview of Project Planning
When articulating the project objectives you should follow the SMART rule:

• Specific – get into the details. Objectives should be specific and written in clear,
concise, and understandable terms.

• Measurable – use quantitative language. You need to know when you have successfully
completed the task.

• Acceptable – agreed with the stakeholders.

• Realistic – in terms of achievement. Objectives that are impossible to accomplish are

not realistic and not attainable. Objectives must be centred in reality.

• Time-based – deadlines not durations. Objectives should have a time frame with an end
date assigned to them.

If you follow these principles, you’ll be certain that your objectives meet the quantifiable
criteria needed to measure success.
Overview of Project Planning
When articulating the project objectives you should follow the SMART rule:

• Specific – get into the details. Objectives should be specific and written in clear,
concise, and understandable terms.

• Measurable – use quantitative language. You need to know when you have successfully
completed the task.

• Acceptable – agreed with the stakeholders.

• Realistic – in terms of achievement. Objectives that are impossible to accomplish are

not realistic and not attainable. Objectives must be centred in reality.

• Time-based – deadlines not durations. Objectives should have a time frame with an end
date assigned to them.

If you follow these principles, you’ll be certain that your objectives meet the quantifiable
criteria needed to measure success.
Weighted Decision Matrix

• Sometimes, we have multiple options to choose from when determining requirements

and deciding which project to work on.

• To select the best option, we can use tools such as a Weighted Decision Matrix.
Weighted Decision Matrix is more advanced than Basic Decision Matrix.

• A Basic Decision Matrix consists of establishing a set of criteria for options that are
scored and summed to gain a total score that can then be ranked. Importantly, it is
not weighted to allow a quick selection process.

• The advantage of the Weighted Decision Matrix is that subjective opinions about one
alternative versus another can be made more objective. Another advantage of this
method is that sensitivity studies can be performed.
Weighted Decision Matrix

• A Weighted Decision Matrix allows decision makers to structure and solve their
problem by:

• Specifying and prioritizing their needs with a list a criteria; then

• Evaluating, rating, and comparing the different solutions; and
• Selecting the best matching solution.
• A weighted decision matrix is a decision tool used by decision makers.

• A Decision Matrix is basically an array presenting on one axis a list of alternatives,

also called options or solutions, that are evaluated regarding, on the other axis, a list
of criteria, which are weighted depending on their respective importance in the final
decision to be taken.
Weighted Decision Matrix

• The sample in the next page shows a Weighted Decision Matrix that compared three
options for a web development project (SJS Enterprises).

• This method is especially useful when choosing purchase alternatives and comparing
them against specific desirable system requirements.
Weighted Decision Matrix
Weighted Decision Matrix
Financial Considerations

• In many new project endeavors, we need to find out if our project is financially feasible.
We do that by using Net Present Value (NPV), Rate of return (ROI), and payback
analysis.
Financial Considerations

NPV
• A dollar earned today is worth more than a dollar earned one or more years from now.
The NPV of a time series of cash flows, both incoming and outgoing, is defined as the
sum of the present values (PVs) of the individual cash flows of the same entity.

• In the case when all future cash flows are incoming and the only outflow of cash is the
purchase price, the NPV is simply the PV of future cash flows minus the purchase
price (which is its own PV). NPV is a standard method for using the time value of
money to appraise long-term projects.

• Used for capital budgeting and widely used throughout economics, finance, and
accounting, it measures the excess or shortfall of cash flows, in present value terms,
once financing charges are met.
Financial Considerations

• NPV can be described as the “difference amount” between the sums of discounted
cash inflows and cash outflows.

• It compares the present value of money today to the present value of money in the
future, taking inflation and returns into account.

• The NPV of a sequence of cash flows takes as input the cash flows and a discount
rate or discount curve and outputs a price.

• Each cash inflow/outflow is discounted back to its present value (PV). Then they are
summed. Therefore, NPV is the sum of all terms.
Financial Considerations

Where:

• t is the time of the cash flow

• i is the discount rate (the rate of return that could be earned on an investment in
the financial markets with similar risk; the opportunity cost of capital)

• Rt is the net cash flow (i.e., cash inflow − cash outflow, at time t)
Video

Insert Text Here Insert Text Here Insert Text Here Insert Text Here

Insert Text Here

https://www.youtube.com/watch?v=cSAfp6D28RM
Financial Considerations
• NPV is an indicator of how much value an investment or project adds to the firm. With
a particular project, if NPV is a positive value, the project is in the status of positive
cash inflow in the time t.

• If NPV is a negative value, the project is in the status of discounted cash outflow in the
time t. Sometimes risky projects with a positive NPV could be accepted.

• This does not necessarily mean that they should be undertaken since NPV at the cost
of capital may not account for opportunity cost (i.e., comparison with other available
investments).

• In financial theory, if there is a choice between two mutually exclusive alternatives, the
one yielding the higher NPV should be selected.
Financial Considerations

Net Present Value

Financial Considerations

Present Value Table (Take note of the decreasing value of money as the period increases from 1 to 10 years.)
Financial Considerations
NPV Example

• The following example is calculating the NPV of a project at a discount rate of 12%. The
project takes five years to complete with given benefits and costs for each year.

• In Year 0, there is no benefit to the organization, just an initial cost of $75,000 with no
discount rate.

• In Year 1, the discount rate is 89%. This means that at 12% assumed interest, the time
value of money says that the $1 today is worth $0.89 in one year, $0.80 in two years, etc.

• By calculating the NPV for the benefits and the costs, you subtract the NPV of all costs
from the NPV of all benefits. The final result is a positive value of $105,175.
Table of NPV of costs and benefits
Financial Considerations
ROI

• Return on Investment (ROI) is a performance measure used to evaluate the efficiency of

an investment or to compare the efficiency of several different investments.

• It is one way of considering profits in relation to capital invested.

• This is calculated by subtracting the project’s costs from the benefits and then dividing by
the costs. For example, if you invest $100 and your investment is worth $110 next year,
the ROI is (110 − 100) ÷ 100 = 0.1 or a 10% return.

• In the example: (306,425 − 201,175) ÷ 201,175 = 0.52, or a 52% return. That’s

considered a good return on investment.
Financial Considerations
Payback Analysis

• Payback analysis is important in determining the amount of time it will take for a project
to recoup its investments.

• This is the point at which the benefits start to outweigh the costs. The best way to see
that is by charting the cumulative benefits and costs.

• In the next diagram, the cumulative benefits outweigh the cumulative costs in the second
year.
Financial Considerations
Financial Considerations
Project Charter

• A project charter, project definition, or project statement is a statement of the scope,

objectives, and participants in a project.

• It provides a preliminary delineation of roles and responsibilities, outlines the project

objectives, identifies the main stakeholders, and defines the authority of the project
manager.

• It serves as a reference of authority for the future of the project.

Financial Considerations

The purpose of a project charter is to:

• Provide an understanding of the project, the reason it is being conducted, and its
justification

• Establish early in the project the general scope

• Establish the project manager and his or her authority level. A note of who will review and
approve the project charter must be included.

*Sample Project Charter Template will be provided

Scope Planning
All deliverables must be described in a sufficient level of detail so that they can be
differentiated from related deliverables. Example:

• A twin engine plane versus a single engine plane

• A red marker versus a green marker
• A daily report versus a weekly report
• A departmental solution versus an enterprise solution
Project Requirements
• After all the deliverables are identified, the project manager needs to document all the
requirements of the project.

• Requirements describe the characteristics of the final deliverable, whether it is a product

or a service.

• They describe the required functionality that the final deliverable must have or specific
conditions the final deliverable must meet in order to satisfy the objectives of the project.
Project Requirements
Functional Requirements

• Functional requirements describe the characteristics of the final deliverable in ordinary

non-technical language.

• They should be understandable to the customers, and the customers should play a direct
role in their development. Functional requirements are what you want the deliverable to
do.

Example:
• If you were buying vehicles for a business, your functional requirement might be:
“The vehicles should be able to take up to a one-tonne load from a warehouse to a
shop.”

• For a computer system you may define what the system is to do: “The system should
store all details of a customer’s order.”
Project Requirements
Non-Functional Requirements

• Non-functional requirements specify criteria that can be used to judge the final product or
service that your project delivers. They are restrictions or constraints to be placed on the
deliverable and how to build it.

• Their purpose is to restrict the number of solutions that will meet a set of requirements.
Using the vehicle example, the functional requirement is for a vehicle to take a load from
a warehouse to a shop.

• Without any constraints, the solutions being offered might result in anything from a small
to a large truck. Non-functional requirements can be split into two types: performance
and development.
Project Requirements

To restrict the types of solutions, you might include these performance constraints:

• The purchased trucks should be American-made trucks due to government incentives.

• The load area must be covered.
• The load area must have a height of at least 10 feet.
Project Requirements

Similarly, for the computer system example, you might specify values for the generic types
of performance constraints:

• The response time for information is displayed on the screen for the user.
• The number of hours a system should be available.
• The number of records a system should be able to hold.
• The capacity for growth of the system should be built in.
• The length of time a record should be held for auditing purposes.
Project Requirements

Similarly, for the computer system example, you might specify values for the generic types
of performance constraints:
• The response time for information is displayed on the screen for the user.
• The number of hours a system should be available.
• The number of records a system should be able to hold.
• The capacity for growth of the system should be built in.
• The length of time a record should be held for auditing purposes.

There are three general types of non-functional development constraints:

• Time
• Resource
• Quality
Project Requirements
Technical Requirements
• Technical requirements emerge from the functional requirements to answer the
questions: how will the problem be solved this time and will it be solved technologically
and/or procedurally?
• They specify how the system needs to be designed and implemented to provide required
functionality and fulfill required operational characteristics.

Business Requirements
• Business requirements are the needs of the sponsoring organization, always from a
management perspective.
• They are usually expressed in broad outcomes, satisfying the business needs, rather
than specific functions the system must perform. These requirements grow out of the
vision for the product that, in turn, is driven by mission (or business) goals and
objectives.
Project Requirements
User Requirements

• User requirements describe what the users need to do with the system or product. The
focus is on the user experience with the system under all scenarios.

• These requirements are the input for the next development phases: user-interface
design and system test cases design.

Regulatory Requirements

• Regulatory requirements can be internal or external and are usually non-negotiable.

• They are the restrictions, licenses, and laws applicable to a product or business that are
imposed by the government.
Scope Inputs

The project manager gathers initial project facts from the project charter. In addition,
background information on the stakeholder’s workplace, existing business model and rules,
etc. assist in creating the vision of the final product/service, and consequently, the project
scope.
Scope Inputs

Techniques

Gathering requirements is part of scope definition, and it can be done using one or more of
following techniques:

• Interviews
• Focus groups
• Facilitated groups such as JAD (joint application development)
• Group creativity techniques: brainstorming, nominal groups, delphi, mind map, affinity
diagnostics
• Prototyping
• Observation
• Questions and surveys
• Group decision-making techniques: unanimity, majority, plurality, dictatorship
Scope Inputs

Requirements Traceability Matrix

• The requirements traceability matrix is a table that links requirements to their origin and
traces them throughout the project life cycle.

• The implementation of a requirements traceability matrix helps ensure that each

requirement adds business value by linking it to the business and project objectives.

• It provides a means to track requirements throughout the project life cycle, helping to
ensure that requirements approved in the requirements documentation are delivered at
the end of the project.
Scope Inputs

Finally, it provides a structure for managing changes to the product scope. This process
includes, but is not limited to, tracking:

• Requirements to business needs, opportunities, goals, and objectives

• Requirements to project objectives
• Requirements to project scope/work breakdown structure deliverables
• Requirements to product design
• Requirements to product development
• Requirements to test strategy and test scenarios
• High-level requirements to more detailed requirements
Work Breakdown Structure

• Work Breakdown Structure or WBS is a hierarchical decomposition of the project into

phases, deliverables, and work packages.

• It is a tree structure, which shows a subdivision of effort required to achieve an objective

(e.g., a program, project, and contract).

• In a project or contract, the WBS is developed by starting with the end objective and
successively subdividing it into manageable components in terms of size, duration, and
responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work
packages), which include all steps necessary to achieve the objective.
Work Breakdown Structure

The WBS creation involves:

• Listing all the project outputs (deliverables and other direct results)
• Identifying all the activities required to deliver the outputs
• Subdividing these activities into subactivities and tasks
• Identifying the deliverable and milestone(s) of each task
• Identifying the time usage of all the resources (personnel and material) required to
complete each task
Work Breakdown Structure

The purpose of developing a WBS is to:

• Allow easier management of each component

• Allow accurate estimation of time, cost, and resource requirements
• Allow easier assignment of human resources
• Allow easier assignment of responsibility for activities
Work Breakdown Structure
WBS Example:
Q&A Session