RISK FACTORS IN THE SOFTWARE DEPLOYMENT PHASE: A CASE STUDY APPLIED IN TWO BRAZILIAN GOVERNMENT COMPANIES

Address for correspondence: Lidvaldo José dos Santos, Centro Federal de Educação Tecnológica, CEFETRJ. Rio de Janeiro, RJ, Brasil.
E-mail:
lidiosantos@tic.ufrj.br

Sildenir Alves Ribeiro, Universidade Federal do Rio de Janeiro, PPGI/UFRJ, Rio de Janeiro, RJ, Brasil.
E-mail:
sildenir.ribeiro@gmail.com

Eber Assis Schimitz, Universidade Federal do Rio de Janeiro, PPGI/UFRJ, Rio de Janeiro, RJ, Brasil.
E-mail:
eber@nce.ufrj.br

Mônica Ferreira da Silva, Centro Federal de Educação Tecnológica, CEFET/RJ, Rio de Janeiro, RJ, Brasil.
E-mail:
monica@nce.ufrj.br

Antonio Juarez Sylvio Menezes de Alencar, Universidade Federal do Rio de Janeiro, PPGI/UFRJ, Rio de Janeiro, RJ, Brasil.
E-mail:
juarezalencar@nce.ufrj.br

Risk Factors	Containment Strategies
Change in environment	Testing in a production environment.
Difficulties in using the system	Conduct user training.
Insufficient data handling	Adoption of a new methodology for analysis and control of existing data
Missing capabilities	Assign a cost to each identified risk based on the probability of occurrence and its level of impact
New requirements emerge	Perform actions that facilitate group discussions, making demonstrations to the client. Perform acceptance tests, evaluating the system against its original requirements and the current needs of the customer.
Problems in installation	Establish new management techniques for proper software integration.
Suspension and Resumption problems	Establish release dates for component integration and software deployment.
Testers do not perform well	Automate the management of test data using appropriate tools. Conduct a complete acceptance test with the user.
The effect on the environment	Adopt new hardware and software tools based on the organization's management guidelines.
Too many software faults	Prioritize the correction of software failures. Hiring experienced programmers.
User resistance to change	Conduct user training in order to solve the problem of acceptance of the software.

Ref.	Risk Factors Identified in the Literature	Risk Factors (RF)
Ref.	Risk Factors Identified in the Literature	Company A	Company B
FR1	Difficulties in using the system	Insufficient or inadequate training of the project team or new users of the system.	Difficulty of employees in using the system.
FR2	User resistance to change	User resistance to new system routines.	User resistance to new technologies.
FR3	Problems in installation	Inadequate or insufficient parameterization.	Difficulties in installing system modules
FR4	Missing Capabilities	Absence of room for training users of the system	Lack of space / equipment for storing system information

Ref.	Risk Factors identified in the literature	Containment Strategies (CS)
Ref.	Risk Factors identified in the literature	Company A	Company B
CS1	FR1	Carry out training plan: diagnose difficulties and promote actions to solve them.	Training Plan: conduct continuous training.
CS2	FR2	Maintain actions related to motivation.	Support from senior management and communication plan.
CS3	FR3	Strategy adopted in real time.	Lack of technical training of Information Communication Technology (ICT) members to treat incidents and implement the solution.
CS4	FR4	Training Plan: review planning and adapt it to the new context.	Update data storage solution(storage) Initially scan only the processes being processed.

	Company A			Company B
Ref.	Risk Factors	Containment Strategies	Ref.	Risk Factors	Containment Strategies
ECEA1	Delay in concluding the technical cooperation agreement with the Ministry of Planning.	Promote contacts with the Ministry of Planning to streamline procedures.	ECEB1	Insufficient capacity of scanners printers in the areas	Make compatible the distribution of printers from the Outsourcing of printing with the implementation Project of the system.
ECEA2	Designation of project members for other activities, not related to the project.	Intensify actions aimed at raising awareness among managers.	ECEB2	Unit authentication integration problems.	Maintain distributed authentication infrastructures.
ECEA3	Government servant’s departure from the Project.	Check the possibility of replacement.	ECEB3	Maintenance of old processes in the system without need.	Do not initially scan the processes already closed. It will be carried out according to demand.
ECEA4	Lack of alignment of expectations with the Executive Board.	Carry out a communication plan in line with the Executive Board.		Not identified.	Not identified.
ECEA5	Delay in the acquisition of equipment.	Promote meetings with the responsible sectors and check the possibility of prioritizing demands.		Not identified.	Not identified.
ECNE6	Idle employees (secretaries, messengers) due to the change in work routines.	Resize and / or redistribute employees across sectors.		Not identified.	Not identified.

Risk Factor (Probability)	Yes	No
Problems during deployment	10	-
User's Resistance to Change	9	1
New requirements emerging	9	1
Lack of Resources	8	2
Failure in the SEI	8	2
Changes in the Environment	7	3
Changes to the Operating Environment	6	4
Difficulties in using the system	6	4
Data manipulation failed	6	4
Test Failures	6	4
Process Suspension and Restart	5	5

Risk Factor (Impact)	Too Low	Low	Medium	High	Too High
Changes in the Environment	1	4	4	1	-
Difficulties in using the system	1	2	2	4	1
Data manipulation failed	2	2	3	3	-
Lack of Resources	2	2	3	3	-
New requirements emerging	1	1	5	3	-
Problems during deployment	-	2	4	3	1
Process Suspension and Restart	3	2	2	2	1
Test Failures	2	2	2	3	1
Changes to the Operating Environment	-	5	2	3	-
Failures in the SEI	1	3	1	4	1
User's Resistance to Change	-	1	1	6	2

Containment Strategies	Percentage
Training of software users.	100%
Establish a software release date, maintaining the infrastructure for component integration.	90%
Support from senior management as well as organizational changes.	80%
Allocate the experienced team for critical tasks to ensure that no delay is expected.	70%
Empower the team to predict new software requirements and adhere to the dynamic circumstances of the company.	70%
Perform actions that facilitate group discussions, performing demonstrations to the client.	70%
Deployment of new resources and allocations.	60%
Promote actions for the greatest degree of involvement and commitment of users.	60%
Adequately manage the integration of the software with the existing business.	40%
Perform a full acceptance test with the user.	40%
Selection of new implementation methodology.	20%
Apply the management of risk factors in the phases prior to software deployment.	-
Automate test data management using appropriate tools.	-
Hiring experienced programmers.	-
Conducting automated tests for the management of risk factors.	-
Other	-

Risk Factor (Probability)	Yes	No
Problems during deployment	9	1
Lack of Resources	8	2
Test Failures	8	2
Difficulties in using the system	7	3
User's Resistance to Change	7	3
Failures in the SEI	7	3
New requirements emerging	5	5
Changes to the Operating Environment	5	5
Changes in the Environment	5	5
Data manipulation failed	4	6
Process Suspension and Restart	4	6

Risk Factor (Impact)	Too Low	Low	Medium	High	Too High
Changes in the Environment	3	3	1	1	2
Difficulties in using the system	1	1	5	1	2
Data manipulation failed	-	3	3	-	4
Lack of Resources	-	-	2	5	3
New requirements emerging	2	2	4	1	1
Problems during deployment	-	1	4	2	3
Process Suspension and Restart	2	3	-	4	1
Test Failures	-	3	2	4	1
Changes to the Operating Environment	2	4	-	2	2
Failures in the SEI	-	3	2	2	3
User's Resistance to Change	1	2	2	4	1

Containment Strategies	Percentage
Training of software users.	90%
Establish a software release date, maintaining the infrastructure for component integration.	90%
Perform actions that facilitate group discussions, performing demonstrations to the client.	80%
Promote actions for the greatest degree of involvement and commitment of users.	80%
Support from senior management as well as organizational changes.	70%
Adequately manage the integration of the software with the existing business.	60%
Allocate the experienced team for critical tasks to ensure that no delay is expected.	50%
Deployment of new resources and allocations.	50%
Perform a full acceptance test with the user.	40%
Apply the management of risk factors in the phases prior to software deployment.	30%
Empower the team to predict new software requirements and adhere to the dynamic circumstances of the company.	20%
Conducting automated tests for the management of risk factors.	20%
Selection of new implementation methodology.	20%
Automate test data management using appropriate tools.	10%
Hiring experienced programmers.	10%
Other	-

Risk Factors	Company A (%)	Company B (%)
Problems during deployment	100%	90%
User's Resistance to Change	90%	70%
New requirements emerging	90%	50%
Lack of Resources	80%	80%
Failures in the SEI	80%	70%
Changes in the Environment	70%	50%
Changes to the Operating Environment	60%	50%
Difficulties in using the system	60%	70%
Data manipulation failed	60%	40%
Test Failures	60%	80%
Process Suspension and Restart	50%	40%

Containment Strategies	Company A (%)	Company B (%)
Training of software users.	100%	90%
Establish a software release date, maintaining the infrastructure for component integration.	90%	90%
Support from senior management as well as organizational changes.	80%	70%
Perform actions that facilitate group discussions, performing demonstrations to the client.	70%	80%
Deployment of new resources and allocations.	60%	50%
Perform a full acceptance test with the user.	40%	40%
Selection of new implementation methodology.	20%	20%

[1] Address for correspondence: Lidvaldo José dos Santos, Centro Federal de Educação Tecnológica, CEFETRJ. Rio de Janeiro, RJ, Brasil.
E-mail:
lidiosantos@tic.ufrj.br

Brasil

Brasil

RISK FACTORS IN THE SOFTWARE DEPLOYMENT PHASE: A CASE STUDY APPLIED IN TWO BRAZILIAN GOVERNMENT COMPANIES

ABSTRACT