Project Management

Lecture 1 : Principles of Project Organisation & Planning

Les Grant, Chief Executive, DCWM Group

Slide 2

Organisation & Planning

Proposition :“ Mankind’s development and dominance of this planet

derives from its opposable thumb and its ‘intelligence’, particularly its abilities to solve abstract problems, predict outcomes and to act as coordinated groups to achieve common objectives. ”

This lecture is primarily about the complementary

sciences of Organisation & Planning – - The Coordination of Action & Predicted Outcome.

Slide 3

Coordinated Action In General, for Group Activities to be fruitful, the

following is required:- A common shared view of the objective and sub-objectives. A high level of sustained communication. The availability of appropriate resources. The ability of the applied resource to meet required

performance levels. A shared ‘plan’ of action. An mechanism to predict outcome, identifying and correcting

errors as they develop.

Slide 4

Football Team Model Primary Objective – Win game

Main Sub-objectives – score goals, stop opposition scoring goals.

Subsidiary contributing objectives – control midfield, employ offside trap, don’t give away penalties…..

The Game Plan – a vision of how the team will play (hopefully understood by all members of the team)

Individual objectives – Mr Savage will ‘mark’ Mr Rooney …..

Communication – verbal, continuous (between players & with Manager)

Resource availability & ability – picking the right players to fill a specific role.

The error identification and correction mechanism – empirical observation, tactical changes, substitutions.

Slide 5

Engineering Programs

Primary Objective –timely completion of project to desired specification.

Sub Objectives – timely design & construction of contributing components within required design tolerances, keeping within cost constraints.

Game Plan – A programme identifying timescales and resources needed for each sub objective and the primary objective.

Individual Objectives – Allocation of responsibility to execute parts of the programme to individuals.

Communication – often verbal, ALWAYS confirmed by written specifications, meeting notes and action lists.

Error Correction – Formal Programme Reviews, identification of adverse variances in cost, time or performance, agreed remedial actions.

Slide 6

Some Definitions

Design - everything involved in the process of turning a customer specification into a realised solution.

Management - the process of organising, prioritising and coordinating resources to meet some desired objective.

Organisational Structure – the framework of reporting relationships and areas of responsibility which describes the structure of a business or group.

Slide 7

Typical Business Functional Organisation

Sales

M arketing

P roductM anagem ent

Service

Custom erSupport

Sales & M arketing

R & D

Design

Draw ingO ffi ce

Engineering

Purchasing

P roduction

Shipping

O perations

Accounting

Clerical

Com m ercial

Adm inistration

Q uality Assurance

Q uality Control

Q ualityM anagem ent

ExecutiveM anagem ent

Slide 8

Typical Student Project Organisation

S tu d en t 1 S tu d en t 2 S tu d en t 3 S tu d en t 4

One of the major challenges you face in successfully completing your student project, as part of a team, is that there is no organisational structure already established.

Slide 9

Overview of a Generic Project Requirement Specification Design Specification & Key Parameters of Design Identification of Applicable Standards Delineation of Tasks and Sub tasks Design Estimation : Costs & Timescales, Risk analysis Organization & Responsibility allocation Program Planning & Budget Setting Design Reviews Program, Quality and Safety Reviews Risk Management Disaster Recovery Conformance Testing

Slide 10

Requirement Specification

The process of design is always predicated by a Requirement Specification. These vary from 4 word descriptions (An electric powered car) through to multi-volume documents which describe the customer requirement in fine detail (e.g. Power Plant, Military Equipment).

Sometimes the ‘Customer’ who generates the Requirement Specification is part of the same organisation as the Design Team. I.e.. the Product Marketing Manager will define a Product Requirement by integrating various inputs from Market Research, External Customers & the Sales Team

Slide 11

Functional Specifications

Even for the simplest product it is essential that the Customer Requirement is translated into a Technical (Functional) Specification which details the functional requirement in precise terms. It should define the performance requirements and constraints as completely as possible.

IT NEEDS TO BE WRITTEN DOWN ! Because this is where things most often start going wrong - with the various stake holders in a Product (Customers, Designers , Manufacturers and Sales people) all having a dangerous tendency to view things differently. The prospect of designing a product which can’t be built or which can’t be sold or which nobody wants is something the designer needs to beware of. He’ll get the blame!

Slide 12

Functional Specifications A well defined, tight Functional Specification is a Good Thing ( and you might need it later to defend your design)

Delineate the Key Parameters of the Requirement. e.g. the externally imposed constraints on the design, try to nail down the external variables (size, voltage, throughput, colour etc. )

Think of the Specification as the foundation on which everything else will be built. Get it right and you’ve isolated one of the greatest threats to your success and that of the design.

Define any applicable external standards for the design. E.g. EMC standards, quality standards (ISO 9001 etc.), compatibility with other equipment, interface standards etc.

Slide 13

Design Specifications

The Functional Specification now needs to be decomposed to a number of sub-components and tasks. Remember that at this stage this is still a paper activity.

A balance is needed: too many subtasks can generate a costly estimate and too few will often generate an underestimate.

It is a good idea to start this process by producing an overall Systems Diagram which shows the major functional modules and their interconnections and to then subdivide these modules into their major elements.

Slide 14

Time & Cost Estimation

Two Key Elements : identify the likely time, labour and material costs needed to complete each subtask and also identify any dependencies between the various subtasks.

Remember each task is likely to decompose into at least the following phases;

Initial Design Review Implementation Testing, Rework and Integration Acceptance

Slide 15

Estimation Estimates are all either based on experience, analogy or ignorance. Use the

experience of those around you to help refine your estimates. Beware of failure to apply Occam’s razor.

Beware of the one-man-week syndrome.

Identify key risk areas and make contingency allowances.

Don’t forget that if you make the estimate too fat you may make the development program appear infeasible.

If you make the estimate too optimistic you may cause other problems.

Remember that you often get to verify (defend, apologise for, bitterly regret) the accuracy of your estimate in practice.

As always time=£

Slide 16

Einstein discovers t=$

Slide 17

Estimation

Produce a costed materials list with quotes for major items. Identify any long lead items. Identify new (untried, unfamiliar) technologies as risks and treat

them as such when estimating durations. Build in learning times. Verify that the development tools needed are either available or

costed into the estimate. For every in-house designed component ensure you have a good

answer to the make/buy question. Estimation needs often to be addressed from both Top down and

Bottom Up perspectives, i.e. you will have externally imposed timescale and cost constraints.

Slide 18

Time-Scheduling Either use a proprietary PM tool like Microsoft Project to generate

timelines or hand draw a Time-Schedule chart.

To Produce a simple Time-Schedule chart you need the estimated time-scale of each component of the design, the Milestones or critical points of interdependency of the program and the external constraints (total elapsed time available, staff type and numbers , lead times for externally bought materials).

In my experience it is better to work back from the delivery date and build up the Critical Path or the line through connected activities which , if any activity on it extends or contracts, then the whole program extends and contracts in the same way.

Slide 19

Time Scheduling - a Simple ExampleImage Analysis SystemM1 M2 M3 M4 M5 M6

Buy Long LeadsDesign Capture CardManufacture & Test

Digitising SWIntegrate CaptureGUISW Application

Commission & TestAccept

Slide 20

Commercial Cost Work Up Labour Hours x Labour Rates (Design, Manufact, QA, Management)

Overhead Recovery (Indirect Costs allocated to contract ) Raw Material Costs (Bought out components & modules)Sub Contract Costs (Major elements made outside)Technical Contingency (Timescale & Cost slippage)Escalation (Increases in cost base over project)Royalties (License fees etc.)

For a fully costed commercial project there are other costs: shipping, duties, installation costs, commissions, in addition to provisions for Warranty Costs, Currency costs, Financing costs, plus some PROFIT.

Slide 21

Commercial Pricing

Pricing is primarily a function of what they market will stand, the competitive position, and the business strategy.

For a design and build special to type project it is not impossible that the job might be priced at around or even below the cost.

For an industrial product, like a medical instrument, it would be usual for a product costing $45K to be priced at >$100K (>55% margin)

For a product with huge development but low manufacturing costs, margins >85% are not unusual.

Pricing is dependent on the business and its circumstances and is not algorithmic.

We’ll discuss pricing further in later lectures.

Slide 22

Planning & Estimation Summary

Customer Requirement – translation into Functional Spec Design Specification & Key Parameters of Design Identification of Applicable Standards Delineation of Tasks and Sub tasks Design Estimation : Costs & Timescales, Risk Analysis Pricing

In industry there is then a Go /No Go Decision for internal projectsor

A decision whether to proceed with a Tender and if so at what price.

The cost & timescale basis of this decision becomes the BUDGET. In your project you will have a financial budget (Limit on spend)

and an overall timescale budget (by when the project must be finished) externally imposed.

Slide 23

Implementation Phase

Organization & Responsibility allocation Program Planning & Budget Setting Design Reviews Program, Quality and Safety Reviews Risk Management Disaster Recovery Conformance & Testing

Slide 24

Program Organization

In industry an overall manager/coordinator for the program is appointed. Someone needs to be in charge.

This raises an interesting issue for your projects – you need to decide as a groups how you will organise yourselves. The lack of an externally nominated leader means that it is vital that you document agreements about who will do what and that you formally review individual progress as a group on a regular basis.

The first task is to revisit the overall design, as a group, identifying again the key components of the system and allocating design responsibility to individuals or teams.

Slide 25

Program Planning & Budget Setting

The Program Plan produced as part of the estimation process now needs to be revisited and more detail added and Line items or Tasks allocated to individuals or team leaders along with both time-scale and financial budgets for the work.

In industry the design team will be tasked with improving significantly upon the basis of the estimate.

The team leaders, their teams, and Project Manager then conduct a detailed review of the program, identifying clearly dependencies between program elements, the timing of formal Design Reviews and the latest date for Deliverables.

The revised Program which emerges might well identify deficiencies in the original estimate. People tend not to be sympathetic to requests to increase budget and time-scale at this stage.

Slide 26

Design Reviews Design Reviews need to be bolted into the Program Plan. They are

immovable, regular events which both management and engineering teams need in order to :

Re-affirm that the Design Objectives & Spec are being met. Confirm that the ‘interfaces’ between design components are being

considered and resolved. Identify emerging problems and risks and establish the strategy for their

resolution. Attempt to avoid BLUNDERS. Confirm that development and documentation standards are being

adhered to. Get all of the guys involved in the Design Process talking to each other on

a regular basis

All decisions and actions agreed at Design Reviews need to be documented.

Slide 27

The Programme Review

Slide 28

Program Reviews

Program reviews (often called Progress Reviews) are regular (monthly) reviews of progress and cost, focusing on the following:

A comparison of actual progress achieved to date versus the program schedule.

A comparison of costs to date versus budget. The identification of remedial programs aimed at reducing

negative variances. For Projects, an evaluation of the payment status of the project ,

its net cash position. The identification of Risks, their status and strategy for

resolution. Again this all needs to be formally documented & published

Slide 29

Quality Plans and Reviews

The Quality Plan simply defines the Standards to which the work will be executed , the number, type and frequency of reviews that will take place, and the procedures to which the design teams will adhere during the Program.

It also identifies a schedule of Quality Audits that will take place during the program to verify compliance with stated standards.

The Quality Plan often also defines the criteria against which completion of milestones (payments) and eventual acceptance of the project (or product) will be made. It often goes so far as to define the testing schedule in detail.

Slide 30

Quality Plans

Quality Reviews are also scheduled as part of the program: they constitute an independent means of verifying the program’s conformance with specifications and standards.

Contracts often call for the publication of internal Quality Review

minutes to the Customer

Slide 31

Safety Reviews Everyone involved in design (or indeed any commercial activity)

has a legal obligation to ensure that the products they make, the processes they use and the environment in which they work does not constitute a hazard to their staff or customers.

Safety Reviews are a statutory requirement which serve to provide positive confirmation that Safety Standards, be they Health & Safety at work or Electrical Safety Standards or whatever applicable, are being complied with.

Normally 2 or 3 times in a program the Safety implications are formally reviewed and minuted.

Slide 32

The Art of determining things that are likely to adversely impact the Program and make appropriate plans to contain the problems, find alternative solutions and minimise their program (time-scale and cost) implications.

Design always involves some risk: that your half baked idea won’t work, that the processor or chip you build into your design is flawed, that you have unwittingly happened upon a hard problem.

The frequent (and often irritating) reviews and revisits are aimed at identifying emerging risks at an early stage, before they become critical path items.

Risk Management

Slide 33

Every Program experiences some level of disaster. Call it Murphy’s Law - SOMETHING ALWAYS GOES WRONG - an the engineering designer often finds himself in the midst of a Spanish Inquisition.

The key to fixing a problem is (not surprisingly) being able to understand its precise cause. For complex systems, the interaction of cause and effect can make fault finding tedious and complex, but failure isolation is the first step to correction.

Never, never believe that things fix themselves - faults that ‘go away’ often are simply waiting for a more critical part of the program before they re-emerge.

Disaster Recovery

Slide 34

Disasters & Blunders

Write everything in your Log Book. The evidence of an emerging difficulty needs to be understood in the context of the system’s state- vague memories are no substitute for written observation.

Whilst industry strives for ‘zero-defects’ and we’d all like perfect designers, the reality is we need people who can logically identify emerging problems and deal with them (& not panic).

Industrial design can be a high pressured activity and if you’re suddenly on the critical path of a multi-million dollar program, then you can expect stress.

Slide 35

Disaster Recovery- Simple Rules

A project disaster impacts everyone on the project - a good project manager will involve those not directly impacted in the resolution of a major problem.

Allocation of Blame is less important than Identification of the Resolution.

The sequence of Reviews is designed to identify problems early enough to be resolved with minimum impact- this requires that everyone takes their role in these reviews seriously.

A good documentation trail, through Log Books, Review Meeting Notes, Action Lists and Design Documents is invaluable in being able to understand and correct the causes of Disasters

Slide 36

Conformance Testing

How do we know when we are finished with our design?

In the main when we have proven that our design meets the requirement specification.

In order to do that we have, built into the Quality Plan a set of Conformance Tests.

These are designed to validate by measurable demonstration or observation that every element of the requirement has been met.

In industry these tests are undertaken independent of the design team and often include customer representatives.