Stakeholder Analysis and Quality Testing for Airline Information System

This report analyzes the stakeholders and quality requirements for the implementation of an airline information system. It also presents a plan for quality testing and managing change in the organization.

Introduction
This report is prepared for the case of Holiday Inc Airline Information System which has been
developed to manage passenger reservations. It is an online application which can be used by
passengers to view flight schedules, destination details, pricing, perform checks, access discounts,
and submit queries if they have any. The information system also takes care of some of the most
critical functions of the organization besides reservations such as human resource management,
sales, marketing, accounting, service reservation, and finance.
For managing human resource through the information system, the company has a database that
stores information on compensation, person, insurance, profit share, working hours, salaries, tax
deductions, and so on. This allows company to also keep track of employee performance which
helps in appraisal. Accounting and finance system produces reports on incomes, billing, assets,
outstanding, and expenses to assist management in decision making. The information is linked
across departments to create a seamless flow of information. The system also serves customers
through other assisting services information such as car hire, travel insurance, hotel booking, and
travel packages.
This report analysis the case to understand its stakeholders, quality requirements and impacts of
change that result from the implementation of the system. It identifies stakeholders and analyses
their objectives and requirements. The report also presents a plan for quality testing of the new
software and a plan for managing change in the organization (BIS, 2010).
Stakeholder analysis – objectives and business
requirements
Stakeholder analysis involves identification of stakeholders, assessment of their objectives and
needs specific to a project or a system, understanding of the impact of project on them, and the
influence they could have on the project. It is important that stakeholders are satisfied with the
developed solution and thus, this analysis is an important step in business analysis.
The key stakeholders of the airline information system are customers, airline staff, sponsor, system
developers, vendors, project manager, domain expert, and governing bodies. For each of these
stakeholders, their characteristics can be identified related to their authority, interest in project,
role, attitude towards project, and decision making (Jainendrakumar, 2016).
Stakeholder Level of
Influence
Interest Roles &
Responsibilities
Objectives and
needs
Decision
making
Project
sponsor
High High Assess
business case
and approve
funds
The
information
system should
deliver good
ROI. The
The sponsor
decides on the
budget that is
assigned for
the

sponsor needs
to review the
project plan
for its viability
to approve
budget
development
of the airline
information
system (LIM,
et al., 2005)
Project
Manager
High High Initiate, plan,
execute,
monitor and
report project
progress
Know
everything
about the
project
essential for
planning,
monitoring
and progress
reporting
Project
manager takes
day to day
decision on
resource
assignment,
task
assignment,
and project
control
Vendors Moderate Moderate Supply systems
needed for
installation
Should have
clarity on
specifications
of systems
needed and
payment for
products and
services on
time
Vendor does
not have any
control over
specifications
Developers Low Moderate Develop the
information
system
Should have all
the
information
about
company
functions,
reports, and
project
requirements
and should be
given sufficient
time for
development
Developers
take day to
day decisions
about coding
and also on
testing
(Ponnappa,
2014)
Domain
Expert
Moderate Moderate Provide
insights on the
subject to the
team of
developers
Should know
the objectives
of the solution
and the project
requirements
Can decide on
the functions
to include in
the solution
that are
essential for
operations
+Staff Low Moderate Provide
support to
project team
when needed
Should be kept
informed as
well as
involved in
requirement
gathering as
They can
provide inputs
during
requirement
gathering
(PMI, 2013)

they would be
using the
system at the
end
Governing
bodies
Moderate Moderate Permits and
approvals for
regulatory
concerns
Should have all
necessary
formalities of
documentation
provided
Regulatory
decisions
Customers High Moderate Provide inputs
for
development
Should be kept
in mind while
planning
features for
the application
Decide on the
features that
would be
needed in the
information
system
Testers Low Low Perform
testing on the
developed
solution
Should have
clear
specifications
of
performance
requirements
and testing
They perform
tests as per
the
requirements
documented
and based on
the results
decide if the
solution is
good to go live
or need
alterations
(Baguley,
2008)
A RACI matrix can be used for identifying roles of these stakeholders for the Airline information
system project which would help to identify if they are responsible or accountable for the project or
just need to be involved through consulting or information sharing. The responsibilities can be
defined along the whole project stages that include initiation, planning, execution, monitoring,
control and system testing (Beringer & Kock, 2013). The analysis of the stakeholders presented
above can help identify their roles and plot them in the matrix as follows:
Stakeholder Initiation Planning Execution Monitoring &
Control
Testing
Project
sponsor
RAC RA CI CI I
Project
Manager
RAC RAC RAC RAC CI
Vendors I CI I I CI
Developers I CI RAC CI CI
Domain Expert CI CI I I I
Staff I CI I I I
Governing
bodies
CI I I I I
Customers CI CI I I CI

Testers I CI I I RAC
Quality assurance testing Plan
Scope: The scope of the quality assurance testing is to ensure that the airline information system
meets all business, functional and technical requirements of the project. The testing plan identifies
strategies to be used for testing and the framework applied.
Objectives of quality testing are:
 Verify if the requirements of the project are fulfilled
 Verify if the project output follows the standards of quality
 Validate the functionalities of the information system with users
 Ensure that the application is compatible with the environment of the airlines system
 Ensure that the system does not have any bugs and if they are detected then also corrected
before release (Futrell, 2002)
Methodology: The testing would be conducted based on certain criteria for entry into the testing
procedure and exit from it. Before performing testing, the entry criteria’s should be fulfilled. These
would include –
 All the requirements are documented and approved
 All the specifications have been reviewed and approved
 The hardware required for testing is available
The test can be served as completed only when all the exit criteria’s are met. These include –
 All the testing scenarios are completed
 There are no issues unresolved in the airline information system
 Any defects found in testing have been corrected
 The product acceptance testing has been performed with end users
Testing Procedures: For the current project, the key tests that would be performed include
functional testing, regression testing, interface testing, integration testing, and user acceptance
testing.
Functional testing would be done to ensure that the information system fulfils all the needed
business functions requirements including human resource management, reservations, and other
service deliveries as defined in the project requirements document.
Regression testing is a recurrent test which is performed after bugs have been identified and
corrected from the system to understand if the system is defect free or need more work.
As the software has multiple modules including reservation, accounting, sales, and human resource
management, the modules are developed separately and would be integrated at the end. Thus, it is
essential to perform integration testing to ensure that all these modules are well integrated and are
performing in tandem.
Interface testing is done to ensure that the information system is able to interact with the user in the
desired way.

A user acceptance testing is the final method of testing in which the developed information system
would be given to the potential end user to test all its functionalities and finally approve it as
completed. Test scripts and scenarios are provided to this user for guiding through the test so that
all possible cases are considered during testing.
Assumptions: The testing results can only be successful of the assumptions made against it are
accurate. These include –
 The functionality of the system has been reviewed and approved by the subject matter
expert
 Development team has completed the review of the code developed
 Testers would test the system as defined in the testing plan document
 Resources identified for testing are available at the time of testing
Go-No Go Decision: Once testing is completed, the team has to take a decision on whether the
system is good to go for a launch or not. The project sponsor provides the final approval for the go
live stage. However, the other team members and stakeholders also play a critical role at this stage.
The project manager provides guidance, tracks project progress and liaisons with all participants.
Subject matters experts define the desired outcomes for the testing. Developers resolve the defects
identified in the tests and documents them. Testers perform the user acceptance testing to give a
final go on functional accuracy of the information system.
Change management plan
The change happening in the organization because of the newly developed system has to be
communicated to different stakeholders through the use of different communication methods and
tools. A change management plan can be developed for the airlines information system adoption in
the company which can help establish a groundwork to follow industry best practices to deal with
change and reduce negative impacts of the changes on the organization. This can include the
changes that are required to be managed during the project and can include changes to be made on
the project scope, schedule or resources. The changes can be triggered by anyone in the project
team or the stakeholders and any change can affect the project outcomes as well as the
organisation. Thys, they are important to control and the company should ensure that only the
changes that are most essential and beneficial to the project and the people of the company are
exercised (LIM, et al., 2005).
Process: The change management would follow a standard procedure that would involve requesting
of a change, prioritizing, analysing, approval or rejection, planning, and implementation. Certain
criteria’s can be defined for approval of the change requested to guide the process. The change
should bring the benefit to the organization or its customers. The change when requested, is
categorized into appropriate heads which makes it possible to prioritize them against other
requested changes. These categories for the airline information system would be hardware,
migration, software, configuration, SDLC, and scheduling. Based on these category and the
assessment of the impacts of the requested changes, priority can be assigned to each request that is
approved. This priority can be emergency which has to be dealt with immediately, high which needs
to be taken care of on priority, routine that follows a timeline, and low priority that is addressed only
after other priority changes are already incorporated (OECD, 2014).

Change Management Scope: The process that are within the scope of change management in a
software development project are software life cycle development, hardware procurement,
software development, database development, applications, scheduling, and modifications (Nguyen,
et al., 2007).
Change Impact Assessment: Any change that is requested on the project needs to be assessed for its
impact on the project and only when the impact is beneficial will it be approved. Thus, change
impact assessment is an essential procedure within change management plan. This evaluation can
be done on the basis of certain criteria including –
 The change is evaluated on the basis of its technical feasibility in terms of performance,
capacity, security, and operability.
 It should be evaluated to assess its impact on the resources and assets of the organization
involved on the project (Virine, 2013)
The evaluation of this assessment could be low impact, medium impact or high impact. The impact
criteria for low category include –
 Resources would be needed from the same IT group that is working on it
 No technical coordination may be needed as the change requested is not complicated
 There is no or low risk to the availability of the system during the change
 The change is easy to implement
 The change does not have any impacts on the service level agreements with the developers
or suppliers (Galway, 2004)
A change is considered to create a medium level of impact when it is meeting the following criteria –
 The resources have to be taken from another work group
 A significant complexity is involved which needs technical coordination
 Availability of the system would be moderately affected during the change
 The implementation is somewhat complex
 It can have impacts on the service level agreements
 The change would affect the application in ways such as impact on the level of security
(Nguyen, et al., 2007)
A change is considered to create a high level of impact when it is meeting the following criteria –
 The resources are needed from multiple IT groups to execute the change
 The change required has high technical complexity
 The availability of the system would be significantly affected during the change
 The security of the infrastructure can be affected by the change
 Support from external vendors may be needed
 Implementation process would be complex and would need experts to execute
Risk Assessment: The changes can also pose risks on the project that are important to assess before
change is accepted. The risks can have different impacts on different stakeholders and can be listed
as low, moderate, high or no risk to them. Based on the intensity of the risk, decisions can be taken

to allow or reject the change. The table below highlights some risks that the project can face and the
level of severity of risk is determined by the probability of its occurrence and its impact on the
project or people. Based on the severity of the risk , an appropriate response plan can be developed.
Risk Impact Probability Response
Lack of resources Moderate High Avoid by proper
planning and in case,
it still occurs,
distribute work to
remaining resources
or hire renew.
Budget overrun High Moderate Avoid by using
essential cost control
measures at every
stage of the project.
Assign a contingency
fund to take care of
situations that are
unavoidable and can
affect project
expenses (Caltrans,
2007).
Delays Moderate High Control delays by
monitoring project
progress against plan
and take control
measures in the cases
of delays occurring to
ensure that the delays
do not affect the final
delivery dates of the
project (Galway,
2004).
Communicating Change to stakeholders: The changes happening on the project must also be
acceptable to key stakeholders of the company and thus, they must eb communicated about
it. The following table suggests the ways, reasons, modes and frequencies at which they can
be communicated by the project manager or the team on changes.
Stakeholder Needs Preferred
mode
Communication Responsibility Frequency
Project
sponsor
Business case Email
Meeting
Business case
and project
viability
assessment
Approve the
budget
Initiation
stage
Project
Manager
Project
progress
Routine work
Email
Meeting
Call
Daily reporting
of project
progress
Plan, monitor
and control
project (IFRC,
2011)
Daily
Vendors Project Email Specifications Delivery Supplies

schedule for
delivery
Call
Developers Understanding
of business
functions
Email
Meeting
Software
requirements
document
Development
of software
Initiation and
weekly
reporting
Domain
Expert
Understanding
of capacities
of
development
Email
Meeting
Project
initiation plan
Suggest
functions
Initiation
Staff Information
on project
progress
Email Project
progress
Suggest
improvement
Initiation
Go-live
Governing
bodies
Project is
meeting
standards
Email Quality
documents
Approval Initiation
Closure (Cliff
Consulting.,
2007)
Customers Software
meets their
needs
Email Software
launch and
features
Acceptance Initiation
Testing
closure
Testers Software
meets all
quality and
functional
requirements
Email
Meeting
Testing plan Testing Testing
Conclusions
This report was made for the implementation of the Airline information system for a case. It
presented assessment of the project stakeholders, a change management plan and a quality testing
plan. It was found that the project had multiple stakeholders who are required to be informed about
the project at different frequencies and different ways based on their characteristics that can be
understood through their analysis.
References
Baguley, P., 2008. Project management. ., s.l.: London: Hodder Education.
Beringer, C. J. & Kock, A. D., 2013. Behavior of internal stakeholders in project portfolio management
and its impact on success. International Journal of Project Management, 31(6), pp. 840-846.
BIS, 2010. GUIDELINES FOR MANAGING PROJECTS: How to organise, plan and control projects, s.l.:
BIS.
Caltrans, 2007. PROJECT RISK MANAGEMENT HANDBOOK: Threats and Opportunities , s.l.: Caltrans.
Cliff Consulting., 2007. A Systems Implementation Project Planning Guide, s.l.: Cliff COnsulting,.
Futrell, R. T., 2002. Quality Software Project Management, s.l.: Pearson Education India.
Galway, L., 2004. Quantitative Risk Analysis for Project Management, s.l.: RAND.
IFRC, 2011. Project/programme monitoring and evaluation (M&E) guide, s.l.: IFRC.

Jainendrakumar, T. D., 2016. Project Stakeholder Management. PM World Journal, 5(5), pp. 1-9.
LIM, G., Ahn, H. & Lee, H., 2005. Formulating strategies for stakeholder management: a case based
reasoning approach.. Expert Systems with Applications, 28(2), pp. 831-840.
Nguyen, T. H., Sherif, J. S. & Newby, M., 2007. Strategies for successful CRM implementation.
Information Management & Computer Security, 15(2), pp. 102-115.
OECD, 2014. Risk Management and Corporate Governance, s.l.: OECD.
PMI, 2013. A Guide to Project Management Body of Knowledge, s.l.: PMI.
Ponnappa, G., 2014. Project Stakeholder Management... roject Management Journal, pp. 1-3.
Virine, L., 2013. Integrated Qualitative and Quantitative Risk Analysis of Project Portfolios, s.l.:
Casualty Actuarial Society.