Chagwa V1.0
Allowing Change, Agile and Waterfall Projects in the Organisation
Paperback Engels 2023 1e druk 9789401810395Samenvatting
We DID IT; so can you. DID is Digital Information Design.
IT is of course the ubiquitous Information Technology that is so simple, so easy to design and change that it (sorry, IT) never goes wrong and all you need to do is to teach a few people a bit about coding, implementing and a best practice.
More seriously, if all of IT projects were successful, Digital Information Design would be a waste of time. However, the failure rate of IT outsourcing deals is around 40%, and hiring a sourcing consultant increases the odds of failure. IT-enabled enterprises thus need to know themselves how to govern the IT function. DID is the only best practice that recognizes that to do just that. You need more than best practice; and inevitably more than one best practice as well as people who understand that there is no such thing as simple easy to design IT that never changes. Therefore, to support your work, Digital Information Design (DID) guidance has been developed as a good practice to get it actually governed and done!
People working in IT rarely have proficient domain experience like working as a user/customer in the line of business that is employing their IT services to perform what once were manual activities. Vice versa, people working in the line of business are rarely well-versed in designing complex IT systems and processes, but times have changed. The DID framework aids in bringing together the right mix of IT and domain expertise, thereby helping to connect both views of the same, albeit complex, IT-enabled world.
DID recognizes complexity, demands inclusivity of all stakeholders in design and provides a simple yet useful model to identify key resources. And it recognizes that you cannot do everything using a single governing concept. If you want to come to grips with designing business services that can be relied upon, try using DID.
This book is about the design and functioning of enterprise-wide business information management using intelligent customer principles, with particular regard to digitization. The DID framework is used to describe, position and provide tools for the design of the intelligent customer function focusing on the enterprise information assets. This framework has been set up to effectively shape business information management within an enterprise, with the aim of ensuring a better use of information and technology in the enterprise.
DID Practitioner guide is part of the DID library and specifically deals with the ability of an enterprise to manage and control data services from a practical viewpoint. The principles are written so that they can be used in various disciplines of supporting services and the primary processes of both for-profit or not for-profit enterprises.
Specificaties
Lezersrecensies
Inhoudsopgave
Credits 7
Contents 9
List of Figures 14
Contents of this book 17
Foreword 19
Chapter 1. The Chagwa Concept 21
1.1 Who should read this book? 23
1.2 Introduction 24
1.2.1 Defining the Product 24
1.2.2 Artefacts 25
1.2.3 A brief definition of Chagwa 25
1.2.4 Managing Product Changes 26
1.2.5 Three Project Management Concepts 31
1.2.6 Choosing a Project Management Methodology 40
1.2.7 Project Management styles 43
1.2.8 What Chagwa wants to solve 46
1.3 Roles 47
1.3.1 Introduction 47
1.3.2 End-Users 48
1.3.3 Stakeholder 48
1.3.4 Product Owner 48
1.3.5 Operations Organisation 49
1.3.6 Enterprise Architecture Organisation 49
1.3.7 Engineering and Development 50
1.3.8 Program and Project Management Organisations 50
1.3.9 Compliance Organisation 50
1.3.10 Security Officer 51
1.3.11 Change Control Board 51
1.3.12 Project Sponsor 52
1.3.13 Project Steerco 52
1.3.14 Project Manager 52
1.3.15 Project Team (Waterfall) 53
1.3.16 Scrum Team (Agile) 53
1.3.17 Scrum Master (Agile) 53
1.4 Chagwa Project Management 54
1.4.1 The Chagwa Flowchart 54
1.4.2 Choosing the Chagwa track for a project 56
1.4.3 Mixed Chagwa projects 59
1.5 Templates and Artefacts used in this book 60
Chapter 2. Commonly used processes in the Chagwa Framework 63
2.1 Overview 65
2.2 Project Governance Process 66
2.2.1 Overview 66
2.2.2 Project Governance in Chagwa 68
2.2.3 Program Management 70
2.2.4 Identify Stakeholders 70
2.2.5 Project Change Control 71
2.3 New Project Request 73
2.3.1 Overview 73
2.3.2 Create Project Charter 74
2.3.3 Project Scaling Process 76
2.3.4 Compliance Assessment 77
2.3.5 Decide on Project Track 78
2.4 Evaluation and Close 79
2.4.1 Overview 79
2.4.2 Clean-up Activities 81
2.4.3 Close Documentation 82
2.4.4 Perform Lessons Learned 83
2.4.5 Close Contracts 84
2.4.6 Close Budget 84
Chapter 3. Change Control in the Chagwa Framework 87
3.1 Overview 89
3.2 Preparation 90
3.2.1 Overview 90
3.2.2 Assess As-Is 92
3.2.3 Assess To-Be 93
3.2.4 Planning 93
3.3 Execute Changes 96
3.3.1 Overview 96
3.3.2 Create Changes 97
3.3.3 Perform Changes 98
3.3.4 Change Testing 101
3.3.5 Document and Close Changes 101
3.4 Review and Iterate 102
3.4.1 Overview 102
3.4.2 Review Planning 103
3.4.3 Select New Changes 105
3.4.4 Iterate 105
Chapter 4. Agile in the Chagwa Framework 107
4.1 Overview 109
4.2 Assessment and Planning 111
4.2.1 Overview 111
4.2.2 Collect User Epics and Preliminary User Stories 113
4.2.3 Assemble Scrum Team 114
4.2.4 Create Product Backlog 115
4.2.5 High Level Solution Design 118
4.2.6 Project and Sprint 0 Planning 119
4.3 Prepare Sprint 120
4.3.1 Overview 120
4.3.2 Collect User Stories 121
4.3.3 Analyse User Stories 123
4.3.4 User Story effort estimation 124
4.3.5 Update Sprint Backlog 124
4.3.6 Sprint Planning 125
4.3.7 Update the Definition of Done 126
4.4 Build and Test 127
4.4.1 Overview 127
4.4.2 Daily Scrum Meeting 128
4.4.3 Deliver User Stories 129
4.4.4 Define Tests 130
4.4.5 Test and Fix Bugs 131
4.4.6 Remove Impediments 133
4.4.7 Provide Hyper-Care 134
4.5 Production Release 135
4.5.1 Overview 135
4.5.2 Product Demo 136
4.5.3 Activate Shippable Product Increment 137
4.5.4 Update Product Backlog 138
4.6 Sprint Review 139
4.6.1 Overview 139
4.6.2 Update Release Planning 141
4.6.3 Sprint Retrospective 141
4.6.4 Iterate 142
Chapter 5. Waterfall in the Chagwa Framework 143
5.1 Overview 145
5.2 Preparation 148
5.2.1 Overview 148
5.2.2 Define Steerco 150
5.2.3 Assess As-Is 151
5.2.4 Assess Requirements 153
5.2.5 Assess Project Impact 158
5.2.6 Planning 159
5.3 Design 170
5.3.1 Overview 170
5.3.2 Execute POC 171
5.3.3 Create Detailed Design 173
5.3.4 Qualification Assessment and Planning 177
5.3.5 Test Planning 178
5.3.6 Refine Cost Plan 180
5.4 Build 181
5.4.1 Overview 181
5.4.2 Create Tests 185
5.4.3 Build Per Design 187
5.4.4 Create Knowledge 190
5.4.5 Installation Qualification 192
5.4.6 The forward shortcut 193
5.5 Test and Training 194
5.5.1 Overview 194
5.5.2 Test As-Built 196
5.5.3 Perform Knowledge Transfer 199
5.5.4 User Acceptance Testing 202
5.6 Iteration in the Waterfall Track 204
5.7 Cut-Over 205
5.7.1 Overview 205
5.7.2 Operational Readiness 209
5.7.3 Migration Planning 211
5.7.4 Perform Go-Live 212
5.7.5 Go-Live Testing 213
5.7.6 Clean Up or Fail Back 214
5.8 Hyper-Care 215
5.8.1 Overview 215
5.8.2 Project Team in Lead 217
5.8.3 Define Transition Point 217
5.8.4 Operations Team in Lead 219
Chapter 6. Chagwa Artefacts 221
6.1 Before you begin 223
6.1.1 Reasons for not creating detailed documentation 223
6.1.2 Reasons for creating documentation 224
6.2 Distrans and Relative Distrans 226
6.3 Overview of Artefacts 228
6.4 Starting a Project 231
6.4.1 Project Charter or Project Brief 231
6.4.2 Phase Gate Criteria 233
6.4.3 Project Change Request 236
6.5 Running a Project 238
6.5.1 Change Request 238
6.5.2 Decommissioning Form 241
6.5.3 Scorecard for Reporting 243
6.6 Agile Track Artefacts 245
6.6.1 User Epics 245
6.6.2 User Story Card 247
6.6.3 Product Backlog 249
6.6.4 Sprint Backlog 251
6.6.5 Agile Task Board 252
6.7 Waterfall Track Artefacts 254
6.7.1 Hyper-Care Intake List 254
6.7.2 Risk Register 256
6.7.3 Task-Issue-Risk Log 259
6.7.4 Kick-Off Meeting 261
6.7.5 Demand Description Document 263
6.7.6 Solution Description Document 265
6.7.7 System/Application Installation Procedure 267
6.7.8 System/Application Configuration Document 270
6.7.9 Project Test Plan 272
6.7.10 Cost Plan 274
6.7.11 Disaster Recovery Plan 277
6.7.12 Business Continuity Plan 280
6.7.13 System/Application Knowledge Document 283
6.7.14 Test and Design Matrix 286
6.7.15 Training Plan 288
6.7.16 Test Script 291
6.7.17 Test Defect Form 293
6.7.18 Hour-by-Hour Plan 296
6.7.19 Go-Live Checklist 298
6.7.20 Operational Responsibility Transfer Checklist 301
6.8 Closing a Project 303
6.8.1 Project Acceptance Notice 303
6.8.2 Lessons Learned Interview and Lessons Learned Document 305
Chapter 7. Integration 307
7.1 Introduction 309
7.2 Guidelines 310
7.3 Example 310
7.3.1 Project Background 310
7.3.2 Planning of subprojects 311
7.3.3 Identify dependencies 313
7.3.4 Integrate projects based on dependencies 315
7.3.5 Add contingencies and plan project 316
7.3.6 Add Integration Layer 317
Glossary 321
Index 331
Rubrieken
- advisering
- algemeen management
- coaching en trainen
- communicatie en media
- economie
- financieel management
- inkoop en logistiek
- internet en social media
- it-management / ict
- juridisch
- leiderschap
- marketing
- mens en maatschappij
- non-profit
- ondernemen
- organisatiekunde
- personal finance
- personeelsmanagement
- persoonlijke effectiviteit
- projectmanagement
- psychologie
- reclame en verkoop
- strategisch management
- verandermanagement
- werk en loopbaan
