Which frameworks can be used with PMBoK

Project management. 5. Frameworks and standards in IT project management. Lecturer version !!!

Transcript

1 Project Management 5. Frameworks and Standards in IT Project Management Lecturer's Version !!! 1 5. Frameworks and standards in IT project management 5.1 V-Modell XT 5.2 PRINCE The 7 basic principles Topics Overview: PRINCE processes Features and special features 5.3 PMBOK Guide Basic structure and structure of areas of knowledge Overview of project processes Processes Phase 1: Preparation phase Processes Phase 2: Planning phase Processes Phase 3: Implementation of processes Phase 4: Introduction of processes Phase 5: Final phase 2 1

2 5.1 V-Modell XT The V-Modell XT contains concrete, standardized procedures. In the individual process steps, the results to be created are defined and responsibilities are assigned for them. The focus is on the questions who has to do what and when in an IT project (cf. V-Modell XT, version p. 1-3). 3 objectives of the V-Modell XT minimization of project risks quality improvements transparent cost presentation communication between all parties open to model changes 4 2

3 Basic conception of the V-Modell XT system development project of a client System development project of a contractor Introduction and maintenance of an organizational change model The core of the V-Modell XT are the process modules. These are independently developable and changeable units. They consist of activities that can be composed of sub-activities, of products that can consist of several topics and of roles that are responsible for a development part. 5 Components of process modules 6 3

4 Product structure ... 7 Process module map When the V-Modell XT is tailored to exactly one IT project, a specific selection of process modules is made. 8 4

5 Project implementation strategy The V-Modell XT is designed so flexibly that, among other things, both the basic model for sequential as well as incremental or evaluative process models can be supported

6 Decision points for the project implementation strategy 11 Application example (structuring of the decision points) 12 6

7 Project planning (project-specific implementation strategy) 13 V-Modell XT project assistant 14 7

8 Tailoring 15 Determination of decision points 16 8

9 Data transfer according to MS-Project 17 V-Modell XT The V-Modell XT Bund is an extension of the flexible process model V-Modell XT adapted to the needs of the authorities

10 Success Factors Pitfalls - Practical Tip Do not start an IT project without defining a process model. Select a process model based on the following criteria of completeness, systematics, modularity, general validity and adaptability (cf. Bunse, C .; Knethen, A .: (2002), p. 101). Adapt the process model to the specific project. Make sure that all those involved in the project (customers, partners, users, developers,) have knowledge of the process model. The process model is an important component in the project documentation and can be used for later IT projects. The experience with a certain process model in a concrete project implementation is of considerable value for follow-up projects PRINCE2 PRINCE = Projects in Controlled Environments PRINCE2 is a process model for project management that consists of processes, components, techniques and a phase model. Linssen, O .; Rachmann, A .: P .: PRINCE2 a process-oriented project management approach, in: HMD Heft 2008; P. 69. Based on best practices Copyright owner: Office of Government Commerce (OGC). Development begins as early as 1989 (Central Compuer and Telecommunications Agency) several revisions (last refresh: 2009) Official website: most widespread in Great Britain 20 10

11 PRINCE2 is based on: 1. Basic principles The basic principles define the basic philosophy of the method. 2. Topics Topics represent the areas (aspects) that are continuously considered during the project implementation. 3. Processes The processes are used to define activities, products and responsibilities. It is required that the method must be adapted to each project. The adaptation occurs primarily in the processes. The basic principles should be preserved The 7 basic principles 1. Ongoing business justification (business case) Every project needs an economic justification. This should be described at the beginning, but it can change during the course of the project. 2. Learning from experience, document positive and negative findings. PRINCE2 calls for the preservation of findings Use of collected findings from completed projects 3. Defined roles and responsibilities Company representatives (project as an investment) User representatives (usability of project results) Supplier representatives (provision of know-how for implementation) 22 11

12 The 7 basic principles (continued) 4. Taxes via management phases Number of phases can be freely selected (at least 2 phases) The end of the phase represents a decision point in which the following is presented: Current project status Business case for the project Plans for further development 5. Taxes according to the Management by exception principle 6. Product orientation Project results are called products each product must be clearly defined at the beginning for each product it should be determined how its completeness can be checked 23 The 7 basic principles (continued) 7. Adaptation to the project environment Tailoring Adaptation of the processes Adaptation to project requirements Adaptation to project scope Adaptation to project size / design Tailoring prevents a project from being implemented according to a single textbook template

13 5.2.2 Topics The basic principles are to be satisfied by 7 topics. Basic principles are taken up and made more concrete. Topics represent the preliminary stage for processes. 1. Business case Specification of the principle Continuous business justification Comparison of costs and benefits Risk assessment. In the event of project changes, the business case may have to be adjusted again. 2. Organization Specification of the principle Defined roles and responsibilities Definition of the responsibilities of the project participants Definition of responsibilities Definition of clear communication structures 25 topics (continued) 3. Quality Specification of the principle of product orientation and learning from experience Definition of quality criteria in product descriptions, these can be the prerequisite for acceptance form quality management Quality planning, control, assurance Integration of regular retrospectives 4. Plans The control of a project is based on plans. Plans describe how, when and by whom one or more goals will be achieved. Plan = simulation of the future 5. Risks Every project harbors risks Risk assessment is essential for every project 26 13

14 Topics (continued) 6. Changes Changes should neither be ignored, waved through nor lost. Changes are to be assessed with regard to the business case. 7. Progress Regular comparison of the services provided in the project with the planned goals serves to justify the business 27 Processes PRINCE2 distinguishes 7 processes that have to be adapted to the specific project. Process model by PRINCE2 Wagner, A .; Ziller, C .: IT project management: classic-agile, in: Kammerer, S .; Lang, M .; Amberg, M .: IT-Projektmanagmeent Methods Best Practices from Scrum to PRINCE2, 2012; S.

15 5.2.3 Overview: PRINCE2 processes 1. Preparing a project Should the project be started at all? First cost / benefit estimates of preliminary business case Clarification of responsibilities 2. Initiation of a project Specification of the preparation process How should the project be controlled? What project results can be expected? Tailoring (adaptation of the processes) 3. Steering of a project Support for the steering committee by providing information Approval of phase plans for the following phase 29 Overview of PRINCE2 processes (continued) Controlling the phase Daily business of a project manager Coordination of work Management of risks and open points Recording project progress Manage a phase transition work after each phase / responsibility: project manager information supply for the steering committee retrospective of the previous phase management of product delivery creation of project results quality control measures acceptance documentation 30 15

16 Overview Caution: adapt !!!! PRINCE2 Prozessmodell.jpg & imgrefurl = _Methodik_und_Bewertung & h = 419 & w = 600 & sz = 75 & tbnid = IWo9IPMjIePPiM: & TBNH = 85 & tbnw = 122 & zoom = 1 & usg = RMCBp atkndv5dlzsuewjydyn3uq = docid = 2g6cazshkmbiam & hl = en & sa = x ei = krnlunxadoab4gtmn4hiba & ved = 0cfyq9qewa A & dur = features and peculiarities project manager is responsible for a phase the overall responsibility lies with the steering committee; the responsibility for use lies with the user representative 32 16

17 Process of a PRINCE2: 2009 project% C3% 9Cbersnungsgrafik / dp / / ref = pd cp eb

18 5.3 PMBOK Guide PMI = Project Management Institute Founded 1969 USA (Atlanta) more than members Association with the largest number of members in the field of project management PMBOK Guide = Guide to the Project Management Body of Knowledge Widely used project management standard recognized by: ANSI and IEEE PMI carries out certifications through CAPM Certified Associate in PM; PMP Project Management Professional In Germany you can find chapters in Berlin, Munich, Frankfurt and Cologne 35 PMBOK Guide contains a collection of best practices The recommendations are structured generically and are suitable for a variety of industrial plant construction projects, organizational projects PMBOK Guide can also be used for software development projects ! Theoretically, the PMBOK Guide can also be used to carry out software projects; Without a specific adaptation, however, a pragmatic, efficient and effective implementation is very difficult. von Brisinski, N .; Vollmer, G .: Pragmatic IT project management; 2010, p. 16 Frameworks need to be adapted company- and project-specific! 36 18

19 5.3.1 Basic structure and structure of the PMBOK Guide PMBOK-Guide comes from without a phase model 37 PITPM based on the PMBOK-Guide PITPM = Practical IT Project Management Adaptation of the PMBOK-Guide for software development by N. Spitczok; G. Vollmer: Pragmatic IT project management; Lead software development projects based on the PMBOK Guide; dpunkt.verlag

20 5.3.1 Basic structure and structure Projects are divided into 5 phases and 9 areas of knowledge Areas of Knowledge (1) 1. Integration management (Project Integration Management) Integration of all knowledge areas (requirements, needs, etc.) Stakeholder management (coordination of all persons that influence the project) 2. Content and scope management (Project Scope Management) Definition and limitation of the project scope 3. Quality management (Project Quality Management) Early integration of quality aspects in all sub-areas of the project 4. Communication management (Project Communication Management) Communication with stakeholders, partners and 40 project participants 20

21 Areas of Knowledge (2) 4. Risk management (Project Risk Management) Avoidance / handling of risks 5. Time and team management (Project Human Resource Management / Time Management) Definition of roles Creation of a project plan 6. Procurement management (Project Procurement Management) Procurement of external resources and materials 7. Cost management (Project Cost Management) Cost estimates Adherence to project budgets 8. Software development management (does not exist in the PMBOK Guide) Integration of software development processes into the PM 41 PITPM project phases (1) 1. Preparation phase of the project assignment Definition of the project scope first risk assessment 2nd planning phase configuration of the project (management plan) detailed planning of the project (implementation of the requirements in a real plan) iteration planning 3rd implementation phase implementation of the project control of the processes see Spitczok, N .; Vollmer, G .: Prof. Pragmatic Dr. Walter IT project management; Call S

22 PITPM project phases (2) 4. Introduction of planning for productive operation Rollout of the product 5. Final phase of formal project completion Conclusion of contracts Documentation of findings see Spitczok, N .; Vollmer, G .: Pragmatic IT project management; S PITPM project checkpoints Control is understood as a separate process K1: Project order placed K2: Project configured K3: Project planning approved K4: Planning of the iterations approved K5: Provision for approval K6: Approval granted K7: Production start K8: Project end 44 22

23 5.3.3 Overview of project processes Call on Assignment of artifacts to processes and phases Call on

24 5.3.4 Processes Phase 1: Preparatory phase V.1 Determine the scope of the project V.1.1 Determine the scope of services Define project and product goals Define product acceptance criteria Input artifacts Documents provided by the client Methods, techniques, tools Collection methods; Workshop; Result artifacts project scope description (project scope description.docx) V.1.2 Identify risks Input artifact: project scope description. Result artifact: Risk register 47 Process V1: Determine the scope of the project (2) V 1.3. Estimating effort Rough estimates (+/- 50% accuracy) Fine estimates (+/- 5-10% accuracy) Methods for estimating effort in the PMBOK, reference is made to PERT estimation :. Ä. 4. Ä .. Ä. 6 Estimation exam, analogy estimation, output artifact, effort estimation 48 24

25 Process V2: Apply for a project Process overview Spitczok, N .; Vollmer, G .: Pragmatic IT project management; S Process V.2.1: Develop project order Definition of a directorate structure Checklist for project initialization Result artifact: Project order (further development) 50 25

26 5.3.5 Process phase 2: Planning phase Specification of the end product Creation of the project manual Development PSP (project structure plan) Refinement of the risk analysis 51 Process P.1.1 Define project organization Clarification of project members and organizational structure 52 26

27 Process P.1.2 Kick-off event Meeting with all project participants Project team, line units, service organization, purposes Clarification of project goal / period Milestones Sponsors Presentation of project participants Result artifact: Minutes of kick-off workshop 53 Process: P1.3 Develop project management plan Scope management plan requirement Management Plan Schedule Management Plan (PSP) Cost Management Plan Human Resource Plan Result Artifacts Project Management Plan 54 27

28 Process P.2 Configure requirements management Objective: Define specifications for the implementation of the requirements analysis Define the infrastructure for the development Process: P 2.1 Plan the requirements analysis Description of use cases Use cases contain a collection of actions, it is often difficult in an early project phase fully describe the use cases prototyping model Spitczok, N .; Vollmer, G .: Pragmatic IT project management; S Process P P 2.2: Define change requests How do you deal with change requests? Provision of computer, operating system, network, access P 3: Configure quality planning P.3.1 Create quality plan Definition of specific quality standards and their implementation Supplement the project plan with the chapter on quality planning P.3.2 Create test concept The test concept describes which system components are to be used at what point in time and how are testing. The basis is the requirements document. The result is recorded in a test concept

29 Process P.4 P.6 P.4 Communication planning How should you communicate with the stakeholders? The result is recorded in the project management plan. P.5 Configure risk planning Clarification of principles and rules for risk management Define reporting The result is recorded in the project management plan. P.6 Configuring procurement planning Planning of procurement of goods and services The result is recorded in the project management plan. 57 Processes P P.7 Configure software development P. 7.1 Selection of the process model for the development Pure phase-oriented process models are problematic iterative process models agile process models Selection of a process model and definition of the necessary activities The result is a project-specific process model! P.7.2 Provision of software development tools Identification, procurement, installation and provision of all tools required for development DBMS, test tools, SES 58 29

30 Process P.8: Specifying requirements Elicitation Determination and description of requirements is the basis for a successful development! P.8.1 Questionnaire for the written survey What do the customers want If you want honest answers, you should ensure confidentiality Clearly structured questionnaire Progress indicator Room for individual comments Written questionnaire, interviews can also be carried out. P.8.3 Carrying out a written survey P.8.4 Creating interview guidelines P.8.5 Carrying out quality assurance of the interview guidelines P.8.6 Carrying out / recording interviews 59 Process P.8: Specifying requirements (2) P.8.7 Analysis of company-specific work and business processes Presentation of the existing processes and of the new, planned processes (e.g. with eepk diagrams) P.8.8 Creating a requirements document a distinction is made between: functional requirements (e.g.Master data acquisition) non-functional requirements (e.g. appearance and handling, response time behavior, expandability,) GUI drafts drafts for the graphical user interface should be presented to future users at an early stage. P.8.9 Quality assurance of the requirements document P.8.10 Create test cases P.8.11 Create acceptance test cases 60 30

31 Process P.8: Specify requirements (3) P.8.12 First work breakdown structure PSP = work breakdown structure PSP is the basis for calculating costs in the project Required work input Items PSP can be developed iteratively Hierarchical structure is advisable PSP contains the work packages from the Requirements definition (requirements document) Project management software tool (e.g. MS-Project) P.8.13 Approve requirements documentation 61 P.9 Start risk management P.9.1 Identify risks P.9.2 Assess and prioritize risks Result artifact: Supplement risk register P.9.3 Risk management measures Strategy: Avoid transfer Reduction - assumption 62 31

32 Process: 10 Create a project plan Plan for the overall project Milestones (for releases; presentations; iterations) P.10.1 Set up tasks and incorporate them in the PSP P.10.2 Plan resources Each work package is later on an employee's responsibility Determination of the process times (earliest start / end; latest start / end) Determination of the critical path 63 Process: 10 Create a project plan P10.3 Implement the project plan Recommendations Descriptive names for the work processes Realistic time estimates Clarity Granularity (work packages should be formed on the lowest level) Suggestion: Duration for a work package approx. 2 7 Days suggestion: no overtime planning / no weekend work Result: holistic project plan 64 32

33 Process: P.10.4 P.13 P.10.4 Set up project team P.10.5 Form and develop project team, if necessary, plan training measures P.11 Plan procurement Allocation of procurement measures (such as external consultants; licenses, insurance) to processes and their timing P. 12 Initialize cost planning Determine expected project costs Create cost history plan P.13 Plan iterations Define requirements for iterations Determine the iteration content Several iterations lead to a deliverable release 65 process P.14 Plan software development for current iteration Requirements for iterative / agile software development P.14.1 Create specification Result artifact: Specification document GUI model P.14.2 Quality assurance of the specification P.14.3 Accepting and releasing the specification P.14.4 Creating a draft P.14.5 Carrying out quality assurance for the draft document P.14.6 Accepting and releasing the draft 66 33

34 5.3.6 Processes Phase 3: Implementation Spitczok, N .; Vollmer, G .: Pragmatic IT project management; S Process: D.1- D.2 D1 Control project D.1.1 Lead project Implementation of iterations are the focus. Project manager records the events that are important for the customer in the project log. D. 1.2 Monitoring and controlling project progress Comparison of the actual values ​​with the project plan List of open points D.2 Check and adapt the project scope D.2.1 Verify the project scope The individual partial results delivered should be accepted by the customer Result artifact: Recognized change need D.2.2 Write change request Recognized change needs lead to a change request of a change request (CR) (only if this means additional costs and development time changes arise) 68 34

35 Process D.3 Checking the product quality Each iteration step includes final tests D.3.1 Creating a test plan Examples: component test; Integration test; Interface test; Load test, system test, acceptance test D.3.2 Carrying out tests Result artifact: test protocol D.3.3 Documenting the test 69 Process D.4 Project communication D.4.1 Involving and informing stakeholders Stakeholders have a significant influence on the project Tip: create transparency Gaining trust Do not delay or disguise problems! D.4.2 Create project status report Content: completed / open points; Risks; Resource consumption; milestones reached; Result artifact: Status report 70 35

36 Process D.5 Monitoring risks D.5.1 Compare and supplement existing risk register, if necessary, carry out a risk workshop Result artifact: updated risk register D.5.2 Plan measures for risk management 71 Process D.6: Manage project team Creation of dedicated work assignments for each team member Integration of young project members into the team Consideration of different characters D.6.1 Composition of development teams D.6.2 Team members plan out for us Be careful when storing personal data! (if necessary coordination with employee representatives) D.6.3 Create work orders for team members Work orders can e.g. can be generated from MS Project. Content of work orders: description; Delimitation; Requirement; Special risks; Working documents 72 36

37 Process D.7 Checking external services In many projects external services are required, e.g. Formulation of general terms and conditions by a lawyer; Installation of fiber optic cables by an electrician D.7.1 Checking external services D.7.2 Billing external services D.7.3 Terminating the contract if the service of the external service provider is no longer required D.7.4 Evaluating the service provider 73 Process D.8 Controlling project costs Cost control is a central task of the PM D.8.1 Record project costs Only the recorded costs do not result in a project control! The degree of completion is still required to evaluate the project. Target / actual comparison takes place via the project plan D.8.2 Update project costs 74 37

38 Process: D.9 Develop software product D.9.1 Implement software source code is generated D.9.2 Test software components D.9.3 Integrate software components D.9.4 Test software product Spitczok, N .; Vollmer, G .: Pragmatic IT project management; S Process D.10 Perform acceptance test Provide contractual regulations for acceptance! D.10.1 Declaration of readiness for acceptance PM must declare readiness for acceptance to the client Partial acceptance, replacement for acceptance that has not been carried out, etc. D.10.2 Coordinate acceptance test D.10.3 Perform acceptance test D.10.4 Declare acceptance D.10.5 Improve delivery item 76 38

39 5.3.7 Processes Phase 4: Introduction The introduction of a new software system must be well planned. Parallel operation with the existing solution successive introduction of rollout Define time window Changeover at one point in time Planning of training for key users E.2 Introduce product Assumption of responsibility goes to the customer. 77 Process E.2 Introduce product E.2.1 Introduce product Assumption of responsibility goes on Submit product responsibility to the customer via E.2.2 78 39

40 5.3.8 Processes Phase 5: Final phase Formal termination of the project Final project reports / summary of the documents A.1 Complete project A.2 Close risk register A.3 Outline team members Transfer team members to a new organizational form Carry out project final workshop End contracts Complete project cost accounting Create final report and feedback Assess development process 79 Assessment of the PMBOK Guide Advantages of a comprehensive, widely used standard Regular adaptation and revision Easy to understand implementation of projects High granularity of the processes Recognized standard (IEEE; ANSI) Disadvantages due to the broad applicability, there is a high level of tailoring effort for the specific project adaptation does not include any PM methodology low Flexibility in comparison e.g. High administration effort for PRINCE2 Phase model must also be created No document templates from PMI 80 40

41 IPMA IMPA International Project Management Association 81 Interesting Links German Society for Project Management (GPM) GPM Blog OpenPM (Association for Project Management) PMI Germany Project Management Blog