Please enable JavaScript.
Coggle requires JavaScript to display documents.
PRINCE2 IM AGILEN KONTEXT (ANPASSUNG AN DIE PROJEKTUMGEBUNG -->…
PRINCE2 IM AGILEN KONTEXT
ANPASSUNG AN DIE PROJEKTUMGEBUNG --> Unterschiede Ausführung des Projects
Level an Formalität
Wo der Schwerpunkt des Projektes liegt
Exploratives, Innovatives arbeiten, neues Entwickeln
wieviel wissen wir über das Feld und das benötigte Proeukt
Wie das Project ausgeführt wird
Erfahrung des Teams mit agilem Arbeiten
Customer involvement, wie viel der Kunde bereit ist feedback zu geben, oder ob er es eher aus der Hand geben will
how much flexibility is there in scope and quality criteria and elsewhere
focus more on the benefit than the solution
PRE-PROJECT &
INITIATION STAGE
PRE-PROJECT
The trigger for the project (idea, need, etc.) is called a project mandate and is provided by the commissioning organization (corporate, program management or the customer) can go from verbal instruction to well-defined and justified project definition.
Starting up a project process - verify that the project is worthwhile and viable to scope the project fully by production of a
project brief and a
stage plan for project initiation.
The project board reviews the project brief —> decides wether to initiate the project and states the levels of authority to be delegated to the project manager for the initiation stage.
INITIATION STAGE
Plan the project at an appropriate level of detail, obtain funding and define appropriate controls to ensure project is carried out to the wishes of stakeholders, sponsors and customers.
Initiating a project process
the planning
establishment of the PM approaches and controls
development of a robust BC means of reviewing benefits
Managing a state boundary process
plan the next management stage in detail
Initiation stage culiminates in the production of PID - PROJECT INITIATION DOCUMENTATION
reviewed by the project board to decide wether to authorize the project
original PID is preserved as input for later pferformance reviews, since the it will likely change throughout the project (under change control)
HOW PRE-PROJECT AND THE INITIATION STAGE WOULD TYPICALLY LOOK WHEN USING AGILE
PLAN, MONITOR AND CONTROL
Project-level planning focuses on sets of features and intended releases
Strong engagement from all levels of the team in planning and estimating
Stage-level planning is carried out collaboratively with the customer in order to most accurately meet their needs and achieve the most benefit
Plans are timeboxed in some form
As specific time interval (e.g. 2-weekly) or flow-baed (backlog) over a longer period
These plans would be created at a time and at a level of detail to allow for uncertainties
BEHAVIOR
Define project approach
Use of self-organizing teams and people-centric values such as empowerment may be explicitly defined as part of the project approach
Mandating or recommending the use of a specific agile approach (such as Scrum and/or Kanban) may be explicitly defined as part of the project approach
A WORKSHOP may be held to collaboratively create the
project initiation documentation (PID
) in order to disseminate information to the project team quickly and more accurately and with high level of engagement and ownership.
PROCESS
Define information on what constitutes a minimal viable product (MVP)
a product roadmap may provide the trigger for the project
Indication of the appropriate use of agile for the project
PRODUCTS
project product description shows which requirement are mandatory and which aren't
purpose of project product description likely to be outcome-based (focusing on the delivery of value) as opposed to the delivery of a specific solution.
Product descriptions initially captured as user stories (or as epics) although it is expected that more will be discovered and learned throughout this phase and beyond.
The business case is defined in a flexible way to allow for the amount of what is being delivered (and its value) to change to a degree during the project.
The benefits management approach focuses on how to deliver value regularly and as early as possible. —> describing what products will be delivered when and, and what value will be enabled.
The PID will be less detailed in certain sections (e.g. product description) since the solution is not necessarily defined at the start. It is a living document that evolves, although it will still need to be baselined.
PID is likely to be a less formal document, as some of the baseline information is visible in the form of an information radiator
The communication management approach will have been created using the concept of ‘minimum viability’ where communication approaches, and particularly documentation, are assessed on the basis of the minimum acceptable level that does not compromise the quality level of the final product.
Tailoring the
project brief and PID
(see book section 23.1.)
SUBSEQUENT
DELIVERY STAGES
The project boards delegates day-to-day control to the project manager for the next management stage at a time.
THE PROJECT MANAGER
PM needs to assign work to be done, ensure that the outputs of such work (products) meet relevant specifications and gain suitable approval where appropriate.
At this point product may be transitioned into operational use by corporate, program management or the customer
PM needs to ensure that progress is in line with the approved plan and that the forecasts for the project’s performance targets are within agreed tolerances.
PM ensures that a set of project records are maintained to assist with progress control
PM informs the project board of progress through regular highlight reports
The activities to control each managment stage are covered by the controlling a stage process.
In the Managing Product Delivery process the team managers or team members execute asigned work packages (that will deliver one or more products) and keep the project manager appraised of progress via checkpoint reports.
HOW SUBSEQUENT STAGES WOULD TYPICALLY LOOK WHEN USING AGILE
PLAN, MONITOR AND CONTROL
Work assignment throughout the stage is carried out collaboratively and in conjunction (together) with the customer in order to address the customer’s needs. This is likely to take the form of the delivery teams collectively selecting their own work (and collaboratively creating customer-focused work packages) as part of the agile concept of self organization. The focus is on working iteratively and delivering incrementally.
High levels of trust and transparency mean that work packages are defined informally even though they represent a vital component when using PRINCE2 with agile.
Self-organized teams are responding rapidly to change, although this will be within well-understood boundaries in order to ensure the accuracy of the products being delivered.
Progress is being measured by work completed and is visualized on a burn chart.
Progress is supported by the use of reviews and demonstrations (‘demo’s) by the PM team and the delivery teams in association with the customer.
Tracking of time and cost still takes place but less prominent than the tracking of features and/or work completed. This is because time and cost are more predictable due to working with fixed timescales and stable teams.
Scope and quality criteria and the primary focus of any tolerances used.
BEHAVIOR
During the managing a stage boundary process, the key baseline information that needs to be updated focuses on
what has been delivered,
the benefits realized and
the level of change taking place.
FINAL DELIVERY STAGE
Towards the end of the final mgmt state (when the PM gained approval for the project product) it is time to start the closing a project process.
The project board needs to be satisfied that the recipients of the project product are in a position to own and use it on an ongoing basis,
so the product can
be transitioned into
operational use and
the project can close
Project documentation tidied up and archived
the project should be assessed for the performance against its original plan and the resources assigned to the project need to be released
Post-project benefit reviews need to be planned
HOW THE FINAL STAGE WOULD TYPICALLY LOOK WHEN USING AGILE
PLAN, MONITOR
AND CONTROL
When formal checks are made against the project baseline defined in the PID, the key aspects that are assessed include
the amount that was delivered,
what extra was delivered, and
what was removed
BEHAVIOR
Initially intended products may not have been created and replaced by others that were not part of the original plan. There is communication about this throughout the project and everybody should be aware this process
The customer is already in ownership of several products that have transitioned into operational use and is now realizing benefits.
Tidying up and archiving is a routine task by this point, as it has been taking place regularly throughout the project, its value is known to everyone and it is not seen as simply a bureaucratic task.
PROCESS
Closing and decommissioning a project is not a significant event as it is a case of ’tidying up’ and finishing off many activities to do with lessons, archiving and handover which have already been started because of continual and early delivery and release
Project closure involves (or is held as) a retrospective
There is an assessment of how appropriate the use of agile turned out to be to help with guidance on the use of agile for future projects.
Outstanding work still exists on backlogs of some kind (e.g. a release backlog), and this is then moved to other backlogs (e.g. an existing BAU backlog), discarded or archived.
PRODUCTS
Lessons may be handed to the project support informally, or project support may have included in retrospectives if the teams were happy for them to be in attendance.
POST PROJECT
Corporate, program managment or the customer defined the benefits and evaluate if the project has contributed towards benefits realization.
They will therefore likely hold a
POST-PROJECT BENEFIT REVIEW
that will focus on
Confirming that the planned benefits have been achieved
Identifying which planned benefits have not been achieved and agreeing a follow-up action plan
Identifying any unexpected benefits that have been achieved and any dis-benefits that resulted
providing lessons for future projects.
The reviews will be signposted in the project’s benefit management approach. If the project is part of a program, then the post-project benefits reviews need be be covered by the program’s benefits management activities.
Typically, some of the benefits will be delivered before the end of the project. Post-project reviews may consider the requirements for any features not implemented at handover.
See Kapitel 4 Buch, Modul 1&2,
Prince2 und agile zusammen