PRINCE2 Foundation revision ebook - with 7 hand illustrated mindmaps!

2
PRINCE2 themes revision e-book
PRINCE2, the world’s most popular project
management framework is composed of 4
integrated elements. These are
• Tailoring the framework to suit the needs of
the project environment
• Processes – who does what and when
• Themes – aspects which need to be
continuously addressed throughout the
project
• Principles – building blocks upon which the
themes and processes have been based
In this e-book we’re going to focus on the 7 PRINCE2
themes. In particular, we’re going to focus on those
elements which most frequently are examined on
the PRINCE2 Foundation exam.
In essence, this e-book is a PRINCE2 Foundation
exam revision tool. It’s not designed as an in depth
guide to PRINCE2. For that, it’s much better to read
the official manual – Managing successful projects
with PRINCE2®
.
We believe that if you use this e-book to study for
the PRINCE2 Foundation exam, then your chances
of passing will be much greater. Words which have
been italicised and/or bolded and their associated
definitions in this e-book are ones which you need
to familiarize yourself before the exam.
In this e-book, any quoted text is Managing
Successful Projects with PRINCE2® 2009 Edition.
Copyright © AXELOS Limited 2009. Material is
reproduced under licence from AXELOS.
Business Case
The purpose of this theme is “to establish
mechanisms to judge whether the project is (and
remains) desirable, viable and achievable as a
means to support decision making in its (continued)
investment”.
In other words it’s all about deciding whether
the project is a worthwhile investment. Both the
customer and the supplier will have a Business Case,
each one written to justify their own involvement in
the project.
A Business Case is also a document (it’s one of
the 26 PRINCE2 management products) and is
‘owned’ by the Executive. At all times therefore, the
Executive needs to ensure there is an acceptable
Business Case, otherwise they should instruct the
Project Manager to close the project. Not wasting
any more time and money on a project is much
better than continuing with a project which is not
worthwhile.
The Executive is responsible for providing the first
(outline) version of the Business Case although
this can also sometimes be given by corporate/
programme management as part of the Project
Brief. This version then gets updated with more
detail in the Initiation Stage of the project.
Every project will deliver one or more ‘specialist’
products (known as outputs), which will then
be used at the end of the project by people in
the customer organization. By using them, this
will change (positively) the way in which they
do their everyday (business as usual) work. This
change is known as an outcome. The measureable
improvements which will then result to the
customer organization are what are known as
benefits.
For example, a company investing in a new business
information computer system sets up a project. The
output of the project would be the new I.T. system.
The outcome might be that the staff are able to do
their work more efficiently. The benefit might be
that the company saves money on staff salaries.
The Senior User role is responsible for both
specifying the benefits of the project, and also for
realizing them i.e. make sure that they are actually
achieved after the project closes. This means that
the people who perform the Senior User role
need to come from those areas of the customer
organization which are most often impacted by the
changes (outcomes).
How the benefits will be measured, when and by
who is documented in a Benefits Review Plan (one
of the 26 management products). This gets updated
as and when the benefits are actually realized.

3
Organization
The purpose of this theme is “to define and
establish the project’s structure of accountability
and responsibilities (the who?)”.
PRINCE2 is based upon a ‘customer/supplier
environment’ whereby the customer organization
specifies the result (the specialist products), and
pays for the project, because it deems that the
project is able to realize sufficient benefits in the
future to make the project worthwhile.
The supplier organization is the person or company
who/which will supply the products which have
been specified by the customer. On a project
where all the work is being done in-house, then
the customer and supplier will be part of the same
organization.
The key decision-making role on the project is
known as the Project Board which consists of 3
other roles: Executive and Senior User (both from
the customer) and the Senior Supplier (from the
supplier). It’s important to note however that the
Project Board is not a democracy and ultimately, it’s
the Executive who takes the decisions, advised and
supported by the other 2 roles.
The Executive role can only be performed by one
person and must be able to represent the business
i.e. that part of the customer organization which
is paying for the project). This role is ultimately
accountable for the project.
The Senior User role which is responsible for
specifying and realizing benefits is also responsible
for specifying the project’s requirements and
products.
The Senior Supplier is accountable for the quality of
the specialist products which they will deliver to the
project.
Reviewing project documentation such as plans
and business cases could be quite time-consuming
so PRINCE2 recommends that Project Assurance
can be delegated by the Project Board members
The Business Case includes the
timescales over which the
cost/benefit analysis
will be based
FINISH
Business Case theme
?
COSTS
RISKS
TIME
BENEFITS
£
PRINCE2® mindmap Business case theme | Copyright © 2013 Knowledge Train Limited | Quoted text Source is Managing Successful Projects with PRINCE2 2009 Edition. Copyright ©AXELOS
Limited 2009. Material is reproduced under licence from AXELOS.
Purpose: “to establish mechanisms to
judge whether the project is (and remains) desirable,
viable and achievable as a means to support decision
making in its (continued) investment”.
Both customer and supplier have a Business Case,
but in PRINCE2, the 'Business Case' refers to the
Customer’s Business Case.
The Executive ‘owns’
the Business Case
Senior User is responsible for
specifying the benefits and
subsequently realizing the benefits
Outputs are specialist products
Outcomes are the result of changes
derived from using the outputs
Benefits are the measurable improvements
resulting from an outcome that is perceived as
an advantage by stakeholders
All benefits are derived from
outputs and outcomes
A Benefits Review Plan is
a plan for who/how/when
will the benefits be measured
Expected dis-benefits are actual
consequences (NOT risks) perceived as
‘negative’ by a stakeholder
START

4
to others. The Project Assurance role is all about
assuring the Project Board independently of the
Project Manager that the project is being conducted
properly. Project Assurance will give advice to the
Project Manager and will review documents prior to
their approval by the Project Board.
The Project Manager role is responsible for the day
to day management of the project and reports on a
regular basis the progress to the Project Board. The
Project Manager is responsible for keeping issues
and risks under control, monitoring progress, taking
corrective action when there is a slippage from the
plan, and escalating exceptions to the Project Board.
Team Managers manage teams of specialists who
have the requisite skills to enable them to design
and build the products which have been specified
by the customer. They are responsible for delivering
the specialist products, on time and within the
agreed tolerances. They report on a regular basis to
the Project Manager.
The Change Authority role is responsible for taking
decisions about Requests for Change (RFC’s) and
Off-Specifications (more later in the Change theme).
The Project Support role assists Project and Team
Managers with administration, writing of reports,
monitoring of progress and with administering tools.
Some of the above roles can be shared (i.e. more
than one person can perform the role). In PRINCE2
all roles can be shared EXCEPT for the Executive and
Project Manager roles.
Some roles can be combined (i.e. one person can
perform multiple roles). However, the Project
Assurance role can never be shared with the Project
Manager, Team Manager or Project Support roles,
otherwise they would not be independent of the
Project Manager.
All of the above roles form the project management
team and they are all stakeholders on the project.
However stakeholders are not just the members
of the project management team, but they can be
anyone who is affected by the project.
PRINCE2 recommends that a Communication
Purpose: “to define
and establish the project’s
structure of accountability
and responsibilities (the who?)”.
PRINCE2 is based upon a customer/supplier environment
The customer specifies
the desired result and
pays for the project
The supplier provides
the resources and skills
to deliver that result
An effective Communication Management
Strategy is needed to manage communication
flows to/from stakeholders
Project Assurance - it’s the Project Board’s responsibility to review, monitor
and advise Project and Team Managers. Must be independant of Project Manager.
Executive (only one person)
represents the ‘business’
Senior
User(s)
Senior
Supplier(s)
Project Manager - manages projects on a
day-to-day basis
Team Manager - manages the delivery of specialist products
Change Authority - takes decisions about changes (the Project
Manager can be a Change Authority)
Project Support - assists Project/Team Manager(s) with admin, tools,
reporting and performs configuration management
Other project roles:
Some roles can be combined (one person
performs many roles) e.g. Combine Executive
& Senior User, or Project Manager & Project Support.
Project Assurance role cannot be combined with
Project/Team Manager or Project Support
All roles (EXCEPT Project Manager
& Executive) can be shared (many people
perform a role)
The size of the Project Board can be
reduced by using user/supplier groups
Stakeholders include anyone who
can affect, be affected by or perceive
themselves to be affected by the
project (note: a stakeholder is NOT a
project role)
The Project Board
consists of 3 roles:
START
FINISH
Organization theme
PRINCE2® mindmap Organization theme | Copyright © 2013 Knowledge Train Limited | Quoted text Source is Managing Successful Projects with PRINCE2 2009 Edition. Copyright ©AXELOS

5
system (QMS) which is a corporate-wide set of
quality policies, procedures and standards expected
within the organization. The corporate role known
as Quality Assurance (QA) is responsible for
defining and maintaining the QMS and for checking
that projects remains in compliance. QA often does
this by performing a quality audit which looks for
evidence of compliance on the project.
The QA role is therefore external to the project
whereas Project Assurance is a role which is internal
to the project (it’s one of the project management
team roles). Project Assurance assures the Project
Board that the project is being conducted properly
whereas QA assures corporate management
that the project is in compliance with corporate
standards, policies and procedures.
QA is not to be confused with quality control, which
refers to the performing of those techniques and
methods which will be used to check if a product
is “fit for purpose”, the maintaining of quality and
approval records, and the gaining of acceptance.
There are hundreds of such quality techniques to
choose from and one example is PRINCE2’s quality
Management Strategy is written which
identifies all of the project’s stakeholders, their
information needs and the means and frequency of
communication e.g. the Quality Assurance Manager
requires a copy of the weekly Highlight Report,
written by the Project Manager.
Quality
The purpose of this theme is “to define and
implement the means by which the project will
verify products that are fit for purpose”.
PRINCE2 defines quality as whether or not a product
is ‘fit for purpose’ i.e. whether it meets its agreed
and stated requirements. The theme also covers
implementation of continuous improvement
methods during the project e.g. methods designed
to improve the effectiveness of the project
management processes.
The project’s approach to the management of
quality on the project is documented by the Project
Manager in a Quality Management Strategy.
Many organizations have a quality management
Quality Assurance (corporate
responsibility) - checks compliance
with corporate quality standards
- is external to the project
Project Assurance (Project Board
responsibility) is independent of the
Project Manager - checks the
project is conducted properly
- is internal to the project
Quality planning (Project Manager’s
responsibility) - defines quality control
methods and Acceptance Criteria
Quality control - the methods
used when specialist products are
tested and approved e.g. the
PRINCE2 quality review technique
The quality review technique is
designed to quality control
written/document products and
involves 4 recommended roles:
Chair, Presenter, Reviewer &
Administrator
Yes
Approve Baseline Subjected to
change control
No
re-work
Customer’s quality expectations -
are captured pre-project when the Project
Manager consults the Senior User to define
what the project will deliver
Acceptance Criteria: the “measurable
definitions of the attributes of a set of
products which make them acceptable
to key stakeholders”
Acceptance methods enable you to prove that
the project product is complete and is acceptable
to the customer
(Corporate) Quality management
system (QMS) - A set of quality
standards, responsibilities & procedures
fit for purpose?
Records
Quality records are produced
when products are quality controlled,
and demonstrate that the quality
methods have taken place
Approval records show that a
product has been duly approved
Acceptance records
are created when the Project
Product is accepted
FINISH
PRINCE2® mindmap Quality theme | Copyright © 2013 Knowledge Train Limited | Quoted text Source is Managing Successful Projects with PRINCE2 2009 Edition. Copyright ©AXELOS
Quality theme
Purpose: “to define and implement the means by which
the project will verify products that are fit for purpose”.
A Quality Management
Strategy outlines the
project’s approach to
quality management
START

6
review technique which is suitable for reviewing the
quality of paper-based documents. PRINCE2 defines
four roles which are involved in such a review: Chair,
Presenter, Reviewer and Administrator.
During the quality method, quality records will
be maintained e.g. the details of the results of a
test and then, based upon the results, the product
shall be judged either fit for purpose or not. If it is
fit for purpose then the product can be approved
and approval records will be needed. This is often a
signature on a form or an email.
Once approved the product becomes a baseline.
This usually entails giving it a version number and it
then becomes subject to change control i.e. nobody
is allowed to modify it without gaining approval
after raising a Request for Change (RFC).
If the product is not fit for purpose, the supplier
needs to perform some re-work on the product to
bring it up to a standard where it can be quality
controlled once more.
On a project, the Project Manager is responsible for
quality planning which entails defining the quality
control methods and the project’s acceptance
criteria (the measurable attributes of the final
product i.e. the product handed over to users at the
end which will make it acceptable to the customer).
Acceptance criteria are derived from the customer’s
quality expectations which are the high level
business requirements for the project and these are
agreed before the project begins.
Certain methods (acceptance methods) will need
to be performed to check that the final product
meets the criteria. If it does, then the project can
be closed because it has delivered what it set out to
deliver. Acceptance records will record the formal
acceptance of the final product by the different
stakeholders.
Plans
The purpose of this theme “to facilitate
communication and control by defining the means
of delivering the products (the where and how, by
whom, and estimating the when and how much)“.
PRINCE2 recommends 3 levels of plan each level
matching the information needs of the 3 levels of
the project management team. These are
• Project Plan (used by the Project Board)
containing project levels costs, timescales
and control points. An updated version is
created at each stage end to reflect actual
progress and revised forecasts.
• Stage Plan (used by the Project Manager)
for day-to-day management of the project.
There is one for each management stage.
• Team Plan (used by a Team Manager) –
covers all the work done in a Work Package.
It’s important to remember that Exception Plans are
new plans (not updated versions of existing plans)
and they can be used to replace Stage Plans or the
Project Plan. In the latter case, it must be authorised
by corporate management.
Plans not only specify which products will be
delivered in the scope of the plan, but also
the timescales and costs required. PRINCE2
recommends the following should be included in all
budgets:
1. money to fund the activities to create
specialist products (and management work)
2. money to fund responses to risks (risk budget)
3. money to fund authorised changes to
baseline products (change budget)
4. cost tolerances
It’s recommended that the product-based planning
technique can be used for all levels of plan). The
technique has 4 steps:
1. Write the Project Product Description to
define what the project must deliver in order
to gain acceptance
2. Draw a Product Breakdown Structure to
show the products within scope (note:
external products are those that already
exist or are being created outside the scope
of the plan)
3. Write Product Descriptions for the major
products
4. Draw a Product Flow Diagram to define
the sequence in which the products will be
developed
Sometimes a Product Checklist which lists the major
products and their key delivery dates is a useful
control on a project.

7
Risk
The purpose of this theme is to "to identify, assess
and control uncertainty and, as a result, improve the
ability of the project to succeed”.
In PRINCE2, a risk is defined as an uncertain event,
which (if it occurs) will have an effect on the
achievement of project objectives (note: when a risk
occurs – it becomes a Project Issue).
Risks can be either:
• threats (which have a negative impact), or
• opportunities (which have a positive impact)
Every organization has its own unique attitude
towards risk taking. This is known as risk appetite.
Each plan in PRINCE2 will have a risk budget, which
is money to be used to fund any risk responses.
Risk tolerance refers to the threshold level of risk,
which once exceeded (or forecast to be exceeded)
will result in an Exception Report being triggered i.e.
an exception has occurred
Information about all project risks are maintained in
a Risk Register, and a Risk Management Strategy
is written to outline the general approach to risk
management during the project.
Included in this strategy is a description of the risk
management procedure which contains 5 steps:
1. Identify - threats and opportunities are
identified and described in terms of the
cause (source of the risk), event (area of
uncertainty), and effect (it’s impact)
2. Assess
a. Estimate the probability (likelihood),
impact, proximity, and
b. Evaluate the overall net effect of all risks
3. Plan one or more specific risk responses
4. Implement the chosen risk responses and
assign:
a. A risk owner – the individual responsible
for managing the risk
Plans theme
Purpose: “to facilitate communication and control
by defining the means of delivering the products
(the where and how, by whom, and estimating the
when and how much)“
3 levels of plan (match the information
needs of the 3 levels of management)
Project (used by the Project
Board) contains project levels costs,
timescales and decision/control
points - is updated at each stage end
Team (used by Team
Manager) - covers
a Work Package
Stage (used by Project Manager)
for day-to-day management
of the project. One for each stage.
Exception Plans (NOT updated plans -
but NEW plans) can only replace
Stage Plans or Project Plan
When an Exception Plan replaces a
Project Plan, it must be authorised by
Corporate Management
In a Plan, the budget contains:
Money to fund
activities to create
specialist products
Money to fund risk
responses (risk budget)
Money to fund authorised changes
to baseline products (change budget)
Product-based planning
technique (used for any
level of plan) has 4 steps
1. Write the Project Product Description
to define what the project must deliver in
order to gain acceptance
2. Draw a Product Breakdown
Structure (PBS) to show the
products within scope
External Products are those that already
exist or are being created outside the scope of the plan
3. Write Product
Descriptions for
the major products
4. Draw a Product Flow
Diagram (PFD) to define the
sequence in which products
will be developed
A Product Checklist is a list of major
products and their key delivery dates
START
FINISH
PRINCE2® mindmap Plans theme | Copyright © 2013 Knowledge Train Limited | Quoted text Source is Managing Successful Projects with PRINCE2 2009 Edition. Copyright ©AXELOS
Cost tolerances

8
b. The risk actionee/s – the people assigned
to carry out the risk response(s)
5. Communicate – report risk information to
stakeholders using the various PRINCE2
reports.
PRINCE2 defines 6 responses to threats: avoid,
reduce, fallback, transfer, accept, share, and 4
responses to opportunities: exploit, enhance, reject,
share.
After performing these responses to primary
risks, there is usually some level of risk left over.
This is known as residual risk. Any risks caused by
performing risk responses are known as secondary
risks.
Change
The purpose is “to identify, assess and control any
potential and approved changes to the baseline”
products (i.e. products that have been approved).
A baseline refers to a product which has undergone
its quality controls, has been deemed ‘fit for
purpose’ and has been approved by those with
authority. At this point the product is usually given a
version number e.g. version 1.0).
There are 3 types of Project Issue:
1. Requests for Change (RFC) - request to
change a baseline
2. Off-specifications - this requirement/product
hasn’t/cannot be delivered
3. Problems/concerns – anything else
If a Project Issue is forecast to exceed a project
tolerance (time, cost, quality, scope, benefits and
risk) it’s an exception.
Project Issues can be managed in 2 ways:
1. Formally - requires formal advice from the
Project Board – the issue gets logged in the
Issue Register and an Issue Report is written
2. Informally – the issue gets recorded in the
Daily Log
All issues are managed using an issue & change
control procedure:
Purpose: “to identify, assess and
control uncertainty” and, as a result,
improve the ability of the
project to succeed”.
A risk is an uncertain event, which
(if it occurs) will have an effect on the achievement
of project objectives (note: when a risk occurs
- it becomes a Project Issue)
Risks can be either:
Threats (which have a negative impact)
Opportunities (which have
a positive impact)
Risk appetite is the organization's
unique attitude towards risk taking
Risk budget - money in the project budget
to be used to perform risk responses
Risk tolerance - if these are exceeded or are
forecast to be exceeded, an Exception Report
will be triggered
Risk Register - is used “to capture
and maintain information on all
identified threats and opportunities“
5 steps of the risk
management procedure:
1. Identify threats and opportunities
and describe the cause (source of the
risk), event (area of uncertainty),
effect (it’s impact)
2. Assess
a. Estimate probability,
impact, proximity
b. Evaluate the overall
net effect of all risks
3. Plan specific
management responses
4. Implement chosen
risk responses and assign:
a. Risk owner -
individual responsible
for managing a risk
b. Risk actionee/s -
those assigned to carry
out the risk response(s) 5. Communicate -
report risk status
to stakeholders
Threat responses:
Avoid, Reduce,
Fallback, Transfer,
Accept, Share
Opportunity responses:
Exploit, Enhance,
Reject, Share
Residual risk - the risk left
over after performing
risk responses
Secondary risks - those
risks caused by performing
risk responses
START
FINISH
PRINCE2® mindmap Risk theme | Copyright © 2013 Knowledge Train Limited | Quoted text Source is Managing Successful Projects with PRINCE2 2009 Edition. Copyright ©AXELOS Limited
2009. Material is reproduced under licence from AXELOS.
Risk theme
?What if...
? ?
? ? ?
?
? ?
?
?

9
1. Capture – either in the Issue Register or Daily
Log (as above)
2. Examine – perform an impact analysis
(impact on cost, time, quality, scope,
benefits, risks)
3. Propose - alternative options for responding
4. Decide – which option is the best overall
value for money
5. Implement – perform the recommended
option(s)
A Change Authority reviews and approves RFC’s and
off-specifications and by default is performed by
the Project Board. A Change Budget is used to fund
changes.
A prerequisite for effective change control is an
appropriate configuration management system. The
5 core activities of configuration management are:
1. Planning – decide how it will be done, which
tools are required
2. Identification – decide a version and naming
schema
3. Control – decide who will have access to
products and able to make changes to
baselines
4. Status Accounting – decide how
configuration status reports (Product Status
Accounts) will be created
5. Verification audits – decide how/when will
the status of products will be checked against
the status which has been recorded
Progress
The purpose is “to establish mechanisms to
monitor and compare actual achievements against
those planned; provide a forecast for the project
objectives and the project’s continued viability; and
control any unacceptable deviations”.
These mechanisms (controls) are used by all 3 levels
of the project management team.
Tolerances refer to the permissible deviation from
plan before bringing to the attention of the next
higher authority.
Corporate management sets project tolerances, the
Project Board sets stage tolerances and the Project
Purpose: “to identify, assess and
control any potential and approved
changes to the baseline” products
(i.e. products that have been approved).
3 types of
Project Issue:
Request for Change (RFC)
- request to change a baseline
START
Change theme
Off-specification - this requirement/product
hasn’t/cannot be delivered
Problem/concern
- anything else
If an issue is forecast to exceed
a project tolerance (time, cost, quality,
scope, benefits and risk) it’s an exception
Project Issues can
be managed:
Formally - requires formal advice
from the Project Board - logged in
the Issue Register and an Issue Report
is written
Informally - recorded
in the Daily Log
A prerequisite for effective
change control is an appropriate
configuration management system
Change Authority: reviews and
approves RFC’s or off-specs
(defaults to Project Board)
A Change Budget
funds changes
The 5 core activities of
Configuration Management are:
1. Planning 2. Identification
3. Control
4. Status Accounting5. Verification audits
Issue & change
control procedure:
1. Capture
2. Examine
3. Propose (alternative
options for responding)
4. Decide 5. Implement
FINISH
PRINCE2® mindmap Change theme | Copyright © 2013 Knowledge Train Limited | Quoted text Source is Managing Successful Projects with PRINCE2 2009 Edition. Copyright ©AXELOS

10
Manager sets Work Package tolerances.
If the project tolerances are forecast to be
exceeded, the project must request new tolerances
from corporate management via an Exception Plan.
Management stages
• are subsets of the project culminating with
a management decision point when the
Project Board assesses the (continuing)
project viability
• equate to commitment of resources and
authority to spend
• are mandatory - every PRINCE2 project has
at least 2 management stages
Technical stages (are NOT management stages)
often overlap – i.e. they occur at the same time.
Monitoring and reporting on a project requires
a time-based approach whereas controlling the
project (i.e. decision making) requires an event-
based approach. Therefore, PRINCE2 defines 2 types
of progress control:
1. time-driven controls – are created at agreed
frequencies (e.g. Highlight Reports and
Checkpoint Reports)
2. event-driven controls – these take place
when a specific event occurs (e.g. Exception
Report)
Some other examples of event-driven controls are:
• Work Package(s) - authorized by a Project
Manager in order to trigger the work of a
team
• Lessons Log - contains lessons often learned
in the reviewing of progress e.g. Checkpoint
Report
• Lessons Report – used by corporate
management to improve standards and to
collect statistics to help future estimating
• End Project Report - used by the Project
Board to evaluate the project and authorise
closure

11
Summary
By now, if you have learned the definitions provided
in bold in this e-book you should be well-placed
to pass the PRINCE2 Foundation exam with flying
colours. Good luck with your exam.
About the author
Simon Buehring is the founder and Managing
Director of Knowledge Train, a PRINCE2
Accredited Training Organization based in the UK.
Simon regularly delivers project management and
PRINCE2 training courses in the UK and overseas
and writes a blog about project management
and PRINCE2. For more than 25 years Simon has
worked on or managed software projects for a
wide range of organizations both in the UK and
internationally, including the BBC and HSBC.

Download the other two ebooks in the series:
These two ebooks will be useful for your exams:
Learn the PRINCE2 Principles Learn the PRINCE2 Processes
PRINCE2 Foundation exam tips PRINCE2 Practitioner exam tips

PRINCE2 Foundation revision ebook - with 7 hand illustrated mindmaps!

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (12)

Recently uploaded

Recently uploaded (20)

PRINCE2 Foundation revision ebook - with 7 hand illustrated mindmaps!