You are on page 1of 8

FACTORES DE EXITO EN PROYECTOS DE DESARROLLO DE SOFTWARE:

ANLISIS DE LA INDUSTRIA CHILENA DEL SOFTWARE


Javier Pereira R.1
Narciso Cerpa T.1
Mario Rivas M. 1
RESUMEN
En este artculo presentamos los avances de una investigacin tendiente a analizar datos recopilados en la industria
chilena de software, para determinar factores de riesgo en proyectos de desarrollo. Los datos han sido obtenidos
mediante una encuesta que consulta por siete categoras de riesgo definidas en la literatura. El anlisis tiene dos
propsitos: saber si esas categoras se verifican para el caso chileno y reconocer qu caractersticas permiten definir un
proyecto exitoso de desarrollo de software en nuestra realidad. Luego de haber encuestado a un grupo importante de
empresas, grupos y profesionales del rea de ingeniera de software, los resultados obtenidos hasta ahora permiten
concluir que un proyecto es considerado exitoso si cumple tres propiedades: 1) mejora las expectativas profesionales de
los participantes, 2) permite a sus participantes mantener relaciones laborales satisfactorias y 3) posee un buen plan, con
tiempos detallados de las actividades. Por otro lado, factores que son considerados importantes en la literatura, como por
ejemplo la gestin de requerimientos, la relacin con el cliente/usuario, o la existencia de patrocinadores de proyecto,
estn ausentes como factores determinantes en las preocupaciones de la industria. En base a estos resultados, y al
comparar con la literatura internacional, argumentamos la necesidad de realizar estudios afinados relativos a la madurez
del mejoramiento del proceso de software, en Chile.
Palabras claves: Riesgos en proyectos de software; Factores de xito; Categoras de riesgo
ABSTRACT
In this article we present the initial results of a research project, which aims to determine the software project risk
factors in the Chilean software industry. The data has been collected through a survey, in which we asked for the seven
software development risk categories defined in the literature. The analysis has two main purposes: to verify these
categories for the Chilean case, and identify the characteristics that define a successful software project in the Chilean
software development environment. After surveying an important group of organizations, software engineering teams
and professionals, the results presented here allow us to conclude that in Chile a software project is considered
successful when it: (1) improves the professionals expectations of the participants; (2) permits to keep a satisfactory
working relationships among its participants; (3) has a good plan including a detailed time estimation of activities. On
the other hand, the factors that are considered important in the literature, such as requirements management,
relationships with clients/users, or the existence of project champions are not determinant factors for the success of
software projects in Chile. Based on a comparison of these results with those in the international literature, we believe
that there is a need for undertaking research studies with focus on the maturity of software process improvement in
Chile.
Keywords: Software project risks; Success factors; Risk categories

Departamento de Ingeniera de Sistemas, Facultad de Ingeniera, Merced 437, Curic, Universidad de Talca,
jpereira@utalca.cl, ncerpa@utalca.cl, mrivasm@utalca.cl

Javier Pereira R, Narciso Cerpa T, Mario Rivas M


INTRODUCCIN
Muchos estudios han mostrado que el xito o
fracaso de un proyecto de software es una cuestin de
percepcin, y que sta puede variar de un proyecto a
otro [23,38]. Otros estudios han destacado una
profunda diferencia de opiniones entre jefes de
proyectos y los miembros del equipo de desarrollo con
respecto al xito en proyectos de software [14,30]. En
un estudio realizado a varios proyectos, los nicos
criterios de xito que tuvieron un acuerdo unnime
entre las partes involucradas fueron cumplir con los
requerimientos del usuario, conseguir el propsito,
cumplir con tiempo de entrega, cumplir el
presupuesto, dejar satisfechos a los usuarios, obtener
un software de calidad [19].
Proyectos de desarrollo de software exitosos son
comnmente referidos como tal debido a que han
cumplido con los objetivos del negocio y porque
adems han sido completados dentro del tiempo y
presupuesto
esperados
[2,19,24,39,40].
Otras
definiciones de xito, incluyen el grado en el cual el
proyecto consigui sus metas; confiabilidad; facilidad
de mantenimiento, satisfaccin de los usuarios; trabajo
efectivo en equipo; y satisfaccin profesional del jefe
de proyecto [15,27], y el grado en el cual el software
es utilizado [13]. No existe acuerdo en la definicin de
xito de un proyecto de software, y adems los jefes
de proyectos no saben como conseguirlo [4,21].
Por otra parte, [19] y [27] sealan que los factores
que conducen a fracasos en proyectos de software son:
fallas de estimacin y programacin de actividades;
fallas en la especificacin de requerimientos; fallas de
comunicacin con el cliente/usuario; pobre estructura
organizacional, falta de liderazgo, falta de apoyo del
nivel gerencial, falta de esfuerzo, choques de
personalidades; uso inefectivo de mtodos de
desarrollo de software, procesos de negocios y
asignacin de recursos inapropiados, gestin de
proyectos y herramientas de seguimiento inadecuados.

cualitativos sobre los cuales se han generado


interesantes ideas. Nosotros creemos que se necesita
un enfoque ms cuantitativo y riguroso, que permita
entender mejor los riesgos, las interrelaciones entre
factores de riesgo y sus efectos en el fracaso de
proyectos. El Taller del Programa de Investigacin en
Software para el siglo 21 de la NSF (National Science
Foundation) [3,5] sugiere que una actividad de
investigacin importante es el desarrollo de una
ciencia emprica para ingeniera de software tan pronto
como sea posible. Otra actividad mencionada como
relevante es el analizar cmo algunas organizaciones
han aprendido a construir sistemas que no presentan
sorpresas en ambientes estables.
En los siguientes prrafos discutiremos en detalle
las siete categoras identificadas anteriormente.
1.

Gestin Senior / Auspiciador


Las prcticas de gestin inadecuadas afectan el
xito de proyectos [1]. Un riesgo serio en
proyectos de software es la falta de apoyo de
auspiciadores [28]. Las malas prcticas de gestin
y la falta de apoyo de auspiciadores pueden
resultar en una falta de compromiso y/o
disponibilidad por parte del cliente/usuario.
Pueden existir serias consecuencias como
resultado de la interferencia por parte de la
gestin senior, dejando al jefe de proyecto sin la
autoridad para gestionar apropiadamente. El
cambiar al jefe de proyecto en forma arbitraria
durante el desarrollo de ste puede tambin causar
serias consecuencias.

2.

Clientes / Usuarios
La falta de involucramiento del usuario en
cualquiera de las fases del ciclo de desarrollo de
software, tambin tendr un impacto negativo en
el xito del proyecto [1,22]. Los problemas de
clientes/usuarios son una de las mayores fuentes
de fracaso de un proyecto [37]. Expectativas
realistas de parte del cliente pueden reducir
capacidad de conflicto, y esto puede a la vez
ayudar en la percepcin que el desarrollador y
nivel de gestin tienen del xito del proyecto [21].

3.

Requerimientos
Entender los requerimientos es un factor crtico
para el desarrollo de un sistema exitoso. La falta
total o parcial de comprensin del problema y su
entorno, conduce a requerimientos incompletos y
por lo tanto causa serios riesgos para el proyecto
[33]. Si no existe un acuerdo de parte de los
clientes y usuarios con respecto a los
requerimientos
del
proyecto,
aparecern
expectativas poco realistas con respecto a ste
[26].
La
obtencin
de
requerimientos
tempranamente en el proceso de desarrollo y el
uso de metodologas claramente definidas que

MARCO TERICO
En general, siete categoras de riesgo en proyectos
de software pueden ser identificadas: (1) gestin, (2)
clientes y usuarios, (3) requerimientos, (4) estimacin
y programacin de actividades, (5) jefe de proyecto,
(6) proceso de desarrollo de software y (7) personal de
desarrollo [28,29,36,37,]. Existen otros investigadores
que tambin han estudiado los componentes de riesgos
del proceso de desarrollo de software. Por ejemplo,
[32] identificaron seis categoras de riesgo:
programacin de actividades y tiempos, funcionalidad
del sistema,
subcontratos, administracin de
requerimientos, utilizacin de recursos y desempeo, y
gestin de personal. La investigacin realizada por
estos autores, se basa fundamentalmente en aspectos

Factores de xito en proyectos de desarrollo de software: Anlisis de la industria chilena del software
proyecto de software que estn gestionando. Sin
embargo, durante la ejecucin de un proyecto,
muchos jefes estn demasiado ocupados y sujetos
a presiones propias del proyecto, de modo que
ellos olvidan las fases de control de riesgo [31].
Todos aquellos involucrados en el proyecto (nivel
de gestin, desarrolladores y clientes/usuarios), y
su impacto en ste necesitan ser considerados.

ayudan a la buena comprensin de los


requerimientos por aquellos involucrados en el
proyecto, disminuye los riesgos [8]. Adems, el
uso de procedimientos bien definidos para
procesar cambios en los requerimientos ayuda al
xito de un proyecto.
4.

Estimacin de Esfuerzo y Programacin de


Actividades
Una mala estimacin de esfuerzo es
frecuentemente
uno
de
los
mayores
contribuyentes al fracaso de los proyectos de
software [6]. De acuerdo a Brooks, ms proyectos
de software fracasan por falta de tiempo que por
todas las otras causas juntas [7]. Este autor hizo
varias observaciones con respecto a estimacin y
programacin de actividades, incluyendo las
siguientes: (1) nuestras tcnicas de estimacin no
son cientficas y asumen que todo funcionar de
acuerdo a lo esperado; (2) no estamos seguros de
nuestras estimaciones y stas no son apoyadas por
el jefe de proyecto; (3) necesitamos ser firmes y
defender nuestras estimaciones; y (4) tendemos a
agregar recursos humanos a un proyecto atrasado,
retrasndolo an ms. Desde que Brooks [7] hizo
estas observaciones en los aos setenta, ha habido
una cantidad substancial de investigacin que se
ha concentrado en la estimacin de esfuerzo y
programacin de actividades. DeMarco sugiere
que actualmente el problema de estimacin de
costos en el desarrollo de software est resuelto, y
que los jefes de proyectos saben qu hacer, pero
que simplemente no lo hacen [10]. La obtencin
de requerimientos incompletos o de mala calidad,
puede causar una estimacin de esfuerzo
inapropiada, una pobre estimacin de recursos,
desarrolladores estresados, y actividades del
proyecto subestimadas.
Desafortunadamente, la gestin senior no
siempre permite a los jefes de proyectos el estar
involucrados en la estimacin de stos [36]. Si los
jefes de proyectos estuvieran mejor entrenados en
tcnicas de estimacin y metodologas, sus
estimaciones de esfuerzo y programacin de
actividades podran ser ms crebles.

5.

Gestin de Proyecto
Un proyecto acfalo, o con un jefe que no tiene la
experiencia apropiada, corre un riesgo serio [37].
Los principales riesgos de proyectos estn
asociados con el mismo proceso de gestin de
proyectos, y muchas de las buenas prcticas de
gestin estn relacionadas al proceso de gestin
de riesgos. Por lo tanto, aquellos jefes de
proyectos exitosos, son buenos en la gestin de
riesgo [6]. Estos jefes de proyectos no aceptan ni
tampoco ignoran los riesgos potenciales del

La gestin efectiva de proyectos est enfocada


en las personas, problemas y procesos [12,26]. A
pesar que la mayora de los jefes de proyecto
admiten que se ven enfrentados a ms problemas
relacionados a las personas que a problemas de
naturaleza tcnica, raramente gestionan enfocados
en las personas, porque no tienen el entrenamiento
en los aspectos sociolgicos del desarrollo de
software [11]. Adems, es ms fcil solucionar los
problemas tcnicos que los sociolgicos. Aquellos
profesionales con un gran conocimiento de los
aspectos tcnicos de ingeniera de software no
estn normalmente preparados para las
responsabilidades de gestin [18].
El satisfacer las expectativas del personal de
desarrollo de software es un aspecto esencial de la
gestin. Esto implica principalmente la
motivacin de los empleados, empezando por
entender aquello que los miembros del equipo de
desarrollo valoran a nivel personal. Los
empleados que han sido motivados, estarn ms
dispuestos a apoyar la obtencin de las metas a
nivel organizacional, ayudando a satisfacer las
expectativas de los involucrados en el proyecto
[12]. Existen muchos otros factores que impactan
el xito de los proyectos, entre otros: tratar a cada
miembro del equipo en forma justa; mantener
buena relacin con el personal; tener la habilidad
para delegar responsabilidad; mantener una buena
comunicacin con otros involucrados; tener una
visin clara del proyecto; tener un buen
entendimiento
de
los
problemas
del
cliente/usuario; y practicar el liderazgo.
6.

Desarrolladores
El impacto de los desarrolladores en el proceso de
desarrollo de software es crtico en trminos de la
actividad que ellos desarrollan, y con quien
interactan. La falta de control de proyecto tiene
como resultado que los desarrolladores trabajan
horas extras sin recompensa, teniendo efectos
negativos en sus vidas personales, y arriesgando
el xito del proyecto [9]. Un mayor entendimiento
de lo que contribuye a mantener a estas personas
felices y motivadas ayudar a disminuir los
riesgos del proyecto. Los desarrolladores tienen
una nica perspectiva de la nocin de xito que
est directamente relacionada a la motivacin. La

Javier Pereira R, Narciso Cerpa T, Mario Rivas M

7.

mayor parte de los estudios de productividad han


encontrado que la motivacin tiene ms influencia
en la productividad que cualquier otro factor [21].
Debido a que la ms importante recompensa de la
motivacin es el crecimiento personal, la
necesidad de los desarrolladores por otras
recompensas, tales como aumentos de sueldos y
promociones, puede ser mitigada [16]. El
satisfacer las necesidades de los desarrolladores
de software contribuye a satisfacer las
necesidades de clientes/usuarios como tambin las
necesidades de la organizacin.

proyectos de desarrollo de software, en el contexto


chileno.
- Desarrollar modelos estadsticos relacionando los
riesgos de proyectos de software, factores crticos
de xito, y mitigantes, con el propsito de predecir
el xito o fracaso de proyectos de software en
Chile.
- Verificar la capacidad de generalizacin de los
modelos en diferentes organizaciones de desarrollo
de software en Chile.
- Desarrollar un prototipo de software que incorpore
los modelos estadsticos desarrollados.

Proceso de Desarrollo de Software


La gestin de riesgo es solo una faceta del
proceso de desarrollo de software que comienza
junto con la definicin y contina a travs de la
planificacin, ejecucin y control, hasta la
finalizacin y clausura del proyecto.
Sin
embargo, el anlisis, seguimiento y control de
riesgos es una de las reas ms dbiles del
proceso de desarrollo [31]. En efecto, el riesgo
puede ser reducido a travs del mejoramiento del
proceso de desarrollo [17]. La idea detrs del
CMM (Capability Maturity Model), es situar el
proceso de desarrollo de software bajo control
estadstico y por lo tanto hacerlo ms predecible.
Metodologas de software inapropiadas, pobre
planificacin, monitoreo y control, agregan riesgo
a un proyecto. Mucho se ha escrito acerca de los
efectos negativos de las subestimaciones en la
programacin de un proceso de desarrollo, lo cual
resulta en un acortamiento de las actividades de
ste [6,25,26].

Actualmente, hemos concluido la fase de


recoleccin de datos. Fueron entrevistadas empresas y
grupos de desarrollo de software, en Chile. Cabe
destacar que un nmero importante de las empresas
encuestadas estn comprometidas en el mejoramiento
del proceso de software, por lo cual fueron bastante
sensibles a nuestra investigacin. En una primera fase
(abril a octubre de 2003), se recolectaron 320
encuestas. De ellas, 129 fueron respondidas por jefes
de proyecto, y 191 por distintos profesionales
asociados al desarrollo de software. Las preguntas
dirigidas a los jefes de proyecto fueron elaboradas de
manera que una persona pensara en los factores que
influyeron en el xito o fracaso de un proyecto real
que hubiese terminado antes del momento en que se
aplicaba la encuesta. En el caso de los profesionales,
las preguntas estaban elaboradas de manera que las
personas reflexionaran sobre los factores que se
perciban como asociados al xito de un proyecto, en
trminos generales. En el primer caso, hablamos de la
Encuesta de Percepcin de Proyecto (EJP), en el
segundo de la Encuesta de Percepcin Personal (EDP).

Existe una paradoja, a veces los participantes de un


proyecto de software tienen grandes incentivos en los
primeros pasos de una actividad para esconder los
riesgos, a pesar de que las posibles consecuencias de
este comportamiento deberan incentivarlos para
detectarlos. El entender la motivacin de esta paradoja
y de otras malas prcticas es esencial para la
evaluacin de cualquier proceso de gestin de riesgos
[34].
MTODO DE ANLISIS
El objetivo de nuestra investigacin es desarrollar
modelos de anlisis y mitigacin de riesgos para
ayudar a los jefes de proyectos a identificar riesgos
potenciales tempranamente en la vida de un proyecto
de desarrollo de software, con el propsito de tomar
acciones correctivas.
Las actividades definidas para desarrollar esos
modelos son las siguientes:
- Recopilar datos para definir la nocin de xito de

El cuestionario dispuesto para la EDP organiza 59


preguntas de acuerdo a las siete categoras de riesgo
siguientes:
- Gestin/proceso:
Grupo de preguntas asociadas a las prcticas de
gestin de proyectos aplicadas por la gestin
superior.
- Estimaciones:
Preguntas asociadas al uso de estimaciones para la
programacin y planificacin de actividades.
- Clientes y usuarios:
Cuestiones centradas en la relacin establecida
entre el cliente y el proveedor de un software
desarrollado.
- Requerimientos:
Preguntas que se relacionan con las prcticas de
gestin de requerimientos.
- Personal y profesionales:
Preguntas acerca del ambiente de desarrollo
personal, profesional y de status de los miembros
de un equipo de desarrollo de software.

Factores de xito en proyectos de desarrollo de software: Anlisis de la industria chilena del software
- Equipo de desarrollo:
Cuestiones relativas a la organizacin que posee el
equipo de desarrollo de software.
- Relaciones interpersonales:
Preguntas concernientes el ambiente laboral
establecido entre una persona y su grupo de
trabajo, incluyendo los superiores.
- Otros aspectos:
Algunas preguntas generales asociadas al mtodo
de trabajo utilizado en el desarrollo.
Cada pregunta comienza con la afirmacin En su
percepcin, para que un proyecto tenga una alta
probabilidad de xito es importante que, a la cual
le sigue otra parte de la frase, por ejemplo, el
proyecto est bien planificado. Todas las preguntas
se responden segn la escala: (Acuerdo 5 4 3 2 1
Desacuerdo).
Para estudiar los resultados de la encuesta,
aplicamos anlisis factorial con el objetivo de verificar
que las 59 preguntas se explican por factores
subyacentes que tengan alguna relacin con las
categoras de riesgo encontradas en la literatura.
Queremos saber si la realidad chilena contempla
categoras de riesgo, e inversamente de xito de un
proyecto, similares a las de la realidad internacional.
Se utiliza una muestra de 191 cuestionarios, los que
fueron respondidos por empresas y grupos de
desarrollo de software de la industria chilena de
software. SPSS v.12.0 de Windows es utilizado en el
estudio. Para verificar la validez del anlisis factorial
en este problema, se utiliza el test Kaiser-MeyerOlkin que da como resultado el valor 0,867, indicando
que la tcnica es apropiada como instrumento de
anlisis. La explicacin de los factores ha sido
mejorada mediante una rotacin Varimax y se observa
que las comunalidades de las variables de base (las 59
preguntas del cuestionario) son todas mayores o
iguales a 0,5, indicando que el nmero de casos de la
muestra es adecuado.
Del anlisis se obtiene 15 factores potenciales que
explican un 67% de la varianza total. Enseguida, para
establecer los factores de inters de nuestro modelo, se
aplican las siguientes reglas [20,35]: una variable es
constitutiva de un factor si su varianza explicada es de
al menos el 65%; un factor vlido debe tener al menos
tres variables constituyentes; las comunalidades de las
variables constituyentes de un factor deben ser
superiores a 0,5.
RESULTADOS
De los 15 factores encontrados, slo tres
cumplieron con las reglas exigidas a los componentes.
A continuacin, describimos cada uno de ellos.

a)

Status profesional
Este es el primer factor, que por si solo explica un
13% de la varianza total. La Tabla 1 presenta las
variables constituyentes las cuales dan al factor una
confiabilidad (Alfa de Cronbach) de 0,93. La varianza
explicada de cada una de las variables se muestra en la
columna Varianza. Este factor lo hemos
denominado el Status profesional puesto que se
asocia al mejoramiento de las expectativas de las
personas en trminos econmicos, profesionales y
organizacionales. En la literatura, estas variables se
agrupan
bajo
la
clase
de
aspectos
personales/profesionales. Sin embargo, vemos que
ellas tienen ms que ver con aspiraciones que las
personas poseen cuando trabajan en un proyecto. Es
posible que este factor nos diga que los individuos ven
un proyecto como una oportunidad de escalamiento
personal,
profesional
y
organizacional.
Consecuentemente, un proyecto exitoso es aquel que
les permite materializar sus aspiraciones. Este
resultado es consistente con estudios previos que
indican la gran influencia del manejo de expectativas
sobre la motivacin de las personas [12] y por
consiguiente sobre la satisfaccin de las expectativas
de un proyecto, es decir, sobre el xito de ste.

Tabla 1 Status profesional (0,93)


Variable
Incremento de salario presente
y futuro
Incremento de reconocimiento
Incremento de status profesional
Oportunidad para avanzar en
carrera profesional
Incremento de nivel actual y
futuro de responsabilidad
Mejorar la seguridad de su
trabajo
Obtener crecimiento profesional
Aprender algo nuevo

Varianza
0,84
0,78
0,77
0,77
0,75
0,71
0,67
0,65

b) Relaciones interpersonales
Este es el segundo factor, que en trminos de
importancia explica un 7,5% de la varianza total. La
Tabla 2 presenta las variables que componen el factor
(la confiabilidad es 0,9). Hemos denominado este
factor de Relaciones interpersonales. Las tres
variables forman parte de la categora de riesgo del
mismo nombre, identificada en la literatura. Los
individuos consideran entonces que un proyecto
exitoso es una instancia poltica donde debe
mantenerse relaciones personales adecuadas a distintos
niveles de la organizacin. Creemos que este factor
est relacionado en cierta medida con el primero, de
status profesional, en el sentido que las buenas
relaciones interpersonales, tanto con los pares como
con los niveles gerenciales, ayudan a crear

Javier Pereira R, Narciso Cerpa T, Mario Rivas M


condiciones adecuadas para alcanzar las aspiraciones
profesionales y organizacionales.
Tabla 2 Relaciones interpersonales (0,9)
Variable
Varianza
Trabajar agradado con gerente 0,76
de equipo
Mejorar relaciones con los pares 0,75
Mejorar relaciones con los 0,72
gerentes
c)

Planificacin del proyecto


Este es el tercer factor, que explica un 6,3% de la
varianza total. La Tabla 3 presenta las variables que
componen el factor (la confiabilidad es 0,74). Hemos
denominado este factor de Planificacin del
proyecto. Notemos que en este caso, el xito de un
proyecto est asociado a la existencia de un buen plan,
es decir, un plan con estimaciones detalladas de la
duracin de las actividades.
Tabla 3 Planificacin del proyecto (0,74)
Variable
Varianza
Estimaciones detalladas del 0,75
tiempo de actividades
Existencia de un plan de 0,69
proyecto
Proyecto bien planificado
0,65

La variable que aparece en la Tabla 3, denominada


Estimaciones detalladas del tiempo de actividades
forma parte de la categora de otros factores de
proyecto. Mientras que Existencia de un plan de
proyecto y Proyecto bien planificado aparecen en
la categora de prcticas de gestin senior. Este factor
seala un elemento clave del xito percibido de un
proyecto: la gestin superior debe velar porque exista
un plan de proyecto que se fundamente en
estimaciones adecuadas de la duracin de las
actividades.
d) Categoras no soportadas
Es interesante observar aquellas categoras de
riesgo que no aparecen representadas en alguno de los
tres factores descritos anteriormente. Por ejemplo,
llama la atencin que las variables asociadas a la
gestin de requerimientos no aparecen representadas
en un factor visible, cuando en la literatura es uno de
los aspectos que tiene un alto impacto en el xito o
fracaso de un proyecto. Igualmente, la gestin de la
relacin entre clientes y usuarios con el proveedor del
software no aparece conformando un factor, a pesar
que estos aspectos son muy relevantes segn estudios
anteriores, pero en una realidad internacional. Luego,
en trminos generales, el proceso de gestin de
requerimientos
no
aparece
significativamente
representado como un factor en el modelo de anlisis
factorial.

Los aspectos relativos a la organizacin y


competencias del equipo de desarrollo de software
tampoco constituyen un grupo o factor confiable. El
anlisis factorial encuentra dos factores que
consideran el lugar de trabajo, el tamao del equipo de
trabajo y las habilidades requeridas como variables
con una varianza explicada aceptable (superior a 0,65).
Sin embargo, en uno de los factores incluye una
variable y el otro dos, luego, no son vlidos de
acuerdo a las reglas que hemos establecido.
CONCLUSIONES
En este documento presentamos los resultados
obtenidos de un estudio que busca determinar los
factores que influyen en el xito o fracaso de un
proyecto de software, en el caso de la realidad chilena.
El anlisis de las respuestas obtenidas en una encuesta
denominada de percepcin personal muestra tres
factores de xito de un proyecto de desarrollo de
software:
- El status:
Las personas consideran que un proyecto exitoso es
aquel que les otorga mejores condiciones
econmicas, un mejor perfil profesional y una
posicin ventajosa en trminos organizacionales.
- Relaciones interpersonales:
El xito de un proyecto se asocia fuertemente a la
posibilidad de establecer relaciones apropiadas con
los pares y los superiores, tanto directos como
indirectos.
- Planificacin del proyecto:
Un proyecto exitoso es aquel donde las actividades
han sido especificadas en detalle, y por
consiguiente, la estimacin de su duracin es
tambin detallada, conduciendo a un buen plan.
Segn estos resultados, en la realidad chilena, las
personas consideran que el xito de un proyecto de
software no slo est asociado al cumplimiento de un
compromiso, en este caso la satisfaccin de un plan de
proyecto, sino tambin a las condiciones en las cuales
sus participantes quedan despus que el proyecto ha
terminado, tanto en trminos de su progreso laboral
como del ambiente de trabajo. Desde una perspectiva
de gestin, esto significa que para que un proyecto sea
exitoso ex ante es necesario que la gestin superior:
- administre la motivacin,
- administre las relaciones laborales,
- administre el cumplimiento de los compromisos.
Es interesante observar que algunas de las variables
de la Tabla 1 tienen que ver con requerimientos que
las personas hacen a la organizacin que alberga un
proyecto, ms que al proyecto en si mismo. As, el

Factores de xito en proyectos de desarrollo de software: Anlisis de la industria chilena del software
sistema de recompensa econmica, el avance en la
carrera profesional, el aumento de responsabilidad, la
mejora en la seguridad del trabajo y el aprendizaje son
caractersticas que pueden ser administrados a nivel
organizacional.
Por otro lado, vemos que en la industria chilena las
personas no reemplazan el mejoramiento econmico
con otro tipo de motivacin. Es la variable ms
significativa en el anlisis. Creemos que esto seala la
necesidad de mayores estudios de la industria chilena
para observar si en ella se maneja adecuadamente
otras variables de motivacin. Una hiptesis es que el
incentivo
econmico
aparece
como
efecto
compensatorio de otros incentivos inadecuados, y por
consiguiente, habra posibilidades de mejoramiento en
esos aspectos.
Por otro lado, factores que son considerados
importantes en la literatura, como por ejemplo la
gestin de requerimientos, la relacin con el
cliente/usuario, o la existencia de patrocinadores de
proyecto, estn ausentes como factores determinantes
en las preocupaciones de la industria. En base a estos
resultados, y al comparar con la literatura
internacional, creemos que se requieren estudios
especficos tendientes a detectar el estado de este tipo
de procesos en la industria chilena del software.
Finalmente, es interesante observar lo siguiente:
dado que los resultados obtenidos sealan los
proyectos exitosos como aquellos que otorgan
importancia a los aspectos profesionales e
interpersonales, entonces una va para mejoramiento
del proceso de software es el enfoque en reas clave
asociadas a esos aspectos, antes o en paralelo con
otras reas ms tcnicas. Esto es un sujeto que debe
estudiarse en investigaciones futuras.
AGRADECIMIENTOS
Esta investigacin ha sido financiada por el proyecto
FONDECYT 1030785, del Gobierno de Chile.
REFERENCIAS
[1] K. Amoako-Gyampah, and K. B. White, When Is
User Involvement Not User Involvement,
Information Strategy: The Executives Journal,
Volume 13, Number 4, 1997, p. 40-45.
[2] D. Baccarini, The Logical Framework Method
for Defining Project Success, Project
Management Journal. Volume 30, Number 4,
1999, p. 25-32.

[3] V. Basili et al., Final Report, NSF Workshop on


a Software Research Program for the 21st
Century, Software Engineering Notes, Vol. 24,
No. 3, May, 1999.
[4] E. M. Bennatan, On Time Within Budget, John
Wiley and Sons, 2000.
[5] B. W. Boehm and V. Basili, Gaining Intellectual
Control of Software Development, IEEE
Software, May, 2000, pp. 27-33.
[6] B. Boehm, Software Risk Management:
Principles and Practices, IEEE Software, Volume
1, 1999, pp. 32-41.
[7] F. P. Jr. Brooks, The Mythical Man Month.
Essays on Software Engineering, Addison
Wesley, USA, 1975.
[8] C. Clavadetscher, User Involvement: Key To
Success, IEEE Software, Volume 15, Number 2,
1998, pp. 30, 32.
[9] T. DeMarco, Keynote speech at the
International Conference on Software Metrics,
London, April 4, 2001.
[10] T. DeMarco, What "lean and mean" really
means, IEEE Software Vol. 12 No 6 November,
1995, pp101-102.
[11] T. DeMarco, Non-Technical Issues In Software
Engineering, IEEE Conference on Software
Engineering, 1991, pp.149-150.
[12] T. DeMarco and T. Lister, Software
Development: State of the Art Vs State of the
Practice, IEEE Conference on Software
Engineering, 1989, pp. 271-275.
[13] D. Gefen, and D. Straub, The Relative
Importance of Perceived Ease-of-Use in IS
Adoption: A Study of e-Commerce Adoption,
JAIS, Volume 1, Number 8, 2000, pp. 1-30.
[14] R. L. Glass, Evolving a New Theory of Project
Success, Communications of the ACM, Volume
42, Number 11, November, 1999.
[15] N. Hagerty, Understanding The Link Between IT
Project Manager Skills and Project Success.
Research in Progress, Proceedings of SIGCPR
Conference, Evanston, IL, 2000, pp. 192-195.
[16] F. Herzberg, One More Time: How Do You
Motivate Employees?, Harvard Business
Review, September/October, 1987, pp. 109-120.

Javier Pereira R, Narciso Cerpa T, Mario Rivas M


[17] W. S. Humphrey, Characterizing The Software
Process: A Maturity Framework, IEEE Software,
Volume 5, Number 3, March, 1988, pp. 73-79.
[18] M. I. Kellner, Non-Technical Numbers In
Software Engineering (Panel Session Overview),
ICSE, 1991, pp. 149-150.
[19] K. R. Linberg, Software Developer Perceptions
About Software Project Failure: A Case Study,
Journal of Systems and Software, Volume 49,
1999.
[20] R. C. MacCallum, K. F. Widaman, S. Zhang, & S.
Hong, Sample size in factor analysis.
Psychological Methods, 4, 1999, pp.84-99.
[21] S. McConnell, Rapid Development, Microsoft
Press. Redmond, Washington, 1996.
[22] A. J. Nolan, Learning From Success, IEEE
Software, Volume 16, Number 1,
January/February, 1999, pp. 97-105.
[23] J. K. Pinto,. and S. J. Mandel, The Causes of
Project Failure, IEEE Transactions on
Engineering Management, Volume 34, Number 7,
November, 1990.
[24] J. K. Pinto, and D.P. Slevin, Project Success:
Definitions and Measurement Techniques,
Project Management Journal. Volume 19,
Number 1, 1988, pp. 67-72.
[25] S. L. Pfleeger, Software Engineering: Theory
and Practice, Prentice-Hall, 1998.
[26] R. Pressman, Software Engineering: A
Practitioners Approach, McGraw Hill, 1996.
[27] R. Pressman, Fear of Trying: The Plight of
Rookie Project Managers, IEEE Software,
January-February, 1998.
[28] J. D. Procaccino and J. M. Verner, Early Risk
factors for Software Development, Proceedings
of the 12th European Software Control and
Metrics Conference, London Eds. K. Maxwell, S.
Oligny, R. Kusters and E. van Veenendaal, April
2-4th 2000, pp.107-116.
[29] J. D. Procaccino, J. M. Verner, S. P. Overmyer,
and M. Darter, Case Study: Factors For Early
Prediction of Software Development Success,
Information and Software Technology, Number
44, 2002, pp. 53-62.

[30] J. D. Procaccino J. D., and J. M. Verner,


Software Practitioners Perception of Project
Success: A Pilot Study, International Journal of
the Computer, the Internet and Management, Vol.
10, No 1, January-April, 2002, pp20-30.
[31] J. D. Raz T and E. Michael, Use and benefits for
project risk management, International Journal
of Project Management 19, 2001, pp.9-12.
[32] J. Ropponen and K. Lyytinen, Components of
Software Development Risk; How to address
Them? A Project Manager Survey, IEEE
Transactions on Software Engineering, Vol 26 No
2, February, 2000, pp98-112.
[33] K. D. Schenk, and N.P. Vitalari, et al.
Differences Between Novice and Expert Systems
Analysts: What Do We Know and What Do We
Do?, Journal of Management Information
Systems, Volume 15, Number 1, 1998, pp. 9-51.
[34] C. Schmidt, P. Dart, L. Johnston, L. Sterling, and
P. Thorne, Disincentives for communicating risk:
a risk paradox, Information and Software
Technology, 41, 1999, pp. 403-411.
[35] W. F. Velicer, and J. L. Fava, Effects of variable
and subject sampling on factor pattern recovery,
Psychological Methods, 3, 1998, pp.231-251.
[36] J. Verner and W. Evanco, The state of the
practice of software effort estimation in business
organizations, Proceedings of ESCOM-SCOPE,
April, 2000 Munich, Germany.
[37] J. M. Verner, S.P. Overmyer and K.W. McCain,
In The 25 Years Since The Mythical Man-Month
What Have We Learned About Project
Management?, Information and Software
Technology, Volume 41, 1999, pp. 1021-1026.
[38] J. Wateridge, IT Projects: A Basis For Success,
International Journal of Project Management,
Volume 13, Number 3, June, 1995.
[39] C. Wohlin, A. von Mayrhauser, M. Host and B.
Regnell, Subjective Evaluation As A Tool For
Learning From Software Project
Success, Information and Software Technology,
Volume 42, 2000, pp. 983-992.
[40] C. Wohlin and A. von Mayrhauser, Assessing
Project Success using Subjective Evaluation
factors, Journal of Software Quality, August,
2000.

You might also like