Project Management

1
Project Management

• Lecture 1 Principles of Project Organisation
  Planning
• Les Grant, Chief Executive, DCWM Group

2
Organisation Planning

• Proposition
• Mankinds 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.

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.

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, dont 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.

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.

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.

7
Typical Business Functional Organisation
8
Typical Student Project Organisation
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.
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

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

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 cant be built or which cant be
  sold or which nobody wants is something the
  designer needs to beware of. Hell get the blame!

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 youve 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.

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.

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

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 Occams razor.
• Beware of the one-man-week syndrome.
• Identify key risk areas and make contingency
  allowances.
• Dont 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

16
Einstein discovers t
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.

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.

19
Time Scheduling - a Simple Example
Image Analysis System M1 M2 M3 M4 M5 M6 Buy
Long Leads Design Capture Card Manufacture
Test Digitising SW Integrate
Capture GUI SW Application
Commission Test Accept
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.

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 gt100K (gt55
  margin)
• For a product with huge development but low
  manufacturing costs, margins gt85 are not
  unusual.
• Pricing is dependent on the business and its
  circumstances and is not algorithmic.
• Well discuss pricing further in later lectures.

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.

23
Implementation Phase

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

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.

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.

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.

27
The Programme Review
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

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.

30
Quality Plans

• Quality Reviews are also scheduled as part of the
  program they constitute an independent means of
  verifying the programs conformance with
  specifications and standards.
• Contracts often call for the publication of
  internal Quality Review minutes to the Customer

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.

32
Risk Management

• 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 wont 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.

33
Disaster Recovery

• Every Program experiences some level of disaster.
  Call it Murphys 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.

34
Disasters Blunders

• Write everything in your Log Book. The evidence
  of an emerging difficulty needs to be understood
  in the context of the systems state- vague
  memories are no substitute for written
  observation.
• Whilst industry strives for zero-defects and
  wed 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 youre suddenly on the critical
  path of a multi-million dollar program, then you
  can expect stress.

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

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.