DE WENDBARE ORGANISATIE 16E BPUG SEMINAR 4 JUNI 2013
AgilePM, altijd raak in een wendbare organisatie? Round Table Challenge BPUG 2013 Georges Kemmerling (Quint Wellington Redwood) Marcel Wilmink (Zelfstandig Professional, GoodSense)
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
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: OF: 6. PRINCE2 in 5 minuten (timeboxed) 7. AgilePM in 5 minuten (timeboxed) 8. Benoem Uw punt en creëer draagvlak in uw organisatie
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 Foundation Exploration and Engineering Deployment Feasibility Assessment bevat outline BC Business Foundations bevat de BC gerelateerd aan de Prioritised Requirements List (relatief variabel) Aanpassingen op de Must Have s van de PRL worden door de Business Sponsor geaccordeerd Starting up a Project Initiating a Project Controlling a Stage Managing Product Delivery Project Brief bevat outline BC PID bevat de BC gerelateerd aan de output van het project (vast) Bij issues/risico s wordt impact op de BC bepaald. Besluitvorming door de stuurgroep in Directing a Project. Post-Project - 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.
Realiseren van Benefits Agile PM lifecycle: Pre-project Feasibility Agile PM product PRINCE2 proces PRINCE2 product Terms of Reference bevat high level business driver. Feasibility Assessment bevat outline BC en de Prioritised Requirements List (PRL) met een richting van de Output (relatief variabel) - Project Mandaat bevat high level business driver Starting up a Project Brief bevat outline BC met globale Project Benefits en de Project Product Description met een definitie van de gewenste Output Foundation Exploration and Engineering Deployment De BC wordt opgesteld met een Benefits Realisation Strategy Deployment Plan wordt opgesteld met daarin een Benefits Realisation Plan met een beschrijving hoe deze Deployed Solution bijdraagt aan de BC Project Review Report bevat een Benefits Enablement Summary, een samenvatting welke onderdelen uit de BC nu gerealiseerd zijn. Initiating a Project Controlling a Stage Managing Product Delivery Managing a Stage Boundary Het Benefits Review Plan wordt opgeleverd naast de BC. Bij issues/risico s wordt impact op de BC bepaald. Besluitvorming door de stuurgroep in Directing a Project. 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.
Projectsturing (1/2)
Sturing Sturen op kwaliteit Sturen op scope Sturen op tijd Sturen op geld Agile PM 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. 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. Scope is in de Prioritised Requirements List vastgelegd. Aanpassingen van Must Have s via de Business Visionary. Sturen op MoSCoW. Volgens Outline Plan en Delivery Plan. Door Timebox principe staat einddatum vast en is functionaliteit variabel. Volgens Business Foundation. Door timebox principe staat budget vast en is functionaliteit variabel. Projectsturing (2/2) Toleranties Scope (Should Have s en Could Have s) zijn tolerantie. Als Must Have s in het geding komen PRINCE2 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. 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. Scope en Out of Scope is duidelijk in PID vastgelegd. Via Change Control beheersen. Er bestaat een tolerantie op scope. Via tolerantie op planning van Project/Fase/Workpackages, verwachte afwijkingen middels Exception/Issue rapporteren naar het juiste niveau. Er bestaat een tolerantie op tijd. Via tolerantie op budget, verwachte afwijkingen middels Exception rapporteren naar het juiste niveau. Igv problemen kan een combinatie van Toleranties worden ingezet.
Omgevingsfactoren Als de onzekerheid hoog is, gaat de PRINCE2 aanpak lijken op Agile. Onderstaand voorbeelden van omgevingsfactoren van onzekerheid; gebaseerd op ISPL) Duidelijkheid en stabiliteit vd requirements is laag 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 Werk met zeer korte stages. Lage tolerantie op project niveau, op tijd en geld. Hoge tolerantie op scope. Stages zijn korte increments, werkpakketten zijn timeboxes. 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. PRINCE2 SCRUM 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 Agile PM 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.
Management Producten Opzet PRINCE2 Baselines (goedgekeurde plannen en kwaliteitsdocument) Reports (eenmalige rapporten) Logs (Dynamische registers voor Issues, Risico s, Kwaliteit, PSA, Configuration Items Records, Daily Log) Agile PM 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 lifecycle. 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 in 5 minuten
AgilePM in 5 minuten Philosophy: Clearly define strategic goals and focus upon early delivery of real benefits to the business 8 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 problem Feasibility: First BC and first estimates Foundations: From 3 perspectives (business, solution, management), BC and high level reqs. Exploration: Investigate detailed business reqs and translate to viable solutions Engineering: Evolve preliminary solutions to full operational readiness Deployment: Get the solution into live use and replan Post-Project: Measure business value actually achieved. 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. Orange roles: Business personnel Blue roles: Agile PM roles Green roles: Technical development of the solution 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 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. 4) Modelling 5) Timeboxing 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 Timebox Solution 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. Versie 1 Source: Agile Project Management Handbook (ISBN 0-9544832-4-3) / APMG International TM
Uw onderwerp
Afronding Uw conclusie Onze conclusie
Landschap Discipline Programma Mgt Project Management PRINCE2 MSP Team Organisatie Requirements Architectuur Ontwerp / Implementatie Deployment SCRUM Agile PM Dag Iteratie Release Project Programma Planningshorizon