Introduction to Project

Management
 What is a Project?
“Unique process consisting of a set of coordinated and
controlled activities with start and finish dates, undertaken to
achieve an objective conforming to specific requirements,
including constraints of time, cost, quality and resources”

• A Project is a planned set of activities

• A Project has a scope
• A Project has time, cost, quality and resource constraints
 What is Project Management?
• The art of organising, leading, reporting and
completing a project through people
 What is Project Management?
• A project is a planned undertaking
• A project manager is a person who causes things to
happen
• Therefore, project management is causing a planned
undertaking to happen.
 Exercise 1
• Write down three attributes of a good Project Manager
 Project Manager Role
• A Good Project Manager
o Takes ownership of the whole project
o Is proactive not reactive
o Adequately plans the project
o Is Authoritative (NOT Authoritarian)
o Is Decisive
o Is a Good Communicator
o Manages by data and facts not uniformed optimism
o Leads by example
o Has sound Judgement
o Is a Motivator
o Is Diplomatic
o Can Delegate
Stakeholder Engagement
 Stakeholder
“A person or group of people who have a vested interest in the
success of an organization and the environment in which the
organization operates”
 Exercise 2
• Write down three typical project stakeholders
 Exercise 2 - Typical Stakeholders
• Sponsor
• Funding Body
• Customer
• Suppliers
• End User
• Environmental Agency
• Maintenance Team
• Neighbours/Community/Shareholders
• Fusion Community
• Interfaces
 Stakeholder Engagement process
• Identify Stakeholders
• Assess needs
• Define actions
• Establish communication channels
• Gather feedback
• Monitor and review
 Software Projects versus
Other Types of Project
• Invisibility When a physical artefact such as a bridge is
constructed the progress can actually be seen
• Complexity Per dollar, pound or euro spent, software products
contain more complexity than other engineered artefacts.
• Conformity The ‘traditional’ engineer usually works with
physical systems and materials like cement and steel
• Flexibility That software is easy to change is seen as a
strength. However, where the software system interfaces with
a physical or organizational system
Contract Management and Technical Project
Management
o The project manager will not worry about estimating the
effort needed to write individual software components as
long as the overall project is within budget and on time.
o On the supplier side, there will need to be project managers
who deal with the more technical issues. This book leans
towards the concerns of these ‘technical’ project managers.
 Activities Covered by Software Project
Management
• 1. The feasibility study assesses whether a project is worth
starting – that it has a valid business case.
• 2. Planning If the feasibility study indicates that the
prospective project appears viable, then project planning can
start. For larger projects, we would not do all our detailed
planning at the beginning.
• 3. Project execution The project can now be executed. The
execution of a project often contains design and
implementation sub-phases. Students new to project planning
often find that the boundary between design and planning can
be hazy.
• The installation of an ICT infrastructure, the design of
user jobs and user training
• Requirements analysis
• Architecture design
• Detailed design
• Code and test
• Integration
• Qualification testing
• Installation
• Acceptance
 Plans, Methods and
Methodologies
• A plan for an activity must be based on some idea of a method
of work. For example, if you were asked to test some software,
you may know nothing about the software to be tested, but you
could assume that you would need to:
• ● analyse the requirements for the software;
• ● devise and write test cases that will check that each
requirement has been satisfied
• ● create test scripts and expected results for each test case;
• ● compare the actual results and the expected results and
identify discrepancies.
• While a method relates to a type of activity in general, a plan
takes that method (and perhaps others) and converts it to real
activities, identifying for each activity:
• ● its start and end dates;
• ● who will carry it out;
• ● what tools and materials – including information – will be
needed. The output from one method might be the input to
another.

• Groups of methods or techniques are often grouped into

methodologies such as object-oriented design.
 Some Ways of Categorizing Software
Projects
• Compulsory versus voluntary users
• Information systems versus embedded systems
• Outsourced projects
• Objective-driven development : Projects may be distinguished
by whether their aim is to produce a product or to meet certain
objectives.
 Setting Objectives
• The project manager runs the project on a day-to-day basis,
but regularly reports to the steering committee.
• Sub-objectives and goals An effective objective for an
individual must be something that is within the control of that
individual. An objective might be that the software application
produced must pay for itself by reducing staff costs
• The mnemonic SMART is sometimes used to describe well-
defined objectives:
• ● Specific Effective objectives are concrete and well defined.
• ● Measurable Ideally
• ● Achievable It must be within the power of the individual or
group to achieve the objective.
• ● Relevant The objective must be relevant to the true purpose
of the project.
• ● Time constrained There should be a defined point in time
by which the objective should have been achieved.
 Measures of effectiveness
• Measures of effectiveness provide practical methods of
checking that an objective has been met. ‘Mean time between
failures’ (mtbf) might, for example, be used to measure
reliability.
• This is a performance measurement and, as such, can only be
taken once the system is operational
 The Business Case
• Most projects need to have a justification or business case: the
effort and expense of pushing the project through must be seen
to be worthwhile in terms of the benefits that will eventually
be felt.
• A cost–benefit analysis will often be part of the project’s
feasibility study.
• Any project plan must ensure that the business case is kept
intact.
• For example: that development costs are not allowed to rise to
a level which threatens to exceed the value of benefits;.
• ● that the features of the system are not reduced to a level
where the expected benefits cannot be realized;
• ● that the delivery date is not delayed so that there is an
unacceptable loss of benefits
 Project Success and
Failure
• The project objectives are the targets that the project team is
expected to achieve. In the case of software projects, they can
usually be summarized as delivering:
• ● the agreed functionality
• ● to the required level of quality
• ● on time
• ● within budget.
 The Project Process
Project Justification Design Approval Readiness for
Strategic and Budgetary Gate 1 Gate 2
Gate 0 - Approve Project Definition - Approval of Gate 3 Manufacture
Approval Undertake Design Final Documents - Approval to
place Contract

Initiate Project
Prepare Technical Design
Ensure Machine Compatibility Prepare
Safety Case Modification
Undertake Tender
Project
set-up Project
Major
Definition Conceptual
Project Scheme
Design
Proposals Design Detailed Tender
Appoint Project Sponsor Design Invitation &
Assess Project Priority Assess
Budget Implications
Est. Proj. Deliverables and
Raise/Extend/Update initial TCD-R/PERF Assessment
Prepare Outline
Objectives Appoint Project Leader
Conceptual Design Define Design Extend TCD-Rs/PERFs
Approve Project Set-up
Constraints Prepare Interface Prepare Sub-system Detailed Design Hold
Requirements Spec. (IRP) Detailed Design Review (DDR)
EFDA/CSU/JOC Management Finalise Conceptual Design Clear Sub-system DDR Issues
Hold Conceptual Design Review Use TCD-I/MMAC for Sub-system DD Approval
(CDR) Clear CDR Issues Prepare Final Documents including:
Initiate Modification Safety Case - Design Documents., Machine *** These will comprise:
Update PMP Compatibility Documents., Safety Case
Approve Proceed to Detailed Design - Technical Specification
Modification
- Drawings
Project Team/IRP/EFDA/CSU/JDC Project Team/Interfaces/EFDA/CSU/JDC - Contractual Requirements

Draft Statement of Requirements (SoR) Compile Tender Docs.***

* This will include: Review & Approve SoR Identify Send out
Resources Appoint Project Raise/Extend Sub-system TCD-Rs/PERFs Invitations (ITTS) Hold
- Initial WBS, OBS and CBS Agree Classifications & Interfaces
Team Produce & Maintain Clarification Meetings Receive
- Project Plan - Prepare Sub-system Scheme Design
Procurement Plans Tenders Evaluate
Risk and Procurement Strategies Hold Sub-system Scheme Design Review (SDR)
Undertake Project Risk Assessment Tenders Arrange
Prepare Project Boundary Document Clear Sub-system SDR Issues site visits Approve
Develop Project Management Plan (PMP)* Update PMP changes to Specs. Choose
** These will only take place here Raise initial TCD-R/PERF** Use TCD-I/MMAC for Sub-system SD preferred Company
for large projects demanding DO Prepare Preliminary Conceptual Design** Approval
effort for preliminary Conceptual Project Team/Contracts/EFDA
Project Team/Interfaces
work
Project Leader/Project Team/EFDA/CSU

Readiness for Operation

Implement Project Gate 4 - Acceptance of System

Note: Overall Project

Complete Project Management and Reporting will
Manufacture
be as defined in the Project
Equipment Install Management Plan (PMP)
Equipment Test &
Commission Confirm
Completion Project Gates (Formal Decision Points)
Raise Contract Documentation
Place Contract Review See accompanying notes
Hold Kick off Meeting
(KOM) Clarify Issues (Quality Test Equipment against Test Schedule
Plan) Monitor Commission Complete System
Progress Witness key
Procedures Complete Release Undertake Post

UNCONTROLLED
Project Team/ICM/EFDA/CSU Project Review
Note Approve Complete
Package**** Approve Release
Note Pack & Dispatch Project Team/CSU
Equipment

WHEN PRINTED
Confirm Technical Completion
Receive Equipment
Project Team/Contractor/ICM Review Project Records Complete
Pre-test Equipment
Handover Documents Resolve
Install equipment
Reservations Obtain
Acceptance of Completed Project
**** This includes Project Team/ICM
supporting documentation
Project Team/EFDA/CSU
Key Points in Project Set-up and Definition

 Create Project Management Plan (PMP)

 Be clear of scope and objectives
 Establish clear statement of what is to be
done (WBS)
 Establish Risks to be Managed
 Establish Costs and Durations
 Establish Resources Required
 Project management Plan - PMP
 Master Document for Project
 Defines the following:-
 Project Objectives, Scope, Deliverables
 Stakeholders (Internal & External)
 Work to be done (WBS)
 Project Organisation and Resources (OBS)
 Project Costings (CBS)
 Project Schedule
 Procurement/Contract Strategy
 Risk Management
 Quality management
 Change Management
Project Planning
 Project Planning
• Adequate planning leads to the correct completion
of work
 Planning
• Inadequate planning leads to frustration towards the end of the
project & poor project performance

Project Start Project End

 Work Breakdown Structure (WBS)
• The Work Breakdown Structure is the foundation for effective
project planning, costing and management.
• It is the most important aspect in setting-up a Project

 It is the foundation on which

everything else builds
 Work Breakdown Structure -
Definition
“A Work Breakdown Structure (WBS) is a hierarchical (from
general to specific) tree structure of deliverables and tasks that
need to be performed to complete a project.”
Project Planning – WBS (1)
 Lowest Level of WBS is the Work Package
(WP)
 WP can be clearly defined allowing package
to be costed, scheduled and resourced
 WP contains a list of Tasks to be Performed
that form the basis for the Schedule
 WP allows assignment of responsibilities
(Work Package Manger, WPM)
Project Planning – WBS (2)
 WBS allows hierarchical build-up of costs
and schedule
 Cost and Schedule can be reported at any
level of the WBS
 WBS facilitates strong management during
project execution (Cost and Schedule
control)
 WBS can be used for many other things -
Document Management, Risk Management
etc.
Project Planning
 A word about Scheduling
– Schedules (task durations) can have a wide
variation
– There is no unique answer. Rather, there is a
statistical variation depending on assumptions
– Need to understand the basis of scheduling
(Most challenging; Most likely; Absolute certainty
- bet your life on it!)
– Most people are very optimistic/naive
Common schedule development
Accuracy of Timescale Estimates

100
90
80
Subsequent
70 Estimates
Probability

60
50
40
30 First
20 Estimate

10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Timescale
 Project Planning – Key Points
• Recognise that adequate project planning is essential
• Produce a sound WBS
• Use the framework provided by the Project Management Plan
(PMP) template
• Involve the right people
• Allow enough time
• Be systematic
Project Risk Management
 Project Risk – Definition (1)
“Project risk is an uncertain event or condition that, if it occurs,
has a positive or negative effect on a project objective”
 Project Risk – Definition (2)

“A combination of the probability of a defined threat or

opportunity (Likelihood) and the magnitude of the
consequences of the occurrence (Impact) defines a Risk Index”
 Risk Impact
Threat → Scope → Poor Quality Product
Threat → Schedule → Late Delivery
Threat → Cost → Overspend

• In addition there are health, safety and environmental threats

that must be managed
 Risk Management Process
• Identify Risks
• Assess likelihood and impact
• Rank risks and prioritize
• Define risk management approach & actions
• Implement actions
• Monitor & review
 Risk Management – Key Points
• Make the management of risk integral to the way the project is
managed
• Ensure that cost and time contingencies are consistent with
identified risks
• Focus on the “significant few” – don’t try to manage too many
risks
• Be vigilant (be ready for possible problems and
diffuculties)and proactive
Project Monitoring and
Control
 Exercise 3
• Write down three typical project control/monitoring activities
•
Project Monitoring
Typical Monitoring Activities
o regular reviews of progress against schedule using WBS as
basis (Plan against Baseline)
o regular review of actual costs (O/P from SAP) against
budgeted costs and Earned Value at WBS level
o regular review of resource loading
o regular progress meetings with project team
o regular meetings with contractors
o production of periodic progress reports
o risk reviews
o inspections/ audits
 Project Control
• Typical Control Activities
o assign responsibilities at Work Package level
o staged authorisation of work to be done
o staged release of budgets (staged release of WBS(e) numbers)
o ensure PM has a ‘Management Reserve’ under his control
o seek corrective action reports when WPs go ‘off track’
(overrunning or overspending)
o release Management Reserve carefully
 Project Monitoring and
Control Summary
• Monitor against the plan – status regularly
• Take a factual approach to decisions
• Identify management action early
• Check that defined controls are being applied – correct if
necessary
• Apply change control
 Confirm Completion
• Ensure design records are complete and accurate
• Ensure any outstanding actions or issues are addressed
• Ensure Maintenance Records are produced
• Ensure User Manuals are produced
• Hold a formal Post Project review