Project Management

1. Project Management Lecture 1 : Principles of Project Organisation & Planning Les Grant, Chief Executive, DCWM Group

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 2

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 3

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 4

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 5

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 6

7. Typical Business Functional Organisation Slide 7

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. Slide 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

16. Einstein discovers t=$ Slide 16

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 17

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 18

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 Slide 19

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 20

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 21

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 22

23. Implementation Phase • Organization & Responsibility allocation • Program Planning & Budget Setting • Design Reviews • Program, Quality and Safety Reviews • Risk Management • Disaster Recovery • Conformance & Testing Slide 23

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 24

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 25

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 26

27. The Programme Review Slide 27

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 28

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 29

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 30

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 31

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 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. Slide 32

33. Disaster Recovery • 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. Slide 33

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 34

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 35

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. Slide 36