prince2 vs scrum in digital business...
TRANSCRIPT
PRINCE2 vs Scrum in digital business
transformation
Ajla Ćerimagić Hasibović
Department of Computer Science
Faculty of Electrical Engineering, University of Sarajevo
Sarajevo, Bosnia and Herzegovina
Anel Tanović
Department of Computer Science
Faculty of Electrical Engineering, University of Sarajevo
Sarajevo, Bosnia and Herzegovina
Abstract – This paper compares two project management
methodologies PRINCE 2 and Scrum in a case study of digital
business transformation. There is no universal methodology, that
could work for all projects, but digital transformation or Industry 4.0
indicates new management strategies, for which right framework is
almost mandatory. Paper also emphasizes that digital transformation
of an organisation can not be just an IT project. In case study we
discuss budget, time and value for a project. We analyzed project of
digital transforamation of insurance company, where we had case
study of issuing a travel insurance policy. PRINCE 2 definitely
provides wide range of guidelines that help managing project, but all
the documentation demands certain knowledge, usually more time,
and not lot of flexibility in project control. On the other side, Scrum
does not provide enough documentation, and it' better for small
projects, with fast delivery needs. Every methodology goal is efficiency
and effectiveness, and we try to give guidelines which one to use, based
on simple comparison.
Keywords: project, project management, PRINCE2, Scrum,
digital transformation
I. INTRODUCTION
Project can be defined as an attempt to achieve some
results, using available resources, in defined time period
[1]. According to [1] and [2], the first thing we need to pay
attention to is the project category – knowing category
eases understanding trends and allows the project size to
be determinated.
Choosing right project methodology, as explained in
[3] is not easy. The main goal of any methodology is to
achieve efficiency and effectiveness, using steps that can
be repeated. In last ten years agile methods became
popular way for overcoming the uncertainty of the project.
Identifying what is a business project requirement,
adapting and providing adequate resources is what is most
important for selecting the appropriate methodology.
Digital business transformation refers to intensive use
of digital technology and digital resources as a tool for
creating new income, new business models or new ways
of doing business, in general. A digital business
transformation arises when company simultaneously and
in short time period performs significant changes in
business activities like strategy, structure, business
processes, business model or organizational structure. It is
usually change where digital technologies connect
business processes, enabling competitive advantage for a
company [4] [5].
Any business can get digitally transformed. Digital
business is result of digital transformation – adaptation to
digital economy. Company can use digital technology and
still not get digitally transformed – eg.it is possible do
make an order using company's website, not over mobile
phone, but that means more of using classic ICT, not
digital business transformation [6].
Section II represents basics of digital strategy in a
company and emhasizes that digital transformation can not
be project for IT only. In Section III we provide theoretical
comparison of PRINCE2 and Scrum as two project
management methodologies, and give introduction to
Section IV which represents case study. Section V
represents conclusion, and Section VI are references used
in this paper.
II. DIGITAL STRATEGY
Digital strategy in business means developing those
activities that will support main strategic goals and allow
them to be realized in three ways:
1. Efficient support of digital technology to existing
business model (run the business)
2. Using digital technology to change existing
business precesses (change the business)
3. Making innovative business models applying
digital technology (reinvent the business) [4]
Figure 1. Phases of developing strategic plan of digital business
1758 MIPRO 2019/SSE
Diagram shows that digital business transformation
is not and never can be only IT project. Management has
to be involved, although many companies are starting agile
change processes in their Diagram shows that digital
business transformation is not and never can be only IT
project. Management has to be involved, although many
companies are starting agile change processes in their IT
areas. Agile management can be promising approach for a
number of application, but strict agilization does not
necessarily lead to the desired goal [7]. It is importat to
consider the situation of specific organization and the
environment it operates in. Study by Westerman [8] has
identified that executives transform three key areas of their
companies: customer experience, operational processes
and business model like in diagram:
Figure 2. Building blocks of digital transformation [8]
According to [9], studies identify three central
challenges for digital transformation: Lack of perceived
urgency to begin the transformation; Coordination and
leadership issues such as having unclear or conflicting
roles, responsibilities and goals; Ineffectiveness of IT to
respond to change. As explained in [10], innovators
usually have to decide do change business that worked for
even decades. But we cannot forget that analog companies
have good start point they are sometimes not aware of:
data. This report suggests that there are five distinct
methodologies that can be applied to develop new business
model:
1. Scenario-based design
2. Epicenter-driven design
3. Unorthodox design
4. Customer-centric design
5. Mirrored design
Both [4] and [9] advice using Dr.Kotters’es eight
steps to digitally transform organization: Establish a sense
of urgency; form a powerful guiding coalition; create a
vision; communicate the vision; empower others to act on
the vision; plan for and create short term wins; consolidate
improvements and produce yet more change;
institutionalize new approaches.
III. PRINCE2 VS SCRUM
Every methodology goal is efficiency and
effectiveness. Methodology should be simple and easy to
understand and learn. It should make it possible to warn
about problems in the early stages of the project, and to be
scalable, adaptable and upgradable
Information systems projects need effective project
management discipline to be successful. The
consequences of failure are expensive, and failure factors
may include a mix of people, technology and methodology
issues. PRINCE2 is more than 20 years old methodology,
and some organizations consider themselves too small for
PRINCE2, but choosing Scrum just because of that cannot
be justification [11] [12]. Scrum is usually used as
synonym for agile methodology. Agile manifesto was
created in February 2001, in Utah, US, so it’s not as young
as we could imagine in the beginning. Manifesto was
published to define the lightweight development approach
[13]. As shown in [11], [13] main differences between
agile principle and other project management
methodologies are:
TABLE 1: DIFFERENCES BETWEEN PRINCE2 AND SCRUM
Feature PRINCE2 Project
Methodology accents
Agile/Scrum principle
Typology Plan-based Adaptive based
Business case Multipurpose, better for
large projects
Multipurpose, best for
software development
Learning Previous experiences
(previous project’s notes
remain for future
projects)
Analysis is given after
each sprint. Experience
can be applicable in next
sprint
Roles and
responsibilities
Project executive, Project
manager, Senior User,
Senior Supplier, Project
Support, Project
Assurance, etc.
Scrum master, Product
owner, team
User
involvement
Role of the Senior user is
part of the steering board
or project committee
Role of the Product
owner, who is
accountable for
maximize product’s
value and team’s work
Active user involvement
is slightly accented
Active users are part of
the development team
itself
Requirements
dealing
Change management is
established as a rigors
process and change is
typically exceptional
Changes are usual part of
the project
Fixed budget, fixed
scope, following plan
Requirements evolve,
budget burn-chart
No or low requirement
prioritization, there is
only Business
Requirement Statement
Baseline
Requirements
prioritization in each
iteration, planning at
each iteration start
Project Requirements
aligned with project plan
must be approved by
project board
Agile development teams
capture high level
requirements in
workshops, working
together in a highly
collaborative way so they
all team members
understand the
requirements as well as
each other
Life cycle Project beginning Project vision
Project initiation Road map
Managing project, setting
borders and project
sustainability
Sprint planning,
development, daily
meetings, sprint audit,
sprint retrospective Project closing
MIPRO 2019/SSE 1759
IV. CASE STUDY
We have analyzed digital transformation of business
firm using Microsoft Project Standard 2016 for graphic
presentation and help in assigning resources to tasks or
managing timetable. It's essential to make a model for
measuring project's productivity first.
We compared budget, time and value as
interconnected limitations for any project.
Usually company’s management has no adequate
knowledge and competencies in recognition of strategic
opportunity provided by intensive and innovative us of
information and communication technology. It can lead to
not investing enough money in project and human
resources with adequate training and knowledge, or not
providing feasibility study and putting too much money
and other resources to project where we do not know what
to expect and what are cost-benefit results.
It’s management’s task to provide “value assurance”
as shown in [14]:
Figure 3. Four groups of success factors
Management can be guilty for project’s failure if it
has no knowledge and expertise in managing project itself.
Manager has to know how to organize and lead teams, but
team work is there most important.
Wrong estimation of project duration is usually
connected with optimistic duration assessment. It can also
be manager’s fault, as said in [4] if it is caused because of
his inexperience or personal goal which he cannot ensure.
Also, stakeholders can have unreal expectations and put
even unfinished project to production. If project starts in
wrong period, when company has most work, and has no
time to adapt to changes, it can be considered faulty time
management as well.
For quality value estimation, we have to have
mechanisms for measuring impact of a project on
company’s business. The best way to do this is audit.
Our analysis is for project of digital transformation,
using PRINCE 2 and Scrum for same project. We
measured digitalization in an insurance company of 450
employees, where we analyzed digitalization of process of
issuing travel insurance policies. Company has sales
department, counting 300 employees, where other 150 are
in back office, but all others sector have to have access to
system, some for reporting, finances for managing
financial data etc. Main challenge for teams or team
leaders was educating top management and having them
provide adequate environment and all sources needed for
a project, of course, their main concern was business
continuity. Insurance itself is conservative business, but
with high potential in processes of digitalization and
improvement of their business. In company we analyzed
the main problem was diffusion of company’s business
units or profit centers across the country.
We provide results of our analysis in following
discussion:
TABLE 2: MAIN BUDGET DIFFERENCES BETWEEN PRINCE2 AND SCRUM
Feature PRINCE2 Project Scrum
Budget Fixed budget Requirements evolve,
budget can be
changed within the box
Certification PRINCE 2 specific
education, not available
in neighbor countries
No extra education
needed, could be
provided with own IT team
Documentation Additional space for
storing, and providing adequate presentation
of documentation
(project plans included)
Keeping only
essential documentation
Stakeholder Must be defined – the
company in our case
Not necessarily
defined - company
If we analyze only what is cheaper, budget is
definitely on Scrum’s side. We had to provide project
management with great knowledge in project management
for PRINCE 2. Also, every decision had to be made with
company’s board first, then with management, and in the
end with project management. Product ownership is
established on the project management level for Scrum.
Additional education for PRINCE 2 is not negligible cost.
We used period of 152 days for completing project
using PRINCE 2. We had 24 weeks for Scrum, and two
Scrum teams, one for development, one for quality
assurance. One sprint lasts for 15 days. Environment
where project held was not included in consideration, we
didn’t investigate if there was a peak for business we
analyzed. We had all needed resources, so it did not affect
our research in any way. The major difference in using
time was – the final project was released in the end with
PRINCE2. We had incremental release with Scrum. We
cannot decide which one method is better, just observing
period used for finishing project. Number of days or weeks
does not matter here – it cannot be used as an advantage.
Internal audit for company was provided, and it
followed the framework for Internal Audit Effectiveness –
International Professional Practices Framework – IPPF.
1760 MIPRO 2019/SSE
Audit followed main process model of auditing itself:
planning of internal audit, critical examination and
business evaluation, reporting, follow up the results. By
definition [4] quality of information system is a relative
category that measures the deviation of its realistic
function for the ideal. Some of parameters we can measure
are: number of incidents in defined period, count of active
incidents, average time for dealing with incidents, open
and closed problems ratio, count of changes that are not
reported using official procedure. Measuring of
information system quality is complex procedure where
the ideal system function should be determined. It’s said in
[4] that internal system quality is insured by internal
system control, and level of that quality is determined by
its internal revision. Critical examination and business
evaluation in our case included revision: does IT work in
accordance with business goals, to what extent it
effectively and effectively supports the business goals,
which controls support information system. Object of
analysis was state of information system in case of selling
travel insurance policies, risk evaluation in observed state
and attempt to guide management to improvement of
current state.
System quality and risk management comparison is
partly described in following table:
TABLE 3: SYSTEM QUALITY AND RISK MANAGEMENT COMPARISON
Feature PRINCE2 Scrum
Quality planning Project quality plan
can be considered as
an equivalent of the
quality management
plan. It is fully covered with
PRINCE 2 – all
expectations are documented
We could not
precisely define
customer’s
expectations
regarding quality in Scrum
Quality assurance Provides adequate
documentation
internal auditors can use as foundation for
audit
No documentation
for internal auditors
is provided. Quality assurance can be
modified during
project itself –team can easily change
focus if previous is
not adequate
Quality control Provides logging
and documents
quality reviews
Does not necessarily
provide logging
Risk management Problem is
assumption that
same approach can be used on all
projects
If risk is shown,
team will try to work
on it
Risk identification Provides risk log to
assist in controlling risks. That helped
managing risks
It was discussed in
team meetings
Sorting risks Suggests high, medium and low
scoring, but no
analysis techniques were available
Instant reaction to a risk was provided
IT in our examined case got to wanted goal. The main
business goal was to digitalize process itself, reduce costs,
and show rapid business expansion in a short period of
time. In a goal to achieve those auditors followed standards
– it was necessary not only because of regulatory
measures, but to intensify consciousness of need to
manage risks. In our comparison both methods satisfied
company’s expectations, provided convenient information
system and created base for achieving business goals.
Auditors provided report, based on verifiable and factually
correct analysis. Of course, the report was not available
until the end of the project, and the greatest value of that
report were lessons learned. Advice for company’s
management was to use Scrum or some other agile
methodology for project where such short period of time
is provided, and results are needed to be shown soon, or
we proclaim project unsuccessful. Price, which is the most
important item, especially for non-technical users, such the
management usually is, is also on Scrum’s side.
V. CONCLUSION
Choosing one particular method or approach can not
guarantee success of a project. PRINCE 2 definitely
provides wide range of guidelines that help managing
project, but all the documentation demands certain
knowledge, usually more time, and not lot of flexibility in
project control. On the other side, Scrum does not provide
enough documentation, so auditors have no help by
method itself. Also, PRINCE 2 is definitely created for
large projects, which need lot of tailoring, but small
project, with fast delivery needs should use some other
approach. Scrum in our case study was almost entirely
information technology solution, with minimum
management engagement, what for fast delivery need in
projects can be shown as advantage.
Both PRINCE 2 and Scrum demanded preparations,
Scrum maybe even more, but PRINCE 2 demanded
exeprienced team members, with special education, what
was one of the main outlay if we consult top management.
The environment in which transformation is carried out
can determine what methodology to use – company like
insurance company may seem like one for PRINCE 2,
because of all the regulations and complexity of a business,
but project that would take too much time, or be too
expensive, must be abandoned, no matter how good or
valuable documentation or sucessfull project would be.
Management has to manage expectations in business, not
provide good results for audit. Audit is tool we can use for
measure the project's sucess, but it must not be purpose of
the project. In the end, great managers would use method
or combination that would make the goal achievement.
A. Future work
The best results would be combining those two
approaches, or using one as base for other future projects
managed by different method. For example, great
MIPRO 2019/SSE 1761
documentation from PRINCE 2 could be great knowledge
base for guiding some project using any agile method. That
could definitely be a direction for future research. Also,
some audit mechanisms or guidebook could be used for
future reviews. Analyzed literature does not cover area of
insurance at any point, and we see great potential in that
area, both for survey and maybe testing some other
methodologies.
VI. REFERENCES
[1] C. Dr. Aljaž Stare, Project management, course textbook,
Ljubljana: University of Ljubljana, Faculty of economics, 2013.
[2] Burgan, Stephen C.; Burgan, Diana S., “One size does not fit all:
Choosing the right project approach,” u PMI® Global Congress
2014—North America, Phoenix, AZ, 2014.
[3] Victorian Government CIO Council, “Selecting a project
management methodology,” Victorian Government Chief
Technology Advocate, 2015.
[4] P. M. Spremić, Digital transformation of a business, Zagreb:
University of Zagreb/Faculty of Economics, 2017.
[5] Jonas Ridderstrale, Kjell Nordstorm, Funky business forever,
how to enjoy capitalism, Stockholm: BookHouse Publishing AB,
2008.
[6] Bharathi R, Elamathy P, Rajesh AS, ""Banking" on Digital
transformation - Surfing the Wave," SQS India BFSI Ltd., 2016.
[7] T. Walter-Gupner, “Agile Value Chain as Competitive
Adventage,” ZIPF (Zeitschrift für interdisziplinäre ökonomische
Forschung), br. 2, pp. 37-43, 2017.
[8] MIT Center for Digital Business and Capgemini Consulting,
“DIGITAL TRANSFORMATION: A ROADMAP FOR
BILLION-DOLLAR ORGANIZATIONS,” MIT Center for
Digital Business and Capgemini Consulting , 2011.
[9] J. Nieminen, “Understanding & Managing Digital transformation
- A case study of a large Nordic retailer,” 2014.
[10] “World Economic Forum White Paper - Digital Transformation
of Industries: Digital Enterprise,” World Economic Forum, 2016.
[11] APM North West branch members, “The Practical Adoption of
Agile Methodologies,” Association for Project Management,
Buckinghamshire HP27 9LE, 2015.
[12] R. Fance, “Wrapping PRINCE2 around Agile - You can, but
should you?,” UXC Consulting.
[13] J. Juricek, “Agile Project Management Principles,” Lecture Notes
on Software Engineering, tom 2, br. DOI:
10.7763/LNSE.2014.V2.117, pp. 172-175, 2014.
[14] Michael Bloch, Sven Blumberg, Jürgen Laartz, “Delivering large-
scale IT projects on time, on budget, and on value,” McKinsey
Quarterly 27:2-7, 2012.
[15] Zeus Kerreavala, Lawrence C.Miller, Digital Transformation for
Dummies, Hoboken: John Wiley and Sons, 2017.
[16] H. Salameh, “What, When, Why, and How? A Comparison
between Agile Project Management and Traditional Project
Management Methods,” International Journal of Business and
Management Review, tom 2, pp. 52-74, 2014.
1762 MIPRO 2019/SSE