J. Software Engineering & Applications, 2010, 3, 858-868
doi:10.4236/jsea.2010.39100 Published Online September 2010 (http://www.SciRP.org/journal/jsea)
IT Project Environment Factors Affecting
Requirements Analysis in Service Provisioning
for the Greek Banking Sector
Krikor Maroukian
Printec Group of Companies, Athens, Greece.
ABSTRACT
The research undertaken within a Greek IT organisation specialising in service provisioning to the Greek banking sec-
tor discusses the various aspects of a number of identified environment factors within five distinct IT projects which
affect the requirements analysis phase. Project Management (PMBOK® Guide 4th ed.), IT Service Management (ITIL®
v3) and Business Analysis (BABOK® Guide 2.0) framework practices applied to the various IT projects are highlighted
in regard to improved activity execution. Project issue management, stakeholder management, time management, re-
sources management, communication management and risk management aspects are presented. These are then linked
to the identified environment factors so as to indicate the adaptability of an IT support team to changing environment
factors in IT project environments and how the fulfilment of these factors can significantly contribute to effective re-
quirements analysis and enhance the requirements management cycle.
Keywords: Requirements Analysis, Project Management, IT Service Management, Business Analysis, Gre ek Ban ki n g
Sector
1. Introduction
International transaction systems have grown rapidly in
the past decade, servicing more efficiently an ever grow-
ing number of debit and credit card holders throughout
the world. Telecom Point-of-Sale (POS) devices offer an
extended prism of services to cardholders in their daily
purchase transactions. The Greek banking sector having
sustained for many years the POS market, has now
reached a high maturity level. This has enabled banking
institutions to set a vision in terms of acquiring new
technologies such as POS devices with embedded GPRS
or Wi-Fi capabilities. It also means that suitable telecom
network and IT infrastructure is established whereby
POS management systems provide the required everyday
service from banks to merchants and ultimately the
cardholders. Requirements analysis is of significant im-
portance in IT projects undertaken to support the POS
management system environments that are currently in-
stalled at various banking institutions within Greece. As
a consequence, it is the primary aim of this paper to in-
vestigate and identify the project environment factors
that affect the requirements analysis phase in the Greek
banking sector, through a series of five IT projects with
distinct characteristics each, carried out by a POS man-
agement systems Support Team acting as part of Printec
Group’s Software R & D Division.
1.1. Background
The research paper focuses on the various issues faced in
the requirements analysis during the service design, ser-
vice transition and service operation execution of five
large to medium-scale IT projects undertaken within the
Greek banking sector. The primary deliverable of all
projects was the deployment of a POS or Terminal Man-
agement System (TMS) within five Greek banks, three of
them forming part of the four largest banking establish-
ments within the Greek banking market. Services are the
means of delivering value to customers by facilitating
outcomes customers want to achieve, without the own-
ership of specific costs and risks [1]. Moreover, there is
extensive reference on the various methodologies and
practices employed towards client requirements identifi-
cation, categorisation and dissemination of information
to other corporate teams and the effect of this analysis on
project deliverables. The paper also discusses the estab-
lished practices which aided the overall process of re-

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
859
quirements management. Four teams were highly in-
volved in the IT projects undertaken. These consisted of
the TMS implementation and support team, the TMS
development team of Printec Group Software R&D Di-
vision and the Printec Greece e-Payments Department
teams of POS application development and POS Help-
desk; a subsidiary of Printec Group. Teams from Printec
Group reported to the Steering Committee and both had
an individual appointed at a managerial role. The Steer-
ing Committee consisted of the Software R&D Division
Director and the Group General Manager. The Printec
Greece e-Payment Department POS Helpdesk and POS
Development teams were headed by the Technical Su-
pervisor and the Head of Software Engineers.
1.2. Project Management Plans
The aim of IT projects undertaken was to install or up-
grade the TMS software for five banking institutions. An
eighteen month period covered the entire duration of the
five executed IT projects starting from May 2008 and
lasting till November 2009, see Table 1. Notice that all
project implementations refer to system upgrades except
for Sigma Bank which resulted to a fresh installation of
TMS at Printec Greece premises.
Printec Group’s IT service provisioning to the five
banking institutions can be further divided into areas
such as POS management, merchant management, POS
issue management, reports management and client spe-
cific business needs. In addition, the client’s point of
contact with Printec Group’s internal software develop-
ment department was the TMS support team. Therefore,
the TMS implementation and support team was respon-
sible for highlighting or escalating any issues or re-
quirements that might arise regarding client needs. Soon
it became apparent that healthy relationships between the
client and the IT services supplier when maintained,
through good professional practices such as regular
communication updates on current issues faced, post-visit
reporting on decisions reached, issue response and reso-
lution or simply updates on a new product release, can
result in higher client utility and improved practice in the
requirements capture activity.
2. Project Management, Servi c e
Management and Business Analysis
Frameworks for Requirements Analysis
in the Greek Banking Sector
From the very beginning of the IT projects, it was real-
ised that a defined period for requirements identification
cycle would ensure that all client requirements would be
recorded as part of the documentation practices already
established within Printec Group. These would be taken
into full consideration by all involved stakeholders for
the release of the new TMS software [2]. Identification
of business and user requirements was directly related to
functional and non-functional requirements. Functional
requirements relate to the scope of work or functionality
the software must have whereas non-functional require-
ments refer to look and feel, usability, performance, se-
curity and maintainability and support requirements of
the software [3].
Moreover, maintaining an up to date set of require-
ments gained significant priority and became a crucial
aspect of applied IT project management practices. It was
important that all stakeholders of the TMS support and
software development teams had a perfectly aligned per-
ception of what the client required so as to avoid a mis-
conception of expressed client requirements.
2.1. Applied Requirements Analysis and
Business Analysis Practices and
Methodologies
The requirements analysis process refers mainly to re-
corded and accepted requirements that will form part of
project deliverables. The acceptance stage can be con-
Table 1. Project management plans duration for five IT projects in the Greek banking sector.
Bank Project Start Date Project End
Date Service Delivery Duration (mont hs)TMS version
Beta Bank 5/5/2008 14/02/2009 9¼ Upgrade TMS6TMS7
Gamma Bank 7/7/2008 18/12/2008 5 Upgrade TMS7New version of TMS7
Delta Bank 7/11/2008-25/11/2008 &
20/05/2009-25/8/2009 25/8/2009 3¾ Upgrade TMS7New version of TMS7
Sigma Bank 23/4/2009 11/05/2009 ¾ Install TMS7
Omega Bank 25/5/2009 24/11/2009 6 Upgrade TMS6TMS8

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
860
ducted under the auspices of a formal meeting with the
client during which essential business requirements are
discussed, recorded and timelines of service delivery
provided to the client by senior management. Later on,
the agreed requirements to be implemented and timelines
should be communicated to all project stakeholders so
that organisational efforts for the release of the new TMS
software are aligned according to specifications. In effect
the purpose of the requirements analysis process is to
establish which requirements have been identified, the
case of whether there needs to be provided clarification
in regard to a requirement and finally accept the imple-
mentation of the necessary software development to re-
lease the new software product which would fully con-
form to client requirements. Three processes were identi-
fied throughout the requirements analysis process as the
key ingredients to best practice. These are the Require-
ments Identification, Requirements Categorisation and
Requirements Prioritisation. It was made clear that there
was a set of requirements to which the client agreed upon
a formal meeting with Printec’s senior management and
that there was flexibility in new requirements to be ac-
cepted after a new release had been scheduled and im-
plemented in terms of establishing an independent pro-
ject altogether to implement these new requests.
Firstly requirements capturing or identification proce-
dures were established whereby client requirements were
identified as follows:
1) Senior management buy-in for the project indicated
strong commitment from Printec Group’s side to the re-
quirements analysis process;
2) Enquiries and incident logging through the Service
Desk;
3) Frequent formal visits to the bank’s site;
4) The use of a coherent vocabulary or common glos-
sary among Printec Group and bank employees was in-
strumental towards an improved understanding of re-
quirements identification;
5) A requirements identification period resulted to im-
proved requirements capture and a better understanding
of the software functionality the client was expecting to
receive.
Secondly the requirements categorisation process re-
fers to identifying the software component or module to
which a requirement refers. There were two types of re-
quirements in regard to resource allocation to tasks for
their implementation. Those that could be handled by the
support team and those that had to be escalated to the
software development team. Resource allocation to tasks
was managed through the issue management system. In
addition, requirements categorisation can be carried out
having in mind functional and non-functional require-
ments. Functional requirements describe the functionality
of a system. These are sometimes known as software
capabilities. On the other hand, non-functional require-
ments act to constrain the solution and can be referred to
as constraints or quality requirements. In fact, non-func-
tional requirements can be further classified according to
whether they are performance requirements, maintain-
ability requirements, security requirements or reliability
requirements.
In addition to categorisation of requirements the estab-
lished issue management system within Printec Group
assisted in the prioritisation of what requirements re-
quired immediate implementation in the new software
release and which ones could be implemented in a later
software release. Within Printec Group the following
points were considered important prioritisation criteria:
1) Importance of requirement to client satisfaction. In
effect this is what the client expressed as necessary to
sign off user acceptance testing and eventually project
implementation;
2) Criticality of requirement in client production envi-
ronment; This attributes to the severity of implications
caused in the client production level if the requirement
was not implemented;
3) Capability of re-tracing previously documented re-
quirements for re-use;
4) Resource allocation to requirements tasks;
5) Cost of implementation per requirement.
Note that there are certain challenges associated with
requirements prioritisation which need to be carefully
considered as defined in BABOK® [4]:
 Non-negotiable demands whereby the client is un-
willing to commit to any trade-offs and ranks all
requirements as high priority;
 Unrealistic tradeoffs whereby the service pro-
vider’s solution development team may intention-
ally or unintentionally try to influence the result of
the prioritisation process by overestimating the re-
quirements implementation complexity.
Subsection 2.2 refers to project management practices
established for Beta Bank, Gamma Bank, Delta Bank and
Omega Bank. In the Sigma Bank case, the installation of
the TMS software was outsourced. Therefore TMS was
deployed at the Printec Greece premises thus mitigating
the execution of the requirements analysis process to the
Printec Greece-e-Payments Department POS Helpdesk
team which in turn collaborated with Sigma Bank - Cards
Division officials. The mental mismatch model can be
also considered for the Sigma Bank TMS deployment
project, see Subsection 3.1.4, in a slightly different stake-
holders’ context but always indicating the necessity to
cater for misconception of expressed client requirements

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
861
between various parties and teams as shown in Fi gu re 1.
2.2. Applied Project Management and Service
Management Practices and Methodologies
Τhe TMS implementation and support team performance
was constantly measured through Key Performance In-
dicators (KPI) which indicated that most of the time all
issues were resolved and whenever serious issues arose
with high business impact these were escalated to the
TMS development team to address the issue in software
development terms. Some of the frequently monitored
and reported KPIs include, issues closed at first call at
the Service Desk, issues closed after second level support
consultation, average time per call per analyst, issues
escalated for third level support to TMS software devel-
opment and POS software applications development
teams. In effect, there was usually a small backlog of
client issues relating to TMS installations which made it
possible to counteract more effectively to newly reported
issues.
Throughout the duration of the IT project the senior
management style was consultative whereby decisions
were taken by seeking the opinions and views of the
teams prior to a decision being made [5]. However final
decisions lied solely in the judgment of the Steering
Committee. Furthermore, knowledge transfer on TMS
usability matters from the development team to the sup-
port team was vital. This was conducted through formal
and informal meetings, online material and communica-
tion, computer based training (CBT) and constant in-
volvement to client issue resolution.
An established Service Desk operating according to
ITIL specifications, was utilised to control and monitor
TMS support performance levels. In particular, it was
decided who would take responsibility of escalating is-
sues to the development team, aligning client site TMS
software items with Printec Group’s TMS related con-
figuration items (CI) and who would trigger and organise
formal team meetings. Moreover, work delegation was
essential in assigning tasks to resources by taking into
consideration resource availability and the individual’s
expertise on the different functionality aspects of TMS.
In this way incident response timeframes to the client
would be minimised. Performance reporting to the
Steering Committee was essential. This involves collec-
tion and distribution of performance information to pro-
ject stakeholders [6].
The established flow of information and client re-
quirements identification to escalation management re-
quired the TMS Support team members be at the heart of
the process as depicted in Figure 2. Notice that the
Steering Committee and Software Development team, at
Figure 1. The mental model mismatch for the Sigma Bank-TMS deployment project.
Figure 2. Printec Group-Software R & D Division communications mapping with clients.

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
862
exceptional cases, had to be involved in the ΙΤ support
process with the client. This occurred due to the fact that
certain requirements had to be clarified in technical terms
to avoid ambiguity so as implementation and the end
result was exactly what the client requested initially. In
addition, this also occurred in situations when senior
management had to engage in the decision making proc-
ess with the client or even to schedule high profile meet-
ings. In fact, decisions or agreements reached in collabo-
ration with Printec Group’s senior management would
indicate higher commitment to the TMS project from the
client side.
2.2.1. Established Service Desk
The implementation of the Service Desk for the TMS
support team entailed the recording of landline incom-
ing/outgoing telephone communications. This was
achieved by monitoring and responding to all outstanding
activities/requests/complaints, creating and maintaining a
Known Error Database (KED) and reporting on a
monthly basis to the Software R & D Division Director
on TMS support productivity and efficiency.
The established Service Desk within the TMS support
team served as a technique for capturing and recording
client requirements
2.2.2. Issue Reporting and Statistics Provision
A suitable frequency of reporting and review was estab-
lished, depending upon the importance of the review.
Providing results in graphical form is useful for present-
ing management overviews on major areas of interest [7].
To provide a common service objective, it was important
that all TMS stakeholders were aware of major issues,
concerns, performance levels and achievements of the
entire Software R & D Division and not just their team.
Table 2 below, shows the monthly performance statistics
produced for the Director of the Software R & D Divi-
sion by the owner of the TMS Support Service Desk.
3. Investigation of Environment
Factors—Five Case Studies in the Greek
Banking Sector
This chapter presents a discussion on each of the five IT
projects the Printec Group TMS support team embarked
on and unravels the factors that affected the requirements
analysis phase which in turn resulted in delays or im-
provements to project timeframes. The case studies are
presented in time sequence as they occurred throughout
an eighteen month period.
The requirements analysis and business analysis (BA-
BOK®) procedures implemented by the TMS support
team have been previously described see Subsection 2.1.
Project Management (PMBOK®) and IT Service Man-
agement (ITIL® v3) framework practices have been
thoroughly described in Subsection 2.2.
3.1. Terminal Management System Deployment
Projects for Five Banking Institutions within
Greece
Each project presented in this section carries a different
set of characteristics which distinguishes it from the rest
in terms of size of client organisation, applied corporate
Table 2. Monthly performance statisti cs of the TMS support servic e desk.
Total issues % Change Resolved issues%
September 2008 25 0.00% 24 96.00%
October 2008 27 7.41% 24 88.89%
November 2008 30 10.00% 29 96.67%
December 2008 30 0.00% 28 93.33%
February 2009 29 –3.45% 28 96.55%
March 2009 28 –3.57% 26 92.86%
May 2009 27 –3.70% 27 100.00%
Jun-Jul 2009 13 –107.69% 13 100.00%
Aug - Sep 2009 19 31.58% 18 94.74%
Sep- Oct 2009 17 –11.76% 16 94.12%
Nov 2009 15 –13.33% 14 93.33%

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
863
IT policies, IT resources and human resources availabil-
ity, project complexity, issue management, demand
management, scope management, time management and
financial management (project budget). The projects un-
dertaken for the Greek banking sector are presented be-
low in chronological order, see Table 3. It is clear that
the project engaged with the largest banking institution,
Beta Bank, faced the highest number of issues requiring
resolution. In the ITIL context these can be classified as
incidents or problems. In case problems arose the appro-
priate changes were requested and upon approval of the
Change Advisory Board (CAB) a new TMS release was
scheduled with a problem resolution patch. Moreover,
the organisation criticality category describes the vitality
and business operations impact each customer represents
to Printec Group as a business customer. For example,
Table 3 shows that Beta Bank is considered to be a stra-
tegic customer of Printec Group and therefore any inci-
dents or problems arising from any Beta Bank project
require additional attention in accordance to the customer
specific Service Level Agreement (SLA). Project com-
plexity refers to the level of bureaucratic processes put in
place by the customer, customer decision making time
and processes on expression of customer requirements,
time of response to service provider requests and in gen-
eral elements that might materialise risks which will
translate, as a consequence, in terms of project delays.
Lastly, the number of tasks assigned per project was
similar in all five case studies as shown in Table 4.
Note that throughout the duration of the five case stud-
ies a project manager was working in conjunction with
the TMS implementation and support team so as both the
service provider and the customer complied with the
agreed project plan and project schedule. The assignment
of tasks to individuals supported the need of task owner-
ship. In this way individual responsibility for the com-
pletion of tasks on-time and within project scope was
encouraged.
3.1.1. Beta Bank
The first project for the deployment of TMS at the Beta
Bank premises, the largest banking institution within
South-Eastern Europe, started in May 2008 and lasted till
February 2009. With an approximate duration of nine
months and thirty-six reported issues, see Figure 3, it
was the largest and most complex project of all. High
Table 3. TMS deployment project characteristics for five banking institutions within Greece.
Bank Completion
Duration (mont hs) Project IssuesOrganisational Criticality Project Complexity % of Tasks Completed
Beta Bank 9 36 High High 100%
Gamma Bank 5 16 Medium Medium 100%
Delta Bank 3¾ 11 Medium Medium 100%
Sigma Bank ¾ 6 Low Low 100%
Omega Bank 6 11 Medium High 100%
Table 4. A standard TMS deployme nt pr ojec t sche dule .
Task Completion
Duration (days) Owner
Project kick-off meeting 0 Software Support Engineers, Project Manager
Requirements Analysis 5 Software Support Engineers, Project Manager
Data migration from old to new system 15 Software Support Engineer 1
Setup of User Acceptance Testing (UAT)
environment at client site 15 Software Support Engineer 2
Testing at client site 5 Software Support Engineer 2
UAT sign-off and software acti va tion in
production 2 Software Support Engineer 1, Project Manager

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
864
Figure 3. Recorded issue rate per day throughout the duration of all five projects.
project complexity resulting to project timeframe delays
existed due to several reasons as described below:
1) High issue reporting rates, see Table 3, meant that
TMS support and TMS Development team members had
to first resolve the issues so as to progress through the
project management plan;
2) Numerous change requests to project requirements
and thus deliverables during the User Acceptance Testing
stage. In general, software development at this stage en-
tails high costs;
3) Numerous confirmation requests for undocumented
TMS workflow which meant that Printec Group’s Intel-
lectual Property had to be preserved while satisfying cli-
ent requests;
4) TMS administrators were constantly seeking reas-
surance on system management matters;
5) Constant requests for additional training provision;
6) The large size of corporate POS Helpdesk and POS
Faults Departments resulted in scheduling requests for
additional training sessions;
7) Beta Bank being a high-profile client meant that no
trade-offs could be made during the requirements analy-
sis phase. Without any ground to negotiate identified
requirements implementation there is additional risk on
the service supplier side during service delivery.
In addition, the prolonged requirements analysis pe-
riod, at the beginning of the project, was beneficial in the
sense that certain requirements were well defined and a
good understanding of their implementation was ac-
quired. However, the prolonged period of service design,
service transition and service delivery in general, had a
serious impact on project constraints e.g. extended pro-
ject duration and contributed to higher project complex-
ity as well.
3.1.2. Gamma Bank
The second project for the deployment of TMS at
Gamma Bank premises, the third largest Greek banking
institution within Greece, started in July 2008 and lasted
till December 2008. With an approximate duration of
five months and sixteen reported issues, see Figure 3, it
was the third largest and complex project of all. Medium
project complexity resulting to project timeframe delays
existed due to the following reasons:
1) Established IT security corporate policies meant
that several authorisations were required to conduct sim-
ple activities such as the installation of new software on
UAT and production environments or the retrieval of a
database backup file. Usually this resulted in task delays;
2) Whenever task delays occurred throughout the pro-
ject lifecycle, the rate of visits increased so as to ensure
that TMS deployment work was carried out as planned.
Gamma Bank having sustained a highly sophisticated
and secure TMS IT environment on its premises, assisted
in keeping the project complexity at a medium level
compared to the rest of the projects even though high IT
security levels resulted at some cases to project time-
frame delays. As observed, in the case of Beta Bank,
when nearing TMS upgrade dates the recorded issues to
be resolved experienced an increased rate. As a conse-
quence the Printec Group TMS Support team had to be
highly responsive, during these periods, regarding re-
quests communicated by the banking institution’s man-
agement. In fact, this team behaviour had to be consistent
within all client project environments.

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
865
3.1.3. Delt a B ank
The third project for the deployment of TMS at Delta
Bank premises, subsidiary to the largest worldwide fi-
nancial institution based in the USA, started in Novem-
ber 2008 and lasted till August 2009 with a halting pe-
riod of six months due to events caused by the recent
global economic recession. With an approximate dura-
tion of three months, three weeks and eleven reported
issues, see Figure 3, it was the fourth in scale project of
all with medium complexity. Medium project complexity
resulting to project timeframe delays existed due to cer-
tain reasons as described below:
1) Established IT security corporate policies meant
that several authorisations were required to conduct sim-
ple activities such as the installation of new software on
UAT and production environments or the retrieval of a
database backup file. Usually this resulted in task delays;
2) Whenever task delays occurred throughout the pro-
ject lifecycle, the rate of visits increased so as to ensure
that TMS deployment work was carried out as planned;
3) The TMS deployment project timeframe of delivery
was largely affected by the recent economic turmoil.
Even though the active project duration was recorded as
three months and three weeks; adding the inactive period
to the project duration equals to nine and a half months.
The Delta Bank TMS environment IT setup shared a
lot of similarities to that of Gamma Bank since both were
seeking upgrades of older TMS7 systems to the most
recent TMS7 software releases. Therefore, the major
factors which affected requirements analysis and project
completion are stated along the same lines.
3.1.4. Sigm a Bank
The fourth project for the deployment of TMS on behalf
of Sigma Bank at Printec Greece premises, a small
banking institution based in Greece, started at the end of
April 2009 and lasted till mid-May 2009. With an ap-
proximate duration of three weeks and only six reported
issues, see Figure 3, in terms of scope, time and budget,
as stated in PMBOK®, this was a successful project. Low
project complexity resulted to the effective application of
project management and service management practices
and an improved project timeframe for reasons described
below:
1) High control of outsourced TMS deployment ser-
vice owned by Printec Greece e-Payments Department
POS Helpdesk team;
2) A quick issue resolution process in collaboration
with Printec Greece e-Payments Department;
3) IT security policies were set internally by Printec
Group TMS support and Printec Greece e-Payments De-
partment POS Helpdesk teams.
Sigma Bank on its own involved a fresh installation of
TMS at the premises of Printec Greece; the Greek sub-
sidiary of Printec Group. Requirements definition and
management was conducted in an organised and concise
manner, from the beginning of the project. The materi-
alisation of a TMS6 system failure meant that reactive
tasks had to be put in place for urgent issue resolution
purposes. All tasks falling within the data migration and
installation barriers were executed in a timely and highly
responsive manner. Furthermore, good communications
among project stakeholders throughout the duration of
the project was executed. This involved communication
of the TMS support team with counterparts in the Printec
Greece e-Payments Department. The Technical Supervi-
sor of the Printec Greece e-Payments Department POS
Helpdesk team was appointed the TMS administrator.
Regarding risk management techniques risk owners were
appointed for the data migration, installation, mainte-
nance and administration tasks. As a result emerging
issues were resolved within reasonable timeframes. A
request was made for risk control and monitoring pur-
poses so that tasks were put in place to avoid future risk
materialisation e.g. establish daily TMS system database
backup plan.
3.1.5. Ome ga B ank
The fifth project for the deployment of TMS at Omega
Bank premises, the Greek subsidiary of a French finan-
cial services Group, started in May 2009 and lasted till
November 2009. With an approximate duration of six
months and eleven reported issues, see Figure 3, it was
the second largest and most complex project of all. High
project complexity resulting to project timeframe delays
existed due to several reasons as described below:
1) Low availability of IT resources;
2) Insufficient IT infrastructure capabilities;
3) Inexistent corporate IT security policy;
4) Lack of appointment of TMS administrator(s);
5) As a result additional TMS performance issues were
recorded due to compliance failure of the client to mini-
mum system specifications;
6) An increased rate of visits so as to ensure that TMS
deployment work was carried out as planned meant that
the project timeframe suffered additional delays;
7) Numerous training sessions had to be organised due
to an apparent indifference of Omega Bank POS Help-
desk staff to acquire the knowledge necessary to proceed
to service delivery;
8) The project was part of the first live deployment of
new corporate TMS software product during which, the
TMS support team underwent a knowledge transfer and
knowledge acquisition period as part of the service tran-

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
866
sition process.
During the project initiation stage Omega Bank
seemed to have many similarities to the Beta Bank TMS
project environment. However, a known risk materialised
over the course of the project which regarded low IT
resources support capability from the client side. This
meant that most of IT resources management had to be
conducted by the Printec Group TMS Support team
which increased the responsibility and accountability
factors on the side of the service supplier. Although the
initial project plan presented to Omega Bank did not in-
clude this kind of additional tasks the overall project du-
ration was largely affected. Moreover, the inexistence of
an appointed TMS administrator added to the already
high complexity level of the project. However, due to the
fact that the newly released TMS8 software was to up-
grade the old TMS6 system project completion was of
high priority and significance and therefore the efforts
focused in enabling a smooth transition for the day-to-
day Omega Bank POS management activities.
3.2. Identified Environment Factors Affecting
Requirements Analysis
In Subsections 3.1.1 through 3.1.5, a series of IT projects
has been presented each with its own distinct characteris-
tics. The five project environments highlighted in terms
of project management, service management and busi-
ness analysis distinguish themselves though certain iden-
tified influential factors. These factors relate to three
domains. Firstly, factors relating to human behaviour and
competencies which entails individual task ownership,
responsibility, accountability, competence and skills.
Secondly, factors related to policy and standards com-
pliance and lastly factors influenced by IT systems ar-
chitecture and IT resources availability.
The total project duration recorded at the end of each
project lifecycle indicated a correlation between the or-
ganisation criticality, see Table 3, and total project issues
per project, see Figure 4, to form a similar pattern as
shown in Figure 5.
Throughout the lifecycle of a project and from infor-
mation recorded during project closure in the lessons
learned documentation, certain environment factors were
identified which carry a major influence on service de-
livery time and budget management as well as require-
ments analysis and implementation acceptance by the
client. These factors are as follows:
1) IT security policies and standards applied, e.g.
ISO/IEC 27000;
2) Corporate software deployment policy procedures
on the client side;
3) Software documentation provision e.g. user manual,
Figure 4. Total project issues per project depicted on a ra-
dar chart.
Figure 5. Total project duration (months) per project de-
picted on a radar chart.
operator manual, etc.;
4) Rate of software training sessions for system ad-
ministrators and system users;
5) Rate of formal walkthroughs, meetings and visits at
the client site;
6) Appropriate IT support team skills on the service
provider side;
7) System administrator(s) attitude(s) in terms of new
requirements requests made, commitment to software
administration, comprehension skills of new software
through training sessions and user acceptance testing
sign-off willingness;
8) IT resources availability i.e. hardware, servers, etc.;
9) Senior management commitment from both, the ser-
vice supplier and the client;
10) Selection of appropriate deployment period. For
example, festive periods which result in high transaction
rates, summer time when seasonal shops operate e.g.
touristic shops, restaurants, hotels, should be carefully
considered when making request for change for TMS;

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
867
11) Definition of project stakeholders’ task ownership
at the beginning of the project, for both the service sup-
plier and the client, using techniques such as a RACI
(Responsible-Accountable-Consulted-Informed) chart.
The aforementioned factors should not be assigned to
a weighting system whereby each factor is categorised
according to impact on project deliverables. The reason
behind this being that throughout the duration of the five
case studies presented wherever one or more of these
factors was not satisfied there were bound to be user ac-
ceptance issues and system deployment delays. The
question at hand is how a service supplier can satisfy as
many of the factors stated previously, in order to fulfil
client requirements and attain high client satisfaction.
Sigma Bank forms a distinct exception to the above
identified factors due to the fact that it signifies an out-
sourcing IT project i.e. the TMS software was installed
internally at Printec Greece premises. In this case, the
control over the IT competency of POS management
system was given exclusively to Printec Greece–POS
Helpdesk team. Therefore, certain environment factors
were considered unnecessary. For example, as mentioned
earlier the Sigma Bank TMS7 installation was a result of
an unexpected system failure and urgency emerged for
the issue to be resolved as soon as possible. Therefore the
factor regarding suitable yearly period deployment can-
not be applied in this case since the system recovery and
deployment processes commenced as soon as the system
failure occurred.
4. Findings
A number of noteworthy findings are evident regarding
the service provision of a Terminal Management System,
developed from Printec Group–R&D Division, to five
banking establishments operating within Greece. More-
over, a full cycle of requirements analysis has been de-
scribed whereby requirements identification, categorisa-
tion and prioritisation processes combined with best
practice in Project Management according to PMBOK®,
IT Service Management according to ITIL® and Business
Analysis according to BABOK® can be instrumental to-
wards successful requirements analysis.
The identification of eleven factors that have poten-
tially influenced the five project environments of Beta
Bank, Gamma Bank, Delta Bank, Sigma Bank and
Omega Bank indicates the necessity to cater for each one
in order to fulfil successfully client requirements in the
Greek banking sector. In other words, to increase project
implementation success rates these factors should be con-
sidered thoroughly. If success is to be measured in terms
of Scope, Time and Budget as stated in PMBOK®, then
that means that projects should be governed by generally
accepted best practice frameworks. For the five case
studies presented in Section 3, the project completion
rate and projects within scope rate was 100%. In general,
these were caused by the project environment factors
identified in Subsection 3.2. There was no case of force-
ful project closure even though on one occasion there
was a halting period which lasted up to six months as a
consequence of the effects of the current economic re-
cession on Delta Bank. It is also notable, that the Sigma
Bank project signified an outsourced IT competency to
Printec Greece. The TMS deployment project was a suc-
cess in project management, service management and
requirements analysis terms but this does not necessarily
mean that outsourcing is an option for any client of any
size. Sigma Bank holds a relatively small corporate
structure, the lowest number of POS devices in its TMS
database and therefore the lowest number of require-
ments.
It has been shown that constantly employed require-
ments analysis tools, techniques and methodologies as
well as issue management, time management, resources
management, risk management, stakeholder management
and service supplier Service Desk Operations reporting,
assist greatly in the process of capturing client require-
ments in a timely fashion. The need of senior manage-
ment buy-in in the process of requirements identification
has been also stressed. This increases client confidence
and maintains a healthy client-supplier relationship. Re-
quirements categorisation has revealed that when priori-
tising requirements, influencing factors should be mainly
customer centric.
Finally a thorough account of PMBOK®, ITIL®v3 and
BABOK® methodologies has been given whereby scope
management, time management, resources management,
issue management, Service Desk, availability manage-
ment, stakeholder management, risk management, busi-
ness analysis and release management processes have
been blended with requirements analysis tasks in order to
maximise business benefits. As PMBOK®, ITIL®v3 and
BABOK® methodologies are used to a certain extent,
though limited within Greece, this research has indicated
the significant opportunities presented for improved re-
quirements analysis when the PMBOK®, ITIL®v3 and
BABOK® frameworks are used in conjunction in IT pro-
ject environments for the Greek banking sector.
5. Conclusions
This paper has presented the various environment factors
with either negative or positive impact on the require-
ments analysis phase while undertaking five IT projects
with differing environmental setups within the Greek
banking sector. The essence of keeping healthy cli-

IT Project Environment Factors Affecting Requirements Analysis in
Service Provisioning for the Greek Banking Sector
868
ent-supplier relationships, appropriate IT and human re-
source provisioning by the customer side, appropriate
visit frequency rates at the customer site, provision of
high-quality software documentation from the service
supplier side, training provision of system administrators
and users from the service supplier, compliancy to cor-
porate IT security and software deployment standards at
the client site, setting service transition milestones in
accordance to specific yearly periods, service supplier
and client senior management commitment to project
deliverables as well as the use of PMBOK®, ITIL® and
BABOK® methodologies has been highlighted. Vital
issue management tools and techniques have also been
presented such as the importance of keeping an up-to-
date set of recorded issues as part of Service Desk opera-
tions and issue resolution statistics reporting to the Di-
rector of Printec Group–Software R & D Division. More-
over, the effects of proper guidance in the requirements
analysis process which entails the requirements identifi-
cation, categorisation, prioritisation, implementation and
release stages has been clearly indicated. The specific
PMBOK®, ITIL® and BABOK® functions applied within
Printec Group–Software R & D Division TMS support
team have also been presented. Finally, the importance of
defining services provision in an ‘IT-enabled business’
context has been discussed whereby the development and
deployment of IT software products support corporate
strategic envisioning, business vitality and viability
through the achievement of specific business goals.
6. Acknowledgements
Special thanks to Printec Group of Companies and the
Software R & D Division which contributed to a signifi-
cant degree to the research presented. Special thanks to
Dr. Fotis Moulatsiotis without whom the research would
not have been realised. His impeccable judgment and
proper guidance filled me with more determination to
complete a thorough research. Many thanks to Alexander
Poutos, Christos Michas and George Dimitropoulos for
their contribution on IT service support matters and
thanks to the POS Applications Development and POS
Helpdesk teams of Printec Greece e-Payments Depart-
ment. Many thanks also to the unknown referees. All
contributions filled me with greater motivation and en-
thusiasm to conduct the research.
REFERENCES
[1] Office of Government Commerce, ITIL® v3–IT Service
Management Core Books, TSO, 2007.
[2] Project Management Institute, “A Guide to the Project
Management Body of Knowledge,” 4th Edition, Project
Management Institute, 2008.
[3] B. Hughes, R. Ireland, B. West, N. Smith and D. I. Shep-
herd, “Project Management for IT Related Projects,” Brit-
ish Computer Society in Association with Biddles Ltd.,
London, 2004.
[4] IIBA, “A Guide to the Business Analysis Body of Knowl-
edge (BABOK Guide),” International Institute of Busi-
ness Analysis, 2009.
[5] P. Wheatcroft, “World Class IT Service Delivery,” British
Computer Society in Association with CAPDM, London,
2007.
[6] J. Robertson and S. Robertson, “Mastering the Require-
ments Process,” 2nd Edition, Addison Wesley, Reading,
2006.
[7] E. Harrin, “Project Management in the Real World,”
British Computer Society in association with CAPDM
2007.