Saturday, 28 January 2012

Literature Review WIP Sat 28 jan 2012 (8)

Reading how to write one,

collating the articles and actually doing the write up

Thursday, 26 January 2012

Thur 26th Jan 2012 -Interim Report WIP (2)





A dissertation submitted to the University of Greenwich
in partial fulfilment of the requirements for the Degree of

Master of Science
in
Information Systems Management

An investigation into why there is user acceptance issues in organisations despite having a methodology and practices in place.

Name:                            Marina Maharaj

Student ID:                   648810





Supervisor             : Mr Kumar Bobby Sookram
Submission Date   : March 2012
    Report                    : Interim Report
Word count           :




13. The Interim Report (Minimum of 2500 words)

It is assumed that significant progress towards the project’s completion will have been made
when this is written. The interim report should be a more substantial document than the initial
report. There is
􀂾 a header sheet plus two parts,
􀂾 Part A which is the Progress Report and
􀂾 Part B which should be a draft of the final report that produced to date.

􀀄 Header
This is also available on the website.
􀂾 Identifying information (student’s name, id).
􀂾 MSc Programme Title
􀂾 Project title
􀂾 The Supervisor’s Name
􀂾 Project Submission Date
􀂾 Keywords associated with the project

Part A which is the Progress Report and

Part A – Progress Report (500 - 1,000 words)
This follows the same format at the initial report and has 3 sections:
Current Situation: This section should include scheduled objectives/sub-objectives and
whether they have been achieved. If not why, those in the process of being achieved,
preliminary results, work completed, etc.

Problem areas: This should cover current problems and plans for their resolution.
Key work during the next period: Specify methods, tasks and activities and the estimates of
time to complete them. Indicate the actual progress made and identify any deviation from the
original proposal and plan.


 Part B – Draft of Project Report to Date (minimum of 2000 words)
This must include:
draft table of contents for your final report, with annotations concerning your intentions
for the chapters

Table of Contents
Introduction.............................................................................
1.1 Background..............................................................................................
1.2 Research methodology.............................................................................
1.2.1 Scope of study.......................................................................................
1.2.2 Objectives of the study..........................................................................
1.2.3 Justification of the study.......................................................................

Literature Review....................................................................
2.1 Definition of User Acceptance..................................................................
2.2 Comparison of Acceptance Models..........................................................
2.3 What works and what does not work in user acceptance..........................
2.4 People factor in Information Systems/Information Technology...............
2.5 Social Implications on Information Systems.............................................
2.6 Culture dimension on Information Systems..............................................

Overview of the Companies being investigated......................
3.1 Background.................................................................................................
3.2 Methodology in the companies...................................................................
3.3 Types of projects the companies are involved in........................................
3.4 Standards adhered to by companies............................................................
3.5 Culture within the companies......................................................................
3.6 Perception of User Acceptance within the companies................................

Companies, Projects and People...............................................
4.1 Investigation into Projects that worked........................................................
4.2 Investigation into Projects that did not worked so well................................
4.3 Differentiation Factors across Companies and projects...............................
4.3.1 Team Involved...........................................................................................
4.3.2 Sub cultures...............................................................................................
4.3.3 Project roll out...........................................................................................
4.4 Survey Results.…………………………………………………………………………………...……..

Acceptance Models revisited......................................................
5.1 Aspects of the Models that work...................................................................
5.2 Limitations of the Models..............................................................................
5.3 Recommendations for the Models.................................................................

Recommendations on achieving user acceptance..........................
6.1 Factors that must be present to achieve user acceptance.....................................
6.2 Conditions that are not encouraged.....................................................................

Limitations of Research Paper........................................................
7.1................................................................................

Critical Evaluation and Reflection of Research Paper
8.1................................................................................................................................


Conclusion..........................................................................................
9.1................................................................................................................................

References..........................................................................................
Appendix.............................................................................................







draft of at least two chapters – one of which must be the literature review.
Your supervisor will give you feedback on your progress at this stage and will make
recommendations for the final stage of the project.



Part B which should be a draft of the final report that produced to date

Chapter 1 Introduction

Abstract
1.1  Background..............................................................................................

Organisations are investing into technology as well as implementing methodologies and best practices to achieve successful information systems projects.  In addition to this, end users are brought in early to get their feedback on the system in order to stay on point with the user needs. Hard and soft system methodologies) are also used as well as user input, yet there is still an end user acceptance issues in organisations in Trinidad.

This end user problem was noticed in one organisation in Trinidad and then informal surveys were carried out in other organisations that implemented methodologies and the common issue arise that is end user acceptance problems.

This research paper seeks to investigate company (ies) in Trinidad which after implementing the known standards and best practices, there is still a disconnect with what the users need and what is actually developed and hence, leading to not high user acceptance in some areas. By understanding the challenges of user acceptance in companies, recommendations will be made to improve the acceptance levels in organisations.


1.2  Research methodology.............................................................................
The approach that was taken in this report was investigative work involving research with three companies. Interviews were carried out with people from the 3 organisations. Surveys were also sent out the keys person hand picked due to their involvement in projects.


1.2.1 Scope of study.......................................................................................
1.2.2 Objectives of the study..........................................................................

Metrics
The objective of this research paper is to understand the factors that inhibit user acceptance. By understanding what these conditions will one be able to adequately work towards achieving end user acceptance. The companies that are being looked at are those with and Information technology and Information System background.
At the end of this paper a list of metrics will be shown that one can use as a guide in attaining user approval.

1.2.3 Justification of the study.......................................................................







Literature Review....................................................................
2.1 Definition of User Acceptance..................................................................
2.2 Comparison of Acceptance Models..........................................................
2.3 What works and what does not work in user acceptance..........................
2.4 People factor in Information Systems/Information Technology...............
2.5 Social Implications on Information Systems.............................................
2.6 Culture dimension on Information Systems..............................................

Tweaking notes - Tue 24th Jan 2012 (3)

2.1 Definition of User Acceptance..................................................................

 User acceptance is the confirmation, through testing, that the delivered system meets all requirements, functions according to design parameters, and satisfies all business, technical, and management stakeholders.


 Effective user acceptance criteria:
• Are based on functional and non-functional requirements
• Are specific, unambiguous, measurable, attainable, and realistic
• Contain specific pass or fail criteria
• Address all aspects of the system in detail
• Indicate if a requirement is critical or non-critical (i.e., not required for acceptance)
• Identify unacceptable errors


 The execution of user acceptance testing is most successful when:
• Predefined and approved user acceptance criteria exist
• Users of the system perform the tests
• The test environment simulates real-world usage conditions
• Tests are conducted on a completed system that has passed unit testing, integration testing, and system testing
• Tests are conducted utilizing test cases that cover all scenarios. Test cases describe the functionality (scenario) being tested, input, expected result, actual result, pass/fail status and rectification strategy for the problems discovered, test run date and time, name of the person/role who ran the test
• All data has been migrated/converted (if applicable) prior to user acceptance testing
• Test case execution is automated with test scripts (when possible)


2.2 Comparison of Acceptance Models..........................................................
User acceptance and uniform view.
The eight models reviewed are
·         the theory of reasoned action,
·         the technology acceptance model,
·         the motivational model,
·         the theory of planned behavior,
·         a model combining the technology acceptance model and
·         the theory of planned behavior,
·         the model of PC utilization,
·         the innovation diffusion theory
·         the social cognitive theory
theory of reasoned action

For example, suppose you wanted to persuade your roommate, Pat, to go see a movie. If Pat had a positive attitude toward that movie (“I’ve heard that movie is funny”), you could try to increase the belief strength (“Everyone says it is funny; no question about it”) or evaluation (“That movie isn’t just funny, its hilarious!”) of that attitude. If Pat had a negative attitude toward attending the movie (“The movie theater is decrepit”) you could try to reduce the belief strength (“They remodeled it”) or evaluation (“The important thing is the movie, not the theater”) of that negative attitude. You could create a new favorable attitude (“I heard the soundtrack to this movie is great!”) or remind Pat of a favorable attitude.
technology acceptance model
TAM is an adaptation of the Theory of Reasoned Action (TRA) to the field of IS. TAM posits that perceived usefulness and perceived ease of use determine an individual's intention to use a system with intention to use serving as a mediator of actual system use. Perceived usefulness is also seen as being directly impacted by perceived ease of use. Researchers have simplified TAM by removing the attitude construct found in TRA from the current specification (Venkatesh et. al., 2003). Attempts to extend TAM have generally taken one of three approaches: by introducing factors from related models, by introducing additional or alternative belief factors, and by examining antecedents and moderators of perceived usefulness and perceived ease of use (Wixom and Todd, 2005).


This paper gives and over view of 8 models, compare and contrast.
Showed results of questionnaires and the compiles a uniform model which is a hybrid of those 8 models.


2.3 What works and what does not work in user acceptance..........................

Measuring Social Influence of User Acceptance – ACM

Results show that participants who
were confronted with the more socially communicative version
of the robotic agent felt more comfortable and were more
expressive in communicating with it.

UTAUT and TAM

Satisfaction and habit.

Satisfactory experiences with a behavior are a key condition
for habit development as they increase one’s tendency to
repeat the same course of action again and again


2.4 People factor in Information Systems/Information Technology...............

2.5 Social Implications on Information Systems.............................................

2.6 Culture dimension on Information Systems..............................................




Overview of the Companies being investigated......................
3.1 Background.................................................................................................
GG
Moving from 5250 = legacy system to web based applications.

3.2 Methodology in the companies...................................................................
GG
AGILE/RAD

Company B
 DSDM, Agile, SCRUM, Microsoft framework Methodology

Iterative show to the clients/beta testers
Scrum every week short status meeting
Plan:
2 weeks sprints of meeting with Product Manager and users to demo progress
- Stuff will be agreed upon and changes made, iterative

Test Lab - still being developed
- 3 sessions 1 hour each with user and technical staff
- sit while they use the share point work flow product

Daily 10 minute updates of status, recommendations, next steps, assistance

Roll out to clients with strict contract of expectations
Beta version will be sent to clients to test and feedback will be given to improve on the product
Poll users

Then the final version

( they do not have a high staff turnover, but they ensure that proper learning takes place and more than one person is quipped with the knowledge)

( Proper project management, proper technical skillset)


3.3 Types of projects the companies are involved in........................................
Company A
New/enhancements – problematic getting requirements at times
Similar/simple fixes/functionality to other programs
Mini Projects/Projects –handled like a project

Simple straight forward requests that might be similar to another task so it is easy to reference

Company B
Sharepoint project
Brand new – R & D

Used share point to manage/create minutes for meetings
Sent to get sign off from Permanent Secretary
Business Process Optimisation
Train the Trainer approach was used
Feedback was used
Iterative
Initially it was scoped at 1 month but really took 6 month
Microsoft took that hit


Online Service for Insurance Company
Iterative, Microsoft System Framework
Bugs were reported and dealt with as stated in service agreement
Good project management
Compromise


3.4 Standards adhered to by companies............................................................
3.5 Culture within the companies......................................................................

Company B
Flat company, learning environment, start up, smaller company. This environment is close knit group where people will more likely be able to share and learn. In a larger company this is sometimes lost with bureaucracy.
What is the day like for a developer or BA?

Company A
Bureaucratic Top down management. Maybe in some depts. You might see innovation but it depends on the attitude of the team lead and the importance of his position

3.6 Perception of User Acceptance within the companies................................
Teleios
Because it is iterative, there are changes done until it gets to be where it needs to be.

Companies, Projects and People...............................................

4.1 Investigation into Projects that worked........................................................

4.2 Investigation into Projects that did not worked so well................................
Another project 2007 -2011
Scope kept changing
Staff changed
14 work flows were done rather than 1
The need to draw the line was not done in the project



4.3 Differentiation Factors across Companies and projects...............................

Flatter structure vs bureaucratic
Skillset of people. Teleos technical people developing for to some level technical people

Company A
Technical people who are accustom to using the system one way designing for users who not very technical and probably use it another way – tabbing, not much mouse action.

4.3.1 Team Involved...........................................................................................
    Teleios – they have a solid team, low turnover
   GG – strapped at times for time and people

4.3.2 Sub cultures...............................................................................................
4.3.3 Project roll out...........................................................................................
4.4 Survey Results.…………………………………………………………………………………...……..
-aggregate questions of survey i.e. perceived usefulness, culture so when I use regression analysis it will be meaningful

Acceptance Models revisited......................................................
5.1 Aspects of the Models that work...................................................................
5.2 Limitations of the Models..............................................................................
5.3 Recommendations for the Models.................................................................

Recommendations on achieving user acceptance..........................
6.1 Factors that must be present to achieve user acceptance.....................................

-Sit and critically evaluate everyday work at gg – what works and what does not work well

Adequately train employees to use the software that you role out to them. Make sure they need to know what they should to do their work. More Productivity. Once they have conquered It they can support their co workers with it. Learning cycle continues and spread. Knowledge management at work. When there are new changes they might be willing to give it a try because of their confidence at mastering what they work with now.

Engage Feedback – ensure culture allows this
-          Flatter company structure allows this.
-          Environment must be right where everyone’s opinions matters and can add to the mix.
-          If there is the perception that one views does not count or one does not have a voice, they withdraw and become resistant to the changes that are to come and in effect reducing the possibility of user acceptance

Empower them to make decisions
Communication all the way – 2 way throughout
-          follow up with surveys after going live. If no follow up is done you will not know if it was accepted or not, you can learn from this for next project, as well as do additional adds on for users to make life easier
-         Company A – allowed users to demo to other users. Comfortable environment
-          Look at the findings of motor quote
-          Eg manager request, lack of communication, misinterpreted notions, different values, different perspectives and artifacts

-Need people even in other countries to push out the change and be the administrator
-          Are they equipped to do this pushing to motivate their team
-          Do they have a voice in their department/taken seriously
-          Select wisely.
-          Would also help if they are from claims and it is  a claims change it pertains to their specialty

-Tasks are diagnosed properly. If it is an enhancement that will affect a whole group and drastic to ther flow eg blanket scheme, it should be treated like a project.

This is all well and good but what happened when a constraint which happens in reality is and you might not have a strong BA to run the show or only 1 or 2 persons have project management skills. The answer is sending the employees to be trained. If double or triple the numbers have project management skills they can fill in the slack when its crunch time so you are not putting all your eggs in 1 basket. If one is sick they are other qualified persons who can pick it up and follow through.


When time is a constraint and there is no choice it has to be done:
What can you do before to deal with the situation when these conditions occur?
-Empower and train staff so the eggs are not in one basket. Larger skill set all around, ie more resources.

Have workers work perhaps a sat to get it done and compensate them adequately. Employees need to be happy. Some companies give the employee a day to take.

Socialize with staff. IS and end users there needs to be comfortable work environment. Faces to the names they deal with on a continuous basis. Company A has held a little after work lime when the other islands came to train for a new enhancement. When the issues arise other islands would have won’t feel as estranged to log issues or to ‘bother people’ who they don’t know.

Reward employees sufficiently to encourage them to own things – to be a part of things –work later is not a huge deal. Pay over time, bonuses, awards, medals.

Cut off – say no to management

What happens when something is bigger than initially thought of?
More implications – longer time?

Should I take a poll with the office people? Of what they think is best? Bas and programmers

6.2 Conditions that are not encouraged.....................................................................

Limitations of Research Paper........................................................
7.1................................................................................


Critical Evaluation and Reflection of Research Paper
8.1................................................................................................................................

Conclusion..........................................................................................
9.1................................................................................................................................
References..........................................................................................
Appendix.............................................................................................







Sunday, 22 January 2012