AgilePM® (PL) - Zwinne zarządzanie projektami

1. AgilePM® - iteracyjno-przyrosoto-adaptacyjna (ang. change-driven / empirical) metoda zwinnego zarządzania projektami oraz framework (nie tylko sam framework jak Scrum) z Wielkiej Brytanii stosowany do niezależnego od branży (nie związanym z konkretną branżą typu IT, Inżynieria czy Budownictwo) zwinnego zarządzania projektami. Metoda AgilePM® jest postrzegana jak hybrydowa metoda, która łączy w sobie zarządzanie projektem z wytwarzaniem produktów w ramach jednej metody. AgilePM® powstała jako pochodna z innej metody o nazwie DSDM® z jej wersji v5 zwanej jako DSDM® Atern® w 2010 roku. Podobnie jak DSDM®, AgilePM® została opracowana przez konsorcium DSDM® Consortium - www.dsdm.org

1.1. Current DSDM family

1.2. Pierwsza wersja AgilePM® (v1.0) została opublikowana 07.2010.

1.3. Wersja v1.1 zawierająca drobne poprawki została opublikowana 09.2012

1.4. Wersja v1.2 zawierająca drobne poprawki została opublikowana 12.2013

1.5. Wersja v2.0 została opublikowana 09.2014

2. AgilePM® Fazy cyklu życia projektu (7) (a.k.a. 'building blocks')

2.1. Overview

2.1.1. W zgodnie z pryncypiami 5 i 6 cykla życvia projektu AgilePM® jest zarówno iteracyjny i przyrostowy.

2.1.1.1. AgilePM® provides an iterative and incremental framework, with seven lifecycle phases.

2.1.1.2. Each phase has objectives and pre-conditions.

2.1.1.3. This configurability of AgilePM® Lifecycle allows the project manager significant opportunity to deliver business value early and to demonstrate progress. The framework is highly configurable, depending on the size and formality of the project being delivered.

2.1.1.3.1. It is sequential for Pre-project, Feasibility and Foundations,

2.1.1.3.2. Can have many iterations of Exploration and Engineering.

2.1.1.3.3. Can have many separate Deployments!

2.1.1.3.4. Post Project will be sequential with the last Deployment.

2.1.1.4. Solution may not be delivered to the business in one go, but in a series of increments that increase the breadth and/or depth of the solution with each delivery.

2.1.1.4.1. Urgent business needs can be addressed early while less important features are delivered later.

2.1.1.5. Iterative nature of AgilePM® enables business representatives to see work under construction, comment on it and request changes during the development of an increment of the solution.

2.1.1.6. Each lifecycle phase will deliver Products and, within AgilePM®, delivery of Products (to the appropriate and agreed level of quality) is used to assess progress.

2.1.1.7. It is important to keep the phases of the lifecycle visible to the SDT during the project.

2.1.1.8. Typically, plan for Feasibility and Foundations phases to be shorter than would be the case for a traditional one-delivery project. Allow for just enough design up front (EDUF)

2.1.1.9. Project phases are 'building blocks' from which you are building project lifecycle.

2.1.1.9.1. see example project lifecycles

2.2. AgilePM® provides an iterative, incremental and adaptive framework, with 7 lifecycle phases.

2.2.1. AgilePM® Project Lifecycle Phases with requirements

2.3. 1. Faza Przedprojektowa

2.3.1. Wprowadzenie

2.3.1.1. In most organisations projects exist as part of a portfolio of other projects and sometimes exist as part of a programme of projects with a shared business change objective. Regardless, projects need to be set up correctly from the outset to ensure success.

2.3.1.2. The work of the pre-project phase simply formalises a proposal for a project and places it in the context of other potential work to be, or already being, carried out by the organisation.

2.3.2. Cele

2.3.2.1. To describe the business problem to be addressed.

2.3.2.2. To identify a Business Sponsor and Business Visionary.

2.3.2.3. To confirm that the project is in line with business strategy.

2.3.2.4. To scope, plan and resource the Feasibility phase.

2.3.3. Consider

2.3.3.1. The intended work of the Pre-project phase should be short, sharp and ideally restricted to the creation of a short statement that has the purpose of justifying and prioritising a Feasibility investigation.

2.4. 2. Faza Oceny Wykonalności (ang. Feasibility Assessment)

2.4.1. Wprowadzenie

2.4.1.1. Project management best practice dictates that the viability of the project should be continually assessed throughout the project, ensuring that the benefits predicted from the use of end products of the project outweigh the costs of delivering them.

2.4.1.2. The Feasibility phase provides the first opportunity for deciding whether a proposed project is viable from both a business and a technical perspective by means of a high level investigation of the potential solutions, costs and timeframes.

2.4.2. Cele

2.4.2.1. To establish whether there is a feasible solution to the business problem described in the Terms of reference defined during Pre-Project.

2.4.2.2. To identify the benefits likely to arise from the delivery of the proposed solution.

2.4.2.3. To outline possible approaches for delivery, including strategies for sourcing the solution and project management.

2.4.2.4. To describe the organisation and governance aspects of the project.

2.4.2.5. To state first-cut estimate of timescale and costs for the project overall.

2.4.2.6. To plan and resource the Foundation phase.

2.4.3. Warunki wstępne

2.4.3.1. The Terms of Reference for the project have been approved.

2.4.3.2. the required resources are available to carry out the feasibility investigation.

2.4.3.3. the Business Visionary has sufficient time available to help shape the project.

2.4.4. Uwagi

2.4.4.1. If you are going to stop work on a project then it is important that you stop as early as possible.

2.4.4.2. The Feasibility phase should be kept as short and sharp as possible, remembering that its only purpose is to justify progressing to the Foundations phase. The detail of the investigation happens in the Foundations phase.

2.5. 3. Faza Określenia Podstaw (ang. Foundations phase)

2.5.1. Wprowadzenie

2.5.1.1. The Foundations phase is aimed at establishing firm and enduring foundations for the project. In establishing the foundations, the three essential perspectives of business, solution and management need to be combined to provide a clear project focus that is both robust and flexible. To create solid foundations, it is vital that detail, particularly around the solution, is strictly limited so that it does not unnecessarily constrain the way the solution evolves but still clearly demonstrates how it will meet the needs of the business.

2.5.2. Cele

2.5.2.1. To baseline the high-level requirements for the project and describe their priority and relevance to the business need

2.5.2.2. To describe the business processes to be supported by the proposed solution

2.5.2.3. To identify information used, created and updated by the proposed solution

2.5.2.4. To describe the strategies for all aspects of solution deployment

2.5.2.5. To detail the Business Case for the project

2.5.2.6. To start designing the solution architecture and identifying the physical or infrastructural elements of solution

2.5.2.7. To define technical implementation standards

2.5.2.8. To decribe how quality will be assured

2.5.2.9. To establish appropriate governance and organisation for the project

2.5.2.10. To describe the solution development lifecycle for the project along with techniques to be applied in managing the project and for demonstrating and communicating progress

2.5.2.11. To baseline a schedule for development and deployment activities for the solution

2.5.2.12. To describe, assess and manage risk associated with the project

2.5.3. Warunki wstępne

2.5.3.1. agreement of the Feasibility Assessment (if created)

2.5.4. Uwagi

2.5.4.1. Significant business input will be required during the Foundations phase. The relevant business representatives must be identified early and their level of involvement agreed. Set a time limit for the Foundations phase and try to stick to it. The aim of this phase is to create a high-level but sound view of the business and technical aspects of the project. Only produce the Foundation products to the level that allows the project to move into the first exploratory development phase.

2.6. 4. Faza Eksploracji (ang. Exploration phase)

2.6.1. Wprowadzenie

2.6.1.1. The Exploration phase is used to iteratively and incrementally investigate detailed business requirements and translate them into a viable solution.

2.6.1.2. The preliminary solution created during Exploration is not expected to be production-ready but is focused on demonstrating that it will deliver what is needed, whilst fitting precisely with the ever-changing detail of overall need.

2.6.1.3. The end-product of Exploration will be refined further during the Engineering phase to ensure technical acceptance criteria such as performance, capacity, security, supportability and maintainability are met.

2.6.2. Cele

2.6.2.1. To elaborate on the requirements captured and baselined in the Prioritised Requirements List during Foundations

2.6.2.2. To explore the full detail of the business need and provide detailed requirements for the evolving solution

2.6.2.3. To create a functional solution that demonstrably meets the needs of the business

2.6.2.4. To give the wider organisation an early view of the solution that they will eventually operate, support and maintain

2.6.2.5. Where needed, to evolve the Business Area Definition and System Architecture Definition products of the Foundations phase into models that describe how the solution works and how it supports all impacted business processes and systems

2.6.3. Warunki wstępne (dla wyjścia z fazy Określania Podstaw)

2.6.3.1. The Business, Solution and Management Foundations products have ben collectively accepted as provide an adequate foundation from which a solution can evolve

2.6.3.2. The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution

2.6.3.3. All required project personnel and stakeholders are engaged as necessary

2.6.4. Uwagi

2.6.4.1. There are many paths through the iterative phases of Exploration, Engineering and Deployment. The three basic patterns to be considered in determining the most appropriate development approach are in the chapter on Configuring the Lifecycle for Evolution.

2.7. 5. Faza Inżynierii (ang. Engineering phase)

2.7.1. Wprowadzenie

2.7.1.1. The Engineering phase is used iteratively and incrementally to evolve the preliminary solution created during Exploration to achieve full operational readiness.

2.7.1.2. Development effort here is focused primarily on addressing non-functional requirements (such as performance, capacity, security, supportability and maintainability).

2.7.1.3. Continued involvement from the Business representatives during this phase provides an ongoing opportunity to validate fitness for business purpose from a functional perspective.

2.7.2. Cele

2.7.2.1. To refine the Evolving Solution from the Exploration phase to meet the agreed acceptace criteria

2.7.2.2. To expand and refine any products required to successfully operate and support the solution in live operation

2.7.3. Warunki wstępne

2.7.3.1. The Evolving Solution from the Exploration phase has been approved.

2.7.3.1.1. Business Visionary has acknowledged that the features demonstrated in the Evolving Solution are in line with the vision for the final business solution.

2.7.3.2. The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution

2.7.3.3. All required project personnel and stakeholders are engaged as required

2.7.4. Uwagi

2.7.4.1. There are many paths through the iterative phases of Exploration, Engineering and Deployment. The three basic patterns to be considered in determining the most appropriate development approach are in the chapter on Configuring the Lifecycle for Evolution.

2.8. 6. Faza Wdrożenia (ang. Deployment phase)

2.8.1. Wprowadzenie

2.8.1.1. The primary purpose of the Deployment phase is to get the solution into live use. Where the end-products of the project are to be sold or distributed outside of the organisation creating it, the Deployment phase is used to get the products ready to ship.

2.8.1.2. A secondary purpose is to act as a key review point prior to Deployment or future development work.

2.8.1.3. The number of passes through the Deployment phase will depend on whether it is sensible and feasible for the business to accept delivery of the overall solution incrementally.

2.8.2. Cele

2.8.2.1. To confirm the ongoing performence and viability of the project and re-plan as required

2.8.2.2. To deploy the solution (or increment of it) into the live business environment

2.8.2.3. Where applicable, to train the end users of the solution and/or provide necessary documentation to support the live operation of the solution in the business environment

2.8.2.4. To train and/or provide documentation for operations and support staff who will responsible for supporting and maintaining technical aspects of the solution

2.8.2.5. To assess whether the deployed solution is likely to enable the delivery of intended elements of business benefit described in the Business Case (where created)

2.8.2.6. After the final deployment:

2.8.2.6.1. To formally bring the project to a close.

2.8.2.6.2. To review overall project performance from a technical and/or process perspective.

2.8.2.6.3. To review overall project performance from a business perspective.

2.8.3. Warunki wstępne

2.8.3.1. The Deployable Solution has been approved for deployment

2.8.4. Uwagi

2.8.4.1. If the solution is being deployed incrementally, it is usually appropriate to formally assess whether the project should continue after each interim deployment.

2.8.4.1.1. The Pareto Principle (or 80:20 rule) implies that it is possible that the vast majority of the benefit might be enabled by an early interim delivery.

2.8.4.2. It therefore makes sense to check that investment in the rest of the planned project will provide a reasonable return.

2.8.4.3. Justification to continue is likely to reflect the cost of operating the solution as it stands against the cost of operating a more complete solution.

2.9. 7. Faza Poprojektowa (ang. Post Project phase)

2.9.1. Wprowadzenie

2.9.1.1. The Post-Project phase takes place after the last planned deployment of the solution. Its purpose is to reflect on the performance of the project in terms of the business value actually achieved.

2.9.1.1.1. Assessment should start as soon as the value can be measured.

2.9.2. Cele

2.9.2.1. To assess whether the benefits described in the Business Case (where created) have actually been achieved through use of the Deployed Solution

2.9.2.2. Mostly, the project will have been closed prior to the start of the Post-Project phase.

2.9.2.3. In some projects where the overall solution is delivered incrementally, it is often appropriate to start the benefits realisation process before the final deployment.

2.9.2.3.1. Under such circumstances it may be appropriate to feed any proposals for change or enhancement back into the ongoing project.

2.9.2.4. The BS and BV have an ongoing responsibility for ensuring that the benefits enabled by the project are actually realised through proper use of the solution provided.

2.9.3. Warunki wstępne

2.9.3.1. The solution has been successfully deployed.

2.9.4. Uwagi

3. AgilePM® Pryncypia (8)

3.1. Principles are universally applicable statements.

3.1.1. They provide guidance to organizations.

3.2. The 8 principles of AgilePM® direct the team (not mandates) in the attitude and culture they must take and the mindset they must adopt in order to deliver consistently.

3.2.1. A way of thinking and working.

3.3. Jeśli zespół projektowy nie przestrzega wszystkich zasad, to nie uzyska pełnych korzyści AgilePM®.

3.4. Nieprzestrzeganie prycypiów należy traktować jako ryzko / zagrożenie dla projektu.

3.4.1. Ponieważ łamanie którejkolwiek z pryncypiów złamie ideę AgilePM® i powstanie znaczne ryzyko wpływające na powodzenie projektu.

3.5. The 10 Golden Rules for Successful Agile Projects (by Keith Richards)

3.5.1. https://www.youtube.com/watch?v=P84PqqJV7Es

3.5.2. No. 1: Define the project objective in less than 10 words

3.5.2.1. You must start with the end in mind

3.5.2.2. You need to know exactly where you are going

3.5.2.3. The business case is your best friend

3.5.2.4. This will take you a long time to do

3.5.2.5. It will help you to kill a project going nowhere

3.5.2.6. The scope of the project will map on to this.

3.5.2.7. TIP

3.5.2.7.1. Can you write the project objective on a Post-it note with a flip chart marker?

3.5.3. No. 2: Build a team with those who say ‘can’

3.5.3.1. A lot of being agile is about options

3.5.3.2. If you get the right people you are half way there

3.5.3.3. Choose the right person above the right skill set

3.5.3.4. “If you think you can’t, you’re right” – Carol Bartz

3.5.3.5. You need collaboration and team spirit.

3.5.3.6. TIP

3.5.3.6.1. Ask a team member this question: Can I ask a favour?

3.5.4. No. 3: Go slow early to go fast later

3.5.4.1. This is counter intuitive

3.5.4.2. How much ‘DUF’ is enough? Answer EDUF!

3.5.4.3. Build from firm foundations

3.5.4.4. You must avoid analysis paralysis

3.5.4.5. Try and spot early solutioneering.

3.5.4.6. TIP

3.5.4.6.1. Ask yourself: Is it safe to move on?

3.5.5. No. 4: Look backwards to go forwards

3.5.5.1. Learn your lessons – both good and bad

3.5.5.2. Evolve the process – it has to evolve

3.5.5.3. If it doesn’t work – do something else!

3.5.5.4. Try this! - Review, Plan, Do

3.5.5.5. Share your experiences with other teams.

3.5.5.6. TIP

3.5.5.6.1. Ask yourself: How many of your projects have ended with a project review?

3.5.6. No. 5: Change is great!

3.5.6.1. You need to anticipate change and embrace it

3.5.6.2. This allows a more accurate solution to result

3.5.6.3. Do not confuse the breadth of the scope with the depth

3.5.6.4. Evolve and converge on the solution with the right kind of change.

3.5.6.5. TIP

3.5.6.5.1. How do you feel when a customer says “I’ve changed my mind”?

3.5.7. No. 6: To be understood, seek first to understand.

3.5.7.1. Command and control may not work with Agile

3.5.7.2. Facilitation is a core competency

3.5.7.3. Big ears, big eyes, small mouth

3.5.7.4. You have to play with the cards you are dealt

3.5.7.5. This will give you ownership.

3.5.7.6. TIP

3.5.7.6.1. Try the 10 second silence when getting a progress update - nothing else can compete with it!

3.5.8. No. 7: Collect Actuals – this is the oxygen for your project

3.5.8.1. ‘You cannot control what you cannot measure’ – Tom de Marco

3.5.8.2. Meten is weten – to measure is to know

3.5.8.3. Start now – build a metrics database

3.5.8.4. Keep it simple to start with

3.5.8.5. Calibrate your estimates.

3.5.8.6. TIP

3.5.8.6.1. Do you know (to the nearest day) how much time was spent on testing during your last project?

3.5.9. No. 8: Use fat communication channels

3.5.9.1. Shift the communication traffic to bigger pipes

3.5.9.2. The written word is a silent killer

3.5.9.3. Go visual

3.5.9.4. Use workshops.

3.5.9.5. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)

3.5.9.6. TIP

3.5.9.6.1. Try turning a document over and take a look at what is on the back

3.5.10. No. 9: Work hard at controlling what you can’t control

3.5.10.1. Continuously manage external risks

3.5.10.2. You may get your team right but what about 3rd parties?

3.5.10.3. Are they playing by the same rules as you?

3.5.10.4. Get the team involved

3.5.10.5. Be ‘a bit of a worrier’.

3.5.10.6. TIP

3.5.10.6.1. Actively manage your risk log – it is not a storage area

3.5.11. No. 10: One more day? NO! We’ll catch up? NO!

3.5.11.1. Time focus is your greatest weapon

3.5.11.2. Force the issue – understand your condition

3.5.11.3. Timeboxes not milestones

3.5.11.4. If you are going to fail – fail early

3.5.11.5. Prioritise with MoSCoW – it should be natural.

3.5.11.6. TIP

3.5.11.6.1. Set a deadline and hit it - never extend it, not even once!

3.6. 1. Koncentruj się na potrzebie biznesowej (ang. Focus on the business need)

3.6.1. Gwarantowany Minimalny Użyteczny Podzbiór

3.6.2. Ustanownie Uzasadnienia Biznesowego

3.6.3. Poszukiwanie ciągłego zaangażowania i biznesu i finanoswania projektu

3.6.4. Zrozumieć priorytety biznesowe

3.6.5. Każda decyzja podjęta w trakcie realizacji projektu musi być rozpatrywana w świetle nadrzędnego celu projektu.

3.6.6. Projekt jest środkiem do celu, a nie celem sam w sobie.

3.6.7. Dostarczanie tego, co wymaga organizacja oraz w terminie jaki wymaga organizacja. Priorytety biznesowe muszą być rozumiane i określone w ustalonym Uzasadnieniu Biznesowym.

3.7. 2. Dostarczaj na czas (ang. Deliver on time)

3.7.1. Zawsze na czas

3.7.2. Skupić się na priorytetach biznesowych

3.7.3. Dziel pracę na łatwo zarządzalne cześci

3.7.4. Okienka czasu są planowane z wyprzedzeniem oraz zakres czasowy Okienek Czasu jest ustalony. Daty nie podlegają zmianom, natomiast dostarczone cechy / funkcjonalności tak - są zależne od priorytetów biznesowych tak, aby zmieścić się w ustalonych terminach.

3.8. 3. Współpracuj (ang. Collaborate)

3.8.1. Encourages increased understanding, greater speed & shared ownership

3.8.2. Involve right stakeholders at the right time

3.8.3. Ensure team members are empowered to make decisions

3.8.4. Actively involve business

3.8.5. Build a one team culture

3.8.6. Atern Business Visionary, Business Ambassador and Business Advisor roles bring appropriate subject matter experts into project to contribute to solution

3.8.7. Business analyst is responsible for facilitating high level collaboration between team members

3.8.8. Facilitated workshops enable stakeholders to share knowledge with the project team

3.8.9. Involve the right stakeholders, at the right time, throughout the project.

3.8.10. Ensure that the members of the team are empowered to take decisions on behalf of those they represent.

3.8.11. The risk of building the wrong solution is greatly reduced.

3.8.12. The final solution is more likely to meet the users' real business requirements.

3.8.13. Deployment is more likely to go smoothly, because of the co-operation of all parties concerned throughout development.

3.8.14. Teams work in a spirit of active co-operation and commitment. Collaboration encourages understanding, speed and shared ownership. The teams must be empowered and include the business representatives.

3.8.15. People want to be part of something.

3.9. 4. Nigdy nie idź na kompromis w kwestii jakości (ang. Never compromise quality)

3.9.1. Level of quality is agreed at the start.

3.9.2. A solution has to be “good enough”.

3.9.3. Projects must test early and continuously and review constantly.

3.9.4. Fail fast.

3.9.5. If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable

3.9.5.1. Ensure quality does not become a variable

3.9.5.2. Design, document and test appropriately

3.9.5.3. Build in quality by constant reviews

3.9.5.4. Test early & continuously

3.9.5.5. MoSCoW & timeboxing ensure testing is appropriate, without introducing unnecessary risks

3.10. 5. Buduj przyrostowo na solidnych podstawach (ang. Build incrementally from firm foundation)

3.10.1. EDUF (Enough design Up Front)

3.10.2. Incremental delivery

3.10.3. Increments deployed into operational use for early ROI

3.10.4. Strive for early delivery of business benefit where possible.

3.10.5. Continually confirm the correct solution is being built.

3.10.6. Formally re-assess priorities and ongoing project viability with each delivered increment.

3.10.7. Implement this principle using Atern lifecycle

3.10.8. Increments allow the business to take advantage of work before the final product is complete, encouraging stakeholder confidence and feedback. This is based on doing just enough upfront analysis to proceed and accepting that detail emerges later.

3.11. 6. Wytwarzaj Iteracyjnie (ang. Develop iteratively)

3.11.1. Do enough design up front (EDUF) to create strong foundations.

3.11.2. Accept that work is not always right first time. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.

3.11.3. Iterative approach on all projects

3.11.4. Build customer feedback into each iteration.

3.11.5. Accept most detail emerges later rather than sooner.

3.11.5.1. Often end user does now what then need and think they know what they want!

3.11.6. Embrace change, the right solution will not emerge without it.

3.11.7. Be creative, experiment, innovate, test, learn, evolve.

3.11.8. Previous steps can be revisited as part of its iterative approach.

3.12. 7. Komunikuj się ciągle i jasno (ang. Communicate continuously and clearly)

3.12.1. Run daily stand-ups

3.12.1.1. Same like Daily Scrum Meetings in Scrum framework. Agile daily team stand-up session are exactly the same.

3.12.2. Use facilitated workshops, daily stand-ups, modeling, prototyping, presentations and encourage informal face-to-face communication.

3.12.3. Use rich communication techniques such as modelling, prototyping, wireframing.

3.12.4. Present instances of the evolving solution early and often.

3.12.5. Keep documentation lean and timely.

3.12.6. Manage stakeholder expectations throughout the project.

3.12.7. Conversation, Collaboration, Community.

3.12.8. Encourage informal face to face communication at all levels

3.13. 8. Demonstruj kontrolę (ang. Demonstrate control)

3.13.1. The team needs to be proactive when monitoring and controlling progress in line with Foundations Phase. They need to constantly evaluate the project viability based on the business objectives.

3.13.2. Use an appropriate level of formality for tracking and reporting.

3.13.3. Make plans and progress visible to all.

3.13.3.1. Even to low level team members.

3.13.4. Measure progress through focus on delivery of products rather than completed activities.

3.13.5. Manage pro-actively

3.13.6. Evaluate continuing project viability based on the business objectives.

4. AgilePM® Filozofia (1)

4.1. The AgilePM® Philosophy is that any project must be adopted and adapted or simply aligned to clearly defined strategic goals

4.2. 6P Model

4.2.1. Philosophy

4.2.2. Prionciples

4.2.3. Process

4.2.4. People

4.2.5. Products

4.2.6. Practices

4.3. Best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate in order to deliver the right solution

4.4. Philosophy is achieved when all stakeholders

4.4.1. Understands and buy into the business vision and objectives

4.4.2. Are empowered to make decisions within their area of expertise

4.4.3. Collaborate to deliver a fit for purpose business solution

4.4.4. Collaborate to deliver to agreed timescales in accorddance with business priorities

4.4.5. Accept that change is inevitable as the understanding of the solution grows over time

4.5. The 8 principles are themself supported by people, Agile process, clearly defined products and recommended practices

4.6. The AgilePM® philosophy is supported by a set of 8 principles that build the mindset and behaviours necessary to bring the philosophy alive

4.7. Project Approach Questionnaire (PAQ)

4.7.1. AgilePM® provides a simple questionnaire - the Project Approach Questionnaire (PAQ)

4.7.1.1. PAQ helps to identify and confirm the level of achievement of all the above factors and to assess potential risk areas to be addressed

4.7.2. PAQ is completed during Feasibility phase and re-assessed as part of Foundations phase

4.7.3. PAQ is original document form DSDM® method

4.7.4. PAQ is based on Instrumental Critical Success Factors (ICSFs), AgilePM® Principles and other situational factors

4.8. Pobierz: AgilePM® Project Approach Questionnaire (PAQ) (XLS)

5. AgilePM® Role i odpowiedzialności (13)

5.1. Wprowadzenie

5.1.1. Project-level roles are the directors, managers and co-ordinators of the project work. They will either be on or directly report to any project board or steering committee.

5.1.2. The Business Visionary and the Technical Co-ordinator hold the customer and supplier visions of solution excellence.

5.1.3. The Project Manager ensures that the funding supplied is used effectively to create the envisaged solution.

5.1.4. Make a clear link between life cycle phases and the AgilePM® products

5.1.5. The Development roles are

5.1.5.1. Team Leader, Business Ambassador, Business Analyst, Solution Developer and Solution Tester.

5.1.5.2. Jointly these roles form the engine room of the project.

5.1.6. The Development roles shape and build the solution, are collectively responsible for its day-to-day development and for assuring its fitness for business purpose.

5.1.7. There may be one or more SDT: the membership of each team should be stable and cover all the responsibilities defined for the Development roles.

5.1.8. The other roles (Business Advisors, Workshop Facilitator and DSDM / Atern Coach) provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

5.1.9. The project may also bring in subject matter experts as necessary for their specialist expertise.

5.1.9.1. Called in AgilePM® - Specialist roles.

5.2. Role projektowe

5.2.1. Koordynator Techniczny (KT) (ang. Technical Coordinator)

5.2.1.1. Techniczna władza projektowa w projekcie

5.2.1.2. Techniczna władza projektowania architektury

5.2.1.3. Ensures technical consistency and coherence across SDTs

5.2.1.4. Ensures adherence to agreed standards

5.2.1.5. The “glue” that holds the project together for technology and innovation

5.2.1.6. Equivalent to the Business Visionary, ensuring the solution is technically sound and cohesive

5.2.1.7. Odpowiedzialności

5.2.1.7.1. Agreeing and controlling the technical architecture

5.2.1.7.2. Determining the technical environments

5.2.1.7.3. Advising on and co-ordinating each team's technical activities

5.2.1.7.4. Identifying and owning architectural and other technically based risk, escalating to the Project Manager as appropriate

5.2.1.7.5. Ensuring the non-functional requirements (NFRs) are achievable and subsequently met

5.2.1.7.6. Ensuring adherence to appropriate standards or best practice

5.2.1.7.7. Controlling the technical configuration of the solution

5.2.1.7.8. Managing technical aspects of the transition of the solution into live use

5.2.1.7.9. Resolving technical differences between technical team members

5.2.2. Kierownik Projektu (KP) (ang. Project Manager)

5.2.2.1. Koncentracja na dostarczaniu

5.2.2.2. Zapewnia wysoko poziomowe ukierunkowanie dla ZRR

5.2.2.2.1. Dla wielu zespołów ZRR naraz, jeśli zespół projektowy jest podzielony na kilka zespołów ZRR

5.2.2.3. Dobre umiejętności komunikacyjne, planowania, zarządzania i umiejętności koordynacji prac dla kilku zespołów

5.2.2.4. Kierownik Projektu to rola - niekoniecznie osoboa posiadającą tę rola musi być zatrudniowa w organizacji jako Kierownik Projektów

5.2.2.5. W małych projektach AgilePM® rolę Kierownika Projektu może pełnić Lider Zespołu

5.2.2.6. Zwykle jest tylko jeden Kierownik Projektu lub co najmniej jedna osoba jest ostatecznie odpowiedzialna za dostarczenie projektu

5.2.2.6.1. Co oznacza, że ta rola może być łączona (np. Kierownik Projektu od strony dostawcy i od strony klienta)

5.2.2.7. Odpowiedzialności

5.2.2.7.1. Communicating with senior management and the project governance authorities (Business Sponsor, project board, steering committee, etc.) with the frequency and formality that they deem necessary

5.2.2.7.2. Wysoko poziomowe planowania projektu i harmonogramowanie, ale nie szczegółowe planowanie zadań

5.2.2.7.3. Monitorowanie postępów w realizacji zatwierdzonych planów projektu

5.2.2.7.4. Zarządzanie ryzykiem i zagadnieniami projektowymi, eskalacja do starszych ról biznesowych lub technicznych w razie potrzeby

5.2.2.7.5. Zarządzanie ogólną konfigurację projektu

5.2.2.7.6. Motywowania Zespołów Rozwoju Rozwiązania (ZRR) do realizacji ich celów

5.2.2.7.7. Zarządzanie zaangażowanie biznesu w ramach Zespołów Rozwoju Rozwiązania (ZRR)

5.2.2.7.8. Pozyskiwania ról Specialistów w ramach potrzeby

5.2.2.7.9. Obsługa problemów eskalowanych od Zespołów Rozwoju Rozwiązania (ZRR)

5.2.2.7.10. Coaching Zespołów Rozwoju Rozwiązania (ZRR) w trundych sytuacjach

5.2.3. Wizjoner Biznesu (WB) (ang. Business Visionary)

5.2.3.1. Starsza rola biznesowa na poziomie projektu

5.2.3.2. Dostarsza szerokiego, całościowego spojrzenia na projekt z perspektywy biznesowej

5.2.3.3. Zaangażowany w większym stopniu w projekt niż Sponsor Biznesowy

5.2.3.4. Odpowiedzialny za interpretowanie potrzeb Sponsora Biznesowego, komunikowanie ich zespołom oraz w razie potrzeby zapewnienie, że są one prawidłowo reprezentowane w Uzasadnieniu Biznesowym

5.2.3.5. Jeśli projekt jest częścią większego programu, Wizjoner jest w stanie ocenić problemy projektowe w świetle programu i potencjalnych skutków poza projektem

5.2.3.6. Pozostaje zaangażowany w projekt przez cały okres trwania projektu

5.2.3.7. Oferuje zespołom strategiczne ukierunkowanie

5.2.3.8. Zapewnienie, że dostarczane rozwiązanie pozwoli uzyskać korzyści opisane w Uzasadnieniu Biznesowym

5.2.3.9. Odpowiedzialności

5.2.3.9.1. Definiuje wizję biznesową dla projektu

5.2.3.9.2. Komunikowanie i promowanie wizji biznesowej dla wszystkich zainteresowanych stron

5.2.3.9.3. Monitorowanie postępów w realizacji projektu, zgodnie z wizją firmy

5.2.3.9.4. Jest odpowiedzialny za szersze implikacje jakichkolwiek zmian biznesowych z organizacyjnego punktu widzenia

5.2.3.9.5. Przyczynianie się do określania kluczowych wymagań, projektowania i sesji przeglądów (w ramach Okinek Czasu), szczególnie tam, gdzie aspekty rozwiązania adresują kluczowe elementy wizji biznesowej

5.2.3.9.6. Zatwierdzanie zmian w wymaganiach wysoko poziomowych w Liście Wymagań Urzegregowanej Według Priorytetów (ang. PRL)

5.2.3.9.7. Zapewnienie współpracy z różnymi obszarami interesariuszy biznesowych

5.2.3.9.8. W razie potrzeby zapewnienie dostępnośći zasobów biznesowych

5.2.3.9.9. Promowanie i tłumaczenie wizji biznesowej na codzienne praktyki pracy

5.2.3.9.10. Uczestnictwo jako końcowy arbiter w sytuacjach sprzecznych między członkami zespołów

5.2.4. Sponsor Biznesowy (SB) (ang. Business Sponsor)

5.2.4.1. Champion projektu.

5.2.4.2. Najbardziej uprzywilejowana rola biznesu na poziomie projektu.

5.2.4.3. Zapewnia ogólny kierunek strategiczny i finansowanie.

5.2.4.4. Posiadają wystarczająco wysoką pozycję w organizacji, aby być w stanie rozwiązać zagadnienia biznesowe i podejmować decyzje finansowe.

5.2.4.5. Odgrywa kluczową odpowiedzialność za zapewnienie i umożliwiienie szybkich postępów w całym projekcie.

5.2.4.6. Nie jest zalecane, aby rola była współdzielona.

5.2.4.7. Główną troską są wartości i korzyści projektu, a nie szczegóły techniczne

5.2.4.8. Odpowiedzialności

5.2.4.8.1. Jest właścicielem Uzasadnienia Biznesowego

5.2.4.8.2. Zapewnia bieżącą rentowności projektu zgodnie z Uzasanieniem Biznesowym.

5.2.4.8.3. Zapewnia, że fundusze i inne środki są dostępne w razie potrzeby.

5.2.4.8.4. Zapewnia, żę proces decyzyjny dla eskalowanych problemów zagadnień jest skutecznie i szybko przeprowadzany.

5.2.4.8.5. Szybka reakcja dla eskalowanych zagadnień.

5.3. Zespół Rozwoju Rozwiązania (ZRR) (ang. Solution Development Team, SDT). Projekt może psiadać kilka zespółów ZRR.

5.3.1. The SDT on an AgilePM® project is empowered to make decisions on a day-to-day basis within their agreed terms of reference.

5.3.1.1. They do not have to formally agree each and every decision with the PM.

5.3.2. Lider Zespołu (ang. Team Leader)

5.3.2.1. Leadership rather than management.

5.3.2.2. Person holding it will ideally be elected by his or her peers as the best person to lead.

5.3.2.3. Reporting to the PM.

5.3.2.4. Ensures that a SDT functions as a whole and meets its objectives.

5.3.2.5. Works with the team to plan and co-ordinate all aspects of product delivery at the detailed level.

5.3.3. Ambasador Biznesowy (ang. Business Ambasador)

5.3.3.1. A true “ambassador”.

5.3.3.2. Business role within the SDT.

5.3.3.3. Working closely with the rest of the SDT.

5.3.3.4. Responsible for the day-to-day communication between the project and the business.

5.3.3.5. Guides the evolution of the solution.

5.3.3.6. Generally comes from the business area being addressed.

5.3.3.7. Provides business-related information from the perspective of those who will ultimately make direct use of the solution.

5.3.3.8. Provides the business perspective for all decisions related to the way the solution's fitness for business purpose is defined and implemented.

5.3.3.9. Stress key nature of this role.

5.3.3.10. These are typically very busy people who the business struggle to spare.

5.3.4. Doradca Biznesowy (ang. Business Advisor)

5.3.4.1. Often a peer of the Business Ambassador.

5.3.4.2. Called upon to provide specific, and often, specialist input to solution development or solution testing.

5.3.4.3. Often user or beneficiary of the solution.

5.3.4.4. May, for example, simply provide legal or regulatory advice with which the solution must comply.

5.3.5. Analityk Biznesowy (ang. Business Analyst)

5.3.5.1. Fully integrated with SDT.

5.3.5.2. Focuses on the relationship between the business and technical roles

5.3.5.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.

5.3.5.4. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.

5.3.6. Twórca Rozwiązania (ang. Solution Developer)

5.3.6.1. Interprets business requirements and translates them into a deployable solution that meets functional and non-functional needs.

5.3.6.2. Should ideally be allocated full time to the project.

5.3.6.3. Where they are not full time, the project ought to be their first priority - if this cannot be achieved, significant risk is introduced with regard to timeboxing.

5.3.6.4. AgilePM states that ideally we are looking for true Analyst/Programmers

5.3.6.4.1. Soft skills cannot be underestimated - especially communication, negotiation, selling, listening etc.

5.3.7. Tester Rozwiązania (ang. Solution Tester)

5.3.7.1. Fully integrated with the SDT.

5.3.7.2. Performs testing in accordance with the Technical Testing Strategy.

5.3.7.3. Ensure quality solution.

5.3.7.4. Independence of testing is key

5.3.7.5. Typically the Solution Tester reports to the TC in terms of test results and quality. rather than to the Team Leader.

5.3.8. Doradca Techniczny (ang. Technical Advisor)

5.3.8.1. Technical equivalent of a Business Advisor.

5.3.8.2. Supports SDT.

5.3.8.3. Provides specific and often specialist technical input and advice.

5.3.8.4. could be in real life for example ...

5.3.8.4.1. IT Security Expert

5.3.8.4.2. IT Security Consultatant

5.3.8.4.3. Risk Manager (from organization)

5.3.8.4.4. Support

5.4. Pozostałe / Wspierające role

5.4.1. Facylitator Warszatów (ang. Workshop Facilitator)

5.4.1.1. Independent from project team and client.

5.4.1.1.1. Independent of workshop outcome.

5.4.1.2. Managing the workshop process.

5.4.1.3. Responsible for the context of the workshop, not the content.

5.4.1.4. Catalyst for preparation and communication.

5.4.2. Coach DSDM (ang. DSDM / Atern Coach)

5.4.2.1. Key to helping a team with limited experience of using AgilePM® to get the most out of the approach within the context of the wider organisation in which they work.

5.4.2.2. Should ideally be independently to ensure competence to fulfil this role.

5.4.3. Specjaliści / Eksperci (ang. Specialist roles), nie widoczne na diagramie

5.4.3.1. The SDT roles will not always cover every skill needed in a project.

5.4.3.2. Specialist roles may also need to be involved and brought into the AgilePM® project (not only Solution Development Team) on an ad-hoc basis by the PM or TL to fulfil specific functions.

5.4.3.3. Project level

5.4.3.3.1. Possible to have Specialist roles at the Project level.

5.4.3.3.2. Is less likely to be ad-hoc and would more commonly be throughout the project.

5.4.3.3.3. Common example of a Project level specialist role would be an Operations Co-ordinator.

5.4.3.4. Solution Development Team level

5.4.3.4.1. Need to be properly integrated into the project team as appropriate.

5.4.3.4.2. Required specialist input to the SDT should be formally planned.

5.4.3.4.3. Individuals identified and their availability checked so that they can attend relevant meetings, facilitated workshops, etc

6. AgilePM® Produkty (17 główynch, 53 wszystkich) (precyzując Produkty Zarządcze, upraszczając dokumentacja)

6.1. Wprowadzenie

6.1.1. AgilePM® identifies deliverables associated with each phase of the lifecycle. These are referred to as Products.

6.1.2. Not all products are required for every project.

6.1.2.1. Enables the product set for a particular project to be kept to a minimum.

6.1.3. Formality associated with each product will vary from project to project and from organisation to organisation.

6.1.3.1. aka. 'Adopt and Adapt' principle.

6.1.4. Some products are specific to a particular phase in the lifecycle, others may continue to evolve through subsequent phases. (see diagram)

6.1.5. Formal products definitions specifies:

6.1.5.1. When the product is produced, used, updated and archived. This gives a clear view of the transience of a given product and therefore enables appropriate levels of quality control to be applied.

6.1.5.2. The roles that could be responsible for producing, contributing to, accepting and approving the product.

6.1.5.2.1. These are only suggestions but give an indication of what product responsibilities could be allocated to the people in each role.

6.1.5.3. The product's Quality Criteria, i.e. the set of questions that should be answered positively if the product has fulfilled its purpose satisfactorily.

6.2. Legenda

6.2.1. Ikonka

6.2.1.1. Oznacza, że wybrane produkty są produktami kontrolnymi, które mogą być użyte do podjęcia decyzji TAK/ NIE czy należy kontywuować projekt (tzw. bramki decyzyjne)

6.2.2. Pomarańczowy

6.2.2.1. Produkty skupiające się na binesie / korzyściach

6.2.3. Niebieski

6.2.3.1. Produkty skupiające się na zarządzaniu

6.2.4. Zielony

6.2.4.1. Produkty skupiające się na rozwiązaniu

6.3. Faza Przedprojektowa

6.3.1. Warunki Referencyjne (ang. Terms of Reference, ToR)

6.3.1.1. High-level definition of the business driver.

6.3.1.2. Scope and justification of Feasibility phase.

6.3.1.3. Very short document (one two sides maximum).

6.3.1.3.1. Can be less formal - email, verbal agreement.

6.3.1.4. Sugerowana zawartość

6.3.1.4.1. A brief outline of the business need and the objectives and scope for the project to meet that need.

6.3.1.5. Rekomendowane odpowiedzialności

6.3.1.5.1. Tworzy

6.3.1.5.2. Zatwierdza

6.3.1.5.3. Konsultowany

6.3.1.5.4. Akceptuje

6.4. Faza Oceny Wykonalności (ang. Feasibility Assessment)

6.4.1. Studium Wykonalności (ang. Feasibility Assessment)

6.4.1.1. High-level overview of the project.

6.4.1.2. Assessing the feasibility of the project both from a business and a technical perspective.

6.4.1.3. Addresses main risks, by providing a description and a mitigation strategy for any risks significant enough to influence the viability of the project.

6.4.1.4. Outline Business Case

6.4.1.4.1. At a very high level deals with the likely costs and benefits.

6.4.1.5. Sugerowana zawartość

6.4.1.5.1. The business vision of success.

6.4.1.5.2. The scope and objectives of the proposed project.

6.4.1.5.3. High-level assumptions, dependencies and risk that may impact project viability.

6.4.1.5.4. Any alternatives that were considered and rejected.

6.4.1.5.5. The major deliverables of the proposed project.

6.4.1.5.6. A high-level description of a solution to support the Business Case.

6.4.1.5.7. An initial identification of any technical constraints to which the solution must adhere.

6.4.1.5.8. (optional) A disposable 'candidate' of the solution (or key elements of it), demonstrating how it will eventually work and/or demonstrating the technical feasibility of its more risky or complex elements.

6.4.1.6. Rekomendowane odpowiedzialności

6.4.1.6.1. Tworzy

6.4.1.6.2. Zatwierdza

6.4.1.6.3. Konsultowany

6.4.1.6.4. Akceptuje

6.4.2. Zarys Planu (ang. Outline Plan)

6.4.2.1. Overview of the project from a Project Management and Solution Delivery perspective.

6.4.2.2. Analyses the responses to the incorporated Project Approach Questionnaire (PAQ)

6.4.2.3. Povides a detailed plan for the work of the Foundations phase.

6.4.2.4. Sugerowana zawartość

6.4.2.4.1. An overview of the likely project approach based on the responses to the Project Approach Questionnaire

6.4.2.4.2. A likely profile of resources required to work on the project

6.4.2.4.3. A description of the facilities and tools required to support the Iterative Development process

6.4.2.4.4. The organisation structure and processes required for project governance

6.4.2.4.5. An analysis of Risk and Issues impacting on the feasibility of the project (considering both development and deployment of the proposed solution)

6.4.2.4.6. An outline schedule for the project overall - with top level milestones related to delivery and deployment of the solution

6.4.2.4.7. A detailed plan for the Foundations phase of the project, clearly stating the scope and objectives of the work to be completed, the resources required a delivery schedule and an analysis of risk associated with the successful completion of the phase

6.4.2.4.8. Project Approach Questionnaire (PAQ)

6.4.2.5. Rekomendowane odpowiedzialności

6.4.2.5.1. Tworzy

6.4.2.5.2. Zatwierdza

6.4.2.5.3. Konsultowany

6.4.2.5.4. Akceptuje

6.5. Faza Określenia Podstaw (ang. Foundations phase)

6.5.1. Podstawy Biznesowe (ang. Business Foundations)

6.5.1.1. Evolution of the Business Vision from the Feasibility Assessment

6.5.1.2. Provides information for and / or about the business that is fundamental to the success of the project and that

6.5.1.3. Needs to be understood by all project stakeholders before development of the solution commences.

6.5.1.4. Sugerowana zawartość

6.5.1.4.1. The business, as it will be after the project has completed.

6.5.1.4.2. The big picture.

6.5.1.4.3. How that picture differs from the current reality.

6.5.1.4.4. How this project will contribute to the required change.

6.5.1.4.5. Any other projects, either planned or in progress, that form part of the vision or may have an impact on it.

6.5.2. (ang. Prioritised Requirements List (PRL))

6.5.2.1. Describes, at a high level, the requirements that the project needs to address if the Business Case is to be met

6.5.2.2. Baselined at a high level at the end of the Foundations phase

6.5.2.2.1. Refined for detail as the project proceeds through Exploration and Engineering reflecting changes to depth and detail drawn out by the Iterative Development process.

6.5.2.3. There is one PRL list for project.

6.5.2.4. Sugerowana zawartość

6.5.2.4.1. A list of high-level requirements to be addressed.

6.5.2.4.2. A business driven prioritisation of the requirements in accordance with the MoSCoW prioritisation process.

6.5.3. Podstawy Zarządzania (ang. Management Foundations)

6.5.3.1. Refinement of the Outline Plan from Feasibility

6.5.3.2. Introduction

6.5.3.2.1. The Management Foundations product describes essential governance and organisational aspects of the project and describes precisely how the project will be managed. It also describes how the Atern practices and techniques will be applied to ensure management of the project through to a successful conclusion.

6.5.3.2.2. Note: it is important that the Project Approach Questionnaire responses created in Feasibility are reviewed at this point and that any changes to responses are considered when defining how the project will be managed from here on.

6.5.3.3. Sugerowana zawartość

6.5.3.3.1. A validation of the Objectives and Success Criteria for the project

6.5.3.3.2. The project approach - based on analysis of the latest responses to the Project Approach Questionnaire and also including the processes required for governance and, where applicable, contact management

6.5.3.3.3. The project organisation, including roles and responsibilities, empowerment of teams and reporting lines and governance

6.5.3.3.4. Project Management controls for Monitoring and Reporting, Change Control and Risk Management

6.5.3.3.5. An overview of the key deliverables, milestones and incremental staging of product delivery

6.5.3.3.6. An analysis of major project dependencies

6.5.4. Plan Dostarczania (ang. Delivery Plan)

6.5.4.1. Introduction

6.5.4.1.1. The Delivery Plan refines and elaborates on the schedule described in the Outline Plan.

6.5.4.2. Sugerowana zawartość

6.5.4.2.1. The incremental nature of the project

6.5.4.2.2. The dates associated with the increments and other key milestones.

6.5.4.2.3. The dates for deployment of the solution and, where applicable, subsets of it

6.5.4.2.4. An indication of the focus of each Development Timebox

6.5.4.2.5. The timing and dependencies of any activities not planned within the Development Timeboxes

6.5.4.2.6. The allocation of resources to timeboxes and other activities

6.5.4.2.7. An identification of the contingency associated with one or more of the key constraints of time, resource/cost or, preferably, scope

6.5.5. Pakiet Kontrolny Dostarczania (ang. Delivery Control Pack)

6.5.5.1. Introduction

6.5.5.1.1. The Delivery Control Pack comprises reports, documents and logs related to the ongoing status of the project.

6.5.5.2. Sugerowana zawartość

6.5.5.2.1. Risk Log

6.5.5.2.2. Change Control Records

6.5.5.2.3. Periodic Reports

6.5.5.2.4. Other elements may be added

6.5.6. Podstawy Rozwiązania (ang. Solution Foundations)

6.5.6.1. Provides information for and/or about the solution that is fundamental to the success of the project.

6.5.6.2. Need to be understood by all internal project stakeholders before development of the solution commences.

6.5.6.3. Consists of 4 components

6.5.6.3.1. Solution Prototype (optional)

6.5.6.3.2. Business Area Definition (BAD)

6.5.6.3.3. System Architecture Definition (SAD)

6.5.6.3.4. Development Approach Definition (DAD)

6.5.6.3.5. aka. BAD SAD DAD :)

6.6. Fazy Eksploracji i Budowy (ang. Exploration and Engineering phases)

6.6.1. Plan Wdrożenia (ang. Deployment Plan)

6.6.1.1. Schedule of activities for the delivery of project products covering all aspects of Composition deployment of the solution from a business and a technical perspective

6.6.1.2. Introduction

6.6.1.2.1. Sometimes included as a subset of the Delivery Plan, the Deployment Plan is the detailed plan for the Deployment phase. Unlike the Timebox Plans used during development, the Deployment Plan tends to focus on specific tasks to be performed by specific individuals, rather than on products to be delivered by the Solution Development Team as a whole.

6.6.1.2.2. Generally speaking it is not possible to Timebox a deployment, as time and resource cannot sensibly be fixed in favour of flexible scope.

6.6.1.3. Benefits Realisation Plan

6.6.1.3.1. Introduction

6.6.1.3.2. Sugerowana zawartość

6.6.1.4. Recommeded content

6.6.1.4.1. The work to be completed

6.6.1.4.2. The dates associated with the key activities and milestones

6.6.1.4.3. The allocation of resources to all activities

6.6.1.4.4. An identification of the contingency associated with one or more of the key constraints of time, resource/cost or, preferably, scope

6.6.2. Plan Okienka Czasu (ang. Timebox Plan)

6.6.2.1. Introduction

6.6.2.1.1. The Timebox Plan elaborates on the objectives provided for each Development Timebox in the Delivery Plan.

6.6.2.2. Sugerowana zawartość

6.6.2.2.1. A definition of the product(s) of an individual Development Timebox

6.6.2.2.2. An identification of key milestones, e.g. technical or user review dates, within a timebox

6.6.2.2.3. An agreed MoSCoW prioritisation of products and activities within a Development Timebox

6.6.2.2.4. An identification of all the resources (human and otherwise) required for successful completion of all work

6.6.3. Zapis Przeglądu Okienka Czasu (ang. Timebox Review Record)

6.6.3.1. Introduction

6.6.3.1.1. The Timebox Review Record is produced/updated at the review points in the Development Timebox. They describe what has been achieved and any feedback which may influence plans moving forwards. After the timebox has completed any outstanding issues are considered in the context of the Delivery Plan and future Timebox Plans.

6.6.3.1.2. The formality of this record will vary from official, signed documents to informal notes or emails depending on the project and the organisation. However the information encompassed by the Timebox Review Record should always exist in some physical form.

6.6.3.2. Sugerowana zawartość

6.6.3.2.1. A record of the success of delivery, against the Timebox Plan, specifically describing what has been delivered and what has not.

6.6.3.2.2. A record of the formal acceptance of the completed deliverables by the business representatives identified to accept them.

6.6.3.2.3. An assessment of the priority of any work not completed and a plan to show whether and when it will be, either as part of the current timebox or at some point in the future.

6.6.3.2.4. An assessment of the effectiveness of the timebox control processes and the Iterative Development techniques in line with the principles of Atern.

6.6.4. Pakiet Zapewnienia Jakości Rozwiązania (ang. Solution Assurance Pack)

6.6.4.1. Consists of 3 components

6.6.4.1.1. Technical Testing Pack

6.6.4.1.2. Business Testing Pack

6.6.4.1.3. Solution Review Records

6.6.5. Rozwijane Rozwiązanie (ang. Evolving Solution)

6.6.5.1. Introduction

6.6.5.1.1. The precise nature and composition of the Evolving Solution is entirely dependent on the objectives of the project and the current position in the project timeline. At one extreme, at the beginning of a project it could be a preliminary sketch of a new business process on a flip chart. Towards the end of a project it may be a fully evolved and documented business process supported by a software application and all documentation to use, support and maintain it. It is simply a convenient term to describe a 'work in progress'.

6.6.5.1.2. Note: the Deployable Solution is a baseline of the Evolving Solution that is ready for deployment.

6.7. Faza Wdrożenia (ang. Deployment phase)

6.7.1. Raport z Przeglądu Projektu (ang. Project Review Report)

6.7.1.1. Increment Review (one or more)

6.7.1.1.1. Introduction

6.7.1.1.2. Sugerowana zawartość

6.7.1.2. Benefits Enablement Summary (one or more)

6.7.1.2.1. Introduction

6.7.1.2.2. Sugerowana zawartość

6.7.1.3. End of Project Assessment

6.7.1.3.1. Introduction

6.7.1.3.2. Sugerowana zawartość

6.7.2. Wdrożone Rozwiązanie (ang. Deployed Solution)

6.7.2.1. Introduction

6.7.2.1.1. The Deployed Solution is an instance of a Deployable Solution from the Engineering phase that is now in operation in the live business environment.

6.7.2.2. Sugerowana zawartość

6.7.2.2.1. Fully integrated and mutually consistent components of the final solution as well as any materials required to support it

6.8. Faza Poprojektowa (ang. Post Project phase)

6.8.1. Ocena Korzyści (ang. Benefits Assessment)

6.8.1.1. Introduction

6.8.1.1.1. The Benefits Assessment describes how the benefits have actually accrued, as the Deployed Solution has been used. For projects where benefits in the Business Case are expected to accrue over a prolonged period, it is likely that Benefits Assessments will be produced on a periodic basis.

6.8.1.2. Sugerowana zawartość

6.8.1.2.1. A quantitative description of how the benefits of using the Deployed Solution have been achieved.

6.8.1.2.2. An analysis of any discrepancies between what has been achieved and what was predicted in the Business Case for the project.

6.9. Podsumowanie oraz wnioski

6.9.1. AgilePM® is a product-based approach, projects use delivery of the appropriate products to demonstrate progress.

6.9.1.1. This is a more effective way than simple progress reports, since a product, whether a document, a model, a plan or an evolving solution, is a physical artefact that can be viewed, used, reviewed or tested.

7. Interaktywny glosariusz

7.1. Interaktywny glosariusz AgilePM® (PL)

8. Matoda AgilePM® składa się z: 1 Filozofii, 8 Pryncypiów, 9 Kluczowych Czynników Sukcesu, 7 Faz Cyklu Życia Projektu, 13 Ról projektowych, 17 głównych artefaktów/produktów zarządczych (upraszczając dokumentacja) i 53 całościowo oraz 7 Technik.

8.1. Pobierz: AgilePM® Matryca Fazy Projektowe vs Produkty Zarządcze vs Role vs Odpowiedzialności (PDF)

8.1.1. Pobierz: AgilePM® - Kwestionariusz Przeglądu Projektu (PHCQ) (XLSX)

8.2. Pobierz: Szablony dokumentów AgilePM® v0.1 ALPHA [DOCX, XLSX]

8.2.1. Pobierz: AgilePM® - Kwestionariusz Podejścia do Projektu (PAQ) (XLSX)

9. AgilePM® przykładowe cykle życia projektu (5 przykładów)

9.1. AgilePM® iterative and incremental framework is highly configurable.

9.2. An individual configuration will depend on the size and formality of the project being delivered.

9.3. The lifecycle provides scalability from small projects to large enterprise-wide programmes.

9.3.1. Governance is not lost in AgilePM®.

9.4. The project / programme characteristics must be taken into consideration in order to configure the optimum lifecycle for delivery of early business benefit and risk mitigation.

9.5. Example AgilePM® lifecycles, 4 separate projects, each with one Deployment phase.

9.5.1. Przykładowy projekt #1

9.5.1.1. 2 Okienka Czasu

9.5.1.2. 1 Wdrożenie

9.5.2. Przykładowy projekt #2

9.5.2.1. 4 Okienka Czasu

9.5.2.2. 1 Wdrożenie

9.5.3. Przykładowy projekt #3

9.5.3.1. 2 "dybrydowe" Okienka Czasu

9.5.3.2. 1 Wdrożenie

9.5.4. Przykładowy projekt #4

9.5.4.1. In this example 2 separate SDT teams are working separetly on two started parallel Timeboxes (one Timebox is type od Exploaration, second in engeenering).

9.5.4.1.1. 4 Okienka Czasu

9.5.4.1.2. 1 Wdrożenie

9.5.5. Przykładowy projekt #5

9.5.5.1. In this example 2 separate SDT teams are working separetly on two started parallel Timeboxes (one Timebox is type od Exploaration, second in engeenering).

9.5.5.1.1. 6 Timeboxes.

9.5.5.1.2. 2 Wdrożenia

9.5.5.2. Project has two separate Deployments in one project lifecycle.

10. Ta darmowa mapa (zgodna z najnowszą wersją metody AgilePM®) została pieczołowicie stworzona z pasji i zamiłowania do nauki oraz ciągłego rozwoju jak również w celu promocji metody AgilePM®. Mam nadzieje, że ta mapa pomoże Ci również w nauce do egzaminów Foundation i Practitioner z metody AgilePM®. (podziel się tą mapą z innymi, polub i przekazaż informacje zwrotne - Twoja opinie, komentarze i sugestie są moją motywacją do dalszego jej rozwmoju THX.!)

10.1. Pytania / wątpliwość / błędy? Zapraszam do kontaktu. Mapa powstała jako pomoc w Twojej nauce. Każda uwaga jest cenna :-), Mirosław Dąbrowski.

10.1.1. http://www.linkedin.com/in/miroslawdabrowski

10.1.2. https://www.google.com/+MiroslawDabrowski

10.1.3. https://play.spotify.com/user/miroslawdabrowski/

10.1.4. http://www.miroslawdabrowski.com

10.1.5. https://twitter.com/mirodabrowski

10.1.6. miroslaw_dabrowski

11. Oprogramowanie do zarządzania projektami Agile

11.1. oprogramowanie do 'ogólnego' zwinnego zarządzania

11.1.1. SkyTap

11.1.1.1. http://www.skytap.com/

11.1.2. VersionONE

11.1.2.1. http://www.versionone.com/

11.1.3. Atlassian

11.1.3.1. https://www.atlassian.com/

11.1.4. Rally Software

11.1.4.1. http://www.rallydev.com/

11.1.5. Microsoft Team Foundation Server

11.1.6. Electric Cloud

11.1.6.1. http://www.electric-cloud.com/

11.1.7. Scaled Agile Framework

11.1.7.1. http://scaledagileframework.com/

11.2. oprogramowanie zgodne z AgilePM®

11.2.1. PROJECT in a BOX

11.2.1.1. http://www.projectinabox.org.uk/

12. AgilePM® rekomendowane techniki (7)

13. Kluczowe Czynniki Sukcesu projektów AgilePM® (9)

13.1. 9 Instrumental Critical Success Factors (ICSF)

13.1.1. 1. Acceptance of the AgilePM® philosophy before starting work

13.1.1.1. Includes the concept that in order to deliver the right thing at the right time and handle change dynamically may result in delivering less than 100% of the possible solution - this needs to be agreed by all parties.

13.1.1.2. Accepting new philosophy in a new organisation may be difficult - piloting the philosophy (perhaps on a less critical initiative) first helps to win acceptance.

13.1.1.3. All stakeholders must be prepared to accept that change is inevitable.

13.1.1.3.1. Change will calibrate project course on 'true' Value.

13.1.1.3.2. It is important that the Business Sponsor and senior management understand and accept the AgilePM Philosophy.

13.1.2. 2. Appropriate empowerment of the Solution Development Team (SDT).

13.1.2.1. The senior business management must agree to delegate an appropriate level of decision-making to the Business Ambassador(s) in the SDT or to take that role themselves. (WHAT)

13.1.2.1.1. Similarly, the Solution Developers in the team should also be empowered to make appropriate technical decisions. (HOW)

13.1.2.2. If this is not possible, they would need to participate in the team themselves (i.e. in this circumstance, the Business Ambassador role may need to be taken by a more senior person from the Business).

13.1.2.3. Without business empowerment, team progress will slow down while awaiting decisions being made elsewhere and to a different timeframe.

13.1.2.4. The Business Ambassador(s) should be empowered to make decisions without referral to higher authorities outside the team.

13.1.2.5. Solution Developers in the SDT should also be empowered to make decisions.

13.1.2.5.1. It is important that the concept of empowerment does not give all SDT members complete freedom to do whatever they want, whenever they want. In reality, empowerment is within agreed boundaries of decision-making.

13.1.2.6. Where a decision is outside the agreed boundaries, this would still need to be formally escalated.

13.1.2.7. However, this is the exception and the majority of day-to-day decision-making should be within the remit of the SDT.

13.1.2.8. Empowerment is two-way - it is not enough to tell people new to AgilePM® that they are empowered -they may need constant reinforcement and coaxing to make their own decisions - the daily stand up will show whether there are risks here.

13.1.3. 3. Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement

13.1.3.1. The level of business commitment for this project should be quantified and discussed in the early stages.

13.1.4. 4. Incremental delivery

13.1.4.1. To achieve an early return on investment, the organisation needs to be amenable to the incremental delivery of solutions.

13.1.4.2. Another benefit of the incremental approach is a reduction in risk (compared with the big-bang, large drop of a 100% final solution).

13.1.4.3. Delivering a partial solution allows the business to take on the solution in manageable chunks and also ensures the solution builds on previous increments, i.e. building from a position of confidence.

13.1.4.4. It is still possible to gain all the project-focused benefits of incremental delivery even if the business chooses not to deploy the solution incrementally: for example building and, potentially, accepting the solution incrementally, ahead of a single production release.

13.1.4.5. All stakeholders must be prepared to deliver a fit-for-purpose solution.

13.1.4.5.1. Not 'all of nothing' solution.

13.1.5. 5. Access by the Solution Development Team (SDT) to business roles

13.1.5.1. The best communication occurs if the SDT - including the Business Ambassador - are collocated in their own dedicated environment, free from daily interruptions.

13.1.5.2. Collocation is recommended.

13.1.5.2.1. Even if co-location is not possible, it is often useful to have a room where everyone can come together from time to time. This gives a focus for the project.

13.1.5.3. Developers are in a different time zone from the Business Ambassador(s), there will be periods where it is not possible just to pick up the phone and this potential delay presents a risk to the AgilePM® approach which needs to be addressed.

13.1.6. 6. Solution Development Team (SDT) stability

13.1.6.1. The overlapping development skills required (i.e. business and technical knowledge in use concurrently throughout the Iterative Development process), the speed of development together with AgilePM®'s emphasis on rich communication at the SDT level, rather than communication driven primarily through documents, means that an AgilePM® project will be put at serious risk if staff are swapped in and out. Specialists may be called in as long as the core team remains stable.

13.1.7. 7. Solution Development Team (SDT) skills

13.1.7.1. Progress is significantly enhanced when the SDTs contains skilled people, both in terms of business knowledge and technical expertise.

13.1.7.1.1. Cross-functional team members.

13.1.7.2. This does not mean that every team member needs to be a multi-skilled expert.

13.1.7.3. All team members must have good communication skills if a team with diverse skills is to function as a coherent unit.

13.1.8. 8. Solution Development Team (SDT) size

13.1.8.1. For this to be effective, AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead..

13.1.8.1.1. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"

13.1.8.2. Bigger or smaller SDTs of course are possible but they can introduce risks

13.1.8.2.1. team is very small (3/4 people)

13.1.8.2.2. team is 9+

13.1.8.3. Where the SDT size is going to be greater than 9, splitting into a number of smaller teams may be a better option, although this in itself will introduce an overhead to manage the various teams.

13.1.8.3.1. Larger teams (SDTs) can be subdivided into smaller teams if the products can be split accordingly.

13.1.9. 9. Supportive commercial relationship

13.1.9.1. Where the supplier and the customer are from different organisations and development is covered by formal contract or where Solution Developers are from the same organisation but working within a service level agreement, the relationship must accommodate the evolution of the solution's requirements without imposing onerous change management overheads.

13.2. Understand your constraints

13.2.1. Consider the AgilePM® Principles

13.2.1.1. Will the organization support this way of working?

13.2.2. Consider the AgilePM® project variables

13.2.2.1. Is there flexibility in depth and detail of features?

13.2.3. Think about the people

13.2.3.1. Are all roles capable of and committed to the project approach?

13.2.4. This is rarely a black and white decision

14. AgilePM® Planowanie

15. AgilePM® Szacowanie

16. Watch: official AgilePM® introduction video (by Keith Richards)

17. AgilePM® Oficjalne publikacje

17.1. Agile Project Management Handbook

17.1.1. ISBN-13: 978-0954483241

17.1.2. ISBN-10: 0954483243

17.1.3. http://www.amazon.co.uk/Agile-Project-Management-Handbook-V1-1/dp/0954483243

17.1.4. Pages: 176

17.1.5. The most important, key position on AgilePM® preparing for Foundation and Practitioner exams

17.1.6. Newest version v1.2

17.1.7. Since AgilePM® is a derived methodology, Agile Project Management Handbook, it's 90% of content is identical to content provided in DSDM® Atern® Handbook.

17.1.7.1. DSDM® Atern® The Handbook

17.1.7.1.1. ISBN-13: 978-0954482220

17.1.7.1.2. ISBN-10: 0954482220

17.1.7.1.3. http://www.amazon.co.uk/DSDM-Atern-Handbook-Consortium/dp/0954482220/

17.1.7.1.4. Pages: 201

17.1.7.2. That's because AgilePM® methodology was derived from DSDM® in 2010.

17.1.7.2.1. Same consortium created both methodologies.

17.1.7.3. DSDM® Atern® The Handbook is available online for FREE.

17.1.7.3.1. http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook

18. AgilePM® Oficjalne zasoby

18.1. AgilePM® przykładowe egzaminy, dostępne online

18.1.1. Foundation

18.1.1.1. http://www.apmg-exams.com/index.aspx?subid=87&masterid=26

18.1.2. Practitioner

18.1.2.1. sample Practitioner exams are not available online

18.2. AgilePM® sylabus egzaminacyjny

18.2.1. EN

18.2.1.1. http://www.pmweb.co.uk/wp-content/uploads/2013/01/AgilePM-Syllabus-v1.4.pdf

18.3. Glosariusz AgilePM®

18.3.1. EN

18.3.1.1. http://www.agilechangemanagement.co.uk/wp-content/uploads/2013/09/agile-glossary.pdf

18.4. AgilePM® White Papers

18.4.1. Agile Project Management White Paper

18.4.1.1. http://www.dsdm.org/sites/default/files/Agile-PM-White-Paper.pdf