Second edition 2019. Published by Richmond Innovation Ltd. Copyright Richmond Innovation.

This guide is free for distribution and sharing in its entirety. No part may be copied or distributed without
reference to the original.

Limits of Liability and Disclaimer of Warranty

While every precaution has been taken in preparing this guide, including research, development, and
testing, the Publisher and Author assume no responsibility for errors or omissions. No liability is assumed
by either Publisher or Author for damages resulting in the use of this information.

Richmond Innovation is a consulting firm specialising in providing training and consultancy services
to organisations that are implementing and improving their innovation capability.

For more information on Richmond Innovation and available publications you can visit:
www.richmondinnovation.com
Contents
1. Introduction..................................................................................................................4
2. What makes innovative projects different?...............................................................5
Uncertainty................................................................................................................................................5
Change.......................................................................................................................................................5
Risk.............................................................................................................................................................5
Agility.........................................................................................................................................................6
Collaboration.............................................................................................................................................6
3. Integrating innovation.................................................................................................7
Tailoring the approach.............................................................................................................................7
4. The Business Case........................................................................................................8
Aspects of an innovation business case..................................................................................................8
Innovation Business Case approaches.................................................................................................10
Accelerating the Business Case.............................................................................................................13
5. Agile in an innovation project context.....................................................................14
Agile value and behaviours....................................................................................................................15
The Agile Manifesto................................................................................................................................16
Common agile approaches....................................................................................................................17
Kanban.....................................................................................................................................................18
Scrumban................................................................................................................................................20
Lean Startup............................................................................................................................................20
Lean / Lean Six Sigma.............................................................................................................................21
DSDM / Agile PM.....................................................................................................................................22
PRINCE2 Agile and PMI Agile.................................................................................................................22
Others......................................................................................................................................................23
Agile tools and techniques.....................................................................................................................23
6. Project risk management...........................................................................................25
Risk factors in innovative projects.........................................................................................................26
Risk profile of innovative projects.........................................................................................................26
Innovation risk management responses..............................................................................................27
Failing fast / Pivoting fast.......................................................................................................................28
Agile risk..................................................................................................................................................29
Risk culture..............................................................................................................................................30
7. Project planning..........................................................................................................31
Approaches to planning innovative projects........................................................................................31
8. Innovation project stages..........................................................................................32
The idea management process.............................................................................................................32
Typical project budget stage gates........................................................................................................33
9. People factors.............................................................................................................34
The innovation project manager...........................................................................................................35
10. Eliminating project bureaucracy.............................................................................36
11. The Innovation Portfolio..........................................................................................38
Innovation portfolio bubble diagram...................................................................................................39
Strategic alignment.................................................................................................................................39
12. Project handover and BAU management................................................................40
Value delivery..........................................................................................................................................40
Learning and continuous improvement...............................................................................................41
13. Additional information and reading.......................................................................42
1. Introduction
The purpose of this guide is to provide the reader with a comprehensive understanding
of innovation project delivery. The focus is on the delivery of projects that are innovative
rather than innovative methods of delivering projects, although delivering innovation
projects does require more agile and responsive approaches.
A number of approaches, such as PRINCE2 Agile, PMI Agile and Agile Project
Management (APMG) go some way to addressing how to deliver innovative projects but
they do not always provide the wider innovation context which is important to consider
when tailoring project approaches.
The guide is aimed at project managers, delivery teams, innovation managers and
organisational leaders who have some responsibility for innovation and delivering
innovation projects. Understanding best practices relating to innovation delivery will
benefit all roles who are either directly responsible for project delivery or associated with
innovation projects in some way. Innovative projects are delivered in a variety of
environments, from large process driven organisations to small entrepreneurial start-up
businesses. This guide aims to provide the reader with tools, techniques and approaches
that can be tailored to suit specific circumstances and blend with existing processes.
The guide is not intended to provide the reader with an entire project management
framework with which to manage innovative projects. There are existing project
methodologies and approaches that already exist (such as PRINCE2 and PMI). Rather, it
will provide the reader with an overview of how an innovation project differs from
conventional projects and offer guidance on how to apply and tailor existing practices
effectively with a focus on successful project delivery within an innovation context. The
guide also considers innovation projects in a wider context than project management, as
there are a number of areas that need to be considered such as organisational culture
and behaviours, idea management, business case, portfolio management, innovation
strategy and definition, and value management.
The guide is the result of extensive research and experience and it reflects best current
practice at the time of writing.

4
2. What makes innovative projects different?
Using a broad definition of innovation, we might say that innovation is the delivery of
something new or breaking new ground in some way. More specifically innovation is
often related to the delivery of products or services that have a restricted time window in
which to deliver value. Organisations and individuals innovate to stay ahead of the
competition and transform creative and conceptual ideas into concrete products,
services and processes that add value in some way. Non-innovative projects might not
have the same critical time window, there is more certainty about the final product, less
risk in terms of value elicitation and more conventional means to plan and deliver the
project. In contrast, innovative projects must embrace uncertainty, risk, change, agility
and collaboration. Let's take a look at each area in more detail.

Uncertainty
When delivering innovative projects there is a lot that we do not know. We don't know
how the market will react to the product, we don't know how the product will perform,
we don't know what issues will emerge during delivery and we don't know what other
unknowns there are (we don't know what we don't know). This uncertainty is far greater
with innovative projects than with non-innovative projects and the uncertainty must be
managed accordingly.

Change
The creative process doesn't stop once the project scope is agreed. With an innovative
project the scope can be base-lined, but the baseline should be at a high enough level to
provide some project direction, but not so high level that there is no clarity on what the
project is trying to achieve. Due to uncertainties, delivery teams must be open to
continuous change to scope. This could be in response to new ideas, changing market
conditions or the emergence of new information.
When base-lining a project, focus should be given to the expected value rather than the
actual solution. The solution will likely change as more information is uncovered. Even
the expected value can change as the project progresses and new information emerges.
During project delivery a completely new value proposition might be uncovered that
exceeds the original scope and purpose of the project. There must be a mechanism to
enable these changes to be fed back into the project without having to restart or threaten
the entire project. This means that an expedited re-justification process will be needed
where project direction can quickly be assessed and re-approved as and when new
information emerges that impacts the baseline.

Risk
Uncertainty also introduces more risk into projects. There is a risk that the project will

5
cost more and over-run as there is limited prior experience on which to base a plan.
There is a risk that the project will not deliver the expected benefits as it is breaking new
ground. If a project environment or business is risk averse then innovative projects will
encounter challenges with justification. Innovation is inherently risky but can also deliver
significant rewards. Much like investing in the stock market, riskier ventures such as
small company funds in emerging markets can sometimes result in huge losses, but they
can also provide large rewards, far in advance of diversified index tracker funds. There
are ways to manage risk and reduce uncertainty but some level of risk must be embraced
in order to benefit from elevated returns.

Agility
One way to reduce risk is to reduce time, deliver incrementally and learn continuously.
'Agile' is a philosophy to project delivery that encompasses a number of frameworks,
concepts, and techniques that are highly relevant to innovative projects. While Agile is
not only for the purpose of delivering innovation it does provide an environment that is
conducive to projects that have high levels of uncertainty. Agile projects embrace speed
of delivery, customer feedback, continual change and low levels of bureaucratic process,
all of which are necessary to deliver innovation projects effectively.

Collaboration
Innovation cannot be delivered in isolation or in organisational silos. The concept of
many minds or the 'wisdom of crowds' means that innovation is more effectively
delivered using collective wisdom.

Definition – 'The wisdom of crowds'

“The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How
Collective Wisdom Shapes Business, Economies, Societies and Nations
published in 2004, is a book written by James Surowiecki about the
aggregation of information in groups, resulting in decisions that, he argues,
are often better than could have been made by any single member of the
group.” Wikipedia.

The ability for teams to work together in an open and supportive environment will
improve the success of an innovative project. Being open and honest about risks, issues
and opportunities and collaborating on solutions will not only improve project success
but it will enhance team dynamics and create a sense of ownership for the project.
Working and collaborating with a wide group of stakeholders will provide insight to
projects that are uncertain and risky.

6
3. Integrating innovation
Highly innovative organisations will consider everything that they do to be innovative and
therefore innovation is embedded into all of their processes, values and approaches and
it will not be necessary to tailor the approach to managing projects. However, many large
organisations, that have standardised their processes, identified their core products and
markets and formalised their management structures will need to adapt the organisation
to cope with innovation. Standardisation and proceduralisation can create barriers to
innovation so it is essential that innovation approaches are sensitively integrated. To get
around this some organisations have created break-out companies to develop new
products and services free of the hindrances of existing processes. This approach can be
successful but it reduces the existing organisations ability to learn and adapt to new
markets. It is always better to integrate innovation where possible, rather than segregate
it. In a project context this means developing innovation project approaches that exist in
harmony and even complement existing processes.

Tailoring the approach

Organisations that embed innovation into every day processes
Organisations that embed innovation into every day process and regularly deliver
innovative products and services will likely gain least insight from this guide. Certain
approaches or methods referred to herein might be useful but the guide is primarily
aimed at those organisations that have realised that they must scale up their innovation
efforts.

Organisations that do not embed innovation

These organisations are likely to have well established procedures and processes that
may be in conflict with an innovation capability. It will be necessary to integrate
innovative project approaches with existing processes so that conflict is minimised. This
will require leadership training and coaching to provide a supportive environment for
innovation.

Organisations that are scaling up

Small and medium sized organisations that are creating new processes and procedures
should consider how processes will continue to support innovation and maintain a
flexible and agile environment. As organisations scale up there is always a risk that they
will lose the agility that made them successful to begin with. This means scaling up and
building processes that support rather than conflict with innovation. Agile project
processes should be favoured over conventional approaches such as standard PRINCE2
or PMI.

7
Entrepreneurial start-ups
Small agile start-ups are innovative by their nature. However, as they become more
established there is value in selectively implementing innovation processes that enhance
the organisations ability to take new products to market. Building an end to end idea
management process would add little value, but agile project delivery approaches to
improve rigour, speed to market and product testing should be considered.

4. The Business Case

There is an argument that a detailed Business Case is not as important in an adaptive
project (high uncertainty and subject to change) versus a predictive project (inputs and
outcomes are more certain). However, for the purpose of innovation projects, the
Business Case is an important step to provide a baseline justification to proceed and
then use it to compare and contrast against. A business case should be documented and
base-lined, but should also be a fluid, flexible document that provides the project with its
vision. The Business Case therefore remains an important step in an innovation project
and should not be neglected.

Aspects of an innovation business case

• Unique Selling Proposition (USP) – A USP is primarily a product related sales
term but it is particularly relevant to an innovation business case. All new ideas
should have the potential to add value in some unique, novel or interesting way.
The USP should be articulated in a short simple statement and be the primary
reason for the business case. If there is nothing unique, new or novel about the
idea it probably does not belong in an innovation pipeline. The USP should define
how the idea is innovative according the the organisational definition of
innovation. Innovative projects might be eligible for special funding, could be
managed by a different team or have different processes (such as those
mentioned in this guide). Therefore, understanding how the idea meets the
organisational definition of innovation will help with justification.
• Minimum Viable Product (MVP) – The MVP provides the baseline deliverable for
the business case. It defines what the project aims to deliver (primarily stated in
value terms such as user experiences and outcomes). It is important to state an
MVP in a business case because if it is not possible to achieve this then the
business case becomes invalid and the project should be failed or pivoted.

8
 Definition – Minimum Viable Product (MVP)
The MVP is a concept popularised by Eric Ries in his book The Lean Startup
where an MVP is launched into the marketplace with the absolute bare bones
of functionality or even the promotion of a product that does not yet exist.
This allows the team to test and learn from feedback and then enhance the
product accordingly. The launching of MVP's is a continual feedback loop
referred to as Build, Measure, Learn.

• Quick start up – Innovation projects must be fast paced because speed to market
is always an important factor with innovation. An innovation business case must
therefore be accessible and relatively easy to complete, but must provide enough
justification to get started and give the sponsor confidence in its potential.
Detailed business cases that take months to complete are not fit for purpose in an
innovation project environment.
• Stage by stage justification – Estimation and analysis should provide sufficient
information to give a good level of confidence that the first iteration of the project
will be successful. A small scale prototype or pilot might be delivered initially
which will demonstrate the effectiveness of the idea, followed by a full
implementation. The business case therefore needs to provide justification for the
initial stages, after which it will be revisited with more detailed analysis to justify
further investment. Unlike conventional projects that often require up front
justification for the entire project, an innovation business case only requires
justification for the next stage. Each stage should aim to further demonstrate the
potential of the idea through customer feedback rather than attempt to justify the
project with detailed revenue and benefit estimates that have little real world
evidence to back them up.
• Qualitative 'v' Quantitative analysis – It is likely that estimates will be more
qualitative rather than quantitative in nature. This is due to the lack of comparable
data that is available with projects that are breaking new ground. Instead of
attempting to build detailed figures, costs and forecasts it will be necessary to
place more reliance on customer surveys, interviews, feedback and opinions. This
should be backed with justifiable reasoning so that, under scrutiny, the business
case holds up.
• 'Fail fast' or Pivot – The production of the business case will identify evidence to
support or fail the project before major project delivery work is started. Business
cases that are in development and fail to produce data that justifies the
investment should be failed at the earliest opportunity. This enables the
investment and resources to be allocated to other higher potential projects
instead. During the course of the project major obstacles might be encountered

9
 but these might not necessarily result in a project fail. It might be possible to
Pivot, where a new approach or project deliverable is developed that will continue
to deliver value. The business case approval process should allow for such
changes.

Definition – Pivot
Pivot is a Lean Startup concept that aims to change the product direction
based on customer feedback. A product or service might need to be adapted
or the anticipated market changed so that it achieves its value objectives. In a
project context this means revisiting the business case or creating a new
business case based on the new information.

• Accommodative to change – The definition of what the project is delivering must

be at a high enough level to accommodate change. Additional features may be
added or taken away as the business case is created. This does not mean that the
scope is uncontrolled, it means that the scope must be carefully monitored and
tested against the business case. Change management must be used to
continually track scope against costs and benefits to ensure that the business case
remains valid.
• Light touch – The business case should provide the sponsors with some level of
confidence that something of value will be delivered, however, developing the
business case should not be a project within itself. Business cases with detailed
sales figure forecasts, costs, product specifications and market analysis rarely
result in an accurate final product. There are high levels of uncertainty associated
with innovation so providing a high level vision that embraces change is a
preferable approach to detailed analysis and justification.

Innovation Business Case approaches

The business case frequently takes the form of a document with supporting
spreadsheets. Information typically includes financial forecasts, detailed market analysis,
risk analysis, expected benefits and dis-benefits, reasoning, timescales, costs, investment
appraisals, alternative options and summary document (often a separate presentation).
Compiling the required information can be time consuming and a project in itself, taking
weeks or even months to complete. With a significant level of detail and information it
becomes more difficult for approvers to make decisions without understanding how
conclusions have been reached. More information raises more questions resulting in
many iterations and repeated approval meetings before a project is initiated. This
approach breeds risk aversion in the organisation and it is not congruent with fast
moving innovation where learning and adaptation are constant.

10
The innovation business case should therefore be short, easy to produce and
understand, have sufficient detail to support the recommendations but be sufficiently
high level to accommodate change.
An expedited business case will accelerate the approval process both at start up and
when approving changes.
Stakeholders must be fully on-board with the innovation business case process as a
different philosophy is required compared to conventional projects. Innovation requires
a learning approach that embraces continuous justification throughout the project rather
than significant 'up front' research that is common to many business justification
approaches. This does not mean that the expected benefits are not clearly defined, it
simply means that the baseline benefits are set at a higher level and must be revisited
frequently to ensure that they remain valid.
It is likely that at each stage during the project further funds are released to scale up the
project as more information emerges. Innovation projects are not always small
speculative pieces of work, they can escalate to become large undertakings as
justification remains valid throughout the review stages.

Business model canvas approach

An approach to creating a simplified business case is based on the work of Alexander
Osterwalder which takes a Lean Startup approach to business justification. Although
Business model canvas emerged as an approach to help start up businesses justify new
products it is equally applicable in an organisational context, particularly for innovation
projects.

11
Fig. 1 – Business Model Canvas template

The business model canvas utilises a single page template that captures all of the
relevant information needed to progress with a new product or business idea. The
template can be used as a review tool or to provide justification to proceed with an
innovation project.
The Business model canvas provides entrepreneurs, intrapreneurs and innovators with a
visual approach to describe the value proposition, infrastructure, customers and
finances. The canvas will help you to map, discuss and design a business model for the
solution or idea. When completing the canvas for a specific idea it is also worth exploring
how the idea is innovative. For example consider questions such as:
• Does it have a unique selling proposition (USP)?

• Is it a 'me too' innovation?

• How does it disrupt existing markets?

• How will the idea be protected from competition?

Definition – Intrapreneur
An organisational employee with an entrepreneurial mindset who is
sufficiently empowered to promote, instigate and drive organisational change
and innovation.

12
Applying the Business Model Canvas to an organisational business case scenario will
require some tailoring and adaptation so that it is suitable for an organisations specific
circumstances. To learn more about the Business Model Canvas visit the Strategyzer
website linked below:
https://strategyzer.com/canvas/business-model-canvas

Accelerating the Business Case

The innovation business case must be an agile business case. It would seem counter-
intuitive to attempt to deliver an agile project that was supported by a business case
process that was long, drawn out and highly detailed. The following points should be
considered to help accelerate the business case process:
• Timebox the process to develop the business case so that it forces the team to
deliver a minimum viable business case. The process to develop the business case
should not have numerous iterations and requests for additional information. The
minimum viable business case required for approval should be stated up front,
with additional information specified as 'could have' or 'would like to have' but not
essential. The minimum viable business case should address risk by limiting the
scope of impact to the organisation, perhaps by initially running a pilot or
producing a prototype.
• Involve the customer as early as possible. Involvement of the end user in the
business case process is essential to provide credibility. Making a decision to
proceed is far easier if the end user is an enthusiastic sponsor. Many business
cases attempt to second guess the customer through product research and
market trends. This approach results in a large amount of data that cannot easily
be verified. A more direct approach of involving customer / end user groups in the
justification should therefore be embraced.
• Provide a means to fail fast or pivot. Detailed justification and research is not
necessary and risk can be reduced by failing fast. During early stage delivery, as
more information becomes available, it might become clear that the original
justification is groundless. An acceptance that the project can be stopped early if it
fails to meet it's expected results will help with the justification and decision
making process. However, work that has gone into developing the business case
and project should not necessarily be thrown away. An assessment of
opportunities to pivot the project and move it in a different direction should take
place and, if necessary, a new business case developed.
• Build in a feedback loop that includes an impact analysis to assess new
information arising from 'What we know that we don't know' and 'What we don't
know that we don't know.' This will help to inform later justification stages and
build in an opportunity to assess unknowns that arise.

13
 • Justify in stages. Risk can be reduced by releasing budget at different stages of the
project. At each stage an assessment is made as to whether the project is still
justified. The major difference from a conventional project is that each stage
should aim to deliver some customer value, whether that be a prototype or mock
up that customers can use to help them understand the product or a limited pilot
that involves a select group of customers or super users. At each stage more is
learned about the value of the final deliverable and goes to further justify the
release of additional funds.
• Coach the organisation to align stakeholders with the process. Everyone involved
in the decision making process must be made aware of how innovation business
cases and projects are conducted. Without stakeholder alignment some
stakeholders might think that the lack of detail introduces risk. An understanding
of the process should help to alleviate that belief.
• Make the business case part of the idea management process. During the idea
lifecycle, from conception to delivery, numerous decisions must be made to assess
it's practicality, strategic alignment, potential benefits and scope. If the idea
management process is embedded into an organisations existing processes this
should not be a problem. The problem occurs when an idea management process
is developed in parallel to existing processes. This can result in a requirement for
re-justification, even after the idea has already been justified through the idea
management process. If the correct stakeholders are involved in the idea
management process and the stage gates are configured appropriately the idea
justification should feed directly into the project justification. For this to occur
decision makers involved in the idea management process must be adequately
empowered and the decision making process transparent.

5. Agile in an innovation project context

Agile is an approach to project delivery that has grown in popularity in the past 10 years.
Previous to that, agile was applied successfully to software development projects and
many agile approaches are still very much rooted in software development. However, a
number of agile approaches can be applied to any project where uncertainty, change and
early value delivery are factors.
Agile is a therefore a suitable and effective approach when applied to innovation
projects. Conventional project management approaches that are top down, document
rich and plan driven are typically not fit for purpose in an innovation context and a
blended agile approach should be used. Agile approaches can be applied to project
delivery and agile values considered in the wider philosophical context of an innovation
capability.

14
Agile value and behaviours
A number of overlapping values and behaviours are typical to a many of the different
agile approaches and these include, but are not restricted to, the following:
• Openness and transparency – Good interactions rely on an open environment
where team are comfortable to communicate good news as well as bad. In an
innovation project environment this is essential to ensure that risks and issues are
openly communicated early. Also, being honest about the real value of a project
rather than perceived or desired value will help maintain focus on the most
important deliverables.
• Collaboration – Innovation rarely happens in isolation. Where there is uncertainty
many minds can help to create something that offers real value. Delivery teams,
subject matter experts from the customer and supplier side and senior
stakeholders must collaborate across all stages of idea management to deliver the
right result.
• Early and iterative delivery of value – Agile approaches rely on delivering value
as early as possible. This is done by decomposing and prioritising requirements
and then delivering the components that will provide the most value first. An MVP
can be used to test the market or user requirements first before enhancing and
improving on the product. In an innovation context this approach is valuable to be
able to test the market appetite for the product before committing additional time
and investment.
• Embracing change – Change is inevitable, but in an agile environment change is
not considered bad. Change is embraced and helps to deliver a more accurate
final product. New information always emerges during the delivery of a project
which must be embraced and reflected in the project deliverables. Conventional
projects often produce detailed plans and Gantt charts. In an innovation context,
where there is a high level of uncertainty, it would be counter productive to
produce a detailed plan. That's not to say that a plan does not have value, it just
means that early stage plans must be higher level, with the detail emerging as the
project progresses. Embracing and responding to change will avoid the significant
overhead of scope re-approval and detailed re-planning.
• Continuous improvement / learning – Feedback loops are common in an agile
environment. Not only are feedback loops important for the design of the product,
but they are also important for team dynamics. A Kaizen approach to delivery
helps project teams to continually reflect and improve.

15
 Definition – Kaizen
Kaizen is the Japanese word for "improvement". In business, kaizen refers to
activities that continuously improve all functions and involve all employees
from the CEO to the assembly line workers. Kaizen is core to the Toyata Lean
manufacturing method where small incremental improvements are
continually made to the manufacturing process.

• Visualisation / Rich communications – Being able to visualise complex concepts

and processes makes them easier to understand. The use of whiteboards, sticky
notes, stand up meetings and process flow boards are common to agile. In an
innovation context it is important to encourage an environment that promotes
creativity and new ideas. Heavy document and process driven approaches, typical
in conventional project management, will not create an environment that is
conducive to innovation.
• Quality – It could be argued that the entire purpose of agile is to deliver quality
quickly. Feedback loops, continuous improvement and good team dynamics all
result in the delivery something that is fit for purpose. By eliminating unnecessary
functionality and focusing on the most value adding components first, the
customer gets what they want. Nothing more. Nothing less.

The Agile Manifesto

The agile manifesto was published by a group of independent thinkers in 2001 to counter
conventional waterfall methods for software development.
The values of the agile manifesto:
We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:
• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.
There are also 12 underlying principles to the agile manifesto which go beyond the scope
of this guide but can be found at http://agilemanifesto.org/
The agile manifesto was the starting point for a number of different approaches and
frameworks that have emerged during the subsequent years. Although the agile
manifesto was software focused, many agile approaches can be applied to any project.

16
Common agile approaches
Scrum
Scrum is one of the more commonly known agile frameworks that provides a process for
delivering products. It is based on the values of courage, focus, commitment, respect and
openness.

Fig 2. Scrum process.

Scrum has a number of roles (product owner, scrum master and development team),
artefacts (product backlog, sprint backlog and increment) and events (sprint, sprint
planning, daily stand-up, sprint review and retrospective). It provides agile teams with a
repeatable and continuously improving method to deliver products.
The product owner (user representative) builds user stories that feed into the product
backlog. These are then discussed and prioritised and the development team plans which
backlog items they can deliver in the next Sprint (usually a time period not exceeding 4
weeks). This will form the Sprint backlog. After the planning meeting the development
team will start work on delivering the increment from the sprint backlog. During the
sprint the Scrum master can help to facilitate daily stand up meetings (usually a short 15
minute meeting) where the development team discuss what has been delivered, what
they will be working on and whether they have any impediments. It is the Scrum masters
responsibility to remove impediments for the team and coach the wider business on
Scrum. The Scrum master is a servant leader to the team who are self organising and
empowered to make decisions relating to how they go about delivering the sprint.
At the end of the sprint it is expected that something of value is produced (the increment
or a potentially shippable product) that can be demonstrated at a sprint review meeting
which is attended by user groups. The outputs and decisions from this meeting then feed

17
back into the Product Backlog for inclusion into later sprints. The development team also
have a sprint retrospective after each sprint to discuss team dynamics, behaviours and
how well they worked as a team, identifying improvements to be implemented in later
sprints.
Scrum is an effective and continuously improving approach to delivering products that
aims to provide some incremental value to the customer after each sprint.
In an innovation project context Scrum enables delivery teams to breakdown user
requirements, identify which aspects offer the most value, deliver them early and then
benefit from learning which can be fed back into the sprint process. With sprints being
no more than 4 weeks it allows the team to focus on delivering minimal viable products
and then building on them in later sprints. Empowered delivery teams are able to work
unhindered in a low bureaucracy environment. The product owner role and sprint
reviews also maintain a close connection with the customer so that the deliverables are
fit for purpose. Retrospectives take a Kaizen approach to inspecting team effectiveness
on a regular basis and then improving continually.
An innovation or project manager would need to understand where their role fitted into
a Scrum organisation and appreciate that top down management goes against the
philosophy of agile. It is possible that a Hybrid role, where the innovation or project
manager acts as either a product owner or scrum 'leader' might be appropriate.
Scrum, as it stands, is an effective delivery approach for innovation pilots, prototypes and
small projects. For larger more complex projects a number of approaches exist that scale
up the use of Scrum into multiple teams. These approaches include Scrum of Scrums,
Nexus and SAFe.
For more information the Scrum guide is available here:
https://www.scrumguides.org/

Kanban
Kanban is a Just in time (JIT) scheduling system which aims to prevent the build up of
work by pulling work items into production and therefore reduce bottlenecks. The
'pulling work' approach is counter to typical project management approaches where
work is allocated to individuals and then individual capacity is used to plan a critical path
based on resource availability. The number of work items are restricted at various stages
in development which creates a queue for work items and highlights where effort is
required.
Should a build up of 'ready' work occur at a previous stage, which cannot move into the
next stage due to Work in progress (WIP) limits, then all effort is allocated to clearing the
back log so that work can flow freely again.

18
 Definition – Just in time (JIT)
Just in time is a manufacturing process related to Lean which is aimed at
reducing lead times and response times and reducing waste. The process was
initially used at Toyota to improve the efficiency of the manufacturing process.

This approach requires multi-skilled teams rather than specifically skilled individuals to
perform tasks. Multi-skilled teams can therefore focus effort at any stage during the
process. For example, in a marketing campaign, the development team might comprise
of a team who are multi-skilled in digital marketing, promotion, marketing
communications, design and proofing. During the campaign all members of the team can
then work on any one area of the project. There will likely be experts in specific areas
(such as Digital marketing) but they will also have skills in other areas.

Fig 3. Kanban board.

Kanban is usually characterised by the use of Kanban boards which clearly illustrate the
work-flow in a visible location or shared system which is available to all participants.
Kanban boards display the work-flow on sticky notes or cards that display essential
information relating to each work item such as an identifier, brief description, estimates
and who the work is assigned to. More information can be stored on the card
(particularly in digital systems) but it needs to be easy enough for anyone viewing the
board to understand the overall status of the project. WIP limits are usually denoted by a
number in brackets at the top of the board and work is 'pulled' from the done columns
when there is capacity in subsequent columns.

19
In an innovation project context Kanban is a very useful approach to improve work-flow
and continuously deliver value. In matrix managed organisations it might be difficult to
negotiate an individuals time to work on certain aspects of a project, particularly when
there are day to day business demands that are often deemed more critical than
innovation activity. Kanban can help to resolve these issues by focusing a delivery team
on a specific innovation product backlog and empowering the team to deliver value
derived from the prioritised backlog. In many ways this focused approach is far more
efficient than a matrix organisation where working on different projects and day to day
demands can create diversion and interfere with project delivery.
For teams that are not co-located it will be necessary to provide a digital means to
display project flow and a number of team Kanban tools can be used for this such as
Trello, Leankit and Kanbanize.
A more detailed explanation of Kanban can be found here:
https://kanbanblog.com/explained/

Scrumban
Scrum and Kanban are complementary in many ways and a Kanban flow system can be
applied and used within a Scrum framework to enhance the effectiveness of product
delivery. This approach is sometimes referred to as Scrumban. Established agile teams
may use this approach or tailor their own own approach that integrates different
elements of Scrum and Kanban. Kanban does not include elements of time-boxing or
specific roles and it does not focus on a specific product. Applying the workflow
principles of Kanban to a Scrum sprint will enhance the project delivery capability within
an innovation environment. Kanban can be applied to Scrum in a much broader sense
but this is beyond the scope of this guide. More information on Scrumban can however
be found here:
https://www.agilealliance.org/what-is-scrumban/
In an innovation project context the use of Scrumban would need to be tailored
appropriately so that it is focused on continual value delivery. It will be more appropriate
where an agile innovation delivery team is responsible for a portfolio of projects,
prototypes and pilots. The Scrumban approach can then be refined and improved as
different projects are delivered and team become more familiar with agile.

Lean Startup
The Lean Startup is an agile approach defined by Eric Ries in his book The Lean Startup.
Lean Startup is aimed at providing start up businesses with a methodology that will result
in faster product success. The foundation of Lean Startup is Build – Measure – Learn,
where an MVP is built and presented to the market and a feedback loop enhances and
improves the final product based on customer feedback.

20
The MVP might only be a promotional web page or a basic prototype that is used to
gauge market reaction to the product. The results are then measured in terms of uptake,
usability, function and feedback and the learning is then fed back into the next iteration
of the product. The advantage of this approach is in the value of real market testing.
Innovators often have good ideas but business cases and business plans only provide
theoretical evidence that the product will be successful. The reality is often very different
from what has been predicted in the business case. Markets react in unpredictable ways
so testing a minimum viable product in a real market will produce valuable feedback and
save significant cost if market predictions are wrong. If necessary the idea can be failed
at an early stage or pivoted in a different direction before too much investment is
committed.
Lean Startup has much in common with other agile approaches and is particularly
relevant in an innovation project context because it addresses uncertainty directly by
delivering an MVP early and learning from the feedback. This approach is compatible
with the Innovation Business case approach that recommends a business case that is
both high level and flexible. Lean startup is not only applicable to startup businesses. The
PRINCE2 Agile® manual states that: “Lean startup is often cited as demonstrating how
agile can work when faced with high levels of uncertainty, and there are parallels
between growing a small company (often using ‘disruptive’ technologies) and running a
challenging project.” Innovation is often referred to in organisations as
Intrapreneurship, where entrepreneurial values are applied to corporate programmes to
support the successful delivery of innovation. The principles of Lean startup should
therefore be considered in the context of all innovation projects.

Lean / Lean Six Sigma

Lean is a system derived from the Toyota Production System in the late 1940's. The basic
Lean principles are:
1. Identify value.
2. Map the value stream.
3. Create flow.
4. Establish pull.
5. Continuous improvement.
6. Customer needs sit at the centre of the Lean process.
Six sigma is a continuous improvement methodology that aims to eliminate defects and
waste and thus improve quality in processes, products and services. It was successfully
introduced in Motorola in the 1980's.
Both the Lean and Six Sigma methodologies aim to achieve the same goals but they do it

21
in a slightly different way. Using both approaches in tandem has been proven to be very
successful.
A detailed overview of Lean Six Sigma is not necessary here. Many of the Lean principles
are built into Agile ways of working, because Agile builds on Lean. It is however useful to
understand what Lean Six Sigma is to highlight it's importance as an underlying
approach. The Project Management Institute provides an overview of how Lean
principles might be built into the project environment (linked below). This will provide a
wider understanding but it is not specifically relevant for innovation projects.
For more information on Lean and Lean Six Sigma in a project context the following links
will help:
https://kanbanize.com/lean-management/what-is-lean-management/
https://www.pmi.org/learning/library/lean-project-management-7364

DSDM / Agile PM
Dynamic Systems Development Method or DSDM is an Agile method that is primarily, but
not exclusively, focused on software development. As with other Agile approaches, DSDM
aims to deliver value to the customer early. It does this through eight core principles:
• Focus on the business need.

• Deliver on time.

• Collaborate.

• Never compromise quality.

• Build incrementally from firm foundations.

• Develop iteratively.

• Communicate continuously and clearly.

• Demonstrate control.

AgilePM® is a project management approach that is optimised for use in an Agile DSDM
environment.
The following link provides more information on AgilePM®:
https://apmg-international.com/product/agilepm

PRINCE2 Agile and PMI Agile

PRINCE2 and the Project Management Institute (PMI) are the two most commonly known
approaches to project management and both have embraced agile to some extent. Both
offer qualifications that provide a blended approach to project management and agile

22
ways of working and both include the most common agile approaches such as Scrum and
Kanban. Gaining a basic understanding of one or both methods is highly recommended
for innovation practitioners that have project delivery responsibilities.
The project management approaches (including AgilePM) are all of value in an innovation
context but they do not specifically provide the practitioner with innovation project
guidance, which is the aim of this guide.

Others
There are a variety of other Agile approaches, many of them relating to IT systems
development, and some enabling scale up for large complex projects with multiple
interdependencies.
IT based Agile approaches include DSDM, Extreme Programming (XP) and Crystal.
Scale up Agile approaches include Scrum of Scrums, Nexus and Scaled Agile Framework
(SAFe).
A detailed discussion of these frameworks is out of the scope of this document but,
depending on the organisation and nature of the project, the innovation practitioner may
encounter one or more of them so it is worthwhile having an awareness.

Agile tools and techniques

Burn charts
Burn up and Burn down charts provide a visual overview of project delivery progress.
They often relate to the sprint level progress rather than overall project progress. For
more information on Burn charts the following link might help:
http://www.clariostechnology.com/productivity/blog/burnupvsburndownchart

Retrospectives
Retrospective activities allow teams to focus on continually improving their approach by
periodically reviewing team performance in terms of behaviours, relationships, skills and
other activities. The retrospective should focus on the 'how' rather than the 'what' so that
lessons learned can be applied to any piece of work or project. In an innovation context
retrospectives are an important way to improve delivery approaches if teams are
breaking new ground and there is a lot of uncertainty.

Stand-up meetings
Usually associated with Scrum, a stand-up meeting is a short regular meeting (usually 15
minutes daily) so that teams can discuss what they have been working on, what they
intend to work on and if they have any impediments.

23
 Definition – Impediment
An impediment is an issue or blocker that is preventing progress on a piece of
work. Impediments may or may not need to be logged as issues in projects.
Usually anything that can be resolved quickly would not need to be raised as
an issue. Impediments might also be raised as risks for future issues that have
not yet occurred.

The information collected in the meeting can then be updated on a display board which
is easily visible to the team and other stakeholders. The Agile coach or Scrum master
would take responsibility for working with other stakeholders to remove any
impediments.

Estimation
Estimation in an innovation context needs to be more fluid and flexible than a
conventional project, where Gantt charts and critical paths are produced over longer
time horizons to estimate how long each part of the project will take. Agile takes a
different approach which is more compatible with innovation projects. Project
components are broken down into releases and tasks and then estimated in terms of
approximate effort. Effort is not usually defined in man hours, rather, it is defined as a
relative measure according to other tasks, for example, a large, medium or small task.
Work is them completed in short sprints (usually no longer than 4 weeks) and delivery
velocity can be tracked and used to refine future estimates. Agile projects aim to deliver
value as early as possible by focusing on the most important project components
according to the users or customers. Therefore, long term planning of an end product is
going to be less accurate where minimum viable products and prototypes are being
developed to demonstrate overall project viability. This is not to say that long term
planning is redundant. Higher level plans will still make use of Gantt charts, but the
expectation is that the detail is at a high enough level to allow for flexibility in terms of
what is delivered.

Rich communications
Agile makes use of big visible boards (such as Kanban boards and information radiators)
to display information to the team and other stakeholders. This helps to eliminate the
need for regular reports, update meetings and progress reviews because stakeholders
can visit the team room and view the information on the board for themselves. In
addition to visible boards innovation teams need to make use of informal
communications, workshops and visualisations to communicate project performance,
decisions, requirements and intentions. This level of informality is not without risk, but it
can be managed.

Collaborative tools and packages

There are a wide variety of different tools and solutions available to download or to use

24
online that can help bridge the gap between distributed teams. Many of these tools use a
Kanban approach to display and allocate work tasks and have a number of advantages
over email and conventional project planning tools.
Some examples are listed below:
• Trello is a Kanban tool that allows tasks to be created on lists that appear on a
Kanban board. The solution is free to use and allows for customisation so that the
board reflects almost any way of working. Teams can collaborate and allocate
tasks to each other and attachments, images and check-lists help to enrich the
user experience. https://trello.com/
• Jira assists with planning, tracking, reporting and releasing of projects. It is a
workflow based planning tool that provides the ability to set up more complex
workflows than a simple Kanban approach.
https://www.atlassian.com/software/jira
• LeanKit was acquired by Planview in 2017 and in their own words it “supports the
implementation of Lean principles, practices, and work methodologies across all
business functions, to help organizations create an environment of continuous
improvement and innovation to deliver customer value, faster.” It is a highly
functional enterprise platform that allows for collaboration and customisation.
https://leankit.com/product/
• Yammer is an Enterprise Social Network (ESN) that integrates with other Microsoft
products such as Sharepoint and Office. https://www.yammer.com/
• Slack is a collaboration tool that allows teams to work together using chat, audio
or video conferencing. Channels can be created for specific projects or delivery
teams, essentially creating an online team room where stand-up meetings and
retrospectives might occur. https://slack.com/
• There are many other agile tools and solutions available and the above provides
only a small selection. In addition, many idea management solutions such as
BrightIdea and Solverboard also have project planning capability built in to allow
ideas to mature from conception through to value delivery.

6. Project risk management

Managing risk on an innovation project requires a different perspective to conventional
project risk management. Innovation projects break new ground which means
uncertainty is higher and projects are subject to more risk and a larger number of
changes and issues as new information is uncovered. Additional attention should
therefore be paid to innovation project risk without unduly stifling the project with

25
excessive risk management formality and risk aversive policies.

Risk factors in innovative projects

The risk management approach must be adapted to accommodate the following factors:
• Continuous changes to the scope of what is being delivered.

• External factors and new information having a higher influence on project

direction.
• Increased customer and end user involvement.

• Less focus on detailed long term plans.

• An appreciation that higher risk potentially results in higher returns, but also a
higher failure rate.
• An expectation that risk is likely to be higher probability but lower impact with a
lower emphasis on mitigation and contingency planning.

Risk profile of innovative projects

From a wider organisational perspective innovative projects should be managed with an
understanding of where they reside on a risk profile in relation to other projects.
Innovative project risks are expected to be higher in terms of probability resulting in
more issues and changes, but there should be a focus on reducing the overall impact to
the organisation in terms of cost, resources and reputation.

Fig 4. Innovation project risk matrix.

• Projects in the bottom left quadrant have a high level of certainty and will often be

26
 classed as 'business as usual' or repeatable projects. These are not likely to be
breaking new ground and would not normally be considered innovative.
• Projects in the bottom right quadrant have a high organisational impact and will
often be large scale organisational change projects such as major infrastructure
implementations or large transformation projects. While there may be elements of
innovation in these projects the delivery of innovative ideas should not unduly
impact the organisation and impact should be reduced using the risk management
approaches set out below.
• Projects in the top right quadrant are usually considered too risky and would need
to be de-risked in some way before initiating.
• Projects in the top left quadrant will include innovative projects where there is a
higher risk of change and issues occurring due to uncertainty but the overall
impact on the organisation should be lowered by using appropriate responses.

Innovation risk management responses

Innovative projects are, by their nature, more risky, but not necessarily in terms of
overall impact to the organisation. While there is a higher probability of issues and
changes occurring they should not result in a damaging impact to the organisation. To
reduce overall impact it is necessary to manage the project so that change can be
accommodated without resulting in an overall larger impact. Responses that should be
considered include:
• Shorter or more frequent stage gates that assess the project at regular intervals.

• The delivery of value as early as possible through prototypes, spiking, pilots, mock
ups and minimum viable products. This will result in feedback and learning that
will result in a more accurate final product that meets the needs of the customer.
• The application of a continuous feedback mechanism that tailors the project
approach as new learning emerges.
• An ongoing focus on the business case to ensure that, whatever the project
delivers, it is in alignment with the expected benefits or that unexpected benefits
are approved and integrated into the business case.
• A fail fast or pivot fast approach (see below) where projects that are unlikely to
achieve the stated benefits in the business case are closed at the earliest
opportunity or redirected in such a way that they result in an improved business
case.
• Informal risk recording and assessment, perhaps by recording risks during stand
up meetings on a white board where they can be viewed by all interested
stakeholders. Although risks can be captured in a risk register, the formality

27
 around managing them by assessing contingency and mitigation planning should
be minimised.
• The spread of resources across multiple small projects to reduce risk (See
portfolio management).

Failing fast / Pivoting fast

Occasionally a business case will no longer be able to achieve it's defined benefits and
deliver value to the organisation. This might be due to spiralling costs, new information
that results in an impact to the expected value or a change in organisational strategic
direction.
There is often a temptation to continue to push ahead with projects, particularly when
there has already been a significant investment of time and cost. Rather than attempting
to deliver something of reduced value, it is usually better to fail fast and allocate
resources to higher value propositions. This is particularly the case with innovative
projects when the probability relating to the value of the project is far less certain.
An alternative to failing a project completely is to pivot (see Lean Startup). This means
that work already done on the project is assessed to establish if it can be re-purposed to
meet a new business case. Pivoting can be used if the new business case remains strong,
but it should not be considered as an option only for the purpose of justifying time
already spent on the project.
Failing or Pivoting decisions should be made as early as possible in the project to avoid
wasted resources and the learning from projects should be fed back into the innovation
pipeline.

Fail / Pivot project assessment criteria

When assessing the project against the business case at regular intervals or stage gates it
should be assessed against a variety of criteria:
• Project cost and expected operational cost – If project costs are forecast to
exceed the potential value that the project will deliver then it will need to be
stopped or refocused. Agile environments reduce this risk by allowing zero
tolerance on time and cost, but flexibility on what is being delivered, provided it
continues to deliver value. Likewise, if something changes in the environment or
new information is uncovered that increases the operational cost then the
business case will need to be revisited. If a project is breaking new ground it is
highly likely that operational costs are going to become clearer as the project
progresses so it is important to factor this into the business case review.
• Overstated benefit – Pilots, MVP's and early stage prototypes can identify
problems with the expected benefits of the project. Perhaps market uptake is far
lower than expected, the solution doesn't achieve it's stated objective or it

28
 resulted in more pain than gain for the end customer.
• Organisational strategic alignment – Innovative projects might not always be
clearly aligned to core organisational strategy. Organisations that are innovating
sometimes need to 'test the water' when breaking new ground. During project
delivery it could become clear that the project is too far removed from the
organisations core strategy and so it will be necessary to explore alternatives or
close the project.
• External factors – It is essential that the team maintains a wider view of the
project context in terms of competing products, external risks and continued
relevance in the market. With innovative projects the environment can change
quickly and new technologies are often over-hyped. It is therefore important to
avoid falling into the 'bandwagon' trap, where organisations feel it necessary to
deliver a solution because it seems that everyone else is doing it. A persistent
focus on value will help to uncover 'bandwagon' projects.
• Delivery team capability – During the project it may become clear that the
delivery team lacks the capability to deliver the project effectively. If this occurs it
will be necessary to stop the project and revisit the business case to see if
alternatives exist such as 'buying in' a solution or outsourcing delivery.
• Pivoting a project – Making the decision to pivot a project in another direction
must be based on a strong case for doing so. For example, adapting the project
deliverables so that they can be used in a different market, or changing the
deliverables so that they deliver additional value. Pivoted projects will usually
need a new or re-approved business case to continue. This ensures that the stated
benefits are still acceptable and other changes (costs, skills, markets etc.) are
assessed for continued viability.

Agile risk
Agile can reduce risk in some areas but introduce risk in other areas. If using an Agile
approach it is worth considering the following:
• Too much reliance on the 'customer view'. In an Agile environment 'user stories'
are often used to define requirements. In an innovation context, where something
is completely new, the customer might not know what they want until they have
some exposure to the end product. So, while customer involvement is important
during design and idea development phases, it should not necessarily be thought
of as a panacea.
• Informality can improve agility but it can also introduce a lack of rigour,
particularly if the agile environment is not executed properly (fragile agile).
Projects should be assessed for their appropriateness for agile before they are

29
 initiated. PRINCE2 Agile® uses an approach called the Agilometer which uses a
scoring approach to assess agile project risk. See link for more information:
http://prince2agile.wiki/The_Agilometer
• Agile has its roots in software development and is, for the most part, designed
with effective software development in mind. The use of agile approaches in non-
software development environments should be carefully considered to establish
whether agile is appropriate as some tailoring will undoubtedly be required.
• Agile values must be embraced at all levels in the organisation to give it the best
chance to succeed. Core to agile are the underlying values and principles that
underpin the various frameworks and approaches. For agile to be effective, all
project participants should embrace these values and principles. If there is a small
concentration of dedicated 'agilists' in the organisation, without senior
management and stakeholder support, the approach will likely encounter too
much resistance to be effective. The agile manifesto provides an overview of agile
values and principles, but each framework and approach also has it's own set of
core principles that should be understood. A link to the agile manifesto can be
found here: http://agilemanifesto.org/.

Risk culture
Innovation is a risky undertaking due to the level of uncertainty. If the organisation has a
culture of risk aversion it is unlikely that new ideas will even reach the project
justification stage, let alone project delivery stage. Coaching and educating the
organisation through training and perhaps bringing in credible external consultants
might be necessary to help decision makers adopt a more positive attitude towards risk.
In the context of the portfolio management, a diversified portfolio that includes a mix of
different projects will reduce risk and increase the probability of delivering high value.
Any organisational portfolio should include an element of speculative innovation to
maximise the potential of high returns and protect the organisation from obsolescence.
Often overlooked is the question 'What is the risk of not doing this?'
An organisational culture that embraces some risk does not mean that the organisation
should be exposed to excessive risk, rather, it helps the organisation deliver more value
in an appropriately controlled environment. Embracing some innovation risk at the
project level reduces overall risk to the organisation. If organisations continually innovate
successfully they are ultimately protected from obsolescence.

30
7. Project planning
The accepted approach to project planning is to break down tasks, identify dependencies,
allocate resources, identify the critical path and produce Gantt flow charts. This approach
is valid for long term projects that have clearly defined objectives and an agreed
approach for delivering them. Innovative projects will, however, need to accommodate
factors that are common to innovation, including continued change, risk profile,
uncertainty and speed of delivery.

Approaches to planning innovative projects

1. Project initiation meeting – The agenda should include business case review and
objectives, agree broad delivery time-scales (high level), identify required
resources and contribute ideas in terms of how best to deliver the objective.
2. Agree working norms and procedures – For example, agree Agile approaches to
be used, how risks and issues are identified, define regular stage gates and
delivery time boxes, agree how the team will work together (particularly important
with remote teams) and define how the team will continually improve the
approach.
3. Identify Minimum Viable Product – Work with customers and the delivery team
to identify an MVP that meets basic requirements in the first stage. This might be a
small scale pilot, a prototype or a mock up.
4. Create a time-boxed plan – Break deliverables down into timeboxes that
potentially deliver some value to the end user or customer. A timebox might, for
example, deliver a website that defines what the final product is intended to look
like. A feedback form can then be used so that potential customers can provide
critical analysis or improvement ideas. There might even be an pre-order form
which would provide some statistics on potential demand.

Definition – Timebox
A timebox is a short period of time (usually a period of weeks rather than
months) which a delivery team uses to deliver a piece of functionality.
Timeboxes are fixed, but it is expected that functionality is variable with 'Must
have' functionality being delivered as a minimum requirement. Scrum uses a
time-boxed approach to deliver projects by having time-boxed sprints that aim
to deliver value after each sprint.

5. Prioritise 'Must have' functionality – Customer or user groups should define

what is essential in the proposed MVP and also provide lower priority
requirements. Essential functions are mandatory and delivered first followed by

31
 lower priority functions.
6. Learning and feedback – With the level of uncertainty associated with innovation
it is essential to provide a mechanism for continuous improvement to both
working practices and what is being delivered. Regular retrospective reviews and
functional reviews should therefore be planned. Lessons learned are therefore
gathered during the project and applied continuously.
7. Allow zero tolerance on project delivery time – Innovative projects need to be
delivered quickly due to the nature of rapid change. By having a zero tolerance on
project delivery time it forces the delivery team to flex what they are able to
deliver during the allotted time. The functionality of the final product must
therefore be negotiated with customers and user groups throughout the project.
The MVP is the absolute baseline product that the team must deliver, in addition
to this there should be lower priority functionality that the team will endeavour to
produce during the available time. The final product is therefore delivered on
time allowing for feedback and improvements that can be planned later. This
ultimately results in a final product that meets the needs of the user and achieves
the benefits of the business case.

8. Innovation project stages

The idea management process
The idea management process will usually precede innovation projects, where new ideas,
concepts and opportunities are explored, reviewed and rejected or recommended. Even
prior to this there should be some effort to define the challenge which is early
justification for generating ideas. Challenges will typically respond to organisational
strategy and should provide some specific guidance relating to the problems being
solved. Ideas that respond to challenges are typically high level, perhaps a single page
overview. These are then reviewed in a number of ways, through criteria assessment,
peer review, subject matter expert review and management review. Ideas that are
successful at this stage are then recommended for business case development. This is
where a project is started (in PRINCE2 this might equate to the SU Start-up stage).
Following the business case production the project will be initiated and the solution
implemented. There are various project stages within the implementation stage as the
project is iterated and value delivered. Once the solution is delivered it will still need to
be managed and, from an innovation perspective, the value of the solution must be fed
back into the idea management process so that the entire innovation capability is
justified and continuously improved.
In the diagram below, the Idea Management process shows where Innovation projects

32
are justified and delivered, including an element of embedding into business as usual. In
agile environments a final deliverable is likely to be replaced by continuous iteration of
value which makes the hand over to business as usual more of an iterative process. In
this scenario project delivery experts might move onto other projects, but those with
responsibility for identifying and valuing innovation (usually innovation managers) will
continue to remain involved in the solution delivery in a consultative role working closely
with product managers to continually assess value.

Fig 5. Idea management process and project context

Typical project budget stage gates

The 'project' elements of the idea management process can be broken down into more
detail to demonstrate how an innovation project might be continually justified.

Fig 6. Innovation projects budget management

In the above diagram, tranches of budget are released as each stage demonstrates value
so that further stages can be justified and funds allocated to deliver more significant

33
undertakings. During each project stage learning, new information and a demonstration
of value continually builds confidence and justifies larger investment into the solution.
This approach is counter to a large up front investment being made on the basis of a
detailed business case. The approach also helps to reduce the risk of uncertainty and
continuous change as failing projects can be stopped before too much time and money is
committed.
Stages and approaches to justification will vary from project to project but it is important
to assess how each stage provides value to the end customer. Even a prototype can add
value by giving the customer something that they can use to help them understand and
provide validated feedback on their requirements.
Once the full deployment is delivered and the project is moved across to business as
usual it is likely that further development will occur to continually improve value. A
method of tracking value after the project has been delivered is necessary to provide a
means to fund future innovation efforts. Those responsible for innovation therefore
continue to have a consultative role when projects are delivered into Business as Usual
(BAU).

9. People factors
Innovative projects have their own challenges in terms of how delivery teams are
organised and stakeholders engaged. How this is done will depend on many factors but a
few points to consider are listed below:
• The complexity of an innovation project often requires the involvement of diverse
skills and experience from across the organisation. These skills are not always
locally available resulting in a distributed team. Remote working practices such as
regular video and audio conference meetings and the use of team tools such as
Trello, Slack and others need to be leveraged to make project delivery and
communication as effective as possible. An additional overhead for project
management and coordination should therefore be factored in.
• Senior stakeholders need to be coached on the reasoning and benefits of
methodologies associated with delivering innovative projects. At least one senior
stakeholder should be well versed and act as an advocate for innovation.
Stakeholders must also be made aware of agile approaches and how they can
support agile projects. Agile is not something that can function at the delivery level
only. Agile values must also be embraced by leadership in the organisation.
• Delivering innovation will usually require new skills that the organisation does not
possess. This might relate to new technology, agile approaches and unfamiliar
software. Online training can quickly help to re-skill existing teams and there are a

34
 number of online platforms such as Udemy.com and Lynda.com. These can help
to fill skills gaps quickly and inexpensively.
• Matrix teams are unavoidable in complex organisations and delivering innovation
is no exception. Despite agile principles suggesting that teams should be co-
located and focused on a single project this is not always possible. The primary
challenge associated with a matrix team in an innovation context is justifying the
priority of innovation. Business as usual (BAU) will frequently take precedence
over innovation because innovation relates to some future benefit, while BAU
must be maintained on a day to day basis. When issues occur innovation is often
de-prioritised. This can lead to innovation projects being continually impacted by
issue resolution on BAU projects. Some way of protecting allocated resources
from BAU issues must be agreed so that the innovation project is not unduly
impacted. If resources must be drawn away then their time away should be logged
as 'resource debt' and re-payed once the business issue is resolved. This, of
course, does not help with the negative impact and interruption to project flow so
it should be logged as a risk and additional mitigation and contingency actions
identified. Senior management should also be supportive of the importance of
innovation and therefore 'borrowing' resources should be discouraged.
• Dedicated innovation teams can provide focus on innovation but they can also
become disconnected from the wider organisation. If an innovation team becomes
a silo it will be difficult to influence and manage resources from across the
business. An innovation process can be managed by an innovation team, but
innovation is delivered by resources from across the organisation. Innovation
teams must therefore be empowered and should build effective relationships to
avoid becoming too far removed from the business.

The innovation project manager

The innovation project manager must have additional skills and responsibilities
compared to a conventional project manager. Although roles and responsibilities will
vary, some common differences are highlighted in the table below:

Project manager Innovation project manager

Develops detailed plans. Develops emergent high level plans.
Estimates and controls budget to deliver Estimates budget required on a stage by
entire project. stage basis.
Controls time management of project Coordinates value delivery of project
resources. products. (Often done in association with a
Product Owner).
Breaks down deliverables into stages and Defines and coordinates project stages and
tasks. releases so that sprints or sub-stages

35
 achieve value.
Change often perceived as issues or risks. Change embraced as potentially positive.
Monitor progress against plans. Monitor progress against value and
continually justify project.
Document management, version control Light weight documentation and informal
and delivery of progress / exception reporting where possible.
reports.
Focused on project delivery and handover Focused on idea management process and
to BAU. value delivery.
Team management and leadership. Servant leadership and coaching.
Aligned to project team to achieve project Aligned to customer to achieve value
delivery. delivery.
Responsible for project delivery. May have additional responsibility for idea
management process including projects,
portfolio and innovation capability
management.
Responsibility for solution ends when Remains actively consulted and informed
project ends and handover is complete. on value after project is delivered.
Frequently uses waterfall based project Mostly uses Agile based project
approaches, sometimes uses Agile. approaches.
Uses tools such as risk registers, issue Uses tools such as collaborative planning,
registers, Gantt charts, product visual information boards, kanban boards,
breakdown structures, critical path and burn charts and stand up meetings.
planning meetings.
Responsible for delivering one or two Often focused on delivering multiple
major projects. innovation projects all at different stages.

10. Eliminating project bureaucracy

Conventional project management, waterfall systems and application development life-
cycles have often been criticised for being too process driven, resistant to change and
bureaucratic for some projects. This has led to the rise of Agile and PM Lite approaches
and also resulted in methods such as PRINCE2 embracing 'tailoring' as a concept.
Innovation projects need to embrace change and deliver quickly, which is why agile
concepts figure prominently in this guide. Other areas where process and bureaucracy
need to be broken down include:
• Documentation – Not all standard project management artefacts need to be
documented in text documents or spreadsheets. Risk registers, Issue registers,
reports, plans etc. might be recorded on white boards, discussed informally or
compiled together in an online shared space. When creating documents to

36
 support project management the purpose and readership should be questioned.
The key question to ask is 'Is this document absolutely necessary for the success
of the project or is there another simpler way to convey the information?'
• Reporting – In a matrix managed environments where resources and
stakeholders are geographically spread out a situation can arise where project
participants are creating multiple reports with the same information for different
audiences. Maintaining a centralised, real-time project dashboard that can be
accessed by all interested stakeholders is be a better approach, but also
minimising the information to only what is necessary should reduce overhead.
• Business case – Achieving the benefits set out in the business case is core to the
success of the project. The business case does therefore need to be documented
and base-lined. However, the requirement to reassess the business case at regular
intervals means that it should be easy to amend the information and compare it
against the baseline. A business case might therefore be produced in a
spreadsheet or on a few presentation slides to convey the essential information.
The business model canvas is a good approach to preparing a simplified business
case (see Business Case section). The underlying research, learnings and
information can be archived, referenced and referred to if necessary. Avoiding
long multi-page business cases that take months to produce is strongly
discouraged. Keeping it simple and testing concepts in the market is far more
effective than producing complex, detailed and highly assumptive forecasts.
• Document contents – Some documents such as Business Cases and Project
Charters might be deemed necessary depending on the organisation. However,
the standard sections in these documents should be minimised to only the
information necessary to serve it's baseline purpose. Duplication of information
across different documents should also be avoided.
• Meetings – Meetings can be highly valuable but can also waste a lot of time. They
are important to gain approvals, solve problems and convey information but their
time should be concentrated and attendees should include only essential
stakeholders. Agendas that include the purpose of the meeting and the desired
objective should be provided beforehand so that attendees understand what is
expected of them. During meetings the flow and conversation should be focused
on achieving the objective. Any interaction that does not relate to the meeting
objective can be captured and followed up later. Teleconference meetings also
need to be carefully managed. Participants should agree, in their working norms,
that they will engage and pay attention during teleconferences. Once the objective
is achieved the meeting should end.
• Informal interactions – In an environment where trust is highly valued, informal
interactions should be embraced. A conversation at the coffee machine can often

37
 convey more useful information than a long detailed email. Furthermore
conversations help to build relationships where the use of written communication
often creates barriers and misunderstandings.
• Visualisation – 'A picture can convey a thousand words'. Making use of visual
imagery, simple prototypes, mock up screens etc., can help to get the message
across far more easily than a detailed functional specification for example.
• Challenging processes – Challenge processes that seem unwieldy or time
consuming, particularly if there does not appear to be a good reason for doing
something a certain way other than “This is the way we've always done it.” If there
is a more efficient way to do something then the innovation delivery team should
test the approach and feed their learning back into the organisation.

11. The Innovation Portfolio

Although somewhat beyond the scope of project delivery, the innovation portfolio is still
important for the innovation project manager to understand so that s/he can see where
their project(s) fit into the larger context. This helps with planning and decision making as
the innovation project manager sees the bigger picture.
Delivering innovation can be a somewhat speculative exercise and needs to be managed
accordingly. An innovation portfolio, in contrast to a standard project portfolio, is likely to
contain a number of highly speculative small scale projects.
To use an analogy; a well diversified personal investment portfolio might include a small
high risk / high return speculative element balanced off with a variety of lower risk long
term investments. The same is true with organisational portfolio's where the innovative
element might be compared to the small high risk / high return component of a personal
investment portfolio. Within the innovation portfolio there will also be a spread of risk
across different projects which might include some or all of the following criteria:
• Size / Scope – A number of small projects at different stages balanced against
larger scale projects that cover a wider scope.
• Risk – More speculative projects where there is more uncertainty balanced against
projects where the outcomes are more certain.
• Strategic alignment – A balance of projects that deliver value to different parts of
the business.
• Innovation type – Innovation can be assessed on a sale from incremental or
continuous improvement to disruptive or revolutionary. Creating a portfolio that
has a balance of different types of innovation will ensure that the innovation
capability is not just focused on one area (continuous improvement for example).

38
 • Other criteria - such as whether the idea is an internal improvement, product,
service, business to business service or business to consumer service might be
used as appropriate.

Innovation portfolio bubble diagram

The example bubble diagram below demonstrates how an innovation portfolio might be
assessed for balance. In this example each idea is represented by a bubble of varying
size. The colours represent the idea management stage and the X and Y axis represent
the market size and type of innovation. Displaying the X and Y axis this way provides the
observer with a view of the level of risk of the overall portfolio. Bubble diagrams can also
help to identify if there are too many groupings in any one area which can highlight
problems.

Fig 7. Innovation portfolio bubble diagram

Strategic alignment
The innovation portfolio should be strategically aligned with the organisational
objectives. This does not however mean that the ideas being approved for innovation
projects should only be incremental improvements or 'me too' innovations. There should
also be an element of radical or revolutionary innovation that stretches the boundaries
of what the organisation considers core business. For example, Kodak invented the
digital camera in the 1970's but they failed to develop the idea further due to the risk of
cannibalising their existing business. This short sightedness exists in many organisations

39
and it is particularly prevalent when large investments are made in infrastructure that
supports existing business models. The fear of damaging returns on existing investments
exceeds the fear of losing business to competitors and new entrants.
What is considered 'core' business should therefore be flexible enough to accommodate
customer preferences. This may go beyond existing capabilities.
Existing products and services can also be considered in the context of new customers
and markets that might not be considered core markets. Adopting a more flexible view of
'who the customer is' can provide new insights into the innovation portfolio.
In summary, the definition of strategic alignment requires stakeholders to be more open
minded than they might otherwise have been to prevent innovative ideas being stifled.
Decision makers must therefore be coached by innovation sponsors to enable innovative
ideas to be market tested. The idea management process for assessing ideas should also
be tailored to allow for a more flexible strategic alignment.

12. Project handover and BAU management

Value delivery
PRINCE2 defines a project as “a temporary organization that is created for the purpose of
delivering one or more business products according to an agreed Business Case.” When
delivering innovation we must take a step back and view the project as just one element
of the overall process, from idea conception to value delivery (which is usually achieved
long after the project has delivered it's products). The business case is usually built up
during the various phases of idea conception and development and then the value from
the business case is only delivered when the final products are fully operational and
providing revenue or cost savings. Agile also takes a less definite view of value delivery
because it is expected that the project will begin to deliver value continuously throughout
the project. This is done by producing an MVP and using that as the baseline to enhance
and improve the final product, which is never completely finalised as it too is subject to
continuous improvement. However, there will usually be a cut-off point where the people
delivering the 'project' will transition the projects deliverables across to a different team,
or at least a different operational process, to manage the product as a day to day
concern.
To measure the success of an innovation capability it is essential that innovation
stakeholders and sponsors remain consulted and informed on the success of the product
in BAU. The value (financial or otherwise) must be measured and a proportion attributed
to the innovation capability. How this is done depends on the organisation, but the
proportional attribution of value not only helps to justify the innovation capability, but it
also provides funding for future innovation projects. Many organisations have a venture

40
fund for the purpose of funding new innovative ideas. The revenue generated from
innovation projects should partly be used to replenish and grow the venture fund and
partly used to improve the organisational innovation capability. Therefore, appropriate
accounting procedures must be put in place to specifically measure the financial benefits
from innovation and allow them to be allocated accordingly.

Learning and continuous improvement

Innovation by definition means breaking new ground and attempting to do things that
might not have been tried before. The learning that arises during innovation will be
significant. Valuable skills, knowledge and experience will be gained along with lessons
relating to mistakes and things that could be improved. All of these learnings must be
captured somehow so that they can be integrated and applied to future work.
Conventional projects would usually document the lessons learned at the end of a
project so that they can be applied to future projects. In reality however many of these
'Lessons learned documents' get filed away and fail to provide sustainable change.
Rather than documenting lessons at the end of the project, learnings should be
addressed throughout the idea management process by continually making changes to
procedures and training additional team members in new skills and knowledge. The
wider organisation might also benefit from innovation learnings so a process to share
and embed the new learnings into the wider organisation should be adopted.

Retrospectives
Agile, more specifically Scrum, makes use of Retrospective meetings after each Sprint to
assess what went well, what should be improved and what should be changed in the next
sprint. Retrospectives can also be used to assess the entire project, the idea management
process and the ongoing management of operational products.
The retrospective process is particularly useful because it focuses on how the work was
done rather than what was delivered and the team involved commits to actionable things
that they will change. Retrospectives are therefore a useful tool to bring about
continuous improvement in processes and methods throughout the product lifecycle.

41
13. Additional information and reading
• PRINCE2 Agile Axelos - https://www.axelos.com/best-practice-solutions/prince2-
agile/what-is-prince2-agile
• PMI Agile - https://www.pmi.org/certifications/types/agile-acp

• Creativity and the Project Managers -

https://www.pmi.org/learning/library/creativity-innovation-project-management-
6037
• Agile Manifesto - https://agilemanifesto.org/

• The Scrum guide - https://www.scrumguides.org/scrum-guide.html

• Various Agile methods in project context - https://kanbanize.com/blog/right-agile-

methodology-for-your-project/
• Innovation and the project manager (PMI) -
https://www.pmi.org/learning/library/importance-innovation-project-
management-9858
• Agile and the Project Manager (PMI) - https://www.pmi.org/learning/library/agile-
innovation-project-manager-6758
• Design thinking and Project Manager (PMI) -
https://www.pmi.org/learning/library/design-thinking-contributions-project-
management-innovation-10054
• Change - https://www.innovationexcellence.com/blog/2018/04/23/changing-
change/
• https://www.strategyex.co.uk/blog/pmoperspectives/agile-prince2-and-pmbok-
how-they-fit-together/
• Business Model Canvas - https://strategyzer.com/canvas/business-model-canvas

• Innovation management 'v' project management -

https://lenbrzozowski.wordpress.com/2013/01/30/innovation-management-vs-
project-management/
• Managing innovation projects research paper -
https://www.pucsp.br/icim/ingles/downloads/papers/TL_038.pdf
• Barriers to innovation in project management - https://pmstudent.com/barriers-
to-innovation-in-project-management/

42
43