The-Report-V7

Page | 0
Business Proposal
Challenge 3: Bank of America
University Technology Challenge 2015
Lancaster University
25/11/15
Daniel Abreu, Cyprian Brytan, Dan Lu, Bartek Mika, Dominika Stylinska

Challenge 3: Bank Of America Lancaster University
Page | 1
TABLE OF CONTENTS
Executive Summary................................................................................................................................................3
Introduction To The Project...............................................................................................................................4
The Design Brief......................................................................................................................................................5
Problems to Address ........................................................................................................................................5
Requirements .......................................................................................................................................................5
Features and Design..............................................................................................................................................6
Main screen......................................................................................................................................................6
Menu screen ....................................................................................................................................................6
My events..........................................................................................................................................................7
Event search.....................................................................................................................................................7
View Profile.......................................................................................................................................................8
Friends ................................................................................................................................................................8
Leader board....................................................................................................................................................8
Achievement.....................................................................................................................................................9
Event Page........................................................................................................................................................9
Settings...............................................................................................................................................................9
Notification screen..................................................................................................................................... 10
Request system............................................................................................................................................ 10
Technology.............................................................................................................................................................. 11
Front-End Development............................................................................................................................... 11
System Architecture ....................................................................................................................................... 11
Example of Use............................................................................................................................................ 13
Delivery Schedule................................................................................................................................................. 14
Agile Methodology......................................................................................................................................... 14
Planning............................................................................................................................................................... 15
Task Breakdown............................................................................................................................................... 16

Page | 2
Execution............................................................................................................................................................. 17
Review and Retrospective............................................................................................................................ 17
Post Implementation...................................................................................................................................... 18
Implementation Plan................................................................................................................................. 19
Post Implementation Plan....................................................................................................................... 21
Project Teams ........................................................................................................................................................ 22
Cost Analysis.......................................................................................................................................................... 23
RAIDS Analysis....................................................................................................................................................... 25
Risks....................................................................................................................................................................... 25
Assumptions ...................................................................................................................................................... 26
Technical......................................................................................................................................................... 26
Functional....................................................................................................................................................... 26
Issues..................................................................................................................................................................... 26
Dependencies.................................................................................................................................................... 26

Page | 3
EXECUTIVE SUMMARY
Bank of America Merrill Lynch has set a goal of conducting two million hours of volunteer work
all across the globe in a push in favour of cooperate responsibility and sustainability. Currently
employees keep track of their volunteer hours through a web-interface located within the internal
network, and it has problems of network restrictions, complexity of use, non-location specific
events. This proposal aims to show the new design of the app, technology used in the app, and
plan and estimate of the project.
Based on the requirements of the app, design of the interfaces (e.g. Main Screen) and relevant
functions are provided along with technology used in the app design and dataflow analysis.
In delivery schedule, by using Agile methodology, 4 sprints (each takes 2 weeks) will be
conducted and the whole project will take 2 months. Each sprint includes planning, execution,
review and retrospective process.
Considering the timeline, roles in Agile, location and man rates, a delivery team and a
maintenance team will conduct the project. Besides, a cost analysis is provided in the proposal,
taking into consideration of employee salaries, cost of servers, marketing cost, contingency cost
and iOS publishing fees.
RAIDS analysis identifies risks and mitigation, general assumptions along with technology and
employee assumptions, key issues and dependencies.

Page | 4
INTRODUCTION TO THE PROJECT
Guided by principles of community betterment and corporate responsibility, Bank of America
Merrill Lynch has been incentivising its employees to do volunteer work for various causes. The
benefits of this practice can be seen in the well-being of the community but also in its employees
who are able to have their personal passions supported by the company.
With all this in mind Bank of America Merrill Lynch has set a goal of conducting two million hours
of volunteer work all across the globe.
Employees keep track of their volunteer hours through a web-interface located within the Bank
of America Merrill Lynch network. Whilst functionally adequate this solution does have its
downfalls, primarily due to the interface being located within the bank’s secure network, many
employees cannot access their profiles without being connected to an internal network, usually
their office. This is a difficulty as it means employees cannot find volunteering options or log their
hours unless they’re in their office, which is not the ideal time for this information.
Another issue with the system is the over complexity and impracticality of its use, and an overhaul
with a focus on automation and simplicity would be well regarded.
The project is therefore to implement a new way for employees to track their hours and sign up
for volunteering opportunities. The predefined medium is an application that can run on
employees’ smart devices and allows employees to access the volunteering information without
local network restrictions.

Page | 5
THE DESIGN BRIEF
Problems to Address
1. Events are not location-specific
2. Logging employees’ hours needs to be done on Bank’s internal central network
3. Employees forget to log their hours (or postpone it because it’s cumbersome)
Requirements
1. Easy to install
2. Encourage more sign-ups
3. Needs to work on iOS, Android and Windows 10
4. Include some sort of location service (both automatic and manual)
5. Check miles walked, laps swam etc.
6. Alerts for upcoming events
7. Method to sign-up for events
8. Event availability (limited number of people)
9. Notifications and reminders
10. Sense of progress
11. Consistent with Bank of America branding
12. Allow users to choose switch alerting on/off and location track
13. Gather information from internal website, and data collection will be uploaded to
internal website (no need to be real time)

Page | 6
FEATURES AND DESIGN
Main screen is the one that
appears while opening the
application. It contains information
about the hours remaining to
achieve the goal and upcoming
events. It also allows users to access
the main menu, settings and
notifications.
The three progress trackers are
designed to incentivise more
volunteering. They track personal
hours against a personally set goal,
an accumulative hour for an
employee’s team, and finally the
corporate assigned goal of the
year, currently assigned at two
million hours.
Menu screen allows users to
switch between different screens.
Easy navigation throughout the
app is important. It will be
universally present from a single
swipe in from the left edge of the
screen.

Page | 7
My events screen shows
upcoming events as well as the
ones from the past. The user can
tap on each of them to reveal more
information such as availability,
date, location, capacity and add
alerts.
Event search screen allows users
to search and sign up for a specific
event. Additionally, it allows users
to invite other people to take part
in the event. There are two ways in
which users can search for the
events:
1. Search by location - app
uses GPS to triangulate
user’s location and then
displays nearby events.
2. Advanced search - users
can search for an event
based on specific criteria
(e.g. location, length, event
type, date).

Page | 8
View Profile each person’s profile
shows events they have
participated in, achievements and
basic information. For privacy
reasons, an employee can always
choose to keep their event
history/achievements/hours
private.
Friends screen allows users to look
at other people’s profiles, invite
them for events and search for new
friends. This social feature could
encourage employees to take part
in more events.
Leader board shows current
leaders as well as the user’s
position. Instead of sorting the
users based on the number of
hours they did, we created a simple
point system: current score = 2 x
hours + achievement points. The
aim of this feature is to promote
friendly competition within the
bank.

Page | 9
Achievement screen shows user’s
current achievements. The aim of
the achievement system is to
incentivise employees to volunteer
more often. If this feature is well
received, there would be abilities to
add new achievements to keep the
system growing. The system could
also allow timed events to appear,
where employees would have a
certain number of weeks to try to
unlock them, which opens up
possibilities for some themed
events nearing annual holidays or
corporate events.
Event Page is designed to give all
the information needed about an
event in a simple presentation.
Notable additions include event
capacity and a space for charities to
add small descriptions for their
events.
Settings allow users to change
privacy, location and alert
preferences. This would also allow
for the setting of personal hour
goals.

Page | 10
Notification screen is accessible
from the main menu allowing users
to check current notifications.
There are a few notification types:
1. Event invite: invitation to
participate in an event from
other users.
2. Event reminder: notification
that reminds about a
certain event. It allows users
to confirm the attendance
or cancel the event. If users
tap on ‘Confirm’, the hours
of an event are set to be
recorded.
3. Friend request.
Request system is another
important feature of the
notification system. To avoid an
even larger income of emails or
notifications, if an employee asks
their manager for permission to
miss some hours to do volunteer
work, their manager will not receive
a push notification. Instead, a
simple badge counter will show a
number near the app’s icon on their
main screen. Managers will have
access to a request approval page
where they can answer request in a
non-invasive method.

Page | 11
TECHNOLOGY
Front-End Development
Regarding front-end, the application has to work on iOS, Android and Windows devices. That
means developing three applications at the same time which will require a larger scrum team
(See Project Teams page 21).
It is important to note that this project assumes that the smartphones are up to date. Some older
versions (e.g. iOS 6 or Android Ice Cream Sandwich) may not be supported due to device
hardware limitations. (See RAIDS analysis page 24 )
The app will be developed simultaneously for all platforms so that it can be released for all devices
at the same time. Prior to the release of an application, a beta version will be released for a
calculated amount of employees. This will help in the gathering of feedback and making final
corrections before releasing the app to all Bank of America employees. The final version of the
app is going to be uploaded onto the Apple AppStore, Google Play and Windows Marketplace
to simplify the installation process.
It is also important to be able to ensure longevity as the app would be futile if unusable in a year’s
time. To guarantee longevity, the project will be developed on three different languages for each
operating system, as follows;
1. Android - Java,
2. iOS - Swift,
3. Windows Mobile - C++.
By choosing three different languages for each platform we can guarantee a longer longevity for
the app on each ecosystem. That is because platform updates do not affect native languages, or
in other words, the inevitable phone upgrades will not change the way the app functions.
System Architecture
Besides the technology used for an app design, dataflow between the app, internal servers and
external servers is shown below.

Page | 12
Although it might be more time consuming and costly, an external server, which is physically
separate from the internal one, will be used to place the application and all the new volunteering-
related features. Currently, the volunteering data is kept on an internal Bank of America server
that also contains confidential information. An external server would act as a intermediate
between the data on the internal servers and the employees smartphone. This extra layer would
allow for limited access to the internal servers minimizing security risks. The phone itself will not
be able to connect directly to the internal server. Instead, it will be connected with an external
one that will then establish a secure connection to retrieve volunteering data.
In essence, the app will be able to access the data in a real time as it is connected to the external.
However, data collected would be uploaded periodically to reduce traffic on the internal server.
Only booking data will be uploaded in a real time in order to avoid double booking.
In order to provide a sufficient level of security, the following technologies will be used:
 Internal Server - External server connection — VPN tunnel
 External Server - Client — SSL over HTTP connection
 Confidential data encryption — SHA-2
A VPN tunnel to link the external server with the internal one will provide a secure and permanent
connection. It enables sending and receiving the encrypted packets between two servers. The
external server will have limited access to the internal, allowing only to read/write the
volunteering data.
Client - External Server will be connected with SSL HTTP protocol, as it does not require a
complicated configuration on a client side. This differs from the VPN tunnel as it creates only a
short term session that allows a client to send and retrieve the data from the server.
The confidential data such as users’ credentials will be encrypted on an external server using
SHA-2 algorithm to provide an additional layer of security. This is a reasonable choice as the
algorithms are frequently used for this kind of application. Furthermore, the secure cryptographic
hashing algorithm doesn’t strain the servers as it has a rapid response time.

Page | 13
For the security purposes, each employee will have to create a new user account instead of using
the one used on internal website however, the volunteering data will be synced automatically on
both accounts. To ensure that the server protocols remain up-to-date a maintenance team has
been accounted for in the budget. (See Cost Analysis page 22)
Example of Use
1. User opens app.
a. A GET request is sent to the external server to update the data such as goal
progress etc.(also occurs when app is running in the background)
b. The external server gets the request, verifies it and then sends the SQL query to
an internal server to get the required data.
c. The required data stored in an external server along with the data obtained from
an internal one is passed to an app.
d. Information is updated.
2. User opens ‘map search’ option, and taps/clicks on an event displayed on the map.
a. App sends another GET request to retrieve information displayed on the event
page. General event information such as available places, name of an event, and
capacity are retrieved from an internal server. App-specific data such as event
photo and a detailed description are retrieved from an external server.
b. Data is passed to the client.
3. User taps on a ‘sign up’ button.
a. A POST request containing a booking information is sent to an external server
The external server, after validation of a POST request, sends the ‘UPDATE’ SQL
Query to the Internal one.
b. ‘Available spaces’ field is instantly decremented.

Page | 14
DELIVERY SCHEDULE
Agile Methodology
Compared to the traditional waterfall (table shown below), Agile methodology has benefits of
speed-to-market (supporting early and regular release), flexibility (changes in requirements are
expected), business engagement and customer satisfaction (active involvement of user
representative/ product owner). Therefore, Agile methodology, especially Scrum, will be
conducted in the delivery of the project.
Criteria Waterfall Agile
Length Typically 9-12 months Typically 2-3 months
Project size Hard to tailor down to small
projects
Well matched to small products and teams
Requirements Requirements defined upfront Flexible requirements
Clients involvement Does not involve clients Clients are highly involved in the
development of the project
Users interaction Only when gathering
requirements and user testing
Interact with users with constant meet ups
Testing Separate phase at the end of
the project
Fully-automated, continuous testing at
both functional and unit level
Cost of change High Low
With the assumptions that each Sprint takes 2 weeks to complete, the delivery timeline is shown
below.

Page | 15
Planning
At the beginning of each Sprint, planning is the first phase (shown below).
The Product Owner is responsible to prioritise the requirements and put each Product Backlog
Item (usually in User Story form) in Product Backlog. Then, the Product Owner and the team will
hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to
convert to working product during each Sprint. While the Product Owner is responsible to declare
which items are important, the team is responsible for selecting the amount of work they feel
they can implement without accruing technical debt. Towards the end of the Sprint Planning
Meeting, the team breaks the selected Product Backlog Items into Sprint Backlog and related
Tasks.
According to the requirements of the application, Product Backlog, Sprint Backlog and Sprint
Tasks for each Sprint are shown below.

Page | 16
Task Breakdown
Product Backlog
Sprint
Number Sprint Task
High Priority
Finding a volunteering opportunity for
themselves in the upcoming weeks. 1
Search opportunities by key words.
Search opportunities by tags.
Filter opportunities by distance to user.
Search opportunities by location.
Search opportunities by charity.
Search opportunities by service work type.
After volunteering, an employee wants to
see how many hours they have done in
total and see how close they are to a set
goal.
2
Automatic logging of hours after
volunteering.
Ability to manually edit the logged hours.
Visual representation of the logged hours.
Hours count towards personally
set/company set goals.
An employee finds a cause of particular
interest to them and performs volunteer
works surrounding it. They then have to
manually add the hours and charity into the
system.
3
Interface for manual logging of hours.
Interface to add charities manually into the
system.
An employee requires permission from
their manager to partake in a volunteering
opportunity, however, due to the high
volume of emails, the request is lost.
Ability to connect employees to their
respective managers.
A system to request permission from
managers.
A system to alert managers of pending
requests.
A system to alert employee of
approved/denied requests.
Medium Priority
An employee checks the capacity of an
event before choosing what volunteering
opportunity to partake in.
4
New design of the opportunity page.
Visualization of event capacity.
Visualization of number of available spaces
remaining.
Filter event by popularity/availability when
searching.
Low Priority
An employee finds a volunteering
opportunity that they believe a co-worker
would be interested in and suggests it to
them.
4
Send other employees suggestions for
events.
An incoming page to manage suggested
events.
A method to respond to suggested events.

Page | 17
Execution
After Sprint Backlog and Sprint Tasks are determined, the next phase will be Execution, including
the execution of the Sprint, Backlog Refining Meeting and Daily Scrum Meeting (shown below).
The general execution of a Sprint includes defining requirements of Sprint Tasks, analysis and
design, implementation & deployment, testing and final evaluation of the final works.
In the Daily Scrum Meeting, the Scrum Development Team members spend around 15 minutes
reporting what they have done, and what they will do to each other. The meeting is intended to
disrupt old habits of working separately, and be more self-organised. For Backlog Refining
Meeting, as most Product Backlog Items (PBIs) initially need refinement that they are too large
and poorly understood, it is useful to take some time out of Sprint Execution to help prepare the
Product Backlog for the next Sprint Planning Meeting.
Review and Retrospective
After the final works are finished in each Sprint, a Sprint Review Meeting and Sprint Retrospective
meeting will be held (shown below).
After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product
increment to the Product Owner and shareholders, and the Product Owner will declare items
considered completed. Incomplete items are returned to the Product Backlog and ranked
according to the Product Owner’s revised priorities as candidates for future Sprints. For
stakeholders, it is the opportunity to inspect and adapt the product as it emerges, and iteratively
refine everyone’s understanding of the requirements.
Team
Daily Scrum
Meeting
(Team & Scrum
Master)
Backlog Refining
Meeting
(Team & Scrum
Master)
Requirements
Analyis & Design
Implementation &
Deployment
Testing
Evaluation

Page | 18
In the final stage of each sprint, clients and users will be involved by providing feedback of the
final works. Any required improvement of the current works will be taken to next sprint and
discussed in the sprint retrospective meeting.
Each Sprint ends with a retrospective that the team reflects on its own process and dedicated
Scrum Masters will find alternative actions for the next level.
For example, at the end of Sprint 1, a sprint review meeting will be held to discuss what sprint
tasks are considered completed. Suppose the task ‘search opportunities by charity’ is not
completed, this task will be returned to product backlog for future sprints. Besides, clients and
users will be asked to try the new features and provide feedback, which will be considered in the
retrospective meeting and in Sprint 2. Furthermore, in the retrospective stage, the Agile team will
reflect on the process and figure out alternatives for Sprint 2.
Besides, at the end of the Sprint 4, a final review and retrospective should be implemented to
review the previous work and develop alternative actions for future steps. (See implementation
plan on page 19)
Post Implementation
After Sprint 4 is complete a beta will be released to a cross-section of employees for testing and
final debugging. Other than data on number of usage and usage habits, questionnaires will be
circulated asking employee’s to give their opinions on the application. The questionnaires will
also ask employees to grade to what extent they believe the app matched each of the original
specifications addressed by the brief. This will give the scrum team the information needed to
make any necessary changes before the Go-Live date.
After the Go-Live date the maintenance team will start a 12 month qualitative and quantitative
study of the app. The aim of Post-implementation review (PIR) is to insure that the initial
requirements were met and that the app is being well received within the company, but also to
produce material that Bank of America can use for future projects. Firstly, the team will gather
quantitative data to form a scope of use for the app. Metrics may include; number of users,
adoption rate, daily usage rate and the number of SQL queries being run by the external server
over a period of time. These metrics will be collected in real time and will go into a weekly report
produced by the maintenance team. For qualitative data the team will be conducting user
feedback studies through a number of circulated questionnaires. These will be sent on a quarterly
basis to a cross-section of employees and will evaluate many aspects of the app such as; UI
design, functionality, any problems found and overall opinion. These questionnaires may also
specifically ask employee’s about the initial project requirements to see if any were not met and
may need iterating in the future. The results will be analysed and compiled together with the
weekly usage studies to form a benefits review that will be released on a quarterly basis.
The aim of this system to insure that the project has a larger scope than simply the release of the
app. The PIR process will provide Bank of America with invaluable information on its employee’s
preferences and usage habits that can easily be transferred into future iterations of the volunteer
app or into other projects. A plan for the post implementation can be seen on page 21.

Page | 19
Implementation Plan
Task Time Frame (8 weeks) Duration
(week)1 2 3 4 5 6 7 8
Sprint1 Weeks 1-2
Identify requirements, create product backlog and sprint 1 backlog 0.5
Design search opportunities by key words 1
Design search opportunities by tags 1
Design filter opportunities by distance to user 1
Design search opportunities by location 1
Design search opportunities by charity 1
Design search opportunities by service work type 1
Implementation & deployment of new features 1
Testing on new features 1.5
Conduct surveys with clients and review feedback on the features 1
Review and retrospective of sprint 1 0.5
Sprint 2 Weeks 3-4
Select product backlog items and create sprint 2 backlog 0.2
Design automatic logging of hours after volunteering 1
Design the function to manually edit the logged hours 1
Create the visual representation of the logged hours 1
Set hours counting function towards personally set/company set goals 1
Conduct surveys with clients and review feedback on the feature 1

Page | 20
(week)
1 2 3 4 5 6 7 8
Sprint 3 Weeks 5-6
Design the interface for manual logging of hours 1
Design the interface to add charities manually into the system 1
Design the function to connect employees to their respective managers 1
Design a system to request permission from managers 1
Design a system to alert managers of pending requests 1
Design a system to alert employee of approved/denied requests 1
Promotional activities within employees (emails, updates on website) 1
Sprint 4 Weeks 7-8
New design of the opportunity page 1
Visualization of event capacity 1
Visualization of number of available spaces remaining 1
Filter event by popularity/availability when searching 1
Design of sending other employees suggestions for events 1
Design an incoming page to manage suggested events 1
Design a method to respond to suggested events 1

Page | 21
(week)
1 2 3 4 5 6 7 8
Final review and retrospective of the whole project 0.5
Post Implementation Plan
Task Time Frame (12 months)
3 4 5 6 7 8 9 10 11 12
Promotional activities (launch day competition, emails, updates on website)
Beta version release (Android, iOS and Windows version)
Review of Beta version (user & functionality)
Public release (Android, iOS and Windows version)
PIR – (team & users)
Access usage and effect of promotion
Maintenance and updates

Page | 22
PROJECT TEAMS
The project assumes one team working on the delivery of the project and the other responsible
for maintenance of the application.
Delivery team will be based on Agile Methodology, with 13 team members, each of them actively
participating in the delivery process. Our ideal agile team is made up of one scrum master and
12 other team members. These team members would have cross-functional roles and be able to
adapt their skills to the given sprint. The onshore team would work for a total 40 days, not
accounting for contingencies, and the offshore maintenance team for 250 days.
In the project outline, there was a list of team members which would be more suitable to the
Waterfall Methodology, however, we have decided to choose roles from the list, with the
assumption that each of these people would be willing and knowledgeable to work as a part of
agile team.
The list above is our allocation of roles from a waterfall methodology to that of a scrum team.
Role Role in Agile Location
Number of
Employees
Project Manager Scrum Master
Onshore
1
Solution Architect
Team
2
Test Analyst 2
UAT Analyst 2
Technical Developer (Build) 4
IT Security 2
BAU Service Manager
Maintenance Offshore
1
BAU Analyst 2

Page | 23
COST ANALYSIS
There are three main cost generating areas of the project: delivery team, the servers and
maintenance team. The fourth section are minor costs as well as contingency cost.
For the delivery team, the estimated delivery time is 2 months, which corresponds to 40 working
days. In addition, personnel cost will also include the maintenance team, working for 250 days
which is the full year.
The delivery team is placed onshore and generates the cost of £192,000.00. (See page 18 for full
breakdown.) The maintenance team will work offshore in order to decrease costs (any changes
to their daily cost incurs huge differences as they work for 250 days), with total cost of
£162,500.00.
Servers, will be provided by a third party, as Bank of America’s servers would involve high security
risk, are assumed to generate £20,000.00. This may vary depending upon the providers and
negotiations with them as Bank of America may have some partners in this sector who would be
able to offer reduced fees.
Other costs include iOS app publishing, which is £200.00 and, for marketing purposes, launch
day prize of iPad Air that would cost approximately £400.00.
Contingency cost has been set at £20,000.00, which has been allocated for unexpected costs such
as; project delays, changes to the sprint backlog. It is worth mentioning that these are incurred
costs for accounting purposes and do not have to occur in the project’s life or afterwards.
The total cost of the project is, therefore, £395,100.00, which does not exceed the given budget
of £400,000.00. That shows high cost efficiency of the project as well as good resource planning,
as all possible risks and additional outflowing cash flows have been taken into account.
Therefore a significant part (41%) of the whole cost is the maintenance team, that we assume will
work as a technological part of Bank of America. Nonetheless, this may not be required if training
for already employed employees was provided and is dependent on Bank of America’s HR
management.

Page | 24
Role Role in Agile Location Number of Employees Man Day Rate Result
Project Manager Scrum Master
Onshore
1 £ 400.00 £ 16,000.00
Solution Architect
Team
2 £ 600.00 £ 48,000.00
Test Analyst 2 £ 300.00 £ 24,000.00
UAT Analyst 2 £ 300.00 £ 24,000.00
Technical Developer
(Build)
4 £ 300.00 £ 48,000.00
IT Security 2 £ 400.00 £ 32,000.00
Total: 13 Days Worked: 40
BAU Service Manager
Offshore
1 £ 300.00 £ 75,000.00
BAU Analyst 2 £ 175.00 £ 87,500.00
Total: 3 Days Worked: 250
Additional Costs
Servers £ 20,000.00
iOS app publishing £ 200.00
Contingency cost (provision for updates) £ 20,000.00
Marketing Cost £ 2 000.00
Total
£ 396, 700.00

Page | 25
RAIDS ANALYSIS
Risks
Risk Impact Mitigation
Likelihood: Medium
Poor marketing of a
new application may
result in low
downloading volume
This would result in low
participation rate and
employee disengagement.
Hosting a launch event where
employees can win a prize.
Changing
expectations of the
product owner
A delay in implementation Scrum methodology allows for an
agile response to any product
requirements.
Likelihood: Low
Lack of access to
smart technology
Exclusion of employees The application will work parallel
with the website.
Hacking The impact of hacking is low
because the pauses in the
functioning of the system
would not affect the final
volunteering results to a great
extent.
The application will use advanced
security protocols.
Data theft The impact of hacking would
be quite low as the data stored
in the application will not be
confidential relatively to other
bank data.
The application will use advanced
security protocols.
Exchange rate
variability
It may affect salaries for off-
shore employees, which
subsequently may cause
budget constraint.
Budget accounts for contingency
costs.

Page | 26
Assumptions
1. Estimated up to 200 000 unique users in 12 months’ time
2. Each sprint takes two weeks to complete
3. Project delivery time is 2 months (40 working days)
4. Salaries proposed in the budget include tax
Technical
a. Application download size is between 50-100 MB
b. Devices have an internet access
c. Application works independently from bank’s internal website
d. Users have at least iOS 7 or Android Jelly Bean software versions on the mobile
devices
Functional
e. The team is cross-functional and self-managing. Each employee is engaged at
every stage of product design, development and implementation
f. The scrum team is based on-shore to facilitate effective communication with a
product owner.
g. The BAU team is based off-shore for the efficiency and cost-saving reasons
h. The provision for unexpected costs is set in the budget
i. The product owner is involved in every sprint review meeting
Issues
1. Privacy issue: bank employees publicly disclose their volunteering activity
Most issue will result after the project commences, usually being realized from the risks.
Dependencies
5. The progression from one sprint to another depends on a feedback from the product
owner
6. The final UI design depends on the users feedback after the beta version is released
7. The maximum size of the application depends on the maximum amount of space
designated for it in an external server
8. Speed of application depends as well on the speed on the internet connection and on
the version of the software installed
9.
10. Because in Agile methodology sprints are independent of each other, the dependencies
list is significantly reduced.

The-Report-V7

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (14)

Similar to The-Report-V7

Similar to The-Report-V7 (20)

The-Report-V7