Embed Size (px)
Citation preview
TESIS DE GRADO EN INGENIERÍA INFORMÁTICA:
MANEJO DE EXPECTATIVAS
EN LOS PROYECTOS
INFORMÁTICOS
TESISTA: Ariel D. Schapiro (80.885)
PROFESORES: Lic. Gustavo López y Lic. Ismael Jeder
Septiembre de 2008
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
2
Agradecimientos
A mi familia, por su apoyo inagotable y su ayuda en la revisión.
A Jesica Baran, mi novia, por acompañarme siempre.
Al Lic. Gustavo López, director de este trabajo, por su orientación y guía.
A Southworks por la experiencia que nos hace crecer; y especialmente a Alejandro Jack, Matías
Woloski, Angel López y Martín Salías por su ayuda y sus consejos.
A los profesionales que se tomaron el tiempo y la dedicación de contestar la encuesta que forma
parte de este trabajo de investigación.
A los profesores, compañeros, colegas y amigos, por su colaboración de alguna u otra forma en
este trabajo.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
3
Resumen
Según los datos arrojados por el Standish Group en el año 2004, el porcentaje de proyectos que
resultan exitosos continúa siendo bajo (29%). A partir de esto, en el comienzo de este trabajo se
plantea la hipótesis que consiste en que el rol del manejo de expectativas en el desarrollo de los
proyectos informáticos, no está lo suficientemente privilegiado en el ámbito local (Argentina) y que
la implementación de metodologías de desarrollo que lo incluyan como un aspecto fundamental,
ayudará a disminuir la proporción de proyectos fracasados.
Luego se expone el estado del arte del papel que cumple el manejo de expectativas en los
proyectos informáticos, a través de aéreas de incumbencia, artefactos y prácticas concretas que lo
alientan como una lista priorizada de requerimientos del producto, entrega frecuente y manejo de
riesgos.
Más tarde se presenta el trabajo de investigación que incluye un relevamiento realizado a través de
una encuesta, que abarca una muestra de proyectos llevados a cabo por empresas del mercado
informático local. Este relevamiento brinda datos prácticos acerca de puntos claves relacionados
con el manejo de expectativas, como la percepción de los clientes, la medida y el seguimiento de la
misma a lo largo de los proyectos, las herramientas que se usan a tal efecto, las metodologías o
prácticas que se aplican y cómo éstos inciden en los supuestos que mantienen los clientes y
sponsors a lo largo de los proyectos.
La hipótesis planteada es más tarde verificada en base a la información obtenida en la
investigación. También se realizan análisis adicionales de los resultados, donde se destaca el grado
de éxito en base a la metodología de desarrollo de software seguida o la frecuencia de
comunicación del avance con el cliente.
A partir de la información recolectada y su análisis es que finalmente se construyen conclusiones
acerca del papel del manejo de expectativas, la percepción de su importancia y el rol de ciertas
metodologías y herramientas que lo alientan.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
4
Abstract
According to the data gathered by the Standish Group in 2004, the percentage of successful
projects is still low (29%). Based on that, the hypothesis raised at the beginning of this thesis states
that the role of expectation management in the development of software projects is not privileged
enough in the local market (Argentina), and that the implementation of development
methodologies that include expectation management as a fundamental aspect, will help on
reducing the proportion of failed projects.
After that, the state of the art of the role of expectation management in software projects is
explained through areas, artifacts and concrete practices that encourage it, such as a list of
prioritized product requirements, frequent delivery and risk management.
The survey-based research that covers a sample of projects undertaken by local companies in the
software market is then explained. This survey provides practical information on key points related
to expectations management, such as the perception of customers, the measurement and
monitoring of the expectations over the projects, the tools used for that purpose, methodologies
or practices that are applied and how they affect the assumptions that customers and sponsors
keep over the projects.
The hypothesis is later verified based on the information obtained in the research. Further analysis
of the results is also conducted, from where we can highlight the degree of success based on the
software development methodology implemented or the frequency of communication with the
customer regarding the project’s progress.
That information and analysis leads to the final building of a set of conclusions about the role of
expectation management, the perception of its importance and the role of the methodologies and
tools that encourage it.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
5
Contenido
Agradecimientos ................................................................................................................................... 2
Resumen ............................................................................................................................................... 3
Abstract ................................................................................................................................................. 4
1. Introducción .................................................................................................................................. 8
1.1. El problema ........................................................................................................................... 8
1.2. Preguntas Centrales ............................................................................................................ 10
1.3. Hipótesis a comprobar ........................................................................................................ 11
2. Estado de la cuestión: El manejo de expectativas ...................................................................... 12
2.1. Definiciones ........................................................................................................................ 12
2.2. El manejo de expectativas en los proyectos informáticos ................................................. 13
2.2.1. Evolución de las diferencias entre las expectativas del cliente y las del proveedor ................ 17
2.3. El manejo de expectativas escapa a la relación cliente-proveedor .................................... 22
2.4. Manejo de expectativas como factor de continuidad ........................................................ 23
2.5. Implementación .................................................................................................................. 25
2.5.1. El Manejo de Expectativas frente a los cambios de requerimientos ....................................... 25
3. Solución propuesta: Artefactos que ayudan en el Manejo de Expectativas .............................. 27
3.1. Visión & Misión ................................................................................................................... 27
3.2. Lista priorizada de requerimientos del producto (“Product Backlog”) .............................. 28
3.3. Reuniones de planeamiento y reporte con el cliente......................................................... 30
3.3.1. Planeamiento de la Iteración ................................................................................................... 31
3.3.2. Sincronización diaria del equipo (planeamiento) .................................................................... 32
3.3.3. Reporte diario del avance del equipo ...................................................................................... 33
3.3.4. Revisión de la Iteración (reporte) ............................................................................................ 34
3.3.5. Reuniones de retrospectiva de la iteración ............................................................................. 35
3.4. Entrega Frecuente .............................................................................................................. 36
3.5. Manejo de riesgos............................................................................................................... 37
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
6
4. Investigación ............................................................................................................................... 38
4.1. Objetivos ............................................................................................................................. 38
4.2. Criterios en los que se basan las preguntas de la encuesta ............................................... 39
4.3. Encuesta aplicada ............................................................................................................... 41
4.3.1. Metodologías de relevamiento ................................................................................................ 41
4.3.2. Términos y Condiciones ........................................................................................................... 42
4.3.3. Verificación de los datos .......................................................................................................... 43
4.3.4. Preguntas Centrales ................................................................................................................. 44
4.3.5. Muestra de empresas .............................................................................................................. 51
4.3.6. Factores de la encuesta que se tienen en cuenta para medir el manejo de expectativas ...... 52
4.3.7. Niveles de éxito planteados: diferencias entre el CHAOS Report y este estudio .................... 53
4.4. Uso de la herramienta de análisis estadístico .................................................................... 55
4.5. Planteo del Análisis de validez de la hipótesis (prueba de hipótesis) ................................ 56
4.5.1. Análisis estadísticos que definen la validez de cada factor ..................................................... 57
4.5.2. Diagrama de probabilidades .................................................................................................... 63
5. Resultados................................................................................................................................... 64
5.1. Resultados del Análisis de validez de la hipótesis (prueba de hipótesis) ........................... 64
5.2. Resultados desagregados por pregunta de la encuesta ..................................................... 66
5.2.1. Contexto .................................................................................................................................. 66
5.2.2. Detalles del proyecto ............................................................................................................... 69
5.2.3. Relación con el Cliente ............................................................................................................. 73
5.2.4. Resultados del Proyecto .......................................................................................................... 83
5.2.5. Detalles de metodología .......................................................................................................... 92
5.2.6. Opinión: metodología y factores de éxito/fracaso .................................................................. 93
5.3. Otros estudios estadísticos y tendencias ............................................................................ 98
5.3.1. Grado de éxito en los proyectos en base al manejo de expectativas ...................................... 98
5.3.2. Grado de éxito en los proyectos en base al plazo de entrega en meses ................................. 99
5.3.3. Grado de éxito en los proyectos en base a la frecuencia de comunicación del avance con el
cliente 100
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
7
5.3.4. Grado de éxito en los proyectos en base a la medición por parte del cliente de lo que se le
estaba entregando a lo largo del proyecto ............................................................................................. 102
5.3.5. Manejo de expectativas en base a la metodología de desarrollo de software ..................... 103
5.3.6. Grado de éxito en los proyectos en base a la metodología de desarrollo de software ......... 105
5.3.7. Cumplimiento de las expectativas del cliente en base al grado de éxito del proyecto ......... 107
5.4. Diferencias con el Chaos Report ....................................................................................... 108
6. Conclusiones ............................................................................................................................. 109
6.1. Sobre el papel del manejo de expectativas y su percepción ............................................ 109
6.2. Sobre los artefactos que ayudan en el Manejo de Expectativas ...................................... 113
6.3. Sobre la definición de éxito .............................................................................................. 114
7. Futuras líneas de investigación ................................................................................................. 115
7.1. Prácticas implementadas a lo largo del proyecto ............................................................. 115
7.2. Información que soporte otras definiciones de éxito ...................................................... 116
8. Bibliografía ................................................................................................................................ 117
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
8
1. Introducción
1.1. El problema
El desarrollo de proyectos informáticos es una disciplina joven, con menos de 50 años y como tal,
está buscando distintas formas para perfeccionarse [Baskerville, 2005]. En este camino surgieron
muchos marcos de trabajo, metodologías, modelos de procesos y estándares que persiguen la
eficiencia en el desempeño de los proyectos. Algunos de aquellos están representados en la
siguiente figura de SYSTEMATIC PROCESS IMPROVEMENT USING ISO 9001: 2000 AND CMMI de
Mutafelija y Stromberg:
Figura 1: Relaciones entre los estándares más prominentes [Mutafelija, et al., 2003].
Sin embargo, estudios como el famoso CHAOS REPORT [The Standish Group, 1994] del Standish
Group en el año 1994 arrojaron datos alarmantes: en EEUU solo el 16% de los proyectos era
considerado un éxito. El 53% no llegaba a cumplir las metas definidas en su comienzo, a nivel de
funcionalidad solicitada, estándares de calidad requeridos, presupuesto económico o fechas de
entrega (proyectos desviados). Mientras que el 31% restante era cancelado antes de completarse.
El reporte del año 2004 [InfoQ, 2006] informó acerca de un 29% de proyectos exitosos: éstos casi
se duplicaron en 10 años, pero aún el porcentaje de proyectos desviados continúa siendo
considerable:
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
9
Figura 2: Proyectos cancelados, desviados y exitosos según el Standish Group.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
10
1.2. Preguntas Centrales
En base a lo anterior, en el presente trabajo de Tesis se plantearán algunas preguntas o hilos
conductores. Estas preguntas servirán de forma introductoria como una guía sobre lo que será el
hilo conductor del trabajo:
¿Es posible que el problema por el cual semejante cantidad de proyectos no resultan
exitosos sea la percepción de los desvíos y no los desvíos en sí mismos?
¿De qué forma y en qué medida afecta una falta de atención al manejo de expectativas de
los clientes en el fracaso de los proyectos?
¿Qué modelos o prácticas favorecen un buen manejo de expectativas de los clientes y
qué inconvenientes se encuentran para implementarlos?
¿En qué medida favorecen los compromisos firmados entre las partes definidos en
modelos orientados a características (“feature-based”) y en los enmarcados en plazos
(“time-boxed”)?
En el presente trabajo de investigación se expondrá la teoría actual sobre estos temas para luego
enriquecerla con un relevamiento similar al del “CHAOS Report” [The Standish Group, 1994], de
alcance local y orientado a contestar entre otras, las preguntas ya expuestas.
Este relevamiento abarcará una muestra de empresas del mercado informático local (ver
Muestra de Empresas); que participarán en una encuesta que brindará datos prácticos acerca del
rol e implementación del manejo de expectativas en sus proyectos.
Puntos clave como la percepción de los clientes, la medida y seguimiento de la misma a lo largo de
los proyectos, las herramientas que se usan a tal efecto, las metodologías o modelos que se aplican
y cómo éstos inciden en los supuestos que mantienen los clientes y sponsors, a lo largo de los
proyectos serán investigados partiendo de parámetros concretos y empíricos.
Se obtendrán conclusiones que, complementadas por información teórica, mostrarán la
incidencia del manejo de expectativas en el éxito de los proyectos, el papel que aquel ocupa en el
mercado local y las prácticas y herramientas que lo promueven.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
11
1.3. Hipótesis a comprobar
La hipótesis a demostrar consiste en que el papel del manejo de expectativas en el desarrollo de los
proyectos informáticos, no está lo suficientemente privilegiado en el ámbito local y que la
implementación de metodologías de desarrollo que lo incluyan como aspecto fundamental,
ayudarán a disminuir la cantidad de proyectos fracasados o desviados, aumentando por
consiguiente el grado de éxito en los mismos. Por otro lado, quienes no incluyan al manejo de
expectativas como aspecto fundamental, obtendrán resultados sensiblemente inferiores a quienes
sí lo hagan.
Con el fin de validar esta hipótesis, se planteará un análisis de validez de la hipótesis (prueba de
hipótesis) a partir de parámetros fijos resultantes de las respuestas de la encuesta.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
12
2. Estado de la cuestión: El manejo de expectativas
“El mayor enemigo de la comunicación es la ilusión de la misma”, Pierre Martineau.
2.1. Definiciones
Según Jens Egerland, [Egerland, 2003] el manejo de expectativas es el proceso de reunir,
incorporar y medir las expectativas de los clientes durante la vida de un proyecto.
Egerland explica que el manejo de expectativas es necesario durante las fases de construcción y
entrega del producto y que las expectativas deben establecerse en el inicio del proyecto y ser parte
de un acuerdo entre todas las partes intervinientes. También explica que las soluciones exitosas en
el plano informático requieren una propuesta de negocio bien definida, un entendimiento de las
capacidades tecnológicas y un entendimiento de las expectativas de los clientes.
Egerland enmarca al manejo de expectativas como uno de los componentes del manejo de calidad
(Quality Management), acompañándolo de la verificación de la calidad, manejo de procesos,
métricas, mejora continua y reconocimientos y recompensas.
Lo que rescatamos de esta definición como punto de partida es que el manejo de expectativas no
parece estar restringido a la industria del software: esta definición se amolda generalmente a
cualquier campo donde exista un proyecto con clientes definidos.
Teniendo en claro la definición y habiendo especificado la pluralidad de la misma, dirijámonos al
campo de los proyectos informáticos en particular, donde veremos el papel teórico y práctico del
manejo de expectativas.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
13
2.2. El manejo de expectativas en los proyectos informáticos
Un hombre está volando en un globo de aire caliente y se da cuenta que está perdido. Decide
reducir la altitud y divisa un hombre abajo. Baja el globo aún más y le grita: “Disculpe, ¿me podría
decir dónde estoy?”
El hombre de abajo le contesta: “Ud. está en un globo de aire caliente suspendido a unos 30 pies
por encima de éste campo”
A lo que el hombre en el globo le responde: “Ud. debe ser un desarrollador de software”
El hombre debajo le contesta: “Lo soy, ¿cómo lo sabe Ud.?”
“Bueno,” dice el hombre en el globo, “todo lo que Ud. me dijo es técnicamente correcto, pero no le
es de utilidad a nadie”
El hombre debajo le contesta,”Ud. debe ser un hombre de negocios o un gerente”. “Lo soy”,
responde el hombre en el globo, “¿pero cómo lo sabe Ud. eso?”
“Bueno,” dice el hombre, “Ud. no sabe donde se encuentra ni hacia donde se dirige, pero Ud. espera
que yo lo ayude. Ud. está en la misma posición que estaba antes de conocernos pero ahora es mi
culpa”
[2007]
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
14
En las definiciones acerca del manejo de expectativas explicábamos como el manejo de
expectativas aplica a cualquier campo donde exista un proyecto con clientes definidos; pero ¿qué
tiene de especial el manejo de expectativas en el campo del desarrollo de proyectos informáticos?
La siguiente descripción gráfica [2008] acerca del desarrollo de proyectos informáticos puede
brindar de una sola mirada un principio de respuesta:
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
15
Figura 3: Distintas expectativas en un proyecto informático
Esta es una representación, que aunque de forma exagerada, describe las visiones que tienen los
distintos actores en el desarrollo de un proyecto informático [Hord, 2005]:
Como el cliente lo explicó: en muchos casos el cliente no tiene un entendimiento
completo acerca de lo que necesita. En esos casos puede pensar que sí lo tiene pero
también puede pensar acerca de funcionalidades extra que raramente llegue a usar.
Como el líder de proyecto lo entendió: la persona a cargo del proyecto lo puede entender
con un detalle crítico errado. Este puede llegar a ser un detalle que lo hace inútil al
producto.
Como el analista lo diseñó: el analista debe decidir como corregir el posible malentendido
del líder del proyecto. Un “arreglo” común puede ser “romper” algo más para que funcione
con el diseño existente.
Como el programador lo escribió: los programadores pueden no entender las
funcionalidades esenciales en un proyecto. Ellos a veces implementan los requerimientos
de forma muy literal.
Como el encargado del negocio lo describió: el equipo de Marketing puede transformarse
en una pesadilla a los ojos de los ingenieros. Le pueden vender al cliente las
funcionalidades más brillantes del proyecto, sin prestarle la merecida atención a la verdad
o practicidad de la situación.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
16
Cómo el proyecto fue documentado: la documentación puede ser usualmente pensada
hacia el final, como si alguien más lo estuviera escribiendo a lo largo del desarrollo.
Qué se instaló: a menudo se invierten meses para que algunas funcionalidades marchen
como era esperado, para luego darse cuenta que esas funcionalidades no fueron instaladas
en el cliente porque A) no andaban, B) el instalador no entendía cómo funcionaban, o C)
alguien temía que los arreglos no fueran buenos.
Cómo fue cobrado el cliente: el software es algo costoso.
Cómo el proyecto estaba soportado:” ¿esta funcionalidad está causando que el usuario
llame a soporte? Tal vez debamos removerla” Eventualmente, se puede terminar con la
funcionalidad básica del proyecto.
Lo que el cliente realmente necesitaba: todo sería mucho más simple si pudiéramos llegar
a este punto. Pero difícilmente lo hacemos…
En base a ésta descripción de Hord, podemos extraer algunas características que tienen los
proyectos informáticos que pueden no ser tan relevantes en proyectos de otros tipos:
En muchos casos el cliente no tiene un entendimiento completo sobre lo que necesita.
Muchas veces el cliente no ve el producto hasta no haber terminado el proyecto.
Según Hord, aquella descripción, más allá de su exageración gráfica, no dista demasiado de la
realidad sobre las percepciones que tienen los distintos participantes de un proyecto informático.
Hacer que estas percepciones estén alineadas y llegar a contar con una apreciación del cliente
que esté al alcance de lo que espera producir el equipo sería en este contexto el objetivo del
manejo de expectativas.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
17
2.2.1. Evolución de las diferencias entre las expectativas del cliente y las
del proveedor
En base a una adaptación de la evolución del la exposición al riesgo explicada en MANAGING
ITERATIVE SOFTWARE DEVELOPMENT PROJECTS [Bittner, et al., 2007], podríamos establecer una
variable δ (“delta”) que utilizaremos para simbolizar la diferencia entre las expectativas del cliente
y aquellas del proveedor:
Figura 4: Áreas definidas para δ
Así como se ve en la Figura 4, podríamos establecer también distintas áreas en el estado de δ:
Equilibrado: las diferencias entre las expectativas del cliente y las del proveedor son
mínimas y/o despreciables. El cliente está al tanto regularmente sobre el avance del
equipo de desarrollo y esto hace que las expectativas que se le generan en base a eso
estén equilibradas. Todos los esfuerzos que realiza el equipo de desarrollo son como
mínimo esperados por el cliente y no se realizan esfuerzos de más.
Manejable: hay notables diferencias entre las expectativas del cliente y el avance del
proyecto. En el caso de detectarse esas diferencias pueden requerirse correcciones en los
planes del equipo de desarrollo o bien en las expectativas del cliente. Aquellas
correcciones pueden llegar a implicar retrocesos, es decir que el equipo realizó esfuerzos
que luego no son aprovechados.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
18
Riesgoso: Las diferencias entre lo que espera el cliente y el avance del equipo es
importante. Al encontrarse el cliente con el cuadro de situación puede demandar
explicaciones que fundamenten decisiones que impactarán en la continuidad del proyecto,
como por ejemplo una cancelación.
En los casos donde no existan esfuerzos para manejar estas expectativas no podremos esperar que
δ disminuya en algún lugar del ciclo de vida del proyecto. δ podría mantenerse constante por un
período de tiempo y aumentaría ante cualquier desvío por parte del equipo de desarrollo de las
expectativas del cliente.
Si como dijimos anteriormente, no existieran esfuerzos para manejar las expectativas del cliente
hasta el final del proyecto, el siguiente escenario es posible:
Figura 5: δ en un escenario donde no existen esfuerzos para manejar las expectativas
En este escenario, el avance del proyecto llega a un punto donde las expectativas del cliente distan
significativamente del avance del equipo. Esto puede poner en riesgo la satisfacción del cliente
junto con la continuidad del proyecto.
Con el objetivo de forzar atenuaciones en δ, es posible incluir espacios en el desarrollo del ciclo de
vida del software, donde el cliente se encuentre con el avance del proyecto y sus expectativas se
acerquen a la realidad del mismo. Estos espacios pueden darse gracias a una mayor comunicación
con el cliente que incluya reportes de avance, planes sobre los próximos pasos, demostraciones del
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
19
software que se está construyendo, etc. Si la metodología de desarrollo aplicable lo soporta, de
estos espacios pueden surgir modificaciones en el plan corriente, que equilibran las expectativas
del cliente con el estado actual del proyecto.
Figura 6: δ en un escenario donde existen esfuerzos para equilibrar las expectativas
Es importante aclarar que este manejo de expectativas no trata solamente de cumplir con las que
tiene el cliente. Como dijimos anteriormente y como explica Dan Fleck en SOFTWARE LEADERSHIP
[Fleck, 2007], en muchos casos, el cliente no cuenta con un entendimiento significativo sobre lo
que quiere, y muchas veces menos acerca de lo que verdaderamente necesita.
Si en los momentos que citamos anteriormente, donde se equilibran las expectativas del cliente,
el equipo solamente se limita a obtener las opiniones del cliente para aplicarlas en el desarrollo
del proyecto sin un análisis desde el punto de vista del desarrollo de software y una devolución
constructiva al cliente, el proyecto puede dirigirse a una zona de δ riesgoso. Esto se debe a que
factores como la expectativa del cliente en términos de fecha de finalización del proyecto tal vez no
sean manejados si solamente se aplican los comentarios del cliente. En este sentido, el manejo de
las expectativas en esos momentos no debería restringirse a una recolección de opiniones, sino
también al análisis conjunto de las mismas y a una devolución en términos de cómo de aplicarse
esas conclusiones el proyecto es afectado. Esta afectación incluirá factores a nivel de proyecto
como la calidad de la entrega, los tiempos de la misma, tecnologías involucradas, presupuestos de
implantación, etc.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
20
Como se ve en la figura anterior, es posible que la frecuencia de dichos momentos posibilite
equilibrar las expectativas luego de que δ entró en el terreno de lo manejable. Esto puede implicar
cambios de rumbo en términos del avance del proyecto, replanteos en el diseño, etc.
Ahora bien, ¿qué ocurre si aumentamos la frecuencia de dichos encuentros, forzando a que δ no se
escape de la zona de equilibrio? La siguiente figura plantea ese escenario:
Figura 7: δ en un escenario donde los esfuerzos para equilibrar las expectativas se repiten con frecuencia
Este escenario implica lógicamente que el cliente se involucre significativamente y que haya
canales de comunicación eficientes que posibiliten contar con sus comentarios en forma
relativamente rápida y una devolución por parte del equipo que incluya información acerca de
posibles alteraciones en factores del proyecto.
Un efecto positivo que se obtiene como consecuencia de intentar minimizar δ, es que el cliente
puede comenzar el proyecto pretendiendo algo como resultado y a lo largo del proyecto sus
expectativas van cambiando, gracias al reporte frecuente por parte del equipo y a que en el
proceso el cliente también puede ir dándose cuenta lo que verdaderamente necesita.
En base a lo expuesto anteriormente, podemos llegar a la conclusión que el camino de equilibrar
δ busca que el cliente reciba lo que estaba esperando; tal vez no lo que el cliente esperó desde
un comienzo, pero seguramente se acerca a que reciba lo que estaba esperando en cada entrega
del proyecto.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
21
Es así como en un plano ideal, podríamos decir que a través de un cuidado manejo de las
expectativas de los participantes de un proyecto, se podría transformar el pasado esquema a uno
como el siguiente:
Figura 8: Luego de aplicar un cuidado manejo de expectativas el cliente recibe lo que estaba esperando
Donde lo que el cliente necesita está consensuado entre él y su proveedor y al tener esto en cuenta
durante todo el proceso de desarrollo, se conoce perfectamente como satisfacer al cliente.
Como vimos anteriormente, las expectativas de los clientes pueden cambiar a lo largo del proyecto.
Como decía Dan Fleck [Fleck, 2007], en muchas oportunidades el cliente no sabe bien lo que
quiere, y eso lo puede ir descubriendo, con la ayuda del equipo de desarrollo a lo largo del ciclo
de vida del proyecto. Si el mecanismo de manejo de expectativas por parte del equipo soporta
estos cambios como parte natural de su comportamiento, entonces podemos decir que estamos
frente a un mecanismo ágil.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
22
2.3. El manejo de expectativas escapa a la relación cliente-proveedor
Se suele entender que las expectativas concernientes en el manejo de las mismas, se dan entre el
cliente y el proveedor en un proyecto dado y se deja al margen las expectativas que se generan
entre los demás involucrados en el proyecto. De la figura 3 se desprenden, no solamente
diferencias entre las expectativas del cliente con las del proveedor en su conjunto (equipo de
desarrollo), si no también dentro del equipo en sí.
Por eso puede ser importante entender que el manejo de expectativas se da en un sentido
amplio entre clientes y proveedores, no solamente entre el cliente del proyecto y el equipo de
desarrollo. En base a esto tendremos múltiples relaciones, como la del analista con la del líder de
proyecto, o la del líder de proyecto con los desarrolladores del equipo. Todas estas relaciones se
pueden ver como clientes-proveedor y allí se debe salvaguardar el manejo de expectativas tanto
como del equipo para afuera.
El resultado de un estudio de Grady Booch, de IBM Rational arrojó que los desarrolladores usan en
promedio el 30% de su tiempo productivo en escribir código, mientras que el resto del tiempo lo
usan en comunicarse con otros miembros del equipo [The Economist, 2008]. Esto nos da indicios
del papel de la comunicación dentro de un equipo y del papel de las expectativas que se presentan
en esa comunicación.
Aunque las relaciones tengan naturalezas distintas, es importante remarcar que muchos de los
principios y herramientas que se aplican para manejar las expectativas del cliente a nivel de
proyecto, se pueden atribuir también en niveles dentro del proyecto. Esto se puede tener en
cuenta a la hora de implementar las prácticas explicadas en el capítulo Artefactos que ayudan en el
Manejo de Expectativas: más allá que estén explicadas en un entorno de un proyecto y los
beneficios que traen para con las expectativas del cliente externo, éstos artefactos recaen en el
principio del manejo de expectativas y por eso son aplicables a relaciones internas al proyecto.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
23
2.4. Manejo de expectativas como factor de continuidad
Una vez que el manejo de expectativas haya cumplido el objetivo de obedecer a las expectativas
del cliente y esto cause que el producto se entregue en tiempo y forma, podemos descubrir efectos
colaterales positivos que se desprenden sin esfuerzo adicional. Tal es el caso de la confianza del
cliente al haber resuelto positivamente los riesgos en un principio supuestos.
Según Marco Antonio Jiménez [Jiménez, 2006], el manejo de expectativas es un “elemento
adicional que cada vez toma más fuerza y que debemos observar si queremos tener éxito no sólo en
el proyecto actual, sino pensando en proyectos y relaciones de negocios a largo plazo”. Esto podría
deberse a que “en la actualidad las decisiones de tecnología dentro de la organización ocupan un
espectro más amplio dentro del negocio y por lo tanto hay mas individuos involucrados.” [Jiménez,
2006]
El hecho de que más personas intervengan en las decisiones, hace que tengamos que manejar más
expectativas y esto puede resultar complejo debido a las distintas necesidades y aspiraciones que
cada participante tiene con respecto a los resultados del proyecto.
En el caso de la Gerencia de Proyectos, podríamos pensar en que los clientes no sólo estén
conformes con que sus proyectos terminen a tiempo y en el costo convenido, sino que todas sus
expectativas hayan quedado cubiertas.
John Fleming y Jim Asplund, en su libro HUMAN SIGMA [Fleming, y otros, 2007], presentan los
resultados de estudios que cubren el comportamiento de los clientes en general. Analizaron la
satisfacción del cliente a lo largo de distintas industrias y encontraron que los clientes que se
encuentran satisfechos pueden ser clasificados en dos grupos: los racionalmente satisfechos y los
emocionalmente satisfechos. Fleming y Asplund reportan que los clientes racionalmente
satisfechos aunque estén extremadamente satisfechos, pueden estar careciendo de un fuerte y
emocional apego a la empresa. Y como podemos predecir, los clientes emocionalmente satisfechos
se destacan de los racionalmente satisfechos en todas las dimensiones (gasto promedio, frecuencia
de consumo, lealtad, tasa de defectos, etc.). Uno de los descubrimientos más fascinantes en este
escenario es que los clientes racionalmente satisfechos se comportan de forma similar a aquellos
que no están satisfechos.
Esto se evidencia en MANAGE YOUR HUMAN SIGMA, un artículo de John Fleming, Curt Coffman y
James Harter de Harvard Business Review [Manage your human sigma, 2005], donde se muestra
que los clientes no satisfechos de una tarjeta de crédito internacional resultan virtualmente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
24
indistinguibles de los clientes racionalmente satisfechos en cuanto a su comportamiento en las
compras. Mientras que los clientes emocionalmente satisfechos por factores como el servicio,
funcionalidades y la imagen de la marca, gastaron en promedio más que la gente en los otros
grupos:
Figura 9: Gastos mensuales promedios de clientes de tarjeta de crédito, según MANAGE YOUR HUMAN SIGMA
[Manage your human sigma, 2005]
Como explican John Fleming y Jim Asplund en HUMAN SIGMA [Fleming, y otros, 2007], con el
objetivo de construir las conexiones con los clientes que producen un aumento en los beneficios
para el proveedor, una vista más completa del cliente es necesaria; y ésta debe incorporar un
entendimiento de las dimensiones emocionales del compromiso del cliente y de las expectativas
involucradas. Esto no solamente nos ayudará a cumplir con las expectativas del cliente en términos
de entregables (satisfacción racional), sino que además asegurará una buena relación con el cliente
(satisfacción emocional) que funcionará de cimientos sólidos a la hora de que la organización del
cliente encare nuevos proyectos.
En el presente, las relaciones de negocios duraderas son codiciadas y es así como se habla de socios
tecnológicos, e inclusive de socios en el camino del aprendizaje. Estos caminos solo son viables
cuando conocemos bien a nuestros clientes, sabemos cuáles son sus expectativas y nos
identificamos con sus metas. Según Jens Egerland, [Egerland, 2003], de esto se trata un
conveniente manejo de expectativas.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
25
2.5. Implementación
2.5.1. El Manejo de Expectativas frente a los cambios de requerimientos
"Es un mal plan que no admite modificación", Publio Siro
Según un artículo publicado por el Standish Group, CHAOS: A RECIPE FOR SUCCESS [The Standish
Group, 1999], Los cambios de requerimientos suelen existir en la mayoría de los proyectos
informáticos en sus etapas tanto de planeamiento como de desarrollo. El hecho de invertir un
mayor esfuerzo en los ciclos de análisis de requerimientos puede favorecer a contar con una menor
tasa de requerimientos cambiados en los pasos siguientes. Sin embargo estamos muy lejos de
poder afirmar con certeza que no estaremos en presencia de alteraciones futuras en las
especificaciones del sistema.
Nuestros clientes son humanos: tienen visiones incompletas, otros asuntos en sus cabezas y una
comunicación imperfecta [Fleming, y otros, 2007]. Y como si eso fuera poco, a veces las
circunstancias del negocio cambian; en muchas oportunidades de forma rápida y en repetidas
ocasiones. Es por eso que aunque se comuniquen requerimientos completos de forma perfecta;
ellos podrían quedar obsoletos en semanas o un par de meses.
Por lo general, el equipo de desarrollo puede establecer un límite en el ciclo de vida del proyecto
desde donde no se aceptarán cambios en los requerimientos y cualquier pedido de cambio
posterior está fuera de ser tenido en cuenta. Esto es un claro ejemplo de las expectativas
propuestas por el equipo de desarrollo que muchas veces no se condicen con la realidad de los
negocios.
Según Robin Goldsmith, autor de DISCOVERING REAL BUSINESS REQUIREMENTS FOR SOFTWARE PROJECT
[Goldsmith, 2004], estos cambios de requerimientos, propios de la mayoría de los proyectos,
pueden tener un impacto negativo en el desarrollo si no se les da lugar en un principio dentro del
esquema de trabajo conjunto entre el equipo de desarrollo y los clientes.
Muchas estrategias y herramientas ayudan a que las expectativas del equipo se acomoden a la
realidad del negocio, y por consiguiente los ciclos de vida de los proyectos de software muten para
aceptar a los cambios de requerimientos como algo esperado y natural.
Las metodologías de trabajo que contemplen estos cambios de requerimientos podrían en este
sentido garantizar, por un lado que las expectativas sobre los cambios de requerimientos por
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
26
parte del equipo se cumplan y por el otro lado, que las que mantienen los clientes en cuanto a su
libertad para agregar, modificar o quitar requerimientos también lo hagan.
Cómo puede un proyecto soportar cambios en los requerimientos sin poner en jaque sus
posibilidades de éxito será una cuestión que cada metodología de desarrollo se animará a
responder o a desacreditar.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
27
3. Solución propuesta: Artefactos que ayudan en el Manejo
de Expectativas
A continuación expondremos artefactos que surgieron de la investigación de la presente tesis y que
forman parte de esfuerzos por manejar las expectativas de los involucrados en el proyecto. Varios
de estos artefactos integran el conjunto de herramientas que se usan en metodologías de
desarrollo de software de hoy día y exponen conceptos como el reporte frecuente o
establecimiento de objetivos comunes.
3.1. Visión & Misión
"Visión sin acción es un sueño. Acción sin visión es una pesadilla." Proverbio japonés.
El hecho de contar con un estado aspirado (visión) y un plan para llegar allí (misión) es solo el
primer paso en este sentido. Como se explica en MANAGING SOFTWARE REQUIREMENTS [Leffingwell, y
otros, 1999], de poco sirve contar con un elaborado y distinguido cuadro de situación a futuro, que
sea específico, medible, realizable, relevante y enmarcado en el tiempo, si éste no es compartido y
consensuado por todos los involucrados en el desarrollo de un proyecto. Es decir, el hecho de
contar con una visión y misión adecuadas, es un arma poderosa en el manejo de expectativas si se
da el caso que el cliente comparte y defiende esa declaración. De esta manera una visión
compartida es un buen puntapié inicial en el desarrollo de un proyecto, no solo porque plantea
un horizonte en común si no porque desde el comienzo intenta que la diferencia en expectativas
entre el cliente y el proveedor sea la mínima.
De la visión compartida se puede extraer una misión también consensuada, donde se establezcan
planes para llegar a esa situación descripta en la visión. Es así como se empiezan a trazar las
primeras estrategias en el desarrollo del software, y si esto está consensuado por el cliente desde
un comienzo, entonces también podemos decir que la diferencia entre las expectativas del cliente y
el avance del proyecto apuntará al equilibrio.
En el caso que la metodología de desarrollo aplicada al proyecto cuente con la posibilidad de
ajustar la visión y/o la misión a lo largo del proyecto, es fundamental que en cada una de las
oportunidades donde aquellas son modificadas, el cliente también esté involucrado en el cambio.
Estas medidas apuntan a disminuir la diferencia entre las expectativas del cliente y el avance
corriente del equipo, tendiendo a una zona de equilibrio como se describe en la Figura 7.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
28
3.2. Lista priorizada de requerimientos del producto (“Product
Backlog”)
Básicamente el “Product Backlog” es una lista priorizada de ítems a resolver en un proyecto que
muchas veces no incluye la complejidad de las estimaciones. Como explica Ken Schwaber en THE
ENTERPRISE AND SCRUM [Schwaber, 2007], su valor proviene del orden estricto en sus elementos: el
cliente puede llamar a varios requerimientos igualmente prioritarios, pero en esta lista no hay
manera de colocar dos ítems a la misma altura. Como resultado de esto, el equipo puede tener el
foco en lo que le representa más valor al cliente en cada momento. Esta lista no es estática, pues
cambia con el tiempo: a medida que el equipo va completando los ítems más prioritarios, los ítems
de más abajo en la lista se dividen en ítems más granulares, se remueven ítems y a veces se
agregan ítems a media que se va ganando entendimiento en el área, tecnología o mercado. En base
a todo esto, en cualquier punto del desarrollo en un proyecto donde se mantiene un “Product
Backlog” actualizado y ordenado, es posible identificar la dirección del proyecto.
Schwaber también explica que los “Product Backlogs” son un poco distintos de otras listas de
tareas. Las diferencias provienen de detalles en la forma en la que se usa la lista:
Un “Product Backlog” siempre enlista ítems que le agregan valor al cliente. Pueden ser
ítems funcionales y no funcionales. Puede también incluir ítems requeridos por el equipo,
pero solo los que eventualmente le traerán valor al cliente.
Un “Product Backlog” no debería incluir tareas de bajo nivel y requerimientos de
construcción concretos de artefactos. Por ejemplo, no debería incluir requerimientos para
producir documentación de diseño a menos que el cliente lo tenga que entregar en el
futuro por algún propósito.
Cuanto más alto se ubican en el “Product Backlog” los ítems, lo más detallados deberían
ser. Los ítems de menor prioridad deberían estar definidos en forma amplia e imprecisa.
En la investigación del presente trabajo, uno de los factores que se analizaron como posibles causas
de fracasos de los proyectos es el hecho de no contar con requerimientos lo suficientemente
completos al inicio del proyecto. Como dijimos anteriormente, muchas veces el cliente no tiene un
entendimiento completo de lo que quiere al inicio del proyecto, mucho menos de lo que realmente
necesita y por consiguiente los requerimientos iniciales pueden ser pobres e inconsistentes. El
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
29
Product Backlog no viene a ayudar en contar con una definición más completa y consistente de
los requerimientos, si no en una definición de los mismos que se ajuste con el tiempo.
En este sentido las metodologías que implementan esta lista priorizada de tareas, no esperan tener
una lista de requerimientos definitiva si no una que solamente les permita empezar, para luego
refinarla iteración a iteración [Schwaber, 2007].
En base a esto, es posible que el inconveniente de los requerimientos no resida en que no sean
suficientes en el inicio, si no que no se renueven a lo largo del tiempo.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
30
3.3. Reuniones de planeamiento y reporte con el cliente
En el capítulo El manejo de expectativas en los proyectos informáticos, hemos indicado en la teoría
como la creación de encuentros que equilibren la diferencia entre las expectativas del cliente y
aquellas del proveedor pueden colaborar en mantener al proyecto lejos de una zona de riesgo.
En proyectos que implementen un trabajo iterativo, dichos encuentros se repiten con una
frecuencia de una iteración y por lo general suelen consistir en reuniones o bien enfocadas en el
planeamiento o bien enfocadas en el reporte al cliente [Bittner, et al., 2007].
Al combinar este enfoque con un artefacto como una lista priorizada de requerimientos del
producto (“Product Backlog”), dichas reuniones pueden incluir un planeamiento de la iteración
corriente usando la lista de requerimientos del equipo, o bien una demostración del trabajo
realizado a lo largo de la iteración, donde se apuntó a completar los requerimientos definidos para
dicha iteración [Schwaber, 2007].
Figura 10: Reuniones como parte del proceso iterativo
Como se muestra en la figura anterior, podemos contar con los siguientes puntos de equilibrio de
expectativas a lo largo del proceso:
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
31
3.3.1. Planeamiento de la Iteración
Al principio de cada iteración, se planifica las metas y objetivos en conjunto con el representante
del cliente. En base al backlog de producto que se encuentra priorizado por el representante del
cliente, el equipo de producción estima hasta que ítem de esa lista se compromete a implementar
en la iteración que comienza. El resultado de esta reunión será una porción del backlog de
producto que será el backlog de la iteración. Este último puede ser desagregado en ítems más
granulares dependiendo de la complejidad de los ítems originales.
Dicho resultado de la reunión es una especie de “contrato” entre el equipo de desarrollo y el
representante del cliente que se mantendrá intacto a lo largo de la iteración. En el caso de que del
lado del cliente haya un deseo de alterar las prioridades, esto se deberá realizar una vez que la
presente iteración haya finalizado; y el nuevo backlog de producto será tenido en cuenta en la
próxima reunión de Planeamiento de Iteración.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
32
3.3.2. Sincronización diaria del equipo (planeamiento)
Como explica Peter Schuh en INTEGRATING AGILE DEVELOPMENT IN THE REAL WORLD [Schuh, 2004], el
objetivo de esta reunión es que rápidamente y antes de ponerse a trabajar, el equipo se ponga de
acuerdo en cuales van a ser las tareas del día para cada integrante en base a las realizadas en el día
de trabajo anterior. Para esto, metodologías como Scrum implementan una estructura de reunión
donde cada integrante del equipo responde a 3 simples preguntas:
¿En qué he trabajado desde la reunión de ayer?
¿En qué trabajaré hoy?
¿Qué inconvenientes me bloquean para realizar mis tareas?
Estas reuniones no suelen durar más de 15 minutos y se suelen llamar reuniones de “stand up” por
el hecho de que con el fin de que sean ágiles y rápidas, sus integrantes lo hacen de parados en vez
de sentarse alrededor de una mesa como en otros reuniones más extensas.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
33
3.3.3. Reporte diario del avance del equipo
En algún momento del día, por lo general al final de la jornada laboral, el equipo se puede encargar
de comunicar brevemente los resultados de lo que estuvo realizando durante el día. Según Julie
Morgenstern, autora de MAKING WORK WORK [Morgenstern, 2004], esta comunicación le puede
servir al cliente para ir teniendo un avance del equipo a lo largo de la iteración, sin necesidad de
esperar hasta el fin de la misma para enterarse de lo que se avanzó, con el riesgo de que esto no
sea lo que se estaba esperando.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
34
3.3.4. Revisión de la Iteración (reporte)
Al final de cada ciclo iterativo, se lleva a cabo una reunión que permite la evaluación del proceso
por parte del cliente y de todos los involucrados. Como se explica en THE ENTERPRISE AND SCRUM
[Schwaber, 2007], en esta instancia surgen las adaptaciones al producto y es en este momento
cuando el equipo presenta al cliente el incremento en la funcionalidad del producto que construyó.
El resultado de esta reunión puede ser una minuta que incluye la devolución por parte del cliente
del avance en el producto y también puede derivarse en una re-priorización del backlog de
producto.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
35
3.3.5. Reuniones de retrospectiva de la iteración
Según Esther Derby y Diana Larsen, las autoras de AGILE RETROSPECTIVES: MAKING GOOD TEAMS
GREAT [Derby, y otros, 2006], estas reuniones suelen ser una pieza clave dentro del proceso de
mejora del equipo de desarrollo. Al finalizar la iteración, el equipo evalúa su desempeño: analiza en
qué aspectos tuvo éxito y en cuáles falló. Esto se hace con el objetivo de que, iteración a iteración,
el equipo conozca en qué áreas debe esforzarse más y así lograr una mejora continua de su trabajo.
El resultado de esta reunión es una lista de ítems evaluados como “buenos”, “malos” y “a mejorar”.
Dentro de las claves del éxito de las reuniones de retrospectiva podrían incluirse los siguientes
puntos:
Que las conclusiones de una reunión de retrospectiva reflejen las opiniones profundas y
reales de los integrantes del equipo sobre el nivel de performance del mismo, tanto a nivel
técnico como no técnico.
Que las conclusiones de una reunión de retrospectiva de una iteración sean tenidas en
cuenta en las iteraciones sucesivas con el objetivo de mejorar la performance del equipo.
Esta herramienta en particular puede ayudar a equilibrar las expectativas internas del equipo,
haciendo que sus integrantes estén de acuerdo sobre lo que se espera del nivel con que el equipo
realiza sus tareas y por otro lado que colaboren en los puntos que ellos mismos identifican como
débiles.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
36
3.4. Entrega Frecuente
George Stepanek, autor de SOFTWARE PROJECT SECRETS: WHY SOFTWARE PROJECTS FAIL [Stepanek,
2005], explica que un error crítico que un miembro de un equipo puede llegar a cometer es asumir
que el cliente no necesita interactuar con el software hasta que esté “listo”. En un proyecto
administrado tradicionalmente, esto puede implicar esperar meses o incluso años antes de que los
usuarios puedan revisar el software. Un malentendido normal puede implicar meses de esfuerzo
desperdiciado, sin mencionar los costos aparejados.
Inclusive cuando los requerimientos han sido bien interpretados, un período muy largo antes de
que el usuario pueda revisar, puede implicar resistencia por parte del equipo de desarrollo a los
cambios propuestos por el usuario. A pesar de que la funcionalidad o aplicación pueden ser
aceptables, es posible que sea más compleja o menos robusta que lo que el usuario estaba
esperando y eso puede resultar muy tarde o muy costoso de cambiar.
Según Stepanek, un enfoque más ágil propone en tener una respuesta rápida del usuario que
pueda mitigar problemas como la mala comunicación, requerimientos mal interpretados y
decisiones pobres sobre la interfaz de usuario. Cuanto más el usuario pueda tocar el producto de
software en desarrollo, más claro será en clarificar requerimientos y encaminar el proyecto.
Antes de comenzar a escribir el software, pequeñas pruebas de concepto o prototipos pueden
ayudar en comunicar las intenciones de forma efectiva. Un enfoque consiste en dibujar las
pantallas en un papel o en un pizarrón y recorrerlas junto con el usuario a través de casos de uso
típicos de la aplicación.
Siguiendo la misma línea, podríamos decir que durante el proyecto, es conveniente liberar el
software en desarrollo para revisión por lo menos al final de cada iteración, dándole al cliente la
oportunidad de revisar el progreso y verificar el entendimiento del equipo. Es posible, inclusive,
recibir una devolución aún más valiosa si además de liberar el software en desarrollo para que el
cliente lo pueda usar, se realizan presentaciones por parte del equipo de desarrollo del mismo.
El hecho de contar con devoluciones frecuentes, uno de los elementos que subrayamos de la
práctica del manejo de expectativas, puede convertirse en uno de los elementos claves en el éxito
de un proyecto.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
37
3.5. Manejo de riesgos
Los riesgos son factores externos que amenazan la habilidad del proyecto de alcanzar los
entregables deseados [Bittner, et al., 2007]. Según Bittner y Spence, para controlar esos riesgos, es
necesario identificarlos y luego evaluar su probabilidad de ocurrencia e impacto. Inicialmente, esto
puede incluir los riesgos y limites generales del proyecto como su plazo, recursos, estándares,
procesos, etc. A medida que el proyecto avanza, riesgos más detallados pueden ser agregados a la
lista.
Esta lista puede convertirse en una buena herramienta a la hora de manejar las expectativas de los
clientes: el hecho de mantener abierta esa lista por parte del equipo de desarrollo promueve el
involucramiento de los clientes y por otro lado afirma la idea de que el equipo tiene el control
sobre el proyecto. Según Kurt Bittner [Bittner, et al., 2007], un error común es que los líderes de
proyectos escondan los riesgos de otros involucrados, como si el hecho de exponer esos riesgos
diera la impresión de que ellos no tienen el control del proyecto o que ellos no son buenos líderes.
En la misma línea, Bittner afirma que esta es una de las prevalentes, peligrosas y poco
profesionales práctica en la industria del software.
La lista a mantener con los riesgos del proyecto puede contener una descripción de los riesgos, su
probabilidad de ocurrencia, su impacto, exposición y plan de mitigación. Si esta lista es
actualizada y comunicada de forma frecuente al cliente, estaremos entonces manejando las
expectativas de los clientes por lo menos en cuanto a los riesgos que aparecen a lo largo del
proyecto.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
38
4. Investigación
4.1. Objetivos
La investigación se realizó con el objetivo de brindar datos empíricos acerca del rol e
implementación del manejo de expectativas en los proyectos, que permitan elaborar piezas de
información tendientes a:
1. Verificar o refutar la hipótesis planteada.
2. Agregar información relacionada al papel del manejo de expectativas en los proyectos de
desarrollo de software locales.
Este último objetivo pretende añadir un valor agregado, con el fin de enriquecer aún más el estado
del arte de la industria del software.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
39
4.2. Criterios en los que se basan las preguntas de la encuesta
Las preguntas de la encuesta que cubre la presente investigación están orientadas a cubrir los
objetivos propuestos.
A continuación se detallarán los criterios específicos para cada una de las secciones de las
preguntas:
4.2.1. Contexto
El manejo de expectativas, así también como la complejidad en las comunicaciones puede variar
según el tamaño de la empresa o el grado de riesgos involucrados en proyectos, en base a pautas
establecidas por implementaciones certificadas de los procesos.
4.2.2. Detalles del proyecto
Esta sección cubre información acerca de los criterios básicos en el manejo de proyectos: alcance,
plazo, medida del equipo y presupuesto. A la hora de medir el manejo de expectativas y el
resultado final del proyecto, estas dimensiones nos proporcionarán la información básica para
comparar un proyecto con otro.
4.2.3. Relación con el Cliente
Algunas de las preguntas que definen el grado en que se midieron las expectativas a lo largo del
proyecto figuran en esta sección. Se trata de la comunicación con el cliente, su percepción, el
tratamiento de sus expectativas y algunos datos de contexto como la ubicación del cliente con
respecto a la del equipo de desarrollo.
4.2.4. Resultados del Proyecto
Esta sección nos permite medir el grado de éxito obtenido en el proyecto, el grado de
cumplimiento de las expectativas del cliente y algunos datos de contexto como la cantidad de
recomienzos en el proyecto. Estas mediciones otorgan la información necesaria para corroborar la
hipótesis planteada en base a la información recolectada en las secciones anteriores.
4.2.5. Detalles de metodología
Dado que muchas prácticas y herramientas en el desarrollo de software se encuentran
circunscriptas en metodologías de desarrollo de software en particular, el hecho de obtener
información acerca de las metodologías seguidas en proyectos con distinto tipo de resultados en el
manejo de expectativas, nos hará extraer patrones y conclusiones que vinculen los resultados con
las metodologías implementadas.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
40
4.2.6. Opinión
Metodología y factores de éxito/fracaso: esta sección brinda información acerca de la percepción
de la audiencia sobre los factores que influyen en los resultados de los proyectos. De aquí se
podrán extraer conclusiones que agreguen información acerca de la relación que existe entre los
hechos demostrados en el resto de las secciones y las percepciones de la audiencia.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
41
4.3. Encuesta aplicada
4.3.1. Metodologías de relevamiento
Con el fin de relevar los datos empíricos acerca del papel del manejo de expectativas en los
proyectos en la industria informática local, se planteó una serie de preguntas de tipo “multiple
choice” en versión impresa para encuestas presenciales y en una versión online publicada en
Internet. Se utilizó el sitio web http://www.reportesoftware.com.ar/ con el fin de presentar el
objetivo de la investigación, los términos y condiciones, datos sobre la encuesta y una entrada a la
encuesta en sí.
La siguiente figura muestra el sitio web en cuestión:
Figura 11: http://www.reportesoftware.com.ar/ como página de inicio a la encuesta
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
42
4.3.2. Términos y Condiciones
Los términos y condiciones que se firmaron antes de contestar cada instancia de la encuesta fueron
los siguientes:
Ariel Schapiro tomará los datos relevados con el fin de realizar un estudio acerca del papel del
manejo de expectativas en los proyectos informáticos en la República Argentina. Los resultados de
ese estudio se publicarán como parte de una Tesis de grado de la carrera Ingeniera en Informática
de la facultad de Ingeniera, Universidad de Buenos Aires.
La información resultante de los datos recabados sólo será revelada de forma agregada; por
ejemplo "el 30% de los proyectos realizados en total por las empresas encuestadas resultaron
exitosos". No se revelará información de ningún tipo que identifique directamente su origen.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
43
4.3.3. Verificación de los datos
La encuesta requirió datos de identificación a los participantes que sirvieron para luego corroborar:
La existencia de la empresa en cuestión
El vínculo de la empresa con la industria
La participación de la persona en la encuesta
El cargo de la persona en la empresa
Cabe destacar que la validación se realizó para cada empresa encuestada, a partir de los datos de
validación incluidos en la encuesta:
Razón Social de la empresa en cuestión
Dirección física
Teléfono/s de contacto
Horarios de atención
Sitio web
Email de contacto
Industria y rubro
Años en el mercado
Nombre de la persona que llena la encuesta
Cargo dentro de la empresa
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
44
4.3.4. Preguntas Centrales
La encuesta se expuso de una forma que posibilitó responder acerca de un proyecto informático
como referencia. La siguiente lista de preguntas conforma la muestra de lo que fue la encuesta que
relevó los datos necesarios sobre el grado de éxito en los proyectos, las metodologías usadas y el
papel del manejo de expectativas en las mismas:
1. Contexto
1. Industria/rubro
2. Años de la empresa en el mercado
3. ¿Aproximadamente con cuántos empleados cuenta la empresa?
a. Hasta 10
b. De 11 a 30
c. De 31 a 50
d. De 51 a 100
e. De 101 a 300
f. Más de 300
4. ¿La empresa cuenta con algún tipo de certificación? ¿Cuál?
2. Detalles del proyecto
1. El entregable consistía o estaba relacionado mayoritariamente con (marque más de
una opción si aplica):
a. Aplicación de línea de negocio
b. Bases de datos
c. Actualización de sistema
d. Sitio Web
e. Servicios Web
f. Documentación
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
45
g. Otra (especifique)
2. ¿Cuál fue el plazo de entrega previsto inicialmente?
3. ¿Qué medida tenía el equipo que se encargó del proyecto?
4. ¿Cuál fue el presupuesto aproximado del proyecto?
3. Relación con el Cliente
1. ¿Se compartió con el cliente un detalle acerca del criterio de éxito del proyecto?
2. ¿En promedio, con qué frecuencia se ponía al tanto al cliente acerca del avance del
proyecto?
3. ¿En caso de haberse detectado desvíos durante la ejecución del proyecto, qué
acciones se llevaban a cabo?
a. Ninguna en particular
b. Se registraban y se comunicaban internamente
c. Se tenía en cuenta para la próxima revisión/contacto con el cliente
d. Se comunicaba inmediatamente al cliente
e. Otra (especifique)
4. Durante el desarrollo del proyecto, el entendimiento de lo que esperaba el cliente
era:
a. Alto: estaba todo claro, no hubo dudas
b. Medio: la mayoría de los puntos esperados estuvieron claros
c. Bajo: un alto porcentaje de lo esperado no estuvo claro
d. Nulo: prácticamente no se sabía que esperaba el cliente
5. ¿Se midió la percepción por parte del cliente de lo que se le estaba entregando a lo
largo del proyecto?
6. En caso de contestar que si en la pregunta anterior, ¿se tuvo en cuenta esa
medición en lo que siguió de desarrollo del proyecto?
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
46
7. En general la comunicación con el cliente fue:
a. Muy fluida
b. Medianamente fluida
c. Poco fluida
8. Con respecto al lugar de desarrollo del proyecto, los clientes se ubicaban
físicamente:
a. A menos de 10 km.
b. Entre 10 km. y 100 km.
c. Entre 100 km. y 1000 km.
d. A más de 1000 km.
9. ¿De qué forma se realizaban las reuniones con los clientes?
a. Personalmente
b. Telefónicamente
c. Virtualmente
d. Otra forma (especifique):
e. No hubo reuniones con clientes
10. ¿Cómo considera la magnitud en los cambios de requerimientos?
a. Nula
b. Irrelevante
c. Baja
d. Media
e. Alta
f. Muy Alta
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
47
4. Resultados del Proyecto
1. ¿Qué grado de éxito se logró?
a. Éxito: se cumplieron favorablemente las metas definidas en un comienzo
sobre plazos, costos, funcionalidad, recursos y calidad.
b. Desviación: No se llegó a cumplir las metas definidas en un comienzo a
causa de desvíos negativos en (marque más de una si aplica):
1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo
provisto
2. Estándares de calidad requeridos. Se cumplió con el ______ % de
lo provisto
3. Presupuesto económico. Se usó el ______ % de lo provisto
4. Plazo de entrega. Se usó el ______ % de lo provisto
5. Recursos (HH). Se usó el ______ % de lo provisto
c. Fracaso: se canceló antes de completarse.
2. ¿En qué medida considera que las expectativas del cliente fueron cumplidas?
a. En gran medida
b. En mediana medida
c. En baja medida
3. ¿Cuántos recomienzos hubo en el proyecto?
a. 0
b. 1
c. 2
d. 3
e. 4 o más
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
48
5. Detalles de metodología
1. ¿Qué metodología de desarrollo de software se siguió?
a. En cascada
b. Prototipos
c. Evolutivo
d. Incremental
e. En espiral
f. XP
g. Crystal
h. Scrum
i. Otra/s (especifique)
j. Ninguna en particular
6. Opinión: metodología y factores de éxito/fracaso
1. ¿En qué grado Ud. opina que las entregas parciales favorecen al resultado de la
entrega?
2. ¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el
éxito de un proyecto?
a. Usuarios involucrados
b. Soporte ejecutivo
c. Requerimientos completos
d. Planeación adecuada
e. Expectativas realistas
f. Hitos pequeños
g. Gente competente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
49
h. Equipo involucrado
i. Visión clara de los objetivos
j. Trabajo duro
k. Otros (especifique)
3. ¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el
desvío desfavorable de un proyecto?
a. Usuarios poco involucrados
b. Requerimientos y especificaciones incompletas
c. Cambios frecuentes en los requerimientos y especificaciones
d. Falta de soporte ejecutivo
e. Incompetencia tecnológica
f. Falta de recursos
g. Expectativas no realistas
h. Objetivos poco claros
i. Cronogramas irreales
j. Nuevas tecnologías
k. Otros (especifique)
4. ¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes que
causan que un proyecto se cancele?
a. Requerimientos/especificaciones incompletas
b. Usuarios poco involucrados
c. Falta de recursos
d. Expectativas irreales
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
50
e. Falta de soporte ejecutivo
f. Requerimientos/especificaciones cambiantes
g. Falta de planeamiento
h. “No se necesitaba más”
i. Falta de gerencia de IT
j. Incompetencia tecnológica
k. Otros (especifique)
5. Con respecto a 5 años atrás, su opinión acerca de la cantidad de proyectos fallidos
es que:
a. Disminuyó considerablemente
b. Disminuyó
c. Es similar a la actual
d. Aumentó
e. Aumentó considerablemente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
51
4.3.5. Muestra de empresas
Las siguientes empresas pequeñas, medianas y grandes formaron parte de la audiencia de la
encuesta. Se trata de empresas que desarrollan aplicaciones informáticas a través de su principal
unidad de negocio o bien a través de su departamento de IT.
Accenture (Outsourcing de Productos)
Accusys
Adexus S.A. América Software
Artware
Autologica
AXG Tecnonexo
BeyondIT technology
Bracketmedia
C & S Informática
Cargill SACI
Carriers Intrerconnect S.A
CDA
Cubika
Dimnetcorp
ED Soft
EDS
Epexo
Eukinetos
e-volution Digital Margeting
Finnegans
Focus Marketing Group
G & L Group
Globant
Grupo Hasar
Grupo Most
Heinsohn
Hexacta
HP Argentina
Intelap
La Caja de Seguros
Latin 3
Latinvia
Lenovo Argentina
Level Extreme
Mapfre
Mastersoft
Mercap Software
MoebiusIT
Neoris Argentina
Novamens
Oikoss S.A.
Pan American Energy LLC
Plenitas
Pragmind S.A.
Procom S.R.L. Quadion Technologies
Repsol YPF
RMyA
Southworks
Synapsis
Team Quality S.A
Tecnosoftware S.A
Telesoft CRM
Ten Roses
Thales
Three Melons
Unitech
Vanward IT
Verizon Business Argentina
Xioma Consultores S.A
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
52
4.3.6. Factores de la encuesta que se tienen en cuenta para medir el
manejo de expectativas
Como se explicará más en detalle en el Planteo del Análisis de validez de la hipótesis (prueba de
hipótesis), se parte de una serie de respuestas de la encuesta a la hora de construir una imagen
sobre el privilegio que se le da al manejo de expectativas en cada caso.
Esta serie de respuestas que se utiliza para alimentar dicho indicador, está compuesta por las
siguientes métricas:
1. Detalle compartido con el cliente acerca del criterio de éxito del proyecto
2. Frecuencia con la que en promedio se ponía al tanto al cliente acerca del avance
del proyecto
3. Acciones que se llevaban a cabo en caso de haberse detectado desvíos durante la
ejecución del proyecto
4. Entendimiento de lo que esperaba el cliente durante el desarrollo del proyecto
5. Medición de la percepción por parte del cliente de lo que se le estaba entregando a
lo largo del proyecto
6. Consideración de esa medición en lo que siguió de desarrollo del proyecto
7. Comunicación con el cliente en general
8. Forma en la que se realizaban las reuniones con los clientes
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
53
4.3.7. Niveles de éxito planteados: diferencias entre el CHAOS Report y
este estudio
Como parte del CHAOS REPORT [The Standish Group, 1994] del Standish Group, se plantearon 3
posibles niveles de éxito para los proyectos investigados:
1. Exitoso: el proyecto es completado en plazo y en el presupuesto dado, con toda la
funcionalidad que se planeó inicialmente
2. Desafiado: el proyecto es completado y está operativo pero se superó el presupuesto, el
plazo y ofrece menor funcionalidad que la prevista inicialmente
3. Afectado: el proyecto es cancelado en algún punto de su ciclo de desarrollo
Por otro lado, en la encuesta que formó parte de la investigación realizada para la corriente tesis,
se plantearon 4 posibles grados de éxito en el proyecto:
1. Éxito: se cumplieron favorablemente las metas definidas en un comienzo sobre plazos,
costos, funcionalidad, recursos y calidad
2. Desviación manejada: No se llegaron a cumplir las metas definidas en un comienzo a causa
de desvíos negativos que fueron identificados, tratados y reportados al cliente. Esto generó
un cambio en las metas que finalmente llegaron a cumplirse
3. Desviación negativa: No se llegaron a cumplir las metas definidas en un comienzo a causa
de desvíos negativos
4. Fracaso: el proyecto se canceló antes de completarse
Al analizar el CHAOS REPORT [The Standish Group, 1994], se identificó que el caso de “desviación
manejada” podía representar un grado de éxito en el manejo de expectativas del cliente y por
consiguiente del proyecto.
Supongamos el caso de un proyecto donde los requerimientos iniciales son completos y suficientes,
pero a lo largo del proyecto, el cliente se da cuenta que sus necesidades son otras. Si la
metodología de desarrollo seguida a lo largo del proyecto lo soporta, el avance del equipo se puede
ajustar a dichos requerimientos con la posibilidad de que se termine por cumplir con la necesidad
del cliente que fue representada en requerimientos posteriores a los iniciales. Podremos decir que
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
54
estamos entonces frente a un caso de “desviación manejada” donde las expectativas del cliente
fueron manejadas y el proyecto resultó relativamente exitoso.
Definición del éxito
Este caso en particular nos puede hacer reflexionar acerca de la definición misma de éxito. Desde
un punto de vista clásico, como el manejado por el Standish Group al formular su CHAOS REPORT
[The Standish Group, 1994], el éxito equivale a que el proyecto es completado en plazo y en el
presupuesto dado, con toda la funcionalidad que se planeó inicialmente.
En una entrevista realizada a Tom y Mary Poppendieck [Poppendieck, y otros, 2008], autores de
IMPLEMENTING LEAN SOFTWARE DEVELOPMENT entre otros, Mary Poppendieck afirma que el éxito
tiene que ver con los términos de negocio. Por ejemplo si se trata de un producto comercial, que
éste logre una buena porción del mercado o signos interesantes de rentabilidad.
En base al caso recién expuesto y a las definiciones de Mary Poppendieck, podríamos decir que el
éxito se podría correlacionar con el estado al cual se llega luego de cumplir con las expectativas
del cliente, donde la devolución consiste en valor agregado al negocio.
Aquellos cuatro grados de éxito planteados en la encuesta, intentan representar un “continuo” en
el grado de logros de un proyecto informático.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
55
4.4. Uso de la herramienta de análisis estadístico
La herramienta de análisis estadístico que se utilizó fue SPSS Base 15.0 (http://www.spss.com/la/productos/base/base.htm). Como primer paso, en la solapa de “Vista de Variables”, se cargaron las variables correspondientes
a las preguntas de la encuesta. Fueron cargadas las respuestas posibles para las preguntas con un
set de respuestas definidas, como los resaltados en la siguiente figura:
Figura 12: Variables cargadas en SPSS
Una vez hecho esto, en la solapa de “Vista de Datos” en SPSS se aplicaron las respuestas
recolectadas desde la aplicación web donde los participantes respondieron la encuesta.
Nota: los detalles de estos datos no se muestran en esta sección por razones de confidencialidad explicados en los Términos y Condiciones de la encuesta.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
56
4.5. Planteo del Análisis de validez de la hipótesis (prueba de
hipótesis)
Se dará como válida la hipótesis en el caso que se den como válidos tres factores. De esta forma
tenemos:
𝐻 = 𝐴 ∩ 𝐵 ∩ 𝐶
Donde:
H. Expresa la validez de la hipótesis
A. Expresa la validez de la afirmación: “El papel del manejo de expectativas en el desarrollo de
los proyectos informáticos no está lo suficientemente privilegiado en el ámbito local”
B. Expresa la validez de la afirmación: “La implementación de metodologías de desarrollo que
lo incluyan (al manejo de expectativas) como aspecto fundamental ayudarán a disminuir la
cantidad de proyectos fracasados o desviados, aumentando por consiguiente el grado de
éxito en los mismos.”
C. Expresa la validez de la afirmación: “Quienes no incluyan al manejo de expectativas como
aspecto fundamental obtendrán resultados sensiblemente inferiores a quienes si lo hagan”
A continuación estableceremos los criterios de validez para cada uno de los factores. Éstos
constituirán las reglas de decisión de la prueba de hipótesis.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
57
4.5.1. Análisis estadísticos que definen la validez de cada factor
4.5.1.1. Análisis estadístico que definirá la validez del factor A (regla de decisión A)
El análisis estadístico que servirá para investigar en qué medida es válido este factor consistirá en
que menos del 30% de los casos de la muestra cuentan cada uno con las respuestas satisfactorias
(marcadas en verde y negrita) para demostrar que la empresa privilegia el manejo de expectativas.
El valor del 30% proviene de los datos del CHAOS REPORT [The Standish Group, 1994]: éste establece
que dentro de los factores que la audiencia valoró en vista al éxito en los proyectos, el
involucramiento de los usuarios representa un 15,9%, mantener expectativas realistas un 8,2% y
una corta frecuencia en los hitos del proyecto un 7,7%. Estos tres parámetros están muy
relacionados con los factores de la encuesta que se utilizarán para medir el manejo de expectativas
y suman el 31,8% de los casos.
El CHAOS REPORT [The Standish Group, 1994] es una fuente confiable de datos y no contamos
actualmente con una estadística precisa, actualizada y local acerca del manejo de expectativas
como se entiende y expone en el presente trabajo. En base a esto utilizaremos la suma de aquellos
tres parámetros como límite aproximado para establecer que menos del 30% de la muestra
privilegia el manejo de expectativas.
Las respuestas satisfactorias (marcadas en verde y negrita) para demostrar que la empresa
privilegia el manejo de expectativas son:
1. ¿Se compartió con el cliente un detalle acerca del criterio de éxito del proyecto?
SI…
2. ¿En promedio, con qué frecuencia se ponía al tanto al cliente acerca del avance del
proyecto? MÁXIMO DE 15 DÍAS
3. ¿En caso de haberse detectado desvíos durante la ejecución del proyecto, qué
acciones se llevaban a cabo?
a. Ninguna en particular
b. Se comunicaba inmediatamente al cliente
c. Se tenía en cuenta para la próxima revisión/contacto con el cliente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
58
d. Otra (especifique)
4. Durante el desarrollo del proyecto, el entendimiento de lo que esperaba el cliente
era:
a. Alto: estaba todo claro, no hubo dudas
b. Medio: la mayoría de los puntos esperados estuvieron claros
c. Bajo: un alto porcentaje de lo esperado no estuvo claro
d. Nulo: prácticamente no se sabía que esperaba el cliente
5. ¿Se midió la percepción por parte del cliente de lo que se le estaba entregando a lo
largo del proyecto? SI…
6. ¿Se tuvo en cuenta esa medición en lo que siguió de desarrollo del proyecto? SI…
7. En general la comunicación con el cliente fue:
a. Muy fluida
b. Medianamente fluida
c. Poco fluida
8. ¿De qué forma se realizaban las reuniones con los clientes?
a. Personalmente
b. Telefónicamente
c. Virtualmente
d. Otra forma (especifique):
e. No hubo reuniones con clientes
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
59
4.5.1.2. Análisis estadístico que definirá la validez del factor B (regla de decisión B)
El análisis estadístico que servirá para investigar en qué medida es válido este factor consistirá en
que como mínimo el 82% de los casos de la muestra donde sí se privilegió el manejo de
expectativas (ver regla de decisión A), cuentan cada uno con las respuestas satisfactorias (marcadas
en verde y negrita) que demuestran un grado satisfactorio de éxito en sus proyectos.
El valor de 82% proviene de los últimos resultados que se tienen por parte del Standish Group
acerca del grado de éxito en los proyectos: dado que nuestra intención es demostrar que en los
casos donde se privilegió el manejo de expectativas se obtuvo resultados altamente exitosos,
tomaremos como referencia la porción de proyectos exitosos (29%) y la porción de proyectos que
resultaron desviados (53%) según el Standish Group. Si sumamos ambos, obtenemos un 82%, que
básicamente representan todos los proyectos que no fueron cancelados. Dentro de la porción de
proyectos desviados se encuentran, según los niveles de éxito a manejar en esta investigación, los
casos de “desviaciones manejadas” y “desviaciones negativas”. Debido a que todavía no contamos
con los datos de la encuesta que proporcionará cuantas son “desviaciones manejadas” y cuantas
“desviaciones negativas”, usaremos la cota máxima resultante de los datos del Standish Group para
proponer que el 82% de los casos de la muestra donde sí se privilegió el manejo de expectativas
obtienen un grado satisfactorio de éxito en sus proyectos.
Las respuestas satisfactorias (marcadas en verde y negrita) que demuestran un grado satisfactorio
de éxito en sus proyectos son:
1. ¿Qué grado de éxito se logró?
a. Éxito: se cumplieron favorablemente las metas definidas en un comienzo
sobre plazos, costos, funcionalidad, recursos y calidad.
b. Desviación manejada: No se llegó a cumplir las metas definidas en un
comienzo a causa de desvíos negativos que fueron identificados, tratados
y reportados al cliente. Estos desvíos consistieron en (marque más de una
si aplica):
1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo
previsto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
60
2. Estándares de calidad requeridos. Se cumplió con el ______ % de
lo previsto
3. Presupuesto económico. Se usó un ______ % más de lo previsto
4. Plazo de entrega. Se usó extendió un ______ % de lo previsto
5. Recursos (HH). Se usó un ______ % más de lo previsto
c. Desviación negativa: No se llegó a cumplir las metas definidas en un
comienzo a causa de desvíos negativos en (marque más de una si aplica):
1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo
previsto
2. Estándares de calidad requeridos. Se cumplió con el ______ % de
lo previsto
3. Presupuesto económico. Se usó el ______ % de lo previsto
4. Plazo de entrega. Se usó el ______ % de lo previsto
5. Recursos (HH). Se usó el ______ % de lo previsto
d. Fracaso: se canceló antes de completarse.
4. ¿En qué medida considera que las expectativas del cliente fueron cumplidas?
a. En gran medida
b. En mediana medida
c. En baja medida
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
61
4.5.1.3. Análisis estadístico que definirá la validez del factor C (regla de decisión C)
El análisis estadístico que servirá para investigar en qué medida es válido este factor consistirá en
que dentro de los casos de la muestra donde no se privilegió el manejo de expectativas (ver regla
de decisión A), el porcentaje correspondiente a los casos donde se logró el éxito en los proyectos es
sensiblemente menor al porcentaje de éxito logrado por quienes si privilegiaron el manejo de
expectativas (ver regla de decisión B).
Este porcentaje deberá ser inferior por lo menos en un 25% con respecto a los casos exitosos de
quienes sí privilegiaron el manejo de expectativas. Este valor proviene de que se está buscando una
diferencia sensible entre el grado de éxito entre dos poblaciones (la que maneja las expectativas en
sus proyectos y la que no). Tomaremos como “sensible” a la máxima diferencia de proporciones de
proyectos detectados como no fracasados (o sea exitosos o desviados) por el Standish Group entre
1994 y 2004. Ésta diferencia es del 25% y la encontramos entre los resultados del año 1996 (60% de
proyectos no fracasados) y los del año 2002 (85% de proyectos no fracasados). De confirmarse esta
regla de decisión, podríamos afirmar que el privilegio del manejo de expectativas estaría
proporcionando una mejoría mayor que la detectada a lo largo de 10 años por el Standish Group.
El conjunto de respuestas necesarias para esta regla de decisión es el mismo que para la regla de
decisión B, donde se mide el mismo parámetro de éxito (respuestas marcadas en verde y negrita):
1. ¿Qué grado de éxito se logró?
a. Éxito: se cumplieron favorablemente las metas definidas en un
comienzo sobre plazos, costos, funcionalidad, recursos y calidad.
b. Desviación manejada: No se llegó a cumplir las metas definidas en un
comienzo a causa de desvíos negativos que fueron identificados,
tratados y reportados al cliente. Estos desvíos consistieron en (marque
más de una si aplica):
1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo
previsto
2. Estándares de calidad requeridos. Se cumplió con el ______ % de
lo previsto
3. Presupuesto económico. Se usó un ______ % más de lo previsto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
62
4. Plazo de entrega. Se usó extendió un ______ % de lo previsto
5. Recursos (HH). Se usó un ______ % más de lo previsto
c. Desviación negativa: No se llegó a cumplir las metas definidas en un
comienzo a causa de desvíos negativos en (marque más de una si aplica):
1. Nivel de funcionalidad solicitada. Se cumplió con el ______ % de lo
previsto
2. Estándares de calidad requeridos. Se cumplió con el ______ % de
lo previsto
3. Presupuesto económico. Se usó el ______ % de lo previsto
4. Plazo de entrega. Se usó el ______ % de lo previsto
5. Recursos (HH). Se usó el ______ % de lo previsto
d. Fracaso: se canceló antes de completarse.
5. ¿En qué medida considera que las expectativas del cliente fueron cumplidas?
a. En gran medida
b. En mediana medida
c. En baja medida
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
63
4.5.2. Diagrama de probabilidades
El siguiente diagrama de probabilidades resume estas reglas:
Figura 13: Diagrama de probabilidades que resume los factores de la validez de la hipótesis
Donde cada uno de los factores de la validez de la hipótesis define:
× < 30% (Regla de decisión A)
𝑥′ > 82% (Regla de decisión B)
𝑦′ + 25% ≤ 𝑥′ (Regla de decisión C)
Y además, por tratarse de porcentajes:
× + 𝑦 = 100
𝑥′ + 𝑥′′ = 100
𝑦′ + 𝑦′′ = 100
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
64
5. Resultados
5.1. Resultados del Análisis de validez de la hipótesis (prueba de
hipótesis)
Una vez que establecimos como será el análisis de validez de la hipótesis y la utilización de la
herramienta, pasaremos a mostrar los resultados de aplicar la prueba de hipótesis al lote de datos
recaudados en la encuesta.
Figura 14: Diagrama de resultados del Análisis de validez de la hipótesis
El siguiente gráfico explica los mismos datos mediante las proporciones de sus partes:
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
65
Figura 15: Diagrama de resultados del Análisis de validez de la hipótesis
En base a lo anterior, verificaremos cada uno de los factores de la validez de la hipótesis:
× = 24,59% → × < 30% ∴ se verifica la regla de decisión A.
𝑥′ = 86,67% → 𝑥 ′ > 82% ∴ se verifica la regla de decisión B.
𝑦′ = 36,96% → 𝑦′ + 25% ≤ 𝑥′ ∴ se verifica la regla de decisión C.
Dado que los factores de validez de la hipótesis (A, B y C en la siguiente ecuación) resultaron
válidos, daremos por válida la hipótesis H:
𝐻 = 𝐴 ∩ 𝐵 ∩ 𝐶
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
66
5.2. Resultados desagregados por pregunta de la encuesta
A continuación se presentan los resultados de cada una de las preguntas de la encuesta agrupados
por sección:
5.2.1. Contexto
Industria/rubro
La siguiente figura muestra que el rubro de la industria de mayor cobertura es el del Software a
medida (54%), seguido por el de consultoría (25%).
Figura 16: Resultados sobre la Industria/Rubro de las empresas de la audiencia
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
67
Años de la empresa en el Mercado
La siguiente figura expone que la mayoría de las empresas encuestadas (57%) cuentan con 3 a 5
años en el mercado; seguidas por las empresas que cuentan con menos de 2 años (18%).
Figura 17: Resultados sobre la edad de las empresas encuestadas en el mercado
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
68
¿La empresa cuenta con algún tipo de certificación? ¿Cuál?
La siguiente figura muestra que la mayoría (61%) de las empresas encuestadas no cuentan con
ningún tipo de certificación, mientras que el mayor grupo de empresas certificadas (26% del total)
lo está bajo la norma ISO 9001:2000.
Figura 18: Resultados sobre tipos de certificaciones con los que cuentan las empresas encuestadas
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
69
5.2.2. Detalles del proyecto
El entregable consistía o estaba relacionado mayoritariamente con…
La siguiente figura expone que la mayoría (54%) de los proyectos de la muestra consistía en
entregables de “Aplicaciones de líneas de negocio”, mientras que el segundo grupo (25%) estaba
formado por sitios Web.
Figura 19: Resultados sobre los tipos de entregables de los proyectos involucrados en la muestra
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
70
¿Cuál fue el plazo de entrega previsto inicialmente (meses)?
La siguiente figura muestra que la mayoría de los proyectos de la muestra (62%), estaba prevista
para entregarse en el plazo de 3 a 5 meses, mientras que el segundo grupo, que solamente
consistió en el 13% de los casos, estaba previsto a entregarse en un plazo de 0 a 2 meses.
Figura 20: Resultados sobre los plazos de entrega previstos inicialmente para los proyectos de la muestra
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
71
¿Qué medida tenía el equipo que se encargó del proyecto (cantidad de personas)?
La siguiente figura muestra que el 28% de los proyectos relevados contaban con un equipo de 2
personas, el 23% con un equipo de 3 personas y el 20% con un equipo de 4 personas. Al agruparlos,
podríamos decir que en los proyectos relevados, el 71% de los casos fueron de equipos de entre 2 y
4 integrantes.
Figura 21: Resultados sobre la medida del equipo que se encargó de cada proyecto de la muestra
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
72
¿Cuál fue el presupuesto aproximado del proyecto (en pesos argentinos)?
La siguiente figura muestra que el mayor grupo de proyectos relevados (18%), contaba con
presupuestos inferiores a $10.000. Por otro lado, podemos decir que casi la mitad de los proyectos
relevados (48%) contaba con presupuestos inferiores a $50.000.
Figura 22: Resultados sobre el presupuesto aproximado de los proyectos de la muestra
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
73
5.2.3. Relación con el Cliente
¿Se compartió con el cliente un detalle acerca del criterio de éxito del proyecto?
La siguiente figura muestra que en el 99% de los proyectos se compartió con el cliente un detalle
acerca del criterio de éxito del proyecto. Solo en el 38% de los casos, esto se hizo por escrito.
Figura 23: Resultados sobre criterios de éxito del proyecto compartidos con el cliente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
74
¿En promedio, con qué frecuencia se ponía al tanto al cliente acerca del avance del
proyecto?
La siguiente figura muestra que en el 66% de los proyectos se ponía al tanto al cliente acerca del
avance del proyecto de forma semanal. Por otro lado, el 13% de los proyectos usó un reporte de
avance de forma diaria para con el cliente.
Figura 24: Resultados sobre frecuencia de comunicación con el cliente acerca del avance del proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
75
¿En caso de haberse detectado desvíos durante la ejecución del proyecto, qué acciones se
llevaban a cabo?
La siguiente figura muestra que en casi la mitad de los casos (48%), los desvíos detectados se tenían
en cuenta para la próxima revisión o contacto con el cliente, mientras que en el 36% de los casos
estos desvíos eran comunicados inmediatamente al cliente.
Figura 25: Resultados sobre acciones tomadas al detectar desvíos
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
76
Durante el desarrollo del proyecto, el entendimiento de lo que esperaba el cliente era…
La siguiente figura muestra que en la gran mayoría de los casos, el entendimiento de lo que
esperaba el cliente a lo largo del proyecto era medio, es decir que la mayoría de los puntos
esperados estuvieron claros. Solo el 8% de los casos relevados se manifestaron por un alto o bajo
grado de entendimiento.
Figura 26: Resultados sobre el entendimiento de lo que esperaba el cliente a lo largo del proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
77
¿Se midió la percepción por parte del cliente de lo que se le estaba entregando a lo largo
del proyecto?
La siguiente figura muestra que prácticamente en la mitad de los proyectos, se midió la percepción
por parte del cliente de lo que se le estaba entregando a lo largo del proyecto y en la otra mitad no.
Figura 27: Resultados sobre la medición de la percepción por parte del cliente de lo que se le estaba
entregando a lo largo del proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
78
En caso de contestar que si en la pregunta anterior, ¿se tuvo en cuenta esa medición en lo
que siguió de desarrollo del proyecto?
La siguiente figura muestra que dentro de los casos donde sí se midió la percepción por parte del
cliente de lo que se le estaba entregando a lo largo del proyecto, el 90% de los casos tuvo en
cuenta esa percepción en lo que siguió del desarrollo del proyecto.
Figura 28: Resultados sobre si se tuvo en cuenta la medición de la percepción por parte del cliente de lo
que se le estaba entregando a lo largo del proyecto en lo que siguió del proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
79
En general la comunicación con el cliente fue…
La siguiente figura muestra que casi la mitad de los casos relevados mantuvo una comunicación con
el cliente muy fluida, mientras que solamente el 11% de los casos mantuvo comunicaciones poco
fluidas con sus clientes.
Figura 29: Resultados sobre la calidad en la comunicación con el cliente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
80
Con respecto al lugar de desarrollo del proyecto, los clientes se ubicaban físicamente…
La siguiente figura muestra que la mayoría (51%) de los casos registraron a clientes que se ubicaron
a más de 1.000 km. del equipo de desarrollo. Este grupo puede corresponder a desarrollos
realizados para clientes en el exterior. Por otro lado, el segundo grupo en importancia (38%)
pertenece a aquellos proyectos donde el cliente se ubicaba a menos de 10 km.
Figura 30: Resultados sobre distancias de los clientes a los equipos de desarrollo
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
81
¿De qué forma se realizaban las reuniones con los clientes?
La siguiente figura muestra que el medio telefónico se usó para casi la mitad de los casos (47%),
mientras que las reuniones personales correspondieron el 28% de los casos.
Figura 31: Resultados sobre la forma en la que se realizaban las reuniones con los clientes
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
82
¿Cómo considera la magnitud en los cambios de requerimientos?
La siguiente figura muestra que la mayoría de los casos de la muestra (51%), representan una
magnitud media en cuanto a los cambios de requerimientos. Aproximadamente los otros dos
cuartos representan a magnitudes bajas y altas.
Figura 32: Resultados sobre la magnitud en los cambios de requerimientos en los proyectos de la muestra
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
83
5.2.4. Resultados del Proyecto
¿Qué grado de éxito se logró en el proyecto?
La siguiente figura muestra que sólo el 36% de los casos relevados registra un resultado exitoso en
su proyecto, mientras que la mayoría de los casos (52%) registra una desviación manejada del
proyecto.
Figura 33: Resultados sobre el grado de éxito logrado en el proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
84
¿En que consistieron los desvíos?
La siguiente figura muestra la distribución de los desvíos en los proyectos que resultaron desviados:
el mayor grupo consiste en el nivel de funcionalidad solicitada (33%) y el plazo de entrega (30%).
En cuanto a la dependencia de estas proporciones, cabe destacar que los desvíos en el presupuesto
económico pueden ser consecuencia de desvíos en la funcionalidad, el plazo de entrega o los
recursos involucrados.
Figura 34: Resultados sobre causales de desvíos en los proyectos de la muestra
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
85
Desvíos en el nivel de funcionalidad solicitada
La siguiente figura muestra la distribución de los desvíos para los proyectos que terminaron con
una mayor funcionalidad que la solicitada: los grupos de 41%-60%, 61%-80% y 81-100% resultaron
los más grandes, cada uno con el 24% de los casos.
Figura 35: Resultados en detalle sobre los desvíos en nivel de funcionalidad solicitada
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
86
Desvíos en estándares de calidad requeridos
La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron
desviados en los estándares de calidad requeridos: los grupos de 61%-80% y 81-100% resultaron
los más grandes, cada uno con el 33% de los casos.
Figura 36: Resultados en detalle sobre los desvíos en estándares de calidad requeridos
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
87
Desvíos en presupuesto económico
La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron
desviados en el presupuesto económico: el grupo más grande (41%) obtuvo desvíos de entre 41% y
60% en sus presupuestos. El grupo que le sigue es el de desvíos menores al 20% con el 35% de los
casos.
Figura 37: Resultados en detalle sobre los desvíos en presupuesto económico
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
88
Desvíos en plazo de entrega
La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron
desviados en el plazo de entrega: el grupo más grande (46%) tuvo desvíos de entre 41% y 60% en
su plazo de entrega. El grupo que le sigue es el de desvíos menores al 20% con el 38% de los casos.
Figura 38: Resultados en detalle sobre los desvíos en los plazos de entrega
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
89
Desvíos en recursos
La siguiente figura muestra la distribución de los desvíos para los proyectos que resultaron
desviados en el uso de sus recursos: el grupo más grande (56%) tuvo desvíos de entre 41% y 60%
en la utilización de sus recursos.
Figura 39: Resultados en detalle sobre los desvíos en los recursos consumidos a lo largo del proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
90
¿En qué medida considera que las expectativas del cliente fueron cumplidas?
La siguiente figura muestra que las expectativas de los clientes fueron cumplidas en gran medida
para casi la mitad de los casos (49%). Solamente el 5% de los casos registra que las expectativas
fueron cumplidas en baja medida.
Figura 40: Resultados sobre el cumplimiento de las expectativas del cliente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
91
¿Cuántos recomienzos hubo en el proyecto?
La siguiente figura muestra que la amplia mayoría de los casos (76%) no registró un recomienzo en
el proyecto, mientras que el 18% de los casos registro un recomienzo.
Figura 41: Resultados sobre la cantidad de recomienzos que hubo en el proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
92
5.2.5. Detalles de metodología
¿Qué metodología de desarrollo de software se siguió?
La siguiente figura muestra que la metodología de software más elegida fue la evolutiva, con el
23% de los casos. Sin embargo las proporciones de ésta junto con las de XP, cascada y Scrum
resultaron muy similares (entre 23% y 19%).
Nota: Cabe destacar que la audiencia tenía la posibilidad de contestar con más de una metodología
de desarrollo de software.
Figura 42: Resultados sobre la metodología de software que se siguió en el proyecto relevado
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
93
5.2.6. Opinión: metodología y factores de éxito/fracaso
¿En qué grado Ud. opina que las entregas parciales favorecen al resultado de la entrega?
La siguiente figura muestra que la opinión de la audiencia con respecto a las entregas parciales,
refleja que en su mayoría (56%) su impacto es muy alto.
Figura 43: Resultados sobre la opinión acerca del papel de las entregas parciales en el resultado favorable
de la entrega total
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
94
¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el éxito de
un proyecto?
La siguiente figura muestra que la opinión de la audiencia con respecto a los 3 factores de mayor
importancia en el éxito de un proyecto refleja que la planeación adecuada es el factor más
valorado.
Figura 44: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el éxito de un
proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
95
¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes en el desvío
desfavorable de un proyecto?
La siguiente figura muestra que la opinión de la audiencia con respecto a los 3 factores de mayor
importancia en el desvío de un proyecto refleja que los cambios frecuentes en los requerimientos y
especificaciones suele ser el factor más valorado.
Figura 45: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el desvío de un
proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
96
¿Cuáles de los siguientes Ud. opina que son los 3 factores más importantes que causan que
un proyecto se cancele?
La siguiente figura muestra que la opinión de la audiencia con respecto a los 3 factores de mayor
importancia en la cancelación de un proyecto refleja que los usuarios poco involucrados (18%)
junto con los requerimientos o especificaciones cambiantes (17%) suelen ser los factores más
valorados.
Figura 46: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en la cancelación de
un proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
97
Con respecto a 5 años atrás, su opinión acerca de la cantidad de proyectos fallidos es que…
La siguiente figura muestra que la opinión de la audiencia con respecto a la cantidad de proyectos
fallidos con respecto a 5 años atrás, es en su mayoría (54%) que esta cantidad disminuyó.
Figura 47: Resultados sobre la opinión acerca de la cantidad de proyectos fallidos con respecto a 5 años
atrás
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
98
5.3. Otros estudios estadísticos y tendencias
A continuación se plantean otros estudios estadísticos y tendencias basados en la información
recabada de las preguntas de la encuesta:
5.3.1. Grado de éxito en los proyectos en base al manejo de expectativas
En la siguiente figura podemos ver como el grado de éxito en los proyectos es sensiblemente
mayor (casi 3 veces) en los casos donde se manejaron las expectativas que donde no se hizo esto.
Además de eso, los casos de fracasos o desviaciones negativas se produjeron solo en donde no se
manejaron las expectativas.
Figura 48: Resultados sobre el grado de éxito en los proyectos en base al manejo de expectativas
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
99
5.3.2. Grado de éxito en los proyectos en base al plazo de entrega en meses
La siguiente figura nos muestra como los proyectos exitosos tienen su mayor repetición en los
proyectos que duran de 3 a 5 meses y luego con el aumento en la duración de los mismos, los
resultados exitosos disminuyen.
Figura 49: Resultados sobre el grado de éxito en los proyectos en base al plazo de entrega en meses
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
100
5.3.3. Grado de éxito en los proyectos en base a la frecuencia de
comunicación del avance con el cliente
Las siguientes figuras nos muestran como varía el grado de éxito con respecto a la frecuencia de
comunicación del avance del proyecto con el cliente. La frecuencia con mayor proporción de éxito
es la diaria (75%). Cabe destacar como esta proporción va disminuyendo acorde crece la frecuencia
de comunicación de avance con el cliente: en los casos de comunicaciones semanales el grado de
éxito es del 37%, luego en los casos con comunicaciones quincenales éste es del 9% y finalmente no
se registraron casos exitosos con comunicaciones mensuales.
Figura 50: Resultados sobre el grado de éxito en los proyectos en base a la frecuencia de comunicación del
avance con el cliente (porcentual)
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
101
Figura 51: Resultados sobre el grado de éxito en los proyectos en base a la frecuencia de comunicación del
avance con el cliente
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
102
5.3.4. Grado de éxito en los proyectos en base a la medición por parte del
cliente de lo que se le estaba entregando a lo largo del proyecto
La siguiente figura pone en evidencia el papel que juega la medición de las percepciones de los
clientes con respecto al grado de éxito obtenido finalmente en el proyecto. Ocurre algo similar con
respecto al grado de éxito según el manejo total de expectativas: la cantidad de proyectos que
resultan exitosos donde sí se midió dicha percepción es aproximadamente 3 veces mayor a la
cantidad donde esto no ocurrió.
Figura 52: Resultados sobre el grado de éxito en los proyectos en base a la medición por parte del cliente
de lo que se le estaba entregando a lo largo del proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
103
5.3.5. Manejo de expectativas en base a la metodología de desarrollo de
software
Las siguientes figuras exponen el cumplimiento del manejo de expectativas que implementan las
distintas metodologías de software. Se puede observar como Scrum es la metodología que en
promedio tuvo un cumplimiento del manejo de expectativas sensiblemente más alto que el resto
(79%). Mientras que las metodologías de cascada y evolutivo fueron las que menos lo hicieron (6%
y 5% respectivamente). Scrum es la única que posee más casos de manejo de expectativas que
donde no se manejaron las expectativas.
Figura 53: Resultados sobre el grado de manejo de expectativas en base a las metodologías de desarrollo
de software implementadas en el proyecto (porcentual)
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
104
Figura 54: Resultados sobre el grado de manejo de expectativas en base a la metodología de desarrollo de
software implementadas en el proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
105
5.3.6. Grado de éxito en los proyectos en base a la metodología de
desarrollo de software
En base a lo expuesto anteriormente sobre la influencia del manejo de expectativas en el grado de
éxito de los proyectos y por otro lado la incidencia de la implementación de las distintas
metodologías de desarrollo de software en el manejo de expectativas, podríamos inferir que las
metodologías influyen indirectamente en este sentido en el grado de éxito en los proyectos.
Las siguientes figuras muestran dicha inferencia de las metodologías elegidas sobre el grado de
éxito resultante en el proyecto. Los proyectos que implementaron Scrum y/o XP fueron los que
tuvieron un mayor grado de éxito.
Figura 55: Resultados sobre el grado de éxito en base a la metodología de desarrollo de software
implementadas en el proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
106
Figura 56: Resultados sobre el grado de éxito en base a la metodología de desarrollo de software
implementadas en el proyecto (porcentual)
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
107
5.3.7. Cumplimiento de las expectativas del cliente en base al grado de
éxito del proyecto
La siguiente figura expone el cumplimiento del manejo de expectativas que se logró en los
proyectos con distintos tipos de grados de éxitos alcanzados. Se puede observar como los
proyectos que resultaron exitosos cumplieron en su mayoría en gran medida con las expectativas
de los clientes.
Cabe destacar que casi el 30% de los casos que obtuvo desviaciones manejadas, cumplió en gran
medida las expectativas de los clientes, mientras que el 70% restante la cumplió en mediana
medida. Según la definición clásica del Standish Group [The Standish Group, 1994], aquel 30% no
sería visto como parte de los proyectos exitosos, sino más bien como parte de los desafiados.
Ahora bien, en base a las sugerencias de Mary Poppendieck [Poppendieck, y otros, 2008] acerca de
la definición del éxito, podríamos afirmar que aquel 30% que sería clasificado por el Standish
Group como “desafiados” y por la presente tesis como “desviados manejadamente”, pudo haber
tenido posibilidades de ser catalogado como “exitoso”. En este sentido, restaría entre otros,
evaluar los resultados de negocio logrados por aquellos proyectos.
Figura 57: Resultados sobre el cumplimiento de las expectativas del cliente en base al grado de éxito del
proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
108
5.4. Diferencias con el Chaos Report
Como se explica en el capítulo Niveles de éxito planteados: diferencias entre el CHAOS Report y
este estudio, el presente estudio plantea una diferenciación entre desviaciones “manejadas” y
“negativas”. Sin embargo, si hacemos un mapeo de los proyectos con desviación manejada o
negativa contra los desviados en el CHAOS REPORT en el año 2004, los resultados no difieren mucho
entre sí.
El grado de proyectos exitosos en el presente registra un 7% más de casos que el del CHAOS REPORT
del año 2004. Si consideramos los proyectos que resultaron en desviaciones tanto manejadas como
negativas junto con los desviados del CHAOS REPORT, contamos con un 4% de diferencia. Por último,
llegamos a estar a un 11% por debajo de los proyectos cancelados del CHAOS REPORT.
Figura 58: Mapeo de los resultados del Chaos Report con respecto a los de la presente Tesis
Estas diferencias no son abundantes pero aún así reflejan cierta mejoría en cuanto al grado de éxito
en los proyectos entre los detectados en el 2004 por el CHAOS REPORT y los de la presente Tesis.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
109
6. Conclusiones
En base a la información expuesta en las secciones anteriores, plantearemos las conclusiones
generales del presente estudio.
6.1. Sobre el papel del manejo de expectativas y su percepción
La hipótesis plantea básicamente que el grado de éxito de los proyectos donde se manejan
adecuadamente las expectativas es considerablemente mayor que donde esto no ocurre. Como se
explica en el capítulo Resultados del Análisis de validez de la hipótesis (prueba de hipótesis),
podemos afirmar que los resultados del presente estudio han validado esa hipótesis.
Figura 59: Diagrama de resultados del Análisis de validez de la hipótesis
Esto nos dejaría en un lugar donde podríamos contar con bases empíricas sobre el posicionamiento
del manejo de expectativas en los proyectos informáticos y lógicamente la conclusión constaría
básicamente de la afirmación de la hipótesis formulada anteriormente.
Sin embargo, en base a piezas de información accesorias también contenidas en el mismo
relevamiento, encontramos información que nos puede llevar a enriquecer la conclusión recién
mencionada. El siguiente gráfico (también contenido en el capítulo Resultados desagregados por
pregunta de la encuesta) nos muestra que solo el 7% de los encuestados incluyó el factor de contar
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
110
con expectativas realistas como parte de los 3 factores más importantes en el éxito de un proyecto.
En este sentido, una planeación adecuada fue tenida en cuenta tres veces más.
Figura 60: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el éxito de un
proyecto
En cuanto a la percepción de la audiencia acerca de los factores que desvían desfavorablemente un
proyecto, también podemos observar una posición no privilegiada para el manejo de expectativas
(9%).
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
111
Figura 61: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en el desvío de un
proyecto
Algo parecido ocurre con la percepción por parte de la audiencia de la encuesta acerca de los
factores que causan que un proyecto se cancele. Como se observa en el siguiente gráfico, el 12% de
la audiencia eligió ubicar a las expectativas irreales como parte de los 3 factores que ayudan a
cancelar un proyecto. En este caso este factor se encuentra en cuarto lugar de preferencia:
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
112
Figura 62: Resultados sobre la opinión acerca de los 3 factores de mayor importancia en la cancelación de
un proyecto
En base a estas últimas piezas de información, podríamos decir que el manejo de expectativas en
los proyectos informáticos resulta ser un factor diferenciador en el resultado de los proyectos, sin
embargo el manejo de expectativas no es percibido de esta forma.
Por el contrario, el hecho de contar con cambios frecuentes en los requerimientos suele ser uno de
los factores más temidos por la audiencia a la hora de elegir los factores de cancelación (17%) o
desvíos (21%). El 75% de los casos relevados obtuvieron una magnitud en los cambios de
requerimientos media o alta y en esos escenarios, los únicos proyectos que fracasaron fueron
aquellos donde no se privilegió el manejo de expectativas. Esto habla de un papel del manejo de
expectativas que trae beneficios en entornos de requerimientos cambiantes.
En este sentido podríamos extraer una conclusión adicional: el foco puesto en intentar evitar o
disminuir los cambios de requerimientos no trajo beneficios claros en los proyectos relevados, por
el contrario, los proyectos donde se implementaron metodologías que incluyeron a los cambios de
requerimientos como una parte natural del desarrollo de los proyectos, han obtenido resultados
relativamente sobresalientes.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
113
6.2. Sobre los artefactos que ayudan en el Manejo de Expectativas
En el capítulo Artefactos que ayudan en el Manejo de Expectativas, se presentó una serie de
herramientas que desde un punto de vista teórico proponen fomentar un adecuado manejo de
expectativas, tanto para con el cliente como interno al equipo de desarrollo. Algunas de esas
herramientas, como la lista priorizada de requerimientos del producto (“Product Backlog”), las
reuniones de planeamiento, el trabajo iterativo, las reuniones de reporte al cliente, la entrega
frecuente y las reuniones de retrospectiva del equipo; son prácticas claves de metodologías ágiles
como Scrum y XP.
En base a esto y a los resultados privilegiados que lograron obtener los proyectos que
implementaron dichas metodologías (como se observa en la próxima figura), podríamos afirmar
que las herramientas citadas en la sección Artefactos que ayudan en el Manejo de Expectativas,
resultan ser útiles a la hora de promover el éxito del proyecto.
Figura 63: Resultados sobre el grado de éxito en base a la metodología de desarrollo de software
implementadas en el proyecto
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
114
6.3. Sobre la definición de éxito
Variabilidad de los objetivos en el tiempo
En el capítulo Niveles de éxito planteados: diferencias entre el CHAOS Report y este estudio, se
explicó porque a la hora de clasificar el éxito de los proyectos en el presente estudio se usó una
escala distinta a la del CHAOS REPORT [The Standish Group, 1994]. La escala implementada por el
CHAOS REPORT se basa en el grado de cumplimiento del plazo, presupuesto y funcionalidad
planteados al inicio del proyecto.
En base al hecho de que los requerimientos, necesidades y entendimientos del problema
planteados al inicio del proyecto pueden (y suelen) cambiar a lo largo del mismo es que se
especificó otro grado de éxito al que se llamó “desviación manejada” que implica el estado que
alcanza un proyecto desviado que termina por cumplir con las metas planteadas en sus desvíos.
Impacto en los términos de negocio
Por otro lado, en el capítulo Definición del éxito, Mary Poppendieck [Poppendieck, y otros, 2008]
sugiere que la definición de éxito establecida por el Standish Group al formular su CHAOS REPORT
[The Standish Group, 1994], es errónea puesto que el éxito tiene en realidad que ver con los
términos de negocio. Por ejemplo si se trata de un producto comercial, que éste logre una buena
porción del mercado o signos interesantes de rentabilidad.
Cumplimiento de las expectativas de los clientes
En el capítulo Cumplimiento de las expectativas del cliente en base al grado de éxito del proyecto,
hemos descripto como casi el 30% de los casos que obtuvo desviaciones manejadas, cumplió en
gran medida las expectativas de los clientes. Sin embargo este grupo no sería visto como parte de
los proyectos exitosos según el Standish Group, sino más bien como parte de los desafiados. Si nos
guiáramos por el contrario por el cumplimiento de las expectativas, este grupo hubiera resultado
exitoso.
En base a estos factores podríamos sugerir que el criterio de éxito establecido en el CHAOS
REPORT [The Standish Group, 1994] resulta incompleto a la hora de definir el grado alcanzado en
un proyecto. Es posible que la inclusión de componentes como la variabilidad de los objetivos en
el tiempo, el impacto en los términos de negocio y el cumplimiento de las expectativas de los
clientes pueda aproximar dicha definición, a un esquema más aplicable a la realidad.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
115
7. Futuras líneas de investigación
7.1. Prácticas implementadas a lo largo del proyecto
En el presente trabajo de investigación se llegó hasta un punto en cuanto a las prácticas que
implementó la audiencia durante el desarrollo del proyecto: se recaudó información acerca de las
metodologías de desarrollo de software usadas, plazos de control de progreso con los clientes,
tipos de entregables, relación con el cliente, resultados del proyecto, etc. Al mismo tiempo se
plantearon de forma teórica distintas herramientas y prácticas que favorecen en el manejo de
expectativas a lo largo del desarrollo de un proyecto de software.
En este sentido, lo que no formó parte del presente trabajo que sí puede ser tenido en cuenta en
otra investigación sería la corroboración de la implementación de las herramientas y prácticas
planteadas en las secciones teóricas de este trabajo. De esta forma se podría llegar a contar con
resultados granulares acerca de los efectos concretos de la implementación de herramientas como
una específica visión y misión del proyecto, una lista priorizada de requerimientos del producto
(“Product Backlog”), reuniones de planeamiento y reporte con el cliente, una clara definición y
manejo de riesgos, etc.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
116
7.2. Información que soporte otras definiciones de éxito
En base a la conclusión extraída acerca de la definición de éxito en los proyectos informáticos, en
una futura línea de investigación empírica, podría incluirse información acerca de una clara
definición de métricas de éxito para el proyecto en cuestión, que evolucione con el tiempo a
medida que crece el entendimiento de lo que se necesita construir. Estas métricas se usarían para
establecer el grado de éxito alcanzado al finalizar el proyecto.
Por otro lado, se podría buscar evidencia acerca del grado de cumplimiento del proyecto, en
términos del valor agregado al negocio o bien el retorno de la inversión.
En base a lo anteriormente dicho, podríamos medir el grado de éxito de un proyecto dado en
base a una combinación de los siguientes parámetros:
Cumplimiento de plazos, costos, funcionalidad, recursos y calidad definidos en un
comienzo y luego actualizados a lo largo del proyecto
Cumplimiento del valor agregado del producto/servicio (retorno de la inversión) a los ojos
del cliente y/o de otros involucrados
Cumplimiento de otras métricas de éxito definidas en un comienzo y que evolucionan con
el tiempo
De esta forma, el éxito de un proyecto podría representarse mediante una métrica más compleja
que la escala de 4 valores propuesta en el presente trabajo o la de 3 valores propuesta por el
Standish Group.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
117
8. Bibliografía
Baskerville, Richard L. 2005. Business Agility and Information Technology Diffusion. s.l. :
Springer, 2005.
Bittner, Kurt and Spence, Ian. 2007. Managing iterative software development projects. 2007.
Derby, Esther and Larsen, Diana. 2006. Agile Retrospectives: Making Good Teams Great. 2006.
Egerland, Jens. 2003. Expectation Management - Key to Project Success. [Online] February 20,
2003. [Citado: Junio 23, 2007.] http://www.pmi-
svc.com/assets/govt_archive/Feb03%20Presentation.ppt.
Fleck, Dan. 2007. Software Leadership. [Online] 2007.
cs.gmu.edu/~dfleck/classes/cs421/fall07/slides/techlead.ppt.
Fleming, John H. and Asplund, Jim. 2007. Human Sigma: Managing the Employee-Customer
Encounter. s.l. : Gallup Press, 2007.
Goldsmith, Robin F. 2004. Discovering Real Business Requirements for Software Project. 2004.
Hord, Phil. 2005. What the customer really needed. [Online] Abril 11, 2005.
http://www.philhord.com/phord/what-the-customer-needed/.
InfoQ. 2006. Interview: Jim Johnson of the Standish Group. InfoQ. [Online] August 25, 2006.
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS.
Jiménez, Marco Antonio. 2006. Gerencia de proyectos: una alternativa para generar nuevos
negocios. Asociación Colombiana de Ingenieros de Sistemas. [Online] Noviembre 17, 2006.
http://www.acis.org.co/index.php?id=864.
Leffingwell, Dean and Widrig, Don. 1999. Managing Software Requirements. s.l. : Addison-Wesley,
1999.
Manage your human sigma. Fleming, John, Coffman, Curt and Harter, James. 2005. 2005, Harvard
Business Review.
Morgenstern, Julie. 2004. Making Work Work. s.l. : Simon & Schuster, 2004.
Manejo de expectativas en los proyectos informáticos Ariel D. Schapiro Universidad de Buenos Aires - Facultad de Ingeniería Padrón 80.885
118
Mutafelija, Boris and Stromberg, Harvey. 2003. Systematic Process Improvement Using Iso 9001:
2000 and CMMI. s.l. : Artech House, 2003.
Online, Phil. 2005. [Online] Abril 11, 2005. http://www.philhord.com/phord/what-the-customer-
needed/.
Poppendieck, Tom and Poppendieck, Mary. 2008. Lean Software Development. [Entrev.] Scott
Hanselman. 2008.
2008. Project Cartoon. Project Cartoon. [Online] 2008.
http://www.projectcartoon.com/cartoon/7515/new.
Schuh, Peter. 2004. Integrating Agile Development In The Real World. s.l. : Charles River Media,
2004.
Schwaber, Ken. 2007. The enterprise and Scrum. s.l. : Microsoft Press, 2007.
2007. Software Requirements . hubpages. [Online] 2007.
http://hubpages.com/hub/Software_Requirements.
2008. Software that makes software better. The Economist. Marzo 8, 2008, p. 2.
Stepanek, George. 2005. Software Project Secrets: Why Software Projects Fail. s.l. : Apress, 2005.
The Standish Group. 1999. Chaos: a recipe for success. 1999.
—. 1994. The Chaos Report. http://www.standishgroup.com. [Online] 1994.
http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf.
