Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Van Haren Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
As the world enters into an unparalleled period of exponential change, most organisations are still using either Waterfall, Agile or Change Control as their primary project management methodology.
Enter Chagwa®, a new process driven structure that allows a seamless interaction between our familiar project management methodologies. With its pragmatic set of rules and guidelines, Chagwa® offers the PMO and project manager a clear way forward for every kind of project.
By selecting the most suitable methodology (including hybrid variants) Chagwa® ensures that projects get off to a good start without the need for endless discussion or compromise. For example, Chagwa® can integrate Agile into what may have been considered as a conventional project or program while still allowing an organization to keep its Waterfall and Change Control project methodologies where it makes sense to do so.
Chagwa® is more than just a theoretical methodology. It is a complete set of templates and tools that integrate with the Chagwa® processes allowing organisations to build out a new Project Management Organisation in an accelerated track without deviating from their proven tools and techniques.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 498
Veröffentlichungsjahr: 2023
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
CHAGWA V1.0
Other publications by Van Haren Publishing
Van Haren Publishing (VHP) specializes in titles on Best Practices, methods and standards within four domains:
- IT and IT Management
- Architecture (Enterprise and IT)
- Business Management and
- Project Management
Van Haren Publishing is also publishing on behalf of leading organizations and companies: ASLBiSL Foundation, BRMI, CA, Centre Henri Tudor, CATS CM, Gaming Works, IACCM, IAOP, IFDC, Innovation Value Institute, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.
Topics are (per domain):
IT and IT Management
ABC of ICT
ASL®
CMMI®
COBIT®
e-CF
ISM
ISO/IEC 20000
ISO/IEC 27001/27002
ISPL
IT4IT®
IT-CMFtm
IT Service CMM
ITIL®
MOF
MSF
SABSA
SAF
SIAMtm
TRIM
VeriSMtm
XLA®
Enterprise Architecture
ArchiMate®
GEA®
Novius Architectuur
Methode
TOGAF®
Project Management
A4-Projectmanagement
DSDM/Atern
ICB/NCB
ISO 21500
MINCE®
M_o_R®
MSP®
P3O®
PMBOK ® Guide
Praxis ®
PRINCE2 ®
Business Management
BABOK ® Guide
BiSL® and BiSL® Next
BRMBOKTM
BTF
CATS CM®
DID®
EFQM
eSCM
IACCM
ISA-95
ISO 9000/9001
OPBOK
SixSigma
SOX
SqEME®
For the latest information on VHP publications, visit our website: www.vanharen.net.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted by law, without either the prior written permission of the author and the publisher.
Copyright © Van Haren Publishing
ISBN Hardcopy: 978-94-018-1039-5
ISBN eBook: 9789401810401
ISBN ePub: 9789401810418
DISCLAIMER
This publication is based on best practices used by experienced project managers. However, no guarantees are given that the content in this publication can be used, or will lead to success, in your particular situation. The author and publisher disclaim all liability, either special, direct or indirect, consequential or compensatory, for any personal injury, commercial, property or other damage, loss of income or contracts, loss of goodwill, work stoppage, performance issues, or any and all other damages or losses of any nature whatsoever, resulting from this publication, use of applications and templates, or reliance on this document.
The author and publisher disclaim and provide no guarantee or warranty whatsoever in relation to the suitability of this publication and the accompanying tools and templates, expressed or implicit, for a specific user purpose, or that this publication, and the accompanying tools and templates, will fulfil any of your particular purposes or needs. There is absolutely no assurance that any statement contained in this publication, touching on legal, compliance or professional matters, is true, correct, or precise. Law varies from place to place and it evolves over time. Even if a statement is accurate at some point in time, it may not be accurate in the jurisdiction of the reader. Moreover the information, regulations and laws may have changed, modified or overturned by the time that this work was published.
The processes, techniques and templates are based on the work of volunteers and/or people that are interested in project management in general. The author and publisher disclaim and give no guarantee or warranty, expressed or implied, as to the accuracy or completeness of any information provided in this publication. Under no circumstances will the author or publisher guarantee that professional or other services can be rendered in relationship to the information given in this publication or the accompanying tools and templates. Nothing that can be found in this publication or the accompanying tools and templates should be construed as an attempt to offer or render a service, legal opinion or otherwise engage in the practice of law.
The author and publisher will not enforce compliance with this publication in any way, and will not test, verify or inspect any work or product that has partly or in full used this publication or the accompanying tools or templates.
You are expected to be a professional reader who is able to interpret and correctly use the information and tools provided in this publication and any accompanying tools and documents. The use of any information obtained through this publication is at the risk of the user. Anyone using this document should rely on his or her own independent judgement, or seek the advice of a competent professional for executing any work or managing any product. Without verification or further advice, use of the information presented is at the user’s own expense and risk.
This publication and the accompanying tools, templates and other documents will not guarantee any compliance with safety, health or legal requirements.
Registered trademarks referenced in this book
“ITIL®” is a (registered) Trade Mark of AXELOS Limited. All rights reserved.
“PMI®” and “PMBOK® Guide” are registered marks of the Project Management Institute, Inc.
“PRINCE®” is a (registered) Trade Mark of AXELOS Limited. All rights reserved.
“TOGAF®” is a registered trademark of The Open Group.
“Zachman®” is a registered trademark of Zachman International, Inc.
CREDITS
The following people have been consulted, or have contributed to the realisation of this publication and version 1.0 of the Chagwa project management methodology.
Candy Lovegrove
David Frans
Dirk Van Moorsel
Francis Van den Driessche
Harley Lovegrove
Jan Borghs
Jo Lamarche
Jürgen Van Gorp
Jurgen Leemans
Kurt Verhaert
Maxim Shutkin
William Watté
CONTENTS
Disclaimer
Credits
Contents
List of Figures
Contents of this book
Foreword
Chapter 1. The Chagwa Concept
1.1 Who should read this book?
1.2 Introduction
1.2.1 Defining the Product
1.2.2 Artefacts
1.2.3 A brief definition of Chagwa
1.2.4 Managing Product Changes
1.2.5 Three Project Management Concepts
1.2.6 Choosing a Project Management Methodology
1.2.7 Project Management styles
1.2.8 What Chagwa wants to solve
1.3 Roles
1.3.1 Introduction
1.3.2 End-Users
1.3.3 Stakeholder
1.3.4 Product Owner
1.3.5 Operations Organisation
1.3.6 Enterprise Architecture Organisation
1.3.7 Engineering and Development
1.3.8 Program and Project Management Organisations
1.3.9 Compliance Organisation
1.3.10 Security Officer
1.3.11 Change Control Board
1.3.12 Project Sponsor
1.3.13 Project Steerco
1.3.14 Project Manager
1.3.15 Project Team (Waterfall)
1.3.16 Scrum Team (Agile)
1.3.17 Scrum Master (Agile)
1.4 Chagwa Project Management
1.4.1 The Chagwa Flowchart
1.4.2 Choosing the Chagwa track for a project
1.4.3 Mixed Chagwa projects
1.5 Templates and Artefacts used in this book
Chapter 2. Commonly used processes in the Chagwa Framework
2.1 Overview
2.2 Project Governance Process
2.2.1 Overview
2.2.2 Project Governance in Chagwa
2.2.3 Program Management
2.2.4 Identify Stakeholders
2.2.5 Project Change Control
2.3 New Project Request
2.3.1 Overview
2.3.2 Create Project Charter
2.3.3 Project Scaling Process
2.3.4 Compliance Assessment
2.3.5 Decide on Project Track
2.4 Evaluation and Close
2.4.1 Overview
2.4.2 Clean-up Activities
2.4.3 Close Documentation
2.4.4 Perform Lessons Learned
2.4.5 Close Contracts
2.4.6 Close Budget
Chapter 3. Change Control in the Chagwa Framework
3.1 Overview
3.2 Preparation
3.2.1 Overview
3.2.2 Assess As-Is
3.2.3 Assess To-Be
3.2.4 Planning
3.3 Execute Changes
3.3.1 Overview
3.3.2 Create Changes
3.3.3 Perform Changes
3.3.4 Change Testing
3.3.5 Document and Close Changes
3.4 Review and Iterate
3.4.1 Overview
3.4.2 Review Planning
3.4.3 Select New Changes
3.4.4 Iterate
Chapter 4. Agile in the Chagwa Framework
4.1 Overview
4.2 Assessment and Planning
4.2.1 Overview
4.2.2 Collect User Epics and Preliminary User Stories
4.2.3 Assemble Scrum Team
4.2.4 Create Product Backlog
4.2.5 High Level Solution Design
4.2.6 Project and Sprint 0 Planning
4.3 Prepare Sprint
4.3.1 Overview
4.3.2 Collect User Stories
4.3.3 Analyse User Stories
4.3.4 User Story effort estimation
4.3.5 Update Sprint Backlog
4.3.6 Sprint Planning
4.3.7 Update the Definition of Done
4.4 Build and Test
4.4.1 Overview
4.4.2 Daily Scrum Meeting
4.4.3 Deliver User Stories
4.4.4 Define Tests
4.4.5 Test and Fix Bugs
4.4.6 Remove Impediments
4.4.7 Provide Hyper-Care
4.5 Production Release
4.5.1 Overview
4.5.2 Product Demo
4.5.3 Activate Shippable Product Increment
4.5.4 Update Product Backlog
4.6 Sprint Review
4.6.1 Overview
4.6.2 Update Release Planning
4.6.3 Sprint Retrospective
4.6.4 Iterate
Chapter 5. Waterfall in the Chagwa Framework
5.1 Overview
5.2 Preparation
5.2.1 Overview
5.2.2 Define Steerco
5.2.3 Assess As-Is
5.2.4 Assess Requirements
5.2.5 Assess Project Impact
5.2.6 Planning
5.3 Design
5.3.1 Overview
5.3.2 Execute POC
5.3.3 Create Detailed Design
5.3.4 Qualification Assessment and Planning
5.3.5 Test Planning
5.3.6 Refine Cost Plan
5.4 Build
5.4.1 Overview
5.4.2 Create Tests
5.4.3 Build Per Design
5.4.4 Create Knowledge
5.4.5 Installation Qualification
5.4.6 The forward shortcut
5.5 Test and Training
5.5.1 Overview
5.5.2 Test As-Built
5.5.3 Perform Knowledge Transfer
5.5.4 User Acceptance Testing
5.6 Iteration in the Waterfall Track 204
5.7 Cut-Over
5.7.1 Overview
5.7.2 Operational Readiness
5.7.3 Migration Planning
5.7.4 Perform Go-Live
5.7.5 Go-Live Testing
5.7.6 Clean Up or Fail Back
5.8 Hyper-Care
5.8.1 Overview
5.8.2 Project Team in Lead
5.8.3 Define Transition Point
5.8.4 Operations Team in Lead
Chapter 6. Chagwa Artefacts
6.1 Before you begin
6.1.1 Reasons for not creating detailed documentation
6.1.2 Reasons for creating documentation
6.2 Distrans and Relative Distrans
6.3 Overview of Artefacts
6.4 Starting a Project
6.4.1 Project Charter or Project Brief
6.4.2 Phase Gate Criteria
6.4.3 Project Change Request
6.5 Running a Project
6.5.1 Change Request
6.5.2 Decommissioning Form
6.5.3 Scorecard for Reporting
6.6 Agile Track Artefacts
6.6.1 User Epics
6.6.2 User Story Card
6.6.3 Product Backlog
6.6.4 Sprint Backlog
6.6.5 Agile Task Board
6.7 Waterfall Track Artefacts
6.7.1 Hyper-Care Intake List
6.7.2 Risk Register
6.7.3 Task-Issue-Risk Log
6.7.4 Kick-Off Meeting
6.7.5 Demand Description Document
6.7.6 Solution Description Document
6.7.7 System/Application Installation Procedure
6.7.8 System/Application Configuration Document
6.7.9 Project Test Plan
6.7.10 Cost Plan
6.7.11 Disaster Recovery Plan
6.7.12 Business Continuity Plan
6.7.13 System/Application Knowledge Document
6.7.14 Test and Design Matrix
6.7.15 Training Plan
6.7.16 Test Script
6.7.17 Test Defect Form
6.7.18 Hour-by-Hour Plan
6.7.19 Go-Live Checklist
6.7.20 Operational Responsibility Transfer Checklist
6.8 Closing a Project
6.8.1 Project Acceptance Notice
6.8.2 Lessons Learned Interview and Lessons Learned Document
Chapter 7. Integration
7.1 Introduction
7.2 Guidelines
7.3 Example
7.3.1 Project Background
7.3.2 Planning of subprojects
7.3.3 Identify dependencies
7.3.4 Integrate projects based on dependencies
7.3.5 Add contingencies and plan project
7.3.6 Add Integration Layer
Glossary
Index
LIST OF FIGURES
Figure 1.
Waterfall Project Flowchart
Figure 2.
Agile Project Flowchart
Figure 3.
The Project Management Octet
Figure 4.
Project Management Control Triangle for Change Driven Projects
Figure 5.
Project Management Control Triangle for Agile Projects
Figure 6.
Project Management Control Triangle for Waterfall Projects
Figure 7.
Project Management Control Triangle Overview for Different Projects
Figure 8.
Chagwa Project Management Methodology Process Flow
Figure 9.
Chagwa Common Processes Overview
Figure 10.
Chagwa Project Governance Process
Figure 11.
Governance for Change Control Driven Projects
Figure 12.
Governance for Agile Driven Projects
Figure 13.
Governance for Waterfall Driven Projects
Figure 14.
Project Governance Process and Sub-Processes
Figure 15.
New Project request Process
Figure 16.
New Project request Process and Sub-Processes
Figure 17.
Evaluation and Close Process
Figure 18.
Evaluation and Close Process and Sub-Processes
Figure 19.
Chagwa Change Control Track
Figure 20.
Change Control Preparation Process
Figure 21.
Change Control Preparation Process and Sub-Processes
Figure 22.
Change Control Execute Changes Process
Figure 23.
Change Control Execute Changes Process and Sub-Processes
Figure 24.
Change Control review and Iterate Process
Figure 25.
Change Control review and Iterate Process and Sub-Processes
Figure 26.
Chagwa Agile Track
Figure 27.
Agile Assessment and Planning Process
Figure 28.
Agile Assessment and Planning Process and Sub-Processes
Figure 29.
Decomposition of Short Tem User Epics into User Stories
Figure 30.
Agile Prepare Sprint Process
Figure 31.
Agile Prepare Sprint Process and Sub-Processes
Figure 32.
Agile Build and Test Process
Figure 33.
Agile Build and Test Process and Sub-Processes
Figure 34.
Technical Debt Growth in Agile Projects
Figure 35.
Technical Debt in Agile Projects with Sufficient Testing 132
Figure 36.
Agile Production release Process
Figure 37.
Agile Production release Process and Sub-Processes
Figure 38.
Informal and Formal User Acceptance Testing in Agile Projects
Figure 39.
Agile Sprint review Process
Figure 40.
Agile Sprint review Process and Sub-Processes
Figure 41.
Chagwa Waterfall Track
Figure 42.
Waterfall Wall of Confusion
Figure 43.
Collaboration in Chagwa Waterfall Design
Figure 44.
Waterfall Preparation Process
Figure 45.
Waterfall Preparation Process and Sub-Processes
Figure 46.
Typical Volume of Product Increments Created over Time in a Waterfall Project
Figure 47.
Example of Planned Work versus Actual Work over Time
Figure 48.
Example of Planned Cost versus Actual Cost over Time
Figure 49.
Waterfall Design Process
Figure 50.
Waterfall Design Process and Sub-Processes
Figure 51.
Waterfall Build Process
Figure 52.
Waterfall Build Process and Sub-Processes
Figure 53.
Typical Use of Tiered Platforms in a Waterfall Project
Figure 54.
Waterfall Forward Shortcut
Figure 55.
Waterfall Test and Training Process
Figure 56.
Waterfall Test and Training Process and Sub-Processes
Figure 57.
Example of Bridge Load Tests for Performance Qualification
Figure 58.
Waterfall Iteration Loop
Figure 59.
Waterfall Cut-Over Process
Figure 60.
Waterfall Cut-Over Process and Sub-Processes
Figure 61.
Waterfall Hyper-Care Process
Figure 62.
Waterfall Hyper-Care Process and Sub-Processes
Figure 63.
Overview of Artefacts Supporting the Chagwa Processes
Figure 64.
Typical Artefact Description
Figure 65.
Artefact Usage Overview
Figure 66.
Example Project Flow for a Building with a Data Centre
Figure 67.
Example Project Flow for the road Construction
Figure 68.
Example Project Flow for the Network Backbone
Figure 69.
Example Project Flow for Antennae Installations
Figure 70.
Example Interdependencies Between the road Construction and the Central Building
Figure 71.
Example Interdependencies Between the Data Center and Network Backbones
Figure 72.
Example Interdependencies Between the Network Backbone and the Antennae Installations
Figure 73.
Example Interdependencies with Data Collection and Data Analysis
Figure 74.
Integration Without Contingencies or Integration Layer
Figure 75.
Effect of Sub-Project Delays on the Overall Project
Figure 76.
Use of an Integration Layer for Integrating Multiple Projects
Figure 77.
Effect of Sub-Project Delays on the Overall Project when Using an Integration Layer
CONTENTS OF THIS BOOK
This book contains eight chapters.
The first chapter in this book introduces the Chagwa concept. First, a more general background of project management is provided with general definitions and role descriptions given. Then, Chagwa is introduced within the larger project management framework. This chapter also gives the basic Chagwa principles and guidelines.
The next four chapters describe the different Chagwa processes and sub-processes in more detail.
Chapter two handles common Chagwa processes.
Chapter three treats the processes used in the Change Control Chagwa track.
Chapter four discusses processes used in the Agile Chagwa track.
Chapter five discusses the Waterfall Chagwa track processes.
The sixth chapter provides a more detailed description of different documentation Artefacts that are used in the different Chagwa processes. Chagwa proposes, but not enforces, the use of particular Artefacts that support the different processes. This chapter also brings in a new concept, ‘Distrans’. Distrans can be used to determine the level of complexity and size of the project artefacts.
The seventh chapter briefly discusses how projects can be integrated. Larger projects can be cut into smaller subprojects, each running its own Chagwa track. Other projects can be running in parallel and may have interdependencies with the current project. The chapter on integration provides an example of how overall planning is achieved.
FOREWORD
Chagwa is a Project Management Methodology. It targets the integration of best practices in project management in a concise framework.
This book first gives an analysis on project management in general, and on much used project management methodologies in particular. The analysis results in the integration of different methodologies in the Chagwa framework.
The analysis is based on three much used methodologies in project management: Agile, Waterfall and Change Control. All three project management methodologies have unique advantages that justify their use. The choice depends on what your project is supposed to deliver. It depends on the Product you’re working on.
If you are a Project Manager or Program Manager, this book will provide you more insight in project management in general, and in the Chagwa approach of project management.
If you plan on setting up a new Project Management Organisation, or you are improving your existing one, this book will help you in kick-starting your organisation. Chagwa will provide you with a project methodology right out of the box, and includes a set of ready-to-use tools. It will provide clear guidance on when to use Waterfall, Agile or Change Control and how new developments can be put into production flawlessly. This can happen whether the new developments are part of a small or large project, or come from continuous change.
Chagwa brings ideas about program and project management. It is not a one-size-fits-all panacea. Every organisation is unique. Every Product is unique. For that reason your Project Management Organisation should adapt itself to the Business. Chagwa can provide you a methodology and set of Artefacts bundled in a single Toolbox, as a starting point.
The author wishes you success in implementing the Chagwa principles in your organisation.
1.1 Who should read this book?
1.2 Introduction
1.3 Roles
1.4 Chagwa Project Management
1.5 Templates and Artefacts used in this book
1.1 Who should read this book?
This book has been written for
Program and Portfolio managers: they can benefit from the processes and procedures described in this book, the artefacts that come with Chagwa, the clear guidance on when to use Waterfall, Agile or Change Control;
Project Managers, because of the mix of three different project methodologies integrated in Chagwa;
Change Managers, because Chagwa relies on Change Management for executing and integrating projects;
Business and Operational managers, because they want to know what their role is in the project management tracks described by Chagwa;
Engineers, technicians and any other stakeholder impacted by projects, because they want to learn about their role in projects in general and how organisations need to organise themselves for each Chagwa track;
Anyone interested in project management in general.
You may have special interest in this book
if you want to make changes to your existing Program, Portfolio or Project Management Organisations and want to gain additional insight in project management;
if you want to start with Program, Portfolio or Project Management in your organisation or enterprise;
if you’re struggling with introducing Agile or Waterfall project management methodologies in an existing project management culture;
if you are impacted by or involved in projects and want to know more details on the practical organisation.
This book provides the description of different project management methodologies, but will not go into the details. You will profit more of Chagwa if you already have experience in the following.
Change Management and Change Control;
Agile driven project management.
Waterfall driven project management;
1.2 Introduction
1.2.1 Defining the Product
DEFINITION
The Product is a separately managed item that can be worked upon and treated as a deliverable. A Product may be composed of different other Products or sub-components, each of which may be individually managed as a stand-alone Product. A Product can be a tangible or intangible. It can be a physical piece of hardware, but it can e.g. also be software source code, a textbook, training, a service or process description.
The Product is assumed to be a managed deliverable and therefore has a life-cycle. It is created at some point in time. The Product is managed and supported during its active life, and it is formally decommissioned at the end of its life-cycle. After decommissioning of the Product, supporting artefacts and documentation may need to be kept available for a Business defined retention period.
This book assumes that creating or updating the Product is typically done through projects, while everyday management is done through Change Control. The level of change control will be different for different organisations. Controlling changes can be loosely managed through oral approval, or strictly controlled through formally approved Change requests. Projects working on the Product can either create the full end-to-end Product or only work on a small part of the Product.
DEFINITION
The Core Product in an organisation is the Product that is considered the “core business” of the organisation and that creates the revenue.
Consider the example of a furniture factory. The Core Product can be identified as the set of furniture sold to customers. The factory may also decide to specialise in exclusive design furniture, or the cheapest furniture available on the market. The Core Product may therefore be “furniture”, but it could also be “design furniture”, or “best price furniture”.
As explained, the Core Product is the central Product that is the reason for the Organisation to exist. Other Products in the Organisation are expected to only exist for directly or indirectly creating or supporting the Core Product. The furniture factory will have production machines that are managed as separate Products. Servers and end-user computers are managed Products, as can be the fleet of trucks for delivering the furniture. All of these Products are supporting Products for creating and managing the Core Product. Only the Core Product generates revenue for the Organisation.
1.2.2 Artefacts
DEFINITION
An Artefact is an object created to support a Product or project. Artefacts can e.g. be written documents describing a function, a process or procedure, written evidence of an action performed in scope of a project, technical documentation for a Product...
An Artefact can be physical, e.g. a warranty seal that is delivered with the Product, or electronic, e.g. digitally signed test evidence, or source code for a function. Artefacts can have their own life-cycle, e.g. strictly controlled quality compliance documents used in nuclear plants. In some cases an Artefact is considered a sub-component of the Product, and treated as a stand-alone Product with its own life-cycle, e.g. installation and repair manuals.
In Project Management, Artefacts describe the set of written project documentation and different types of evidence deliverables. An Artefact can e.g. be a Project Charter, but also a Test Script or Test Defect description.
1.2.3 A brief definition of Chagwa
DEFINITION
Chagwa is a Project Management Methodology (PMM). Its target is to describe ways of managing changes to the Product in a structured and consistent way. It provides tools and techniques for successful and controlled project management, while still allowing flexibility and adaptability to the organisation.
Chagwa defines different types of tracks for managing the changes to the Product, and provides guidelines as to which track is most favourable per type of change. Smaller changes to the Product will typically be done through simple Change Control, e.g. vendor maintenance or software patching. Larger upgrades may require a project approach through one of the three project management tracks defined in the Chagwa framework.
Chagwa also proposes artefacts for documenting the Product and how a Product can be enhanced by means of incremental changes. The Business defines which artefacts are essential for Product and project documentation in the organisation. Additional artefacts may be required by the Program Management Organisation and internal or external Compliance Organisations. Further in this book the concept of Distrans is defined, which can be used as a tool to determine the need for artefacts, and the size and complexity of an artefact.
1.2.4 Managing Product Changes
This chapter describes different ways of handling changes in an organisation, with an increasing level of governance control. Governance control over projects can depend on the following.
Maturity of the organisation: companies that have existed for many years can be expected to have a more matured set of processes and procedures.
Size of the organisation: larger companies have complex communication structures and may have more need of formalised documentation and processes.
Type of organisation and work performed: e.g. health care and Governmental organisations can be expected to be subject to more scrutiny on the level of Product documentation, processes and procedures.
Legal and Industry standards: if an organisation is subject to e.g. SOx or ISO regulations, specific processes and evidence requirements can be put in place.
Management structure: there may be a management demand for additional processes that help structuring the work and the use of resources. An organisation may therefore require that additional procedures or templates are used.
1.2.4.1 UNCONTROLLED CHANGES
In an uncontrolled environment one or several persons are given the responsibility for putting a Product in place and further supporting the Product. Changes are identified and executed as deemed necessary by the people responsible. Little governance is provided apart from “make it happen”.
When creating or implementing the Product in an uncontrolled way the Product Owner accepts that little investigation is done on time and cost within the overall Business scope. Usually only the cost for buying or creating the Product itself is assessed upfront. The labour cost for further supporting and upgrading the Product, or managing the Product during its life-cycle, is typically deferred or neglected.
The advantages of an uncontrolled approach, are the following.
Agility to implement the Product and perform changes with minimal communication. Communication lines only exist between the Business sponsor and the engineer performing the changes. This allows for fast responses to a need for change.
Clear roles and responsibilities, even if multiple independent instances of a Product are rolled out. Each instance of the Product has a Business sponsor who inherently also becomes Product Owner for that instance.
The simpler and smaller organisational structure inherently implies a minimal cost for managing the Product. This makes an uncontrolled project methodology a favourable approach for small companies where support engineers are scarce.
The risks that come with an uncontrolled approach are the following.
Over time there is risk that in-house support for the Product is impacted as a result of changing roles in the organisation or engineers leaving the company.
To decrease risk of a support gap, technician managing the Product need always be available, even during holiday periods. resources on sick leave can result in the Product being unmanageable.
The costs for creating or buying the Product were assessed upfront, and typically a maintenance contract is closed with a third party provider. A budget for an in-house engineer performing e.g. Product upgrades, may not be available. responsibilities and budgets for pro-active maintenance and in-house break-fix are not clearly agreed upon. The risk is that maintenance cycles and upgrades for the Product are missed.
Setting up Products randomly in the organisation increases the risk for Legacy applications. Over time organisations are faced with in increasing number of different Products for which support is no longer available and that results in an Operational nightmare. Third party support may no longer be provided for an outdated version of the Product. Some vendors have gone out of business or moved to a new version of the Product some time before, resulting in a support gap.
Instances of a Product that were supposed to be decommissioned are still used by one or a few people in the organisation. In some cases legacy applications must remain active for a long time because information must be kept available for legal reasons. Another reason can be that the budget for migrating functionality and data to a newer version is not available. As a result the relative support and license costs for keeping the Product alive for a small group of people becomes unacceptably high.
The people implementing and supporting a Product get support requests randomly. The subject matter expert for a Product risks that all support tickets are routed to a single person, who then becomes overloaded. Support engineers are overwhelmed with requests and are trapped in constant break-fix issues. Planned maintenance is delayed or skipped with an inherent risk for a downward spiral of more and more issues and legacy situations.
There is little overall control on the costs for the Products used in the organisation. Each Product Owner is responsible for licence and maintenance costs for an instance of the Product. Consequently it is difficult to report on Total Cost of Ownership within the organisation. This makes it difficult to do cost optimisation, e.g. negotiating quantity discounts or centralising Product support in the organisation.
1.2.4.2 LOOSE PROJECTS
In a Loose Projects organisation the Product Owner is responsible for setting up a project organisation and for scaling the support organisation for a Product. He/She hires a Project Manager and makes sure that sufficient funding is available for the Product life-cycle. Operational support of the Product also depends on the Product Owner.
It is the Product Owner who chooses the project management methodology, or who relies on the project approach favoured by the Project Manager. There is no centrally controlled way of doing projects in the organisation.
The advantages of Loose Projects are similar to the advantages of the Uncontrolled Changes approach. The Product Owner has a direct communication line with the engineers supporting the Product, even in a larger support organisation. Decisions are made quickly, thus making projects more agile to change.
Disadvantages of managing Products with loose projects are the following.
There is little coordination between Project Managers on which project management methodology is used. Project documentation and coordination is based on a best effort basis. Success or failure of the project depends on the quality of the Project Manager and project team, and the relation with the Product Owner.
Auditing project results and documentation is complex, because there is no consistent way of doing projects and delivering project documentation. An auditor or manager auditing the project deliverables, needs to do a deep dive into the project itself.
Every project needs to start from scratch, with little re-use of Project Documents, resources or lessons learned from previous projects.
Reporting on projects is done ad-hoc at discretion of the Project Manager or Product Owner. This can lead to confusion on the Governance level on the status of a project. Only someone who is involved in the project can have an insight on the project status, cost structure or deliverables.
The lack of a multidisciplinary governance over projects results in a higher risk of project failure.
Running loose projects in an organisation is usually based on cost considerations. Smaller organisations may not require a Project Management Organisation, and thus avoid the costs for the extra governance bodies. Optimisations, e.g. through using a common project methodology, are still possible.
1.2.4.3 PROGRAM, PORTFOLIO AND PROJECT MANAGEMENT OFFICE
Larger organisations will often put a Program (PgMO) or Portfolio Management organisation in place for coordination of the different projects.
Subordinate to the Program Management Organisation (PgMO) a company can make use of one or multiple Project Management Organisations (PMO). The Project Management Organisation manages proper handling of individual projects. The Project Managers are required to use a common framework for doing Project Management. They are expected to easily move from one project to another, or run multiple projects in parallel.
Notice that in this book we refer to the Project Management Organisation (PMO) as the governance body for Projects. I.e. the Program or Portfolio Management Organisations which make sure that the right projects are done. The Project Management Organisation makes sure that the projects are done right. Chagwa is a guide for the Project Management Organisation.
The difference in Program/Portfolio Management and Project Management is defined as follows.
Program Management Organisation (PgMO)
- Collects new requests for projects and project changes, and performs an overall assessment on scope, time and cost.
- Ensures that the right Projects are initiated. I.e. the Program Management Office performs governance on selecting those projects that generate the highest value to the organisation.
- Prioritises projects in line with Business demand, resource availability and funding available.
- Assesses that the Products created or changed in projects are in line with the Enterprise Architecture.
- reports to senior management on costs and progress of the overall Project portfolio.
Project Management Organisation (PMO)
- Makes sure the Project is run correctly. I.e. the Project Management Organisation performs governance on running projects.
- Manages Project Management resources, e.g. Project Managers, Technical Writers, administrative resources ...
- Reviews mandatory project deliverables through Stage Gate reviews.
- First Point of Contact for project level issues.
- Reports to senior management on project progress.
The advantages of putting a Program/Portfolio Management organisation in place are the following.
Organise chaos through managing the Product Life-cycle in line with Business targets and time lines.
Decrease number of failed projects through proper multidisciplinary governance on the project deliverables. Bad projects are stopped or re-aligned earlier in the process.
Program Management manages integration of the Product into the Business processes and assures they are in line with other Products, other projects and programs. It takes care of integration of projects into the Business processes, systems and organisations.
The advantages of putting a Project Management Organisation in place are the following.
Organise chaos through managing changes to the Product in line with Business Operations. Business downtime is avoided or minimised by proper planning of the projects in coordination with the stakeholders for the Product.
The risks resulting from change are pro-actively assessed and managed. Here also the direct result is a decrease of risk for Business downtime.
Manage Quality of the Product through pro-actively assessing requirements and feedback to the Business through coordinated testing. Inherently this also increases the value of the end Product.
Build and Use Knowledge on the Product, create and maintain Knowledge Documents. Document Application Landscapes.
Detailed time, scope, cost, resource, quality, stakeholder and risk management.
Make sure that changes in the Product follow Change Control.
There is no strict need for an organisation to have separate Program, Portfolio or Project Management Organisations. Smaller companies may choose to decrease costs by merging tasks into a single Project Management Organisation. Larger enterprises may even decide that an additional Enterprise Architecture Organisation needs to be put in place for management of the Product Life-cycles.
The disadvantages of putting a Program and Project Management Organisation in place are the following.
An increased level of governance makes projects run slower. Multiple authority levels, with each having its own approval cycles, can slow down the project kick-off. The time lost typically has to be compensated by the project team later in the project, with an increased risk for errors of poor quality.
Multiple decision makers are involved in the project, with an inherent risk of conflicts in approaches and solutions preferred. This can be another source of delay in the project.
There is a cost for hiring the resources needed in the project organisations. The cost for staffing the Program and Project Management Organisations must be justified by improved project successes, or avoidance of costs resulting from failing projects or bad Product quality.
There is a hidden cost in the projects, caused by communication overhead. This involves delays while waiting for decisions and approvals, and time spent on reporting, audits and stage gates.
The extra governance bodies add one or more Distrans levels in the organisation (see further in the book for a definition of Distrans). Project level decisions are taken based on formal project management process or documentation demands. These decisions may not have the Product in mind or may even be at the expense of the Product.
The Program and Project Management Organisations are a separate Product in the organisation, with a separate life cycle. Processes and procedures change, resources come and go, and roles and responsibilities constantly change. The way project management is done also changes. As a result the Project Management Organisations must constantly adapt. These changes in processes and procedures have a direct impact on how projects are run. For large, multi-year, projects there is a risk that the Project Management Organisation has gone through multiple process changes, resulting in inconsistencies in how the project is managed and governed.
There is a risk of over-governance whenever a project is in trouble. A project reporting status ‘red’ gets swamped in demands for management reports. The project manager is required to go to governance meetings, at a time when all of his/her energy is required for bringing the project back on track.
1.2.4.4 AUDIT, COMPLIANCE AND VALIDATION
Additional project deliverables may be required, dependent on the level of compliance and risk control in the Organisation. There may be a legal or Business requirement to comply with one of the many regulatory compliance rules such as ISO9000, SOx, GxP, HCCP, PCI, Personal Safety ... For risk control an enterprise may enforce additional requirements that need to be addressed in projects, such as review of Disaster recovery and Business Continuity Plans for every large project.
In strongly controlled environments, such as health care and chemical production plants, a strong methodology needs to be enforced where the Product goes through different stages of Factory, System, and Installation and Operational qualification before going into Production. Multiple staging versions or tiers of the Product may need to be built for testing, development, Quality Assurance and Production. The testing and validation of the Product will need to be thoroughly documented.
In practice this is typically solved by adding more governance for projects. Next to the already existing management layers additional stakeholders are added to the project. These stakeholders provide governance on safety and security, quality and regulatory deliverables in the project.
1.2.5 Three Project Management Concepts
1.2.5.1 CHANGE CONTROL PROJECTS
Change Management helps Enterprises understand and control the impact of changes on the Product. Changes are assessed before the change is actually performed. The assessment is done on the level of actual work required, risks involved with the implementation, resources required, timing for doing the change and ways of undoing the change in case the desired quality is not reached, or results are not as expected or even have adverse effects.
A typical Change Control Process can be the following.
Identification of a change to the Product. This is typically a manual task, even though the origin of the change can be an automatic process, e.g. an incident ticket created by a monitoring system. Changes can result from - an incident (acute),
- a problem (chronic),
- planned maintenance, or
- a planned update to the Product, e.g. by a Project Team.
The change is formally recorded. This is usually done in a dedicated application for tracking changes and allowing follow-up and reporting.
Preparation of the change by an Engineer. The Engineer can be a member of one of the Operations or Project Teams. The preparation typically describes
- the configuration items in the Configuration Management Database (CMDB) that are impacted by the change,
- the urgency for executing the change,
- the risk level of the change,
- a sequenced list of tasks that are to be executed,
- testing tasks required for verification that the change was successful,
- a description and list of tasks required for undoing the change.
- time schedule for executing the change.
Assessment of the change by a Change Management review team. The Change Management review team would include members of the Operations Teams, the Product Owner and the Change Owner. When required (e.g. for high risk changes) also other people can be invited as members of the review team, e.g. Business, Architecture, Engineering ...
Formal authorisation for executing the change.
Execution of the change, including testing and optional roll-back.
Collect evidence of the work performed. This can be a photograph, measurement results or (signed) test reports, a Product sample, screenshot or log file...
Updates in the CMDB, both from a Change Management and a Configuration Management perspective. The CMDB updates can include storing the change evidence with the change request.
Change review by quality assurance.
Closure of the change.
Archiving of change details for later review or reference.
In case changes are done by third parties, regular reporting on change requests handled can be used for collecting Key Performance Indicators (KPIs) and verifying performance versus the Service Level Agreement (SLA). The reporting is also used for improving internal processes and monitoring performance of the internal Operational and Project teams.
Change Management helps in identifying how a Product has changed after its original build or implementation. Since changes are maintained in the CMDB it may be the only source of truth of what happened with the Product and what the current status is. This is certainly the case if the architecture design of the Product has not been consistently and diligently kept up to date.
Notice that a strict implementation of Change Management would require that any update to a Product is recorded in the Change Management tool. When updates to the Product are done within a Project framework the requirement of creating a Change Ticket for every change can negatively affect project work. For that reason the level or control through Change Management must be carefully balanced.
Most organisations will e.g. not require Change Management for non-Production systems unless the change imposes a risk for the Production systems. A developer can therefore be allowed to make changes in a test system at will as long as it is isolated from the Production environment. Building a new test system, however, can impact Production and would therefore require to be performed under Change Control.
1.2.5.2 WATERFALL PROJECT MANAGEMENT
Waterfall Project Management is a sequential process where the customer first provides detailed requirements for the Product. From these requirements the Product is designed, engineered, built and rolled out to the Production environment. Once in Production the Operations Teams take over maintenance for the Product.
The Waterfall process is based on the Product hand-off from one team to the other. The customer defines the Product requirements and provides these to the Architecture Team. Architecture creates the architecture design for the Engineering and Build teams. Engineering will design the new components and write procedures and Knowledge Articles for the Product. The Product is then installed using a standard installation procedure. Once installed, the customer tests if the Product matches the requirements. After successful testing the Product is rolled out and handed off to the Operations team. The Operations and Project teams can run in parallel for some time for knowledge transfer and support reasons.
Figure 1. Waterfall Project Flowchart
The challenge in the Waterfall methodology lies in the creation of good requirements.
Insufficient requirements can lead to errors in the design. Architecture and Engineering teams are left with the freedom to create a design that makes it easier for engineering and managing the Product but may be in conflict with the Business use of the Product.
The Business may be asked to describe requirements in full detail. This is soon perceived by the Business as if they need to describe the World.
Many requirements are related to how Business does day-by-day work. End-users may simply not realise which of their daily habits need to be explicitly described as a requirement. They often don’t realise that some of the day-by-day procedures can have a significant impact on the Product design.
Writing down a comprehensive and detailed list of processes, procedures and demands will often result in an unmanageable set of requirements. Project Teams that go through this effort will be confronted with the critique that the requirements Document is impossible to read. Important requirements are drowned in the many details and remain hidden.
A detailed requirements Document would need constant updating. The world is changing, and so are requirements.
The end-users and Product Owner may be unaware of how requirements influence the end design. A requirement that is considered small and negligible by an end-user could have a disastrous impact on the Product design.
Requirements that include technical details limit the ability for Architecture and Engineering teams to create a design that fulfils both the Business and Enterprise Architecture demands. The Architect will often be in a position where a technical Business requirement needs to be challenged.
In many projects requirements are only identified once the technical design is shown. The Product Owner may e.g. come up with a requirement that specific plastics are not allowed in a Production Line only after a design of the production line is proposed. The IT platform chosen may conflict with an application that the Product Owner hadn’t informed about. The result is that the Customer seems to be constantly changing the requirements. Architecture and Engineering teams feel they’re shooting at a constantly moving target.
Time spent in the early phase of the Waterfall methodology will therefore reduce costs in a later stage of the project. The Product Owner, Enterprise Architecture, Engineering and even Operational Teams need to spend time to collaboratively refine both requirements and design for the Product. Previous designs and lessons learned from other projects can help in this early design phase. In some cases, a Proof of Concept needs to be built to allow verification of the design against existing requirements and identify additional requirements.
1.2.5.3 AGILE PROJECT MANAGEMENT
Introduction
Agile thinking was initially proposed in the software development area. The aim was to improve effectiveness of software writing by working closer with the end customer during development. Agile Project Management is an iterative process where the customer and the development team work closely together when developing the Product.
The values used in the Agile project methodology are described in the Agile Manifesto.
Individuals and interactions over processes and tools. The trustworthiness of the Scrum Team lies in capable team members. The members need to be able to resolve issues themselves without being limited by a strict way of working.
Working software over comprehensive documentation. This does not mean that there will be no documentation. Analysis and design documents will still be created, and test results documented as required. The focus is a working Product and just as much documentation as is strictly required.
Customer collaboration over contract negotiation. The Product Owner is the prime contact person to the Business and end-users and works collaboratively with the Development Team. It is the Product Owner that selects the most valuable features that need to be developed next, and for that a rich collaboration with the Development Team is needed.
Responding to change over following a plan. The Agile project team must focus on effective Product increments that can immediately be approved by the Product Owner and end customer. It is the Scrum Team that decides how the end goal will be reached, but it is the Product Owner who prioritises the Product increments required and inherently determines the plan.
Kanban is one of the methodologies adopted by Agile. It originates from how Toyota improved their production process in the late 1940s. Kanban organises the work visually in a “To Do”, “Ongoing”, “Done” scheme. Other columns can be added, e.g. for “Under Test”, “Code review”, or “Validation”. The key principles of Kanban are.
Visualise: everyone needs to know what work is being performed and what is outstanding. This is typically achieved through a Kanban board.
Limit Work in Process (WIP): people need to be focusing on a single item and drive it to completion.
Focus on the flow: optimising the flow of the Product through the system helps in minimising Work in Process.
Continuous improvement: foster a culture where everyone is inspired to constantly improve the processes.
Another well known Agile technique is Scrum. In Scrum the Product Owner and the Development Team collaboratively work on the Product. In the Development Team the Scrum Master acts as a coach for the team, clearing impediments that delay or block the development team. The Development Team is at best five to nine people in size and is self-organising so as to maximise the work and quality delivered in a Sprint.
A Sprint is a time limited period in which the Scrum Team develops an increment in the Product that can be demonstrated and tested. A typical Sprint length is two to four weeks. A Sprint starts with a Sprint Planning where the Scrum Team decides on what work will be done in the next Sprint. The work is added to the Sprint Backlog which is a plan that contains the teams’ forecast of the increment that will be created for the Product.
Figure 2. Agile Project Flowchart
Artefacts
Scrum uses Artefacts to guide the development process. Typical Artefacts are the following.
The Product Backlog is a list of ideas for the Product that is sorted in the order the Scrum Team expects to develop them. The Product Backlog items include a description and an estimate on the work it takes to develop the item compared with one small and standard task. Every idea, enhancement, bug fix, writing documentation, large test development... is entered in the Product Backlog.
Product Backlog items need to be small enough in size to allow them to be developed in a single Sprint. The Product Owner is responsible for keeping the Product Backlog up to date.
An important feature of the Product Backlog is that it is high level in the beginning. When the project progresses the Product Backlog items are further refined and split up into more detailed items.
Product Backlog Items can be written as Epic Stories. A User Epic does not contain much detail and can be used for describing a requirement or functionality that must be added to the Product on a high level or further in the future. User Epics are then further broken down in more detailed User Epics or User Stories.
A User Story is a more detailed description of a requirement. A User Story explains an end-user need in the form of “As a ... I want ... so that ...”. The User Story therefore describes the Viewpoint of the end-user, what is asked, and why this is asked. User Stories must be written up to a level of detail that allows a developer to actually work on the story.
The Sprint Backlog is an excerpt from the Product Backlog and only contains the Product Backlog items that will be executed in a particular Sprint. As a rule these Backlog items have already been broken up to a User Story level of detail.
A Product Increment is the work done on the Product during a Sprint that is of sufficient quality to be given to Users. A Product Increment must satisfy the Definition of Done for that Sprint and must be acceptable to the Product Owner.
The Definition of Done is a shared understanding in the Scrum Team on what is a high enough a quality of the Product Increment. The Product Increment needs to be sufficient to be shippable and must allow the Product Owner to release the next version of the Product to the Users. The Definition of Done is dynamic and progresses as each Sprint is completed.
Not every User Story involves the same amount of work. To compare the effort for completing one story to the other, each story is given a Story Point value. The Story Point value compares the work required for the User Story when compared with a reference User Story, i.e. work for delivering User Stories is not described in number of hours or days.
On a Task Board the overview of tasks to be completed in the next sprint is presented. This makes the work being performed visible to everyone. The Task Board shows the tasks that still need to be started, the ongoing tasks and tasks completed, with their respective number of Story Points.
Notice that the Task Board for the sprint can also be a Kanban as described previously. Scrum and Kanban don’t need to be competitive, they can be complementary.
In a similar way a Burn Down Chart displays the Sprint Backlog items that are completed compared with an estimation of what should have been completed. The forecast uses an estimate of effort needed for the Sprint Backlog item and the current Velocity of how the Development Team is able to develop Product Increments. The Burn Down Chart displays the number of Story Points that have been ‘burned’ in the sprint.
Activities
The Development Team uses specific activities to synchronise the work to be done. Typical activities are:
During Product Backlog Refinement the Product Backlog is reviewed, refined, and re-ordered. Product Backlog items are reviewed and the relative time for development is estimated. This work is done as a preparation for the next Sprints. Although the Product Owner is the owner of the Product Backlog all Development Team members are involved in the Product Backlog refinement.
Each sprint begins with a Sprint Planning meeting that is time boxed. A typical time limit is two hours per week planning for the next Sprint. During Sprint Planning the Development Team selects and discusses the Product Backlog items that will be developed in the next Sprint. The Development Team also determines how they will accomplish the work to be done for the selected items.
In the Daily Scrum each Development Team member will briefly describe what was accomplished the previous period, what will be done in the next period and what is impeding the work. The Daily Scrum is an informative meeting that allows the Development Team members to keep in touch with each other’s work. It is therefore not a reporting meeting and should be limited in time, typically 15 minutes daily.
The Sprint Review is held at the end of each Sprint. The Development Team, Product Owner and other stakeholders review the output of the previous Sprint in a short meeting that is limited to one hour per week of Sprint length. The Product Increment is demonstrated to the stakeholders and the Product Backlog updated with the Product Owner.
Similar to the Sprint review the Development Team members can hold a Sprint Retrospective within the team. The Sprint retrospective is also time boxed, typically one hour per week the Sprint has taken. The Development Team discusses what has gone well and what went badly in the Sprint, and identifies possible improvements.
Analysis
The advantages of Agile Project Management are the following.
Agile will allow for constant changes in requirements and planning. If the Product Owner decides to prioritise a new idea, it can easily be added to the development.
End-user feedback is built into the development. As a result there is a higher and faster end-user satisfaction.
In that same sense user dissatisfaction is captured more quickly also. If a project is performing bad or is not delivering the right Product, it can be stopped sooner in the development. Stopping failing projects sooner will prevent expenditure on projects that are doomed to fail anyway.
The instant feedback from customers and close collaboration between team members, end-users and the Product Owner will easily create a positive atmosphere.
Bug fixing is done immediately, in close collaboration with the end-user, and within a short time frame. Developers have the development fresh in mind, which gains time when executing the fix.
Intermediate releases of the Product are more easily possible. The development in each sprint is expected to be fully completed, such that the Product (or part of the Product) can be released immediately.
Agile reduces the risk of ‘Gold Plating’. It is the Product Owner who determines priorities for the next Sprints and who reviews the quality of the Product Increments. Features with low added value receive a lower priority and may not be delivered in project scope if budgets won’t allow continuation of the project.
Challenges that come with Agile development are:
Program Management Organisations that are used to work with Waterfall driven projects, tend to prioritise projects based on economic value. This implies that an upfront detailed cost must be determined, also for Agile projects. Agile projects are therefore forced to do requirements analysis and create a detailed design that allows cost estimation. I.e. there is a fundamental difference in selecting Waterfall versus Agile projects that the Program Management Organisation needs to be aware of.
Agile requires skilled and experienced, self-driven, cross-functional team members that are able to self-organise to develop the Product. This requires a specific mind-set for the Scrum Team members that may not always be available. Having the technical skills is not enough, the right social skills are also required.
Agile is a small team methodology. Teams are not larger than ten people and all team members work on the same Product. For large and complex projects involving different types of skills this may be a problem. Agile tries to solve this through e.g. the Scrum of Scrums framework. In essence it still requires the project to be balanced and complexity is low enough such that teams can spontaneously coordinate tasks between themselves.
Agile works best in environments with little to no governance. Leadership must not interfere with how a Scrum Team organises itself and how they manage their work. For large organisations this may result in conflicts if engineers and developers need to report to different managers and projects. Management may be challenged in scaling their teams, justifying costs and do Program or Portfolio level planning.
Tasks must be comparable for a good estimation of the effort needed to complete the task compared with a small reference task. This is more easily done for software related projects. It may be much more difficult in mixed and complex projects that e.g. involve a mix of construction work, technical and non-technical tasks, IT level work, defining processes and procedures and providing customer care.
Many organisations claim to be using Scrum, but are caught in non-Scrum thinking. As a result the benefits of Agile are not reached or the teams become ineffective. Examples are the following.
- Creating large teams of 15 or more people because the project is growing too large.
- Not co-locating the Scrum Team members because e.g. a third party specialist is required or several of the team members are located in other regions. For best performance the team members must be co-located and able to constantly communicate with each other.
- Not doing daily scrums because it is considered overhead.
- Retrospectives are not done because they’re considered a waste of time.
- Management is constantly directing Scrum Team members because they are required for escalation meetings and problem fixing. As a result the Scrum Team never reaches the targets of a Sprint.
- Sprints are extended because a specific functionality cannot be created within the sprint.
- Scrum Teams are not allowed to align on timing for a sprint, in line with a targeted Product Increment. Instead they are required to coordinate the Sprints with the monthly management meeting and demonstrate whatever is ready by then.
- The use of a Kanban or other Task Board is abandoned because teams don’t reach the Sprint targets anyway. Instead specific software is used that is only available for the Development Team members. I.e. the public Kanban board is abandoned to disguise that the project is not delivering.
The Product Owner has high focus in Scrum and needs to be available for the Development Team members, e.g. for constantly negotiating and updating User Stories. In practice the role of the Project Manager is largely replaced by the role of the Product Owner. It means that an organisation adopting Agile needs to give the Product Owners more responsibility, at the cost of Project Managers owning the responsibility. The work to be performed by the Product Owner must not be underestimated. Development teams heavily depend on the constant input provided by the Product Owner.
1.2.6 Choosing a Project Management Methodology
1.2.6.1 THE PROJECT MANAGEMENT OCTET
A commonly heard statement is that Project Management manages the triangle of Cost, Scope and Time in a project. We can call these the Control Triangle. The Control Triangle has three components:
Scope: describes the changes that need to be done to the Product, including all work that needs to be done in the project to be able to do these changes.
Time: the targeted time needed to do the project. The time can include intermediate checkpoints where specific project milestones must be reached.
Cost: the overall cost for the project. This includes the cost of the Product, and resources and tools needed for executing the project.
Experience teaches that balancing these three is hard to do, and usually only two of the three corners of the project management Control Triangle are really in control.
These three corner stones are not the only items that need to be controlled in a project. Each project also needs to take into account dependencies with Quality, risks, resources, the Project Sponsor (or Customer), and more general stakeholders. These five items make up the Influencer Pentagon.
Stakeholders: these are all people that can influence a project, or that are impacted by the project. Stakeholders are further discussed in section 7.3.3.
Customer: also called the Project Sponsor. The customer is the most important stakeholder for the project and will be a major source for requirements. During the project the Customer will need to be properly informed about project progress for the right alignment.
Quality: describes the quality level of the changes done to the Product, but also the quality of how the project itself is managed, the volume and detail of project and Product documentation...
Risks: can both be positive or negative to the project. risks are described more in detail in sections 11.2.6.3 and 12.7.2.
Resources: are the people that execute the project and the tools used in the project.
The elements of the Influencer Pentagon will need to be managed through the Control Triangle. For e.g. improving quality, or avoiding specific risks, additional testing can be done. This testing needs to be added to the project scope and budget, and which may take additional time for completing the Product. Stakeholders may have additional requirements for the Product or how the project is being executed. Additional tools may need to be bought, or external resources hired in the project.
The Control Triangle and Influencer Pentagon have a direct impact on the project. Together they make up the Project Management Octet that needs to be managed by the Project Team as a whole.
Figure 3. Project Management Octet
For managing these eight areas companies can choose from different methodologies for Project Management. This is described in more detail in the following sections.
1.2.6.2 CHANGE MANAGEMENT AND THE CONTROL TRIANGLE
Change Management as a project methodology implies that a larger number of changes are performed on the Product. The changes need to be followed up by a Project Manager to make sure that they are properly tracked and executed in the right order, and at the right time. Strictly speaking a Project Manager or Project Lead only needs to babysit the project and make sure the momentum is kept for executing the changes.
