Which project management methodology? A guide for the perplexed. BCS London (South) branch Wednesday 6 th May 2015

Transcription

1 Which project management methodology? A guide for the perplexed. BCS London (South) branch Wednesday 6 th May

2 Because someone says so To provide guidance to novices To identify best practice To impose a common approach Improves communication common language Can add/change staff without massive retraining Simplifies project interfaces Why project management methods? 2

3 Ensures consistency of work quality does not depend purely on who does the work Quality benchmarks Encourage/enforce quality within your own team Encourage/enforce it with contractors Why project management methods? 3

4 Orientation Types Examples Personal (project manager) Bodies of Knowledge PMI, APM Projects Standard procedures PRINCE2 Processes Project organisation Waterfall, V-process model, DSDM etc Quality assessment Organisations Process quality CMMI, ISO 900x Product quality ISO 9126 Kinds of ITPM standards 4

5 Focus on project manager: Project management Bodies of Knowledge 5

6 PMI-BOK Project Management Institute Body of Knowledge A US-based PM professional body with individual membership with a UK chapter BOK can be seen as a syllabus PMI runs examinations leading to PM professional qualifications APM-BOK Association for Project Management Similar to above but UK-based Project manager - Bodies of knowledge 6

7 BS 6079 Guide to Project Management British Standard published by British Standards Institution No examinations/qualifications for this one Note: all these are related to general PM not just IT PM. Bodies of knowledge - continued 7

8 Focus on project management processes 8

9 PRINCE2 Emphasis on practical procedures and information system needed to manage a project UK-based generic PM approach but origins in IT Although focused on procedures which an organisation would have to set up, it runs examinations/qualifications for individual practitioners Procedure/ project manager - PRINCE2 9

10 Product Activity Product Activity Product e.g. Specification e.g. coding e.g. Software component e.g. Test component e.g.tested component Activities vs Products 10

11 1. Identify deliverable and intermediate products create Product Breakdown Structure 2. Identify dependencies between products e.g. Code needs a specification create a Product flow diagram 3. Dependencies are effectively activities draw up Activity Network Other key PRINCE2 feature project stages PRINCE2 product-driven approach 11

12 How activities and products in a project are arranged for execution Processes standard ways of doing things; are repeatable e.g. Design and write code using UML Project defined, one-off undertakings which use processes e.g. Implement UK Universal Credits system process <<<<repeated one-off>>>> project Process models 12

13 1. The age of order waterfall 2. The age of uncertainly reduction 3. The age of efficiency The three ages of project process models 13

14 The age of order 14

15 requirements analysis design build test install Waterfall or once-through or one shot 15

16 Perceived advantages An orderly approach Each stage supplies intermediate products used by next Quality control at the end of each stage User knows what is to be delivered agreed at requirements stage Waterfall 16

17 feasibility study corrections review requirements analysis corrections user acceptance system design corrections system test software design corrections unit test Another way of looking at the waterfall model code V-process model 17

18 During progress through the waterfall processes Effort/duration estimates tend to become more accurate Defects tend to accumulate Waterfall project progress 18

19 The age of uncertainty reduction 19

20 Designed for high-risk innovation projects At the beginning of the project Identify areas of uncertainty Design learning activities e.g. Prototypes to reduce uncertainty - these become extra initial stages Could have more than one iteration of a prototype At end of each waterfall stage Assess amount of uncertainty remaining in project If too high, abandon the project Boehm s spiral model 20

21 delivered system design build install evaluate first incremental delivery increment 1 design build install evaluate second incremental delivery increment 2 design build install evaluate increment 3 third incremental delivery Incremental delivery 21

22 IF uncertainty HIGH THEN use evolutionary approach If complexity is HIGH THEN use an incremental approach IF uncertainty and complexity both LOW THEN use one-shot/ waterfall IF schedule is TIGHT THEN use evolutionary or incremental Euromethod/ISPL heuristics 22

23 Dynamic System Development Method Essentially a codification of incremental/ evolutionary principles Has developed a DSDM Atern vocabulary UK-based Offers examinations/qualifications DSDM Atern 23

24 The age of efficiency 24

25 Key concern of these approaches the reduction of the length of communication paths e.g. between specification and software delivery Examples: XP (extreme programming) Crystal technologies, features-driven development, DSDM Atern, Scrum The viewpoint is very much that of software development Agile Alliance ( acts as an umbrella organisation Agility 25

26 All these focus on the immediacy of communication Talk directly with users Provide very frequent working increments Create test plans as you identify requirements Daily integration of components Programming in pairs These need Collocation User participation Examples of XP practices 26

27 More widely applicable than XP origins in product development than design Product owner is key stakeholder authority on design requirements Development done in a number of one to two week sprints Scrum 27

28 Group meeting to identify requirements - recorded in a product backlog Also identifies tasks needed to implement product backlog in a sprint backlog Identifies tasks/products for first sprint, i.e. Increment Estimates effort for each task and allocates tasks to developers Scrum planning meeting 28

29 Each developer reports: Progress since last meeting Planned activities for next meeting Any inhibitions of further progress Sprint terminates with a sprint review meeting presentation of products to product owner Followed by planning meeting for the next sprint Sprint execution Sprint meetings daily 15 minute stand-up meeting of the development team 29

30 Software projects as production lines 30

31 PROCESSES <<<<repeated one-off>>>> PROJECT Where time to delivery is crucial increments can be over-lapped TIME>>>> Inc 1 design build test Inc 2 design build test Inc 3 design build test Need for careful coordination as stages not same length The project as production line 31

32 code B feeder specify design code C test buffer create tests feeder Critical chain projects 32

33 TWO estimates produced for each activity: most likely (50% chance of being achieved), and a safety margin Most likely estimates are targets for all activities Critical chain activities: 50% of sum of safety margins in chain are used in the project buffer at end Feeder buffers where sub-chains feed in All activities started as late as possible Critical chain 33

34 Central idea of lean manufacturing is just in time only make components when actually needed. This saves having large expensive inventories Japanese companies have reputation for effective Quality Circles in industry focussing on process improvements groups of workers identify/implement improvements Attempts made to apply ideas to software development with mixed results Lean and Kanban 34

35 Suitable for where there is a group of software intensive systems sharing common features and assets and/or supplying a specific market e.g. Where there are product lines. Software product lines 35

36 Focus on the identification of reusable software components and other assets. Core Asset Development Product development Management Software product lines 36

37 Delivery quality 37

38 How do you know that your suppliers are of good quality? How do you persuade your customers you are good? ISO 900x a generic standard for quality management systems CMMI Capability Maturity Model ISO 9126 Software Quality Standard Delivery quality standards/ methods 38

39 A company is at level 1 by default i.e. there is no level zero 4. managed 3. defined 5. optimizing process management process control 2. repeatable process definition 1. initial basic management control ISO is an international standard which implements a CMM Approach Process maturity levels 39

40 system errors requirements design methods a managed process design & define directives design defects system design manage tools, staff etc inspection criteria code & unit test tested modules tools, staff etc. test plans integrate/ system test tools, staff etc. system software 40

41 ISO 9126 Software product quality Attributes of software product quality External qualities i.e apparent to the user of the deliverable Internal qualities i.e. apparent to the developers of the deliverables and the intermediate products ISO Procedures to carry out the assessment of the product qualities defined in ISO 9126 ISO standards 41

42 ISO 9126 software qualities functionality reliability usability efficiency maintainability portability does it satisfy user needs? can the software maintain its level of performance? how easy is it to use? relates to the physical resources used during execution relates to the effort needed to make changes to the software how easy can it be moved to a new environment? 42

43 Need for organisational commitment/ motivation Danger of lip service only e.g. PINO Danger of means-end inversion Need for the tailoring of methods Judgement about level of detail Some discussion points 43