Introduction to Project

Management cont.
Lecture 2
 2

Project Manager Challenge

Subject
Matter
Expertise
Methodology/ Framework
Soft Skills
Planning Tools
PRINCE2
Negotiation
Microsoftskills
Project
PMBOK
Leadership
Excel Methodology
Project
Team building
Pen and paper
Presentation
IPM skills

2
 3

Technical Skills Alone Won’t Ensure Success

Key project “soft-skills”:

• Facilitation skills

• Empowerment-motivation

• Critical thinking

• Relationship management

• Communication-education

• Decision making risks

3
 4

Project Leadership

“Good project managers command both the authority & the

responsibility to guide the project...as a leader your team expect you to
be honest, competent & inspirational as well as competent in the use of
project management techniques. But most of all to be an effective
project manager, you need to lead the project with an energy & a
positive attitude that make you a catalyst for moving the project
forward”.
(Sunny & Kim Baker)

The impact of a PM’s behavior on a project cannot be neutral; it is either

positive or negative.

4
 5

Governance Structure Roles & Responsibilities

5
 6

Activity – A Day in the Life

In pairs, come up with a description of what a “day in the life” may

look like for a:

• Project Sponsor versus

• PM versus

• Project team

6
 7

Project Management Methodologies

• Project management requires sound management approaches based on

consistent and repetitive processes

• Process alone does not form

methodology. Project management
must contain a system of methods,
rules, processes, tools and templates

• A project methodology provides an organisation with common systems,

procedures and language across projects.

7
 8

Project Principles

1. Continued Business Justification

2. Learn from Experience

3. Define Roles and Responsibilities

4. Manage by Stages

5. Manage by Exception

6. Focus on Products

7. Tailor to the Environment

 9

Project Sizes

Some projects: large, complex

Full engagements, typically strategic projects

Most projects: medium, detailed

Medium engagements, can be tactical or strategic
projects

Lite Some projects: small, simple

engagements, typically tactical projects

9
 10

Project Types

Project management, processes, corporate knowledge and tools

not well developed

Project objectives Quest

Paint byFog
Movie
Numbers Project objectives
clear not clear

Project management, processes, corporate knowledge and tools

well developed

Developed by Eddie Obeng

10
 11

Project Phases

4 stage project management approach:

3.
4. Close &
1. Initiation 2. Planning Execution/
Handover
Delivery

1. Initiation – the WHAT - development of the initial goal and technical

specifications of the project.
2. Detailed Planning the HOW – all detailed specifications, schedules, schematics,
and plans are developed.
3. Execution – the actual “work” of the project is performed.
4. Close & Handover – project is transferred to the customer, resources reassigned,
project is closed out.

11
 12

Project Management Methodology

Project
Initiate Plan Execute Close Benefits
Management
Effort realisation
Crisis management

Resources:
People and
$

Good practice - in control

Start
Finish
Time

12
 13

PM Methodology – Project Size

Full

Medium

Lite

13
 14

PM Methodology – Project Types

Paint by Project

Number
Project Project
Movie

Project Project
Quest

Project Project Project

Fog

14
 15

O3 – Objectives, Outputs, Outcomes

To help you articulate the objectives of the Project, it is important to

understand the difference between ‘objectives’, ‘outputs’ and ‘outcomes’.

OBJECTIVE OUTPUT OUTCOME

What we What we What the

are aiming actually business gains
to achieve deliver from our
output
 16

Objectives
• Objectives give your project a direction and once identified will allow
you to develop methods and activities that will achieve them.
• Throughout the project, revisit your objectives and measure what you
have achieved.
• At the end of the project they will help you to demonstrate what you
have achieved.
• Ensure you set ‘SMART’ project objectives:
− Specific - Be clear about what your objectives will achieve
− Measurable – Ensure your objectives can be measured
− Achievable - Ensure your objectives can be achieved
− Realistic – Ensure your objectives can be achieved with available
project resources
− Time-bound – Ensure your objectives can be achieved within a
specified timescale
 17

Outputs
 Projects produce or deliver Outputs (sometimes called Products, or
Deliverables).
 Outputs can usually be seen, touched, or moved about. They are the
tangible products, services or facilities created by your work and are
usually quantifiable.

− Example 1:
− Recruitment. You might have a project to recruit some new
staff. The outputs for your project might include a recruitment
strategy, position descriptions, job adverts, shortlist criteria and
so on

− Example 2:
− Sales. You might have a project to develop a new banking
product. The outputs for your project might include a
prototype, specifications, competitor analysis, bill of materials
and so on
18

Outcomes
 Outcomes are the changes, benefits, learning or other effects that
happen as a result of your project.
 Outcomes can be wanted or unwanted, expected or unexpected. They
are often hard to count or prove, and normally rely on an
understanding of the initial situation or problem for comparison.

− Example 1 outcomes may include:

− Increased capacity to perform particular tasks
− Increased capability with new levels of skills and experience to
ensure we do things better for our customers
− Improved response time when dealing with customers
− Example 2 outcomes may include:
− Increased market share for the banking product
− Enhanced reputation of our brand
− Raised awareness of our brand in the NZ marketplace, or with a
targeted group
 19

Objectives, Outputs, Outcomes

For example, a particular objective might be to improve the Home Loan

approval process.
• The output is a redesigned Home Loan approval process.
• The outcome is an increase in customer uptake of Home Loans.
• In order to meet an objective the project may need to produce more than
one output. Outputs can also produce more than one outcome (benefit).
 20
PM ‘Documentation’
The following are examples of required documents per phase:
Initiate
Full • Initiate Business Case
• Project Charter
• Status Report
• Project Register
• Concept Designs
• Business Requirements
• Procurement Plan
Medium • Charter on a Page
• Status Report
• Project Register
• Concepts/Business
Requirements
• Procurement Plan
Lite • Initiate and Plan on a Page
• Project reports/ agendas/ actions (as required)
Plan Execute Close
• Final Business Case • Execute Report • Close and
• Project Plan (including schedule, coms • Status Report Handover Report
plan, budget, Scope Management Plan) • Project Register • Status Report
• Status Report • Project Register
• Project Register
• Change requests • Handover
• Detailed Designs Documentation
• Detailed Business Requirements
• Plan on a Page • Execute on a Page • Close on a Page
• Status Report • Status Report • Status Report
• Project Register • Project Register • Project Register
• Detailed Designs/Business Requirements • Change • Handover
documentation Documentation
• Execute on a Page • Close on a Page
• Project reports/ • Handover
agendas/ actions (as Documentation
required) • Project reports/
agendas/ actions
(as required)
20
 21

Business Case Process

Confirm Confirm Confirm

benefits benefits benefits

Gate 1 Gate 2 Gate 3 Gate 4

Pre- Initiation Execution Post
project stage Planning stage project
stage

Verify outline Verify detailed Verify updated

Business Case Business Case Business Case

Develop Business Case Maintain Business Case Benefits Realisation

21
 22

Alignment between the Business Case and Project

• The Business Case captures the justification for doing a project (the
problem to be solved, the options considered, the recommended option,
the high-level delivery approach – what, who, how, when, where – the
costs and benefits)
• The Project Manager may be involved in the development of the Business
Case – especially the delivery options – but its often the role of the
Business Analyst or Business Owner to create this document
• No project should begin without an approved Business Case (but this can
be as simple as a directive from the business owner).
• The Business Case is a living document. The project is continually checked
against it to confirm they are both still aligned or, if changes are needed to
the project to ensure delivery, the Business Case is updated to reflect the
impact of those changes.

22
 23

Introducing Feasibility

• Feasibility – the measure of how beneficial or practical a change will be to

an organisation.
• Feasibility analysis – the process by which feasibility is measured.

23
 24

Feasibility

Purpose:
• Provide information for decision making by management/sponsor and/or
steering committee
• It’s about whether the project goal can be achieved given the required
constraints of scope, cost, time and quality
The goal:
• To determine whether to proceed with the project in its present or
modified state*.
• Identify important risks associated with the project
• State the preferred alternative
* Feasibility is reviewed with each scope change

24
 25

Reasons given to have a feasibility study

• Gives focus to the project and outlines the alternatives
• Narrows business alternatives
• Identifies new opportunities through the investigative process
• Identifies reasons not to proceed
• Enhances the probability of success by addressing and mitigating potential issues
early
• Provides quality information for decision making
• Helps to increase investment in the company
• Provides evidence that the business venture was thoroughly investigated
• Helps in securing funding from lending institutions and other sources
http://www.extension.iastate.edu/agdm/wholefarm/html/c5-65.html
 11
26
-
26

TELCOS: Six Tests For Feasibility

Technical feasibility – a measure of the practicality of a technical solution and the

availability of technical resources and expertise.

Economic feasibility - a measure of the cost-effectiveness of a project or solution.

Legal feasibility - a measure of how well a solution can be implemented within

existing legal/contractual obligations.

Cultural (or political) feasibility - a measure of how well a solution will be

accepted in an organisational climate.

Operational feasibility – a measure of how well a solution meets the system

requirements.

Schedule feasibility – a measure of how reasonable the project timetable is.

 11
27
-
27

Technical feasibility

 Is the proposed technology or solution practical?

 Do we currently possess the necessary technology?

 Do we possess the necessary technical expertise?

 28

E.g. if building a house . . .

 Not too technical for a qualified tradesman:
− Builder
− Plumber
− Electrician

 Is it possible to get those tradesmen?

− Now?
− 6 Months from now?

 The Technical Feasibility looks at two key aspects:

− Can it be done?
− Can we get the skilled people/resources to do it?
 11
29
-
29

Economic feasibility

 The purpose of the economic feasibility assessment is to determine the

positive economic benefits to the organisation which the proposed system
will provide.
− It includes identification and quantification of all the benefits
expected.
− It typically involves a cost/ benefit analysis.
− It goes beyond the items typically included in a financial analysis.
− Includes tangible and intangible aspects, and externalities
 It should provide a set of scenarios (sensitivity ranges on the values
assumed in the analysis) that can be tested as part of the economic
feasibility in order to get an idea of potential variation in the outcome
(think optimistic versus pessimistic values)
11
30
-
30

Legal feasibility
 Legislation and regulation
 Copyrights
 Union or other employment contracts
 Legal requirements for financial reporting
 Antitrust laws
 National data and work laws. For example:
− Having a payroll system for NZ developed in another country
− Storage of data in the cloud where the host storage is in another
country
 11
31
-
31

Cultural (or political) feasibility

 Does management support the system?

 How do end users feel about their role in the system (today)?

 What end users may resist or not use the future system? How can this
be overcome?

 How will the working environment change? How difficult might it be

for users and management to adapt to the change?
 11
32
-
32

Operational Feasibility
 How well does the proposed system solve the problems and take
advantage of opportunities identified during the scope definition and
problem analysis phases (including strategic alignment)?

 How well might the proposed system satisfy system requirements

identified in the requirements analysis phase?

 Is the problem still worth solving?

 33

Operational feasibility is a measure of:

1. How well the solution will work and
2. How people feel (or are likely to feel) about the project/solution.

Will the system be accepted by its users, and how easily can it be incorporated
into normal business operations?

Is the problem worth solving? 

Will the solution to the problem work?

How do end users and management feel about the solution?

Has a usability analysis been conducted?


Monday, June 15, 2020

 11
34
-
34

Schedule feasibility
A measure of how reasonable the project timetable (i.e. the project plan
schedule) is.

The objective is to create a realistic project schedule which provides a basis for
monitoring the progress of a project.
 Given our technical expertise, is it possible to complete the project in
time?
 What are the consequences of delay?
 Are the deadlines mandatory, or just desirable?
 Can these constraints be met?