Sei sulla pagina 1di 5

IADIS International Conference Applied Computing 2012

$''5(66,1*0$,1352%/(06,1352-(&7
0$1$*(0(17 35,1&( %<$'237,1*$*,/(
35,1&,3/(6 6&580 

Martin Tomanek and Jan Juricek


University of Economics in Prague, Faculty of Informatics and Statistics
Nam. W. Churchilla 4, 130 67 Prague 3, Czech Republic

$%675$&7
There is still lack of confidence of the overall success in the SW development projects or of the outputs coming out from
the IT project delivery. Typical management approach strengths on using proper project management (PM) methods to
leverage the success rate of projects and programs. Not-selected and not-tailored implementation and application of
worldwide PM methods such as PRINCE2, PMI and IPMA in many cases are not the right factor of the potential success
of the final IT project output. This research paper is addressing main problems in IT project delivery by adopting agile
principles on main selected issues.

.(<:25'6
Agile project management, PRINCE2, Scrum, project management problems, PRINCE2 tailoring, adopting Scrum

 ,1752'8&7,21
Project management practice based on non-agile project management methods such PRINCE2 still suffers
from typical project management problems as changing requirements, different stakeholders’ expectations,
lack of budget and time etc. The main goal of this paper is to:
x Analyze the project management problems as stated in the Ernst&Young 2011 research and define
the underlying problem root causes
x Propose how these root causes can be potentially mitigated by adopting agile principles or any agile
elements from agile framework to enhance the general project success
In this paper, we select PRINCE2 as the project management method, because is widely used across the
Europe and Australia (APM GROUP, 2012), and explicitly require to be tailored to suit the project needs.
This tailoring can be done via adopting agile principles.
From agile process frameworks or methods we select SCRUM which is largely used in SW development
area. SCRUM generally is a framework for developing and delivering products. Agile approach from
SCRUM perspective means an iterative and incremental approach to optimize predictability and control risk.
The SCRUM framework consists of role and responsibilities, events, artifacts and rules (Schwaber,
Sutherland, 2011).
PRINCE2 is based on following 7 principles and 7 themes that can be applied to every project regardless
of project scale, type, organization, geography or culture. Its principles are based on continual business
justification, learning from experience, defined roles and responsibilities, managing the project by stages,
managing the project by exceptions, focusing the delivery on specialized products and overall tailoring of the
methodology approach to the particular company and project.
PRINCE2 defines project as a temporary organization that is created for the purpose of delivering one or
more business products according to an agreed business case (Office of Government Commerce, 2009),
while using 5 characterizes of the project (a);
x Change (as a meaning of the project itself)
x Temporary (defined start and the end)
x Cross-functional (different skills of different team to deliver the solution)

385
ISBN: 978-989-8533-14-2 © 2012 IADIS

x Unique (every project is unique)


x Uncertainty (threads)
And (b) the project management works of all aspects of the project: Plan, Delegate, Monitor and Control.
When you take project definition as it is defined by PRINCE2, then SCRUM sees a project as each sprint
because a sprint produces a shippable product (change), lasts usually one month (temporary), involves
different skills (cross-functional), is unique based on prioritized list of customer requirements.

 67$7(0(172)$352%/(0
There is still lack of confidence of the overall success in the SW development projects or of the outputs
coming out from the IT project delivery. In general for a project to be successful, is has to be delivered on
time, within budget, and conform to the client's requirements; requirements analysis is mainly related to
determine the needs and conditions to be met for a successful project, taking into account the possible risks
and of course, understand customer's needs and expectations (Karamitsos et al, 2010).
Management approaches strengths on using proper project management methodologies to leverage the
success rate of projects and programs. This paper addresses common project management problems
formulated by Ernst&Young 2011 research, a regular survey of project management practices in Czech
Republic, which can be applied on the world-wide range of project management practices.
List of common project management problems (Ernst&Young, 2011):
1. Scope change as a consequence of the unexpected external change
2. Project scope change, as a poor or insufficient initial planning
3. Different Project outputs / object expectation
4. Insufficient or lack of TOP management support
5. Deficient budget or optimistic expectation

 0(7+2'6
This paper looks at problems mentioned in previous chapter in more details trying to analyze the problems
and define the respective root causes using the “5 Whys” technique (Wikipedia, 2012) based on case studies
and lessons learned documents gathered by the Czech company with more than 1.000 realized projects per
year.
Each root cause is then evaluated on the impact on the potential project success from the following three
perspectives:
x Impact on time and possible delay
x Impact on project costs and increased budget
x Impact on quality of project deliverables (products)
If there is an impact on all three perspectives then the impact will be evaluated as a high impact on the
project success. Analogically, impact on two perspectives is the medium impact on the project success and
impact only on one perspective is evaluated as a low impact on the project success.
At the end the potential mitigation by adopting agile principles is defined for the each problem root cause.
Agile principles or elements are used from the widely used agile framework called SCRUM. SCRUM is
universal agile product-delivery framework which is used mostly by software development organizations but
it can be applied to any sort of products and not only software.

 352%/(062/9,1*
The following table contains the identified problems, related root causes, evaluated impact on the project
success and the potential root cause mitigation by agile approach.

386
IADIS International Conference Applied Computing 2012

Table 1. Problem addressed by agile approach: 6FRSHFKDQJHDVDFRQVHTXHQFHRIWKHXQH[SHFWHGH[WHUQDOFKDQJH

5RRW&DXVH ,PSDFWRQWKHSURMHFW 3RWHQWLDO0LWLJDWLRQE\$JLOH$SSURDFK


VXFFHVV
Project can have a long duration Medium Agile project is split to individual sprints
(>1 year). which last usually one month. Project
scope is reviewed and prioritized at the
beginning of each sprint.
Stress on initial planning of the whole High The whole project is planned only on high
project can lead to undetected external level and details are planned for each
dependencies.  sprint or product release.
A change to the project scope needs to Low Changes are considered before each sprint
be formally documented and approved. and are documented and prioritized in the
A project change request is therefore product backlog. A change to the scope
administratively difficult to handle. during a sprint is against SCRUM
principles.
Accountable stakeholders are not willing Medium Current project scope and approach is
to adopt the changes. They stay focused modified before each sprint.
on current project scope and approach.

Table 2. Problem addressed by agile approach: 3URMHFWVFRSHFKDQJHDVDSRRURULQVXIILFLHQWLQLWLDOSODQQLQJ


5RRW&DXVH ,PSDFWRQWKHSURMHFW 3RWHQWLDO0LWLJDWLRQE\$JLOH$SSURDFK
VXFFHVV
Project scope is defined only at the beginning High Project scope is defined in the product backlog in
of the project. the form of user stories and it is continuously
reviewed, updated and prioritized.
Project scope cannot be defined in the needed High Selected requirements (user stories) from the produc
detail in the initiation phase. backlog are planned for each sprint in more details in
the sprint backlog.

Table 3. Problem addressed by agile approach: 'LIIHUHQWSURMHFWRXWSXWVREMHFWH[SHFWDWLRQ


5RRW&DXVH ,PSDFWRQWKHSURMHFW 3RWHQWLDO0LWLJDWLRQE\$JLOH$SSURDFK
VXFFHVV
Requirements are not fully understood High All the requirements selected for each sprint
by the project team which can cause are discussed at the sprint planning meeting.
misunderstanding between the project The product owner and development team
team and the customer. participate face to face in this meeting.
Product owner can see and test the shippable
product at the end of each sprint. It
eliminates the big negative surprise at the
end of the project where product doesn’t
meet the customer requirements.
Stakeholders are not regular involved in Medium Stakeholders are regularly involved at the
the project progress. end of each sprint where they can see and
test the potentially shippable product.
Multi-level reporting while each Low SCRUM framework defines a basic set of
organizational level needs different reports available to all stakeholders. The
inputs. reports are mostly focused on work
remaining to finish all the requirements from
the sprint backlog.
Customer is not in the direct touch with Medium Customer involvement in the project is the
particular project team members. key of SCRUM framework. The product
owner represents the customers and is in
touch with the development team at least at
the beginning and the end of each sprint.

387
ISBN: 978-989-8533-14-2 © 2012 IADIS

Table 4. Problem addressed by agile approach: ,QVXIILFLHQWRUODFNRI723PDQDJHPHQWVXSSRUW

5RRW&DXVH ,PSDFWRQWKHSURMHFW 3RWHQWLDO0LWLJDWLRQE\$JLOH$SSURDFK


VXFFHVV
If the project doesn’t cross the High Scope boundary can be established as
established project boundaries (time, minimum set of requirements (user stories)
money, scope) then the project board which need to be delivered at the end of the
won’t need to be involved in any sprint.
decision. Project is managed by
exception.
Project board members don’t consider a Medium Product Owner role and Senior Customer
project as high priority and are focused role should be assigned to the same person
on different activities. which will actively participate in the project.

Table 5. Problem addressed by agile approach: 'HILFLHQWEXGJHWRURSWLPLVWLFH[SHFWDWLRQ


5RRW&DXVH ,PSDFWRQWKHSURMHFW 3RWHQWLDO0LWLJDWLRQE\$JLOH$SSURDFK
VXFFHVV
Risk budget is disapproved or Low Risks are spread across the sprints. Short-
underestimated. term sprints and potentially shippable
product at the end of each sprint minimize
Risk is poorly defined and evaluated in Low the impact of risks
the business case which increases the
likelihood of business case approval.
Business case is created with optimistic Medium Expectation of stakeholders is managed at
expectations and unrealistic benefits. the end and beginning of each sprint.

 &21&/86,21
This paper analysis the main 5 problems which occur in the project management practice in the Czech
Republic. As the result of the analysis there are 15 root causes underlying the problems. 5 root causes are
evaluated as having high impact on project success, following 6 root causes with medium impact and 4 root
causes with low impact.
In order to eliminate or at least reduce the main problems in project management practice we recommend
focusing at the root causes with high impact on project success first follow with medium impact.
All root causes with high impact on project success are related to problems with project scope, external
dependencies and customer expectations/requirements. The main benefits and strength of SCRUM is directly
related to these problems. As a result of our analysis we recommend to tailor the PRINCE2 method as
follows:
1. At the beginning of the project, senior customer/product owner should extract all the project/product
requirements from the approved business case and transform them to the product backlog. These
requirements should be defined on high level only in the form of free-text user stories (epics). These
requirements must be prioritized and a set of must requirements must be defined.
2. At the beginning of each sprint the product backlog is reviewed, updated and prioritized
requirements are selected. These selected requirements are transferred to the sprint backlog and are
analyzed in more detailed. This selection and deeper analysis is done between the senior
customer/product owner and project team. This meeting is face-to-face and the objective is to fully
understand the requirements and their importance.
3. At the end of each sprint the product owner can see ant test the shippable product which should
fulfill the requirements from the sprint backlog and meet the customer expectations for the product
features. The shippable product must contain all the must requirements.
Root causes with medium impact on project success are more-less related with optimistic expectations of
main stakeholders transformed into the unrealistic business case, their unwillingness to adopt the changes in
the long-term view as well as misunderstood requirements and staying in close touch with the customer team.
Based on our analysis we recommend:

388
IADIS International Conference Applied Computing 2012

1. Split the project phases into sprints which take a month maximum and review the scope with the
customer and a stakeholders; make a priority
2. Managed and review the stakeholder expectations at the end in each sprint
3. Assemble teams, participated from both delivery team (development) and customer product owners
and approve at each sprint the potential shippable product

5()(5(1&(6
APM GROUP, 2012. Consulting Organsations List. Online:
http://www.prince-officialsite.com/ConsultingOrganisations/ConsultingOrganisationsList.aspx
C. Apostolopoulos and I. Karamitsos, 2009. The Success of IT Projects Using Agile Methodology, 1st International
Workshop on Requirements Analysis Proceedings, Pearsons Education, Elista, pp. 13-21
Ernst&Young, 2011. Project Management Practices in the Czech Republic for year 2011 Research, Ernst&Young.
Online: http://www.ey.com/CZ/cs/Issues#publikace
I. Karamitsos et al, 2010. Benefits Management Process Complements Other Project Management Methodologies.
Journal of Software Engineering and Applications, vol. 3.9, pp. 839-844
Marquis, Hank. 5 Whys to Solve Problems. ItSM Solutions: Do-IT-Yourself Guide [online]. Vol. 5.39. October 2, 2009
Online: http://www.itsmsolutions.com/newsletters/DITYvol5iss39.htm
Office of Government Commerce, 2009. Managing Successful Project with PRINCE2 Reference Manual. TSO (The
Stationery Office), London, ISBN 978-0-11-3310593.
K. Schwaber and J. Sutherland, 2011. The Scrum Guide: The definitive guide to Scrum: The rules of the game. Scrum.org
. Online: http://www.Scrum.org/storage/Scrumguides/Scrum_Guide.pdf

389

Potrebbero piacerti anche