Embed Size (px)
Citation preview
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
4 JUNI 2013
DE WENDBARE ORGANISATIE
16E BPUG SEMINAR
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
AgilePM, altijd raak in een ‘wendbare organisatie’?
Round Table Challenge BPUG 2013 Georges Kemmerling (Quint Wellington Redwood)
Marcel Wilmink (Zelfstandig Professional, GoodSense)
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
‘AgilePM altijd raak’ in een timebox van 45 minuten
U bent de wendbare organisatie
Wij willen U maximaal bedienen, U bepaalt
MoSCoW prioritering van onderwerpen
U bepaalt de scope: 3 punten willekeurig verdelen
U keurt een onderwerp goed: Afvlaggen
Tijd staat vast, inhoud is variabel
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Onderwerpen
De wendbare organisatie en PRINCE2 ® versus AgilePM op het gebied van:
1. de Business Case
2. realiseren van Benefits
3. de sturing van een project
4. omgevingsfactoren
5. Management Producten
Algemeen:
6. PRINCE2 in 5 minuten (timeboxed)
7. AgilePM in 5 minuten (timeboxed)
OF:
8. Benoem Uw punt en creëer draagvlak in uw organisatie
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Business Case
Agile PM
lifecycle:
Agile PM product PRINCE2 proces PRINCE2 product
Pre-project Terms of Reference bevat
high level business driver.
- Project Mandaat bevat high level
business driver
Feasibility Feasibility Assessment
bevat outline BC
Starting up a
Project
Project Brief bevat outline BC
Foundation Business Foundations
bevat de BC gerelateerd
aan de Prioritised
Requirements List (relatief
variabel)
Initiating a
Project
PID bevat de BC gerelateerd aan de
output van het project (vast)
Exploration
and
Engineering
Aanpassingen op de Must
Have’s van de PRL worden
door de Business Sponsor
geaccordeerd
Controlling a
Stage
Managing
Product Delivery
Bij issues/risico’s wordt impact op de
BC bepaald. Besluitvorming door de
stuurgroep in Directing a Project.
Deployment
Managing a
Stage Boundary
De BC wordt bijwerkt en door de
stuurgroep opnieuw geautoriseerd.
Closing a Project End Project Report beschrijft o.a.
aantal changes op de output van het
project en impact op de BC.
Post-Project -
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Realiseren van Benefits
Agile PM
lifecycle:
Agile PM product PRINCE2 proces PRINCE2 product
Pre-project Terms of Reference bevat high level
business driver.
- Project Mandaat bevat high level business
driver
Feasibility Feasibility Assessment bevat outline BC en
de Prioritised Requirements List (PRL) met
een richting van de Output (relatief variabel)
Starting up a
Project
Project Brief bevat outline BC met globale
Benefits en de Project Product Description met
een definitie van de gewenste Output
Foundation De BC wordt opgesteld met een Benefits
Realisation Strategy
Initiating a Project Het Benefits Review Plan wordt opgeleverd
naast de BC.
Exploration
and
Engineering
Deployment Plan wordt opgesteld met
daarin een Benefits Realisation Plan met
een beschrijving hoe deze Deployed
Solution bijdraagt aan de BC
Controlling a Stage
Managing Product
Delivery
Bij issues/risico’s wordt impact op de BC
bepaald. Besluitvorming door de stuurgroep in
Directing a Project.
Deployment Project Review Report bevat een Benefits
Enablement Summary, een samenvatting
welke onderdelen uit de BC nu gerealiseerd
zijn.
Managing a Stage
Boundary
Benefits Review Plan wordt geactualiseerd nav
eventuele metingen.
Closing a Project
Benefits Review Plan wordt overgedragen aan
de lijnorgansisatie.
Post-Project Benefits Assessment, indien mogelijk een
analyse wat is bereikt. Indien niet mogelijk
een plan hoe dit periodiek te doen.
- Benefits Review Plan wordt door de
lijnorganisatie uitgevoerd.
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Projectsturing (1/2)
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Projectsturing (2/2)
Agile PM PRINCE2
Sturing High level gestuurd door de Project Manager. In
detail door zelfsturend Solution Development
team. Gebaseerd op samenwerkingsmodel:
Klant is expliciet onderdeel van ontwikkeling en
oplevering.
Top down gestuurd door stuurgroep. 4 Levels van
hiërarchie. Gebaseerd op Klant
Leveranciersmodel: Leverancier levert op aan de
klant. Sturing is gebaseerd op toleranties en
Management by Exception.
Sturen op
kwaliteit
Basis principe ‘Never compromise quality’. Test
en acceptatie wordt globaal beschreven in de
Solution Foudations en wordt gaandeweg in
Exploration&Engineering vastgelegd en
uitgewerkt in een Solution Assurance Pack.
Expliciet belegd middels Quality Management
Strategy en acceptatie van deelproducten. Wordt in
het begin van het project vastgelegd.
Kwaliteitscriteria sijpelen door tot in de Product
Descriptions. Er bestaat een tolerantie op kwaliteit.
Sturen op
scope
Scope is in de Prioritised Requirements List
vastgelegd. Aanpassingen van Must Have’s via
de Business Visionary. Sturen op MoSCoW.
Scope en Out of Scope is duidelijk in PID
vastgelegd. Via Change Control beheersen. Er
bestaat een tolerantie op scope.
Sturen op
tijd
Volgens Outline Plan en Delivery Plan. Door
Timebox principe staat einddatum vast en is
functionaliteit variabel.
Via tolerantie op planning van
Project/Fase/Workpackages, verwachte
afwijkingen middels Exception/Issue rapporteren
naar het juiste niveau. Er bestaat een tolerantie op
tijd.
Sturen op
geld
Volgens Business Foundation. Door timebox
principe staat budget vast en is functionaliteit
variabel.
Via tolerantie op budget, verwachte afwijkingen
middels Exception rapporteren naar het juiste
niveau.
Toleranties Scope (Should Have’s en Could Have’s) zijn
tolerantie. Als Must Have’s in het geding komen
volgt een escalatie naar Steering level.
Igv problemen kan een combinatie van Toleranties
worden ingezet.
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Omgevingsfactoren
Als de onzekerheid hoog is, gaat de
PRINCE2 aanpak lijken op Agile.
Onderstaand voorbeelden van
omgevingsfactoren van onzekerheid;
gebaseerd op ISPL)
PRINCE2
PRINCE2
Agile PM SCRUM
Duidelijkheid en stabiliteit vd
requirements is laag Werk met zeer korte stages.
Lage tolerantie op project
niveau, op tijd en geld. Hoge
tolerantie op scope. Stages
zijn korte increments,
werkpakketten zijn time-
boxes. Bij elke stage worden
benefits gerealiseerd en
geëvalueerd. MSB/IP zijn
kortlopend en MSB gaat meer
lijken op het IP proces (wat
gaan we nu doen?) Senior
user en senior supplier zijn
inhoudelijk erg betrokken.
Assurance is erg informeel en
op de werkvloer betrokken.
Weinig risico management en
weinig change management.
Idem als
PRINCE2.
Scrum tools
kunnen worden
ingezet om de
teams te
faciliteren.
Scrum is
minder
formeel, meer
een setje
technieken,
dus het heeft
iets als
PRINCE2
nodig voor de
sturing en
governance
Als wendbaarheid het doel
van de organisatie is dan
moet je voor Agile PM
kiezen. Hier zit alles al in
voor het overwinnen van
hoge onzekerheid het
bieden van een snelle
response en het
behouden van maximale
flexibiliteit: de organisatie
is namelijk inhoudelijk
betrokken bij het Solution
Development team! In dat
geval is Agile de betere
keuze. Niettemin zul je
ook minder onzekere
projecten hebben (infra)
en dan blijft PRINCE2 de
betere optie.
Kwaliteit van bestaande specs is laag
Inzicht in business proces is laag
Stabiliteit business proces is laag
Het systeem is erg innovatief
Kwaliteit van business proces is laag
Kwaliteit van de informatie is slecht
Houding van de medewerkers is negatief
Vaardigheis van de medewerkers is laag
De vernieuwing is heel belangrijk
Grote afhankelijkheid van leveranciers
Zeer nieuwe technologie
Beschikbaarheid van benodigde
technologie is laag
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Management Producten
PRINCE2 Agile PM
Opzet Baselines (goedgekeurde plannen en
kwaliteitsdocument)
Reports (eenmalige rapporten)
Logs (Dynamische registers voor Issues,
Risico’s, Kwaliteit, PSA, Configuration Items
Records, Daily Log)
Focus op Business
Focus op Project Management
Focus op de Evolving en Delivered Solution.
Documenten Templates van documenten zijn
gedefinieerd evenals rollen Producent,
Reviewer, Goedkeurder.
Formaliseren van documenten is verankerd
in de PRINCE2 methodiek
Bevat een generieke set van documenten met
per product een beschrijving van doel en life-
cycle. Een een voorstel over inhoud en rollen.
Tips voor op maat maken.
Flexibiliteit Documentie is aan te passen volgens
principe ‘Op maat maken van PRINCE2’.
Uitgangspunt is dat de PRINCE2 Principes
van toepassing dienen te blijven.
Aanpassingen worden in de PID vastgelegd.
In de Management Foundations wordt
vastgelegd wat de afspraken zijn voor het
betreffende project: Aanpak, governance en
beheersing. Uitgangspunt is minimale
documentatie.
Basis hiervoor is een geanalyseerde Project
Approach Questionnaire.
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
PRINCE2 in 5 minuten
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
AgilePM in 5 minuten
Philosophy: Clearly define strategic goals and focus upon early delivery of real benefits to the business8 Principles: Focus on business needs Deliver on time Collaborate Never compromise quality Build incrementally from firm foundations Develop iteratively Communicate continuously and clearly Demonstrate control
Pre-Project: Define business problemFeasibility: First BC and first estimatesFoundations: From 3 perspectives (business, solution, management), BC and high level reqs. Exploration: Investigate detailed business reqs and translate to viable solutionsEngineering: Evolve preliminary solutions to full operational readinessDeployment: Get the solution into live use and replanPost-Project: Measure business value actually achieved.
Orange roles: Business personnelBlue roles: Agile PM rolesGreen roles: Technical development of the solution
Business Sponsor: Owner of the BC and the final solution, make final decisions. Deliver capability to realize benefits.Business Visionary: Provide strategic direction, align business needs and BC. Ensure the solution will meet business benefits.Project Manager: Focus on delivery, provide high-level directions to the solution development team(s).Technical Coordinator: Technical design authority for the project, ensure consistency across solution development team(s).Team Leader: Ensures the team functions as a whole. Coordinate product delivery at detailed level. Leadership rather than management.Business Analyst: Focus on relationship between busines and technical roles. Ensures business needs are properly analyzed and correctly evolution of solution.Solution developer: Translate business requirements to a deployable solution.Business ambassador: Key business role within the SDT. Provides business related information of those who will use the solution.Business advisor: Often peer of the Business Ambassador, provides specific or specialist input (compliancy, legal, …).Workshop facilitator: Manages the workshop process, independent of workshop outcome.
Terms of Reference: High level definition of business driver for and objectives of the project.Feasibility Assessment: Outline Business Case, Outline Solution, optional: Feasibility Prototype.Outline Plan: Overview of the project from Project Management and Solution Delivery perspective bases on a completed Project Approach Questionnaire.Business Foundations: Information for and about the business that is fundamental to the succes of the project.Prioritised Req List: High level requirements to be addressed in order to meet the Business Case.Delivery Control Pack: Reports, documents and logs related to the ongoing status of the project.Delivery Plan: Refined and elaborated Outline Plan describing timeboxes, increments, deployments, key milestones.Management Foundations: Essential governance and organisational aspects of the project. How the project will be managed.Based on an updated and reviewed Project Approach Questionnaire.Solution Foundations: Information for and/or about the solution that is fundamental to the succes of the project (Business Area Definition, System Architecture Definition, Development Approach Definition, Solution Prototype).Deployment Plan: Detailed plan for the deployment phase. Schedule of activities for the delivery of products from business and technical perspective. Benefits realisation Plan is an extension of the Deployment Plan.Timebox Plan: Definition of what to deliver in a Timebox and specific resources needed for success.Timebox Review Record: Result of the assessment of the effectiveness of a TimeboxSolution Assurance Pack: Collection of elements proving the completeness and fitness for purpose of components of the Evolving solution (Solution Review Records, Business Testing Pack and Technical Testing Pack).Evolving Solution: A certain state of the solution after x increments.Project Review Report: Evolving product updated at the end of each increment (Increment Review Record(s), Benefits Enablement Summary(ies), End of Project Assessment.Deployed Solution: An instance of the evolving solution brought into operation. Benefits Assessment: Assessment how Benefits have actually been realized while the Deployed Solution has been used.
Kick-off: (1-3 hrs) Short session for the Solution Development Team to understand timebox objectives and accept them as realistic.Investigation: (10-20% of the timebox) Initial investigation of the detail of all the products to be delivered by the timebox including timebox success factors.Refinement: (60-80% of the timebox) The bulk of development and testing of the timebox products according agreed priorities.Consolidation: (10-20% of the timebox) Finish up any loose ends and ensure that all products meet the acceptance criteria.Close-out: (1-3 hrs) Formal acceptance of the timebox deliverables by the Business Visionary and the Technical Coordinator.
Identify what they need to achieve in this iteration.Plan how they are going to do it.Evolve the product(s) in question in accordance with their plan.Review the outcome with a view to determine whether another iteration is required.
Versie 1Source: Agile Project Management Handbook (ISBN 0-9544832-4-3) / APMG International TM
5 Techniques:
1) Facilitated Workshops:- Rapid, high quality decision making- Greater buy-in from all stakeholders- Building team spirit- Building consensus- Clarifiation of issues
2) MoSCoW prioritisation
3) Iterative Development
4) Modelling
5) Timeboxing
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Uw onderwerp
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Afronding
• Uw conclusie
• Onze conclusie
PRINCE2®, MSP®, MoP®, M_o_R®, MoV® and P30® are registered trade marks of the Cabinet Office.
Landschap
Dag Iteratie Release Project
Planningshorizon
Programma Mgt
Project Management
Team Organisatie
Requirements
Architectuur
Ontwerp /
Implementatie
Deployment
Discipline
Agile PM
PRINCE2
Programma
SCRUM
MSP
