Tag Archives: English Post

Review EBM Evidence-Based Management Guide

schermafdruk 2019-01-19 17.32.18The Evidence-Based Management Guide was developed by Ken Schwaber, Christina Schwaber, Scrum.org, the professional Scrum Trainer community and the Engagement Manager community.

EBM is an empirical approach that provides organizations with the ability to measure the value they deliver to customers and the means by which they deliver that value, and to use those measures to guide improvements in both.

EBM consists of four Key Value Areas (KVAs):

  • Current Value (CV): Reveals the value that the product delivers to customers, today
  • Time to Market (T2M): Expresses the organization’s ability to quickly deliver new capabilities, services, or products
  • Ability to Innovate (A2I): Expresses the ability of a product development organization to deliver new capabilities that might better meet customer needs
  • Unrealized Value (UV): Suggests the potential future value that could be realized if the organization could perfectly meet the needs of all potential customers

qrc (evidence-based management, 190119) v1.0To download: qrc (evidence-based management, 190119) v1.0

To produce genuine and long-lasting improvements the guide explains a five-step learning loop:

  1. Quantify Value
  2. Measure KVMs (Key Value Measure)
  3. Select KVAs to improve
  4. Conduct practice experiments to improve targeted KVAs
  5. Evaluate results

In the appendix an overview of KVMs, clustered by KVAs, and how to measure them.

Conclusion an easy to read guide to get a better understanding of business value, how to measure and how to improve it.

To download the guide (for free): Evidence-Based Management Guide

Advertisements

A birds eye view on the agile frameworks forest

Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?” Now we know there is more flesh on the bones. At this moment there are more than fifty known and less known agile frameworks available. To get a first impression of the different frameworks, I try to bring some structure in the jungle to methods and frameworks. In Figure 1, I position the best-known agile frameworks in a structure. The frameworks are positioned within the ‘One-time programs / projects’ sections or within ‘Business as usual’ / indefinite, or both.

Grasp session (Scaling Agile T-Mobile, 2019 Q1) v0.1Fig. 1 Overview agile framework[1]

On the other side the frameworks are clustered around team, product or programme and portfolio level. In the dark blue boxes in Figure 1 we see agile frameworks that are only applicable in IT-focused organizations. All other frameworks can be used within IT and non-IT-oriented organizations (light blue coloured). I haven’t mapped all the known frameworks in this figure, and to be honest, I think there is a lot of duplication and probably commercial drivers play a role too to ‘develop’ the next kid on the block without added value in comparison with the existing frameworks.

The team level, including Scrum and Kanban, is applicable in both IT-oriented and non-IT-oriented products and services development and operations. The engineering level focuses specifically on IT-oriented product development. The one-time, temporary projects and programme frameworks are suitable for both IT and non-IT. The permanent umbrella frameworks (both product-targeted and team-targeted) focus specifically on IT and product development and the business-targeted frameworks help organisations to increase their agility.

Teamlevel

If we start at the team level in Figure 1, then we see of course Scrum as described by Ken Schwaber and Jeff Sutherland in their Scrum Guide. In addition, you will see frameworks such as Kanban (as described in the Kanban Guide for Scrum Teams), Scrumban and DevOps or BusDevOps. The team level can be used both within the IT environment and the non-IT environment. At this team level we can position the following IT frameworks too: Crystal family (developed by Alistair Cockburn with Crystal Clear and Crystal Yellow, Orange, Orange Web, Red, Maroon, Diamond, and Sapphire), Rapid Application Development (RAD developed by James Martin), Adaptive Software Development (ASD by Jim Highsmith, Sam Bayer), Agile Unified Process (AUP) as a simplified version of Rational Unified Process (RUP) which was superseded by Disciplined Agile Development (DAD) which was superseded by Disciplined Agile (DA). If you want to deliver quality as a team within the IT world, only following these frameworks is not enough. To improve quality and minimize technical debt (e.g., inefficient code due to many iterative adjustments), you could make use of eXtreme Programming (XP, developed by Kent Beck, Ward Cunningham, and Rom Jeffries) with Pair Programming, Acceptance Test Driven Development (ATDD), Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Example Driven development (EDD), User Experience (UX) Design, Continuous Integration and Continuous Deployment. AgileBA delivers the techniques to perform business analysis.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project. There are several core practices: documentation, document continuously, document late, executable specifications, single-source information, active stakeholder participation, architecture envisioning, inclusive tools, iteration modeling, just barely good enough (JBGE), look-ahead modeling, model storming, multiple models, prioritized requirements, requirements envisioning.

 Scrum or Kanban?

When teams start working with Agile, Scrum is often chosen. An obvious choice, but the question is whether this is always the right choice. In a Roman Pichler[2] blog the link was made with the life phase of a product. During the first phase of a commercial product lifecycle, in which the commercial product is finally put on the market for the first time, the uncertainty is high, and the focus is on on-time delivery of the first market-ready product. A deadline has been set and that date must be met. During this phase, the focus of the entire team is on delivering a commercially marketable product. This development is perfect for Scrum with its iterative approach, being able to deal with uncertainty and working together on the result (the commercial product). Optionally, a second launch can take place with a next set of important functionalities, so that eventually a mature product is put on the market. During the further course of the product lifecycle, we see the amount of uncertainty and requested changes decrease. At this moment you can make good use of Kanban. In a continuous flow, User Stories can be picked up, developed and deployed one by one by individual team members.

If one looks at the often difficult transfer to production environments, the time-to-market can be shortened by properly arranging the transfer and reducing the number of transfer errors when development and production teams are merged, and the integration testing and deployment are automated (Continuous Integration and Continuous Deployment CI/CD). In this way a DevOps team is created.

Scrumban is the combination of Scrum and Kanban. In the first instance it was intended as a transitional model to switch from Scrum to Kanban and let the team experience Lean- and Kanban concepts. Nowadays it is an approach in which the team has chosen to work according to Scrum with Sprints, but to use the Kanban system to continually view and improve its working method to optimize the flow of units of work (e.g. User Stories).

Scaling up towards product- or program level

In order to be able to use an agile way of working in an organization of some size, just having individual agile teams is not enough. The agile way of working needs to be scaled up and where possible the overarching alignment needs to be institutionalized.

To institutionalize coordination, management of dependencies and integration between the different permanent agile teams within ‘the run-the-business’ / ‘business-as-usual’ side there are various frameworks available, including:

  • Nexus, as described in The Nexus Guide, is a framework for developing product or software development initiatives with three to nine Scrum Teams, in Sprints of up to thirty days. Nexus is the answer of Ken Schwaber, one of the founding fathers of Scrum, to the scalability of Scrum. It requires more than just the will and the agile behaviour of the different Scrum Teams to work together to deliver an integrated product. Nexus is based and builds on Scrum and the rules and roles formulated in The Scrum Guide. We can position Nexus over the team and program levels of SAFe, but it does not offer provisions on portfolio level.
  • Scrum at Scale (S@S, developed by Jeff Sutherland and Alex Brown) is a modular framework. The starting point at S@S is that an all-encompassing one-size-fits-all framework is not possible, but that every time we have to look at scaling of the underlying Scrum principles. The framework can be tailored for your own organization by adding the needed S@S modules. S@S builds on the well-known Scrum framework. By analogy with Nexus you could therefore say that S@S is the answer from Jeff Sutherland, next to Ken Schwaber, the other founding father of Scrum, on the scalability of Scrum.
  • Large-Scale Scrum (LeSS, developed by Craig Larman and Bas Vodde) is an agile framework with rules, based on principles and doing experiments. The LeSS Company offers a freely accessible knowledge base (less.works) containing the integrated approach, principles, process descriptions, definitions, roles, examples, et cetera, for large-scale, mainly IT-related, product development. Transparency is also a key concept within LeSS. The first version dates from 2005 and since then, work is constantly being done on the use and further development of LeSS.
  • Scaled Agile Framework (SAFe, developed by Dean Leaffingwell) is a framework to enable scaling up of agile teams in order to create better systems, create higher employee engagement and make use of correct cost considerations. This is the mission of the scaled agile organization and of the founder of SAFe, Dean Leffingwell. The scaled agile organization offers a knowledge base that is freely accessible to everyone (www.scaledagileframework.com) with an integrated approach in the form of process descriptions, definitions, roles, examples, etc. for Lean / Agile product development. SAFe is based on five core competences: Lean-Agile Leadership, Team and Technical Agility, DevOps and Release on Demands, Business Solutions and Lean Systems and Lean Portfolio management.

Figure 1 (see the ‘Business as usual’ / indefinite block), makes use of a division between product and team targets, namely on the basis of cooperation, if necessary, of teams or not. Or with other words, can the individual teams work autonomous (team focus) or do they have to work together to deliver a new or modified product (product focus). The fore mentioned frameworks all relate to examples where multiple teams work on a single complex product or value stream (product targeted frameworks). Not visual in the figure several frameworks make a distinction between products where you are working together in with a maximum of nine teams (in total the team of teams must not exceed the Dunbar number of 125-150 people) and a team of teams of teams (e.g. SAFe large solutions, Nexus+, LeSS Huge).

The other group concerns frameworks to support IT departments that have to maintain dozens or hundreds of applications or services, whereby the dependencies between the teams are minimal (multiple team targeted frameworks). Here the Spotify model (developed by Henrik Kniberg, Anders Ivarsson and Joakim Sundén) can be positioned, but also Scaled Agile Lean Development (ScALeD, developed by Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock and Andreas Schliep). For both groups, there are essential interfaces between the teams in areas such as data integrity, security and architecture that may not or sometimes will ask for coordination when implementing changes.

In addition, there are many, less known, frameworks that can offer support at the product level, including Agile Integration Framework (AIF), Agile Team Portfolio Management (AgileTPM), AgilePath, Continuous Agile, Disciplined Agile (DA), Enterprise Scrum, Enterprise Agility, FAST Agile, RAGE, Surge, XSCALE, Industrial XP, and AgileDS.

On the left side of figure 1 we see the one-time projects and programs as part of ‘change the business’. Here a distinction is made between projects and programs. Within the project block we see three frameworks and/or methods, all three of which are a further development of the more traditional project management frameworks:

  • Agile Project Management (AgilePM, which is derived from DSDM);
  • PRINCE2 Agile (derived from PRINCE2 from AXELOS)
  • PMI-ACP (in addition to the PMBoK Guide of PMI)
  • Project Half Double (Project Half Double is run by a community of dedicated project management practitioners who are passionate about what they do)
  • Agile Project Management (APM), not mentioned in the figure, can be positioned here too.

On the program side we see:

  • Managing Successful Programs (MSP from AXELOS) that is very agile in itself with the step-by-step growth (via tranches) towards the intended goal (and connects to PRINCE2 (Agile)) and
  • AgilePgM (Agile Program Management of Agile Business Consortium) that connects with AgilePM on the one hand and is comparable with MSP on the other hand.

Praxis covered the portfolio, programme and team levels. Praxis is a free framework for the management of projects, programmes and portfolios (based on PRINCE2, MSP, MoP, AgilePM and other frameworks). It includes a body of knowledge, methodology, competency framework and capability maturity model. The framework is supported by a knowledgebase of resources and an encyclopaedia.

Disciplined Agile (DA) covers both one-time projects and programs as well as business as usual product development. The DA toolkit is a process decision toolkit that describes how agile software development, DevOps, IT, and business teams work in enterprise-class settings.

Portfolio management level

Traditional portfolio management focuses on ‘change the business’. In the previous chapters it has become clear that more and more changes are being handled by the line organization, that is to say: by the permanent agile teams. This means that portfolio management must now also provide an overview of what takes place in ‘run the business’ / ‘business as usual’ for to be implemented change initiatives. Existing portfolio frameworks such as Management or Portfolios (MoP from AXELOS) and Standard for Portfolio Management (SfPfM from PMI) only cover the change-the-business part. Agile Portfolio Management (AgilePfM from ABC) covers ‘run the business’ / ‘business as usual’ as well as ‘change the business’.

In addition, there are a number of agile frameworks that also include a portfolio management component:

  • SAFe offers a portfolio management layer to control ‘run the business’ / ‘business as usual’ permanent team(s) of teams.
  • Disciplined Agile (DA) offers a portfolio process in which, in addition to projects, a number of ‘run-the-business’ / ‘business-as-usual’ aspects are taken into account, such as the permanent teams and the operational management of existing IT solutions.
  • Scrum @ Scale contains modules Strategic vision and Organizational development to which portfolio management can be related.
  • Spotify also provides its own portfolio management approach with its strategic planning.
  • AgilePfM use some basic concepts of an innovation hub, an agile portfolio process, maturity of the initiatives within the portfolio as well as horizons for an agile portfolio.

At the moment (Jan’ 2019) there are no mature portfolio management frameworks that include ‘change the business’ as well as ‘run the business’ / ‘business as usual’. AgilePfM was launched by the Agile Business Consortium (previously DSDM Consortium) as part of their Agile Business Change Framework. However, it is becoming increasingly clear that the overarching agile portfolio management principles are based on frameworks like SAFe, Agile PfM and Disciplined Agile.

Business level

The culture targeted block provides frameworks to increase business agility by changing the mindset of all staff in the organisation. What does it mean to work in an agile way? How can we make sure that the Agile Manifesto values and principles are understand and applied, and the Scrum values (courage, focus, commitment, respect and openness) are part of what we are doing? If the right mindset is in place it makes it much easier to implement an agile framework. In figure 1 the following frameworks are mentioned:

  • Open Space Agility (OSA) is a safe, pragmatic and repeatable technique for getting a rapid and lasting Agile adoption. It works with the framework you are currently using, and OSA can be added at any time. OSA is used to actively engage as many employees as possible in your Agile program.
  • AgileSHIFT (developed byAXELOS) is a framework that prepares people for transformational change by creating a culture of enterprise agility. The AgileSHIFT framework helps organizations to undergo a transformational change, to adopt a ‘survive, compete and thrive’ mindset. It will help to bridge the gap between the current and the target state (the Delta in AgileSHIFT) by embracing a range of agile, structured and hybrid approaches across the organization. The existing severe split between ‘run the business’ and ‘change the business’ will vanish.
  • Agility scales (developed by Jurgen Appelo) helps organizations achieve agility at scale from the bottom up – with measurable evidence of organizational transformation.
  • Lean Startup (developed by Eric Ries) is a methodology for developing businesses and products, which aims to shorten product development cycles and rapidly discover if a proposed business model is viable; this is achieved by adopting a combination of business-hypothesis-driven experimentation, by using a minimum viable product (MVP), iterative product releases, and validated learning.
  • Holacracy (developed by Ternary founder Brian Robertson) is a method of decentralized management and organizational governance, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy.

Not mentioned in the figure:

  • Goal Driven Agile (GDA) rests on three main pillars: autonomy, alignment and structured improvement. It’s a very simple framework and consists of only one base structure, the diamond, five roles and ten building blocks.

Already more than 50 agile frameworks and it’s still growing. The figure can help you in your agile framework selection process, but it cannot be said often enough, do not act dogmatically, see a framework not as a panacea that can be implemented out of the box. Common sense helps too to achieve more agility and probably the best route to become more agile is dividing your products and services into smaller autonomous parts and have them supported by an individual team.

To download this article: A birds eye view on the agile frameworks forest v1.3

[1] This picture is based on a simpler version in the book Scaling Agile in organizaties (Portman, 2017)
[2] Pichler, Roman, ‘Is Scrum right for your product?’, 19 september 2016, see: www.romanpichler.com

PRINCE2 SmartTabs versus Portman’s PRINCE2 tabs

smarttabs p2In 2010 I developed a first set of tabs as an aid to pass your PRINCE2 Practioner exam. As of that moment I developed these tabs for many other methods like MSP, MoP, P3O, AgilePM, PRINCE2 Agile et cetera.
If I compare these SmartTabs with the one I developed is see similarities and differences:
  • Both have been create to help users to find and access relevant key sections of Managing Successful Projects with PRINCE2® quickly while studying Foundation and in the open book Practitioner examinations.
  • Both deliver tabs to access sections for principles, themes and processes
  • In addition, Portman’s PRINCE2 tabs delivers tabs to access individual management products and individual roles and responsibilities
  • In addition, PRINCE2® Smart Tabs have QR codes which, when scanned, link users to further online resources which closely align to the core guidance for learning and exam preparation. These resources can be videos, the PRINCE2 Wiki, blogs, tutorials, et cetera.

PRINCE2 SmartTabssmarttabs prince2Portman’s PRINCE2 tabsPRINCE2_update_2017_UK_v2

Conclusion both will work but I am somewhat biased if I look at my own tabs, so you have to judge for yourself too. To accomodate your study the SmartTabs are a better fit, to support you during your practitioner exam I prefer my own tabs.
To download (and print on sticker paper) or order (die-cut stickers): Portman’s PRINCE2 tabs (€3.50)
To order: PRINCE2 SmartTabs (£15.00)

Review: Out of the maze

9780525537298-480x600Spencer Johnson wrote Out of the maze, the sequel to the #1 bestseller and global phenomenon Who moved my cheese?

This stunning little sequel will help you unlock the riddle of whatever mazes you may be facing in your own life. And not only your own life. Think about the VUCA world where business agility is key. Things that may have been true yesterday suddenly are no longer true today.

In this little book we follow Hem (the one in Who moved my cheese? who believed that the old situation would return) and his new friend, Hope, on their journey, by thinking outside the box, to find their way out of the maze. Believes are put central in this fable. It’s not only cheese you can eat; an apple will work too and when they are gone you have to choose new beliefs. During their journey we learn the following particularities about beliefs:

  • Notice your beliefs
  • Don’t believe everything you think
  • Let go of what isn’t working
  • Look outside the maze
  • Choose a new belief
  • There are no limits to what you can believe

the way out of the mazeBeliefs are powerful things. A single stubborn belief can take down an entire company (Kodak?, Nokia?, BlackBerry?). People believe that how things have always been is how they’ll always be. But it never is.

You can read this little book in less than an hour and it gives you a multitude of hours to notice, exam and test your own beliefs and not necessarily discard them to find the way out of your own maze.

To order: Out of the maze

Nederlandse versie: Breek los uit het doolhof

Spenser Johnson passed away in July 2017.

Open Space Agility (OSA)

In one of my previous posts I discussed the new framework AgileSHIFT. A generic framework for organizations to make the shift towards agility. One of the reactions I received was a reference to Open Space Agility. As an ‘agile framework digger’ I had to take a deep dive into Open Space Agility (OSA).

Open Space Agility can help organizations with:

  • A dramatic reduction in the coaching & training costs of your agile program
  • A rapid, genuine and lasting agile transformation
  • Much higher employee engagement scores
  • Predictable, reliable, repeatable improvement in overall results
  • Increases in stakeholder satisfaction and potentially, stakeholder delight

Open Space Agility actually embodies the agile principles of iteration, experimentation, frequent inspection, and improvement. The five steps are repeated in an iterative fashion:

  1. Leadership and enterprise preparation
  2. Initiate the process using an all-hands “Open Space” meeting
  3. Initiate agile practices across the enterprise
  4. Complete the process in open space
  5. Inspect results and adapt

As we can see in the big picture and these five steps, engagement is key and can perfectly combined with other agile frameworks. E.g. you want to introduce SAFe you can follow the SAFe implementation roadmap. But to create buy-in, engagement and increase the energy Open Space Agility can help to create the right mindset.

BP OSA

If we look at the big picture (please visit openspaceagility.com/resources/ for a downloadable version of the big picture) , we see a timeline of 100 days, two open space meetings, 60 days before the first open space meeting and 30 days after the second open space meeting to level up. During those 100 days we experiment with agile practices, and then inspect the results about every 100 days. Start and end the 100 days in open space. During the 100 days, “suspend disbelief,” “act as if,” and “pretend” these Agile principles and practices might actually work. After the 100 days, discard practices that are not working. Improve and keep using practices that are working.

There are just a few open space roles. A sponsor who authorizes the meeting. The facilitator, authorized by the sponsor, to execute the meeting from start to finish and the participants to attend the sessions. Some participants become conveners and initiate small-group discussions. The coach who is responsible for delivering guidance on specific practices and facilitation of meetings.

Open Space has a light structure. The meeting starts in a large circle, where those attending learn about the 5 principles and 1 law of Open Space. The Five Principles are:

  • Whoever comes is the right people
  • Whatever happens is the only thing that could have
  • Whenever it starts is the right time
  • When it’s over, it’s over
  • Wherever it happens is the right place

The One Law: If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, and go someplace else.

It will take around 60 days of preparation before you can start with the first open space meeting. Part of the preparation will be the selection of a theme that frames the story of the open space experience for participants. The theme helps participants “know what it means.”.

Make sure that your meetings are optional and work only with the willing and leaders go first. They have to show that they are willing to do their leadership work in an agile way. To give all potential attendees enough time to consider the invitation and discuss with others it is recommended to give them around 6 weeks.

The management of the organization has to understand the difference between a mandate and an invitation, the open space meeting format, their role as a sponsor, the importance of storytelling and the importance of supporting and encouraging emergent leadership.

During the first open space meeting (OST-1) the participants learn about how Open Space works. They experience diverse perspectives on the agile adoption from diverse sources: teams, executives, managers, directors, and stakeholders. The participants learn that there will be another open space meeting in about 100 days (OST-2). This is the event where all of the experience from the 100 days of agile practices is inspected and reviewed. This allows everyone to give the agile practices a try.

Between the two open space meetings any practice that aligns with the Agile Manifesto is a candidate practice to experiment with. This could be done in the form of iterations (visualized by the numbers 1 – 8, but these iterations are not mandatory). A lot of experimentation is happing to understand the 4 values and 12 principles of the agile manifesto. Organizational learning, emergent leadership, leadership storytelling, direct experience, experimentation and game mechanics are key. Depending on the chosen framework or way of working additional roles can emerge. One specific OSA role is worthwhile to mention: the informal “Master of Ceremonies” role who provides reassurance and guidance through a difficult transition.

After the second open space meeting it is expected that the group can clearly identify the top issues of immediate concern. Each issue has a champion who brings passion and responsibility and a wider team who pitch in to help. In this manner a sense of progress across the entire organization begins to manifest. Before long, the culture starts to tip in the direction of continuous improvement and a strong intention to create great results. When this happens, many impediments tend to go away, as those who are not really supporting the new culture realize that more than a few things have changed in the past 100 days. The culture is actually shifting.

51CaLOiLZWL._SX320_BO1,204,203,200_For more information visit openspaceagility.com

There is also a book explaining Open Space Agility: Open Space Agility

In my agile framework overview, I added this Open Space Agility (OSA) framework too.

Grasp session (Scaling Agile, 180526) v1.1

 

 

 

The Agile Culture Map

In one of my previous posts I reviewed The culture map by Erin Meyer. Based on this book I created a questionnaire to ask my readers the come up with their ideas where to position the agile culture on the eight scales of The Culture Map. As we know, and stated by many surveys, the top 1 reason for agile transition failures is that the organizational culture is at odds with agile values. So I was curious to see the agile culture map visualizing the differences. In this map I compare The Netherlands with the Agile culture. For other countries you will have complete different results. At this moment there are culture maps available of 67 countries.

Agile culture map results

As we can see in this comparison there are a lot of differences to take into account. In the book The Culture Map you can find approaches how to bridge those gaps. The figures from The Netherlands are Erin Meyer’s figures. The agile figures are the average figures of 29 respondents of my Agile Culture Map questionnaire. Feel free to submit your input too so we can make it even more accurate. You can find an explanation of each row in the questionnaire. See the Agile Culture Map questionnaire.

I am looking forward to your reactions if you think these differences make sense or how you want to cope with them!

 

 

Review: PRINCE2 2017 Edition Practitioner Courseware – English / – Nederlands

Voor de Nederlandse versie van de courseware naar beneden scrollen.

9789401802253-480x600This book PRINCE2 2017 Edition Practitioner Courseware – English was created by Douwe Brolsma and Mark Kouwenhoven and can be used as a replacement for a syllabus that training organizations provide for each attendee when following a PRINCE2 practitioner training class.

What do we get:

  • A timetable for a four-day training class with the exam at day 4 (starting with an overview and the principles, the project lifecycle including PRINCE2 processes and themes, tailoring.)
  • A print of all slides to be used during the training class. In the slides you find all the figures as provided by AXELOS, the preferred content of all products including references to the official manual
  • Two PRINCE2 Foundation sample papers from AXELOS (Question Booklet, Answers and rationales. 1 hour, 60 questions, to pass you need 33 correct answers) to be used at the start of the training class
  • The PRINCE2 Practitioner Examination Specification from AXELOS (learning outcomes, examination design and the weightings (number of questions) across learning outcomes, assessment criteria and ‘Bloom’s level’
  • Two PRINCE2 Practitioner Sample Papers from AXELOS (Scenario Booklet, Question Booklet, Answers and rationales. 2 hours 30 min, 68 questions, to pass you need 38 correct answers, open book, you can use the Managing Successful Projects with PRINCE2)
  • 14 assignments to be used throughout the training with different types of exercises (create a product, explain a role, perform an assessment)

Conclusion: The courseware contains all the needed material for a training but could be of much more value when each slide is accompanied with an explanation of the content of the slide. In that case you could use the material as reference material after the training class/exam too.

To order: PRINCE2 2017 Edition Practitioner Courseware – English

Recensie: PRINCE2 2017 editie Practitioner Courseware – Nederlands

9789401803458-480x600Dit boek PRINCE2 2017 Edition Practitioner Courseware – Nederland is gemaakt door Douwe Brolsma en Mark Kouwenhoven en kan gebruikt worden als vervanging van een syllabus zoals die door opleidingsorganisaties aan elke deelnemer wordt gegeven bij het volgen van een PRINCE2 Practitioner cursus.

Wat krijgen we:

  • Een tijdschema voor een vierdaagse training inclusief examen op dag 4 (de training begint met een overzicht en de principes, vervolgens volgen we de levenscyclus van een project met daarbinnen de verschillende PRINCE2-processen en thema’s, en het op maat maken)
  • Een print van alle PowerPoint slides die tijdens de training gebruikt kunnen worden. In de slides vindt u alle figuren/tekeningen zoals verstrekt door AXELOS en de gewenste inhoud van alle producten inclusief verwijzingen naar de officiële handleiding
  • Twee PRINCE2 Foundation voorbeeld examens van AXELOS (vragenboekje, antwoorden en toelichting, 1 uur, 60 vragen, om te slagen hebt u 33 correcte antwoorden nodig) die gebruikt kunnen worden aan het begin van de training
  • De PRINCE2 Practitioner Examination Specification van AXELOS (eindtermen, examenontwerp en de wegingen (aantal vragen) over leerresultaten, beoordelingscriteria en ‘Bloom’s level’
  • Twee PRINCE2 Practitioner voorbeeld examens van AXELOS (scenario-boekje, vraag-boekje, antwoorden en toelichting) 2 uur 30 min, 68 vragen, om door te geven hebt u 38 correcte antwoorden nodig, open boek, u kunt het beheren van succesvolle projecten met PRINCE2 gebruiken)
  • 14 opdrachten die tijdens de training gebruikt kunnen worden met verschillende soorten oefeningen (een managementproduct maken, een rol uitleggen, een beoordeling uitvoeren)

Conclusie: het cursusmateriaal bevat al het benodigde materiaal voor een training, maar kan van veel meer waarde zijn wanneer elke slide vergezeld gaat van een uitleg van de inhoud van die slide. In dat geval zou je het materiaal ook kunnen gebruiken als referentiemateriaal na de training / examen.

Om te bestellen: PRINCE2 2017 Edition Practitioner Courseware – Nederlands