Tesis para optar al grado de Magíster en Ingeniería de ...posgrado.frba.utn.edu.ar/investigacion/tesis/MIS-2009-Turin.pdf · 9.5- Anexo V – Respuestas del Cuestionario del Experto

UNIVERSIDAD TECNOLÓGICA NACIONAL

FACULTAD REGIONAL BUENOS AIRES

Tesis para optar al grado de Magíster en Ingeniería de Sistemas de Información

MODELO DE MEJORES PRÁCTICAS PARA LA ADMINISTRACIÓN DEL FACTOR HUMANO EN LOS

PROYECTOS DE TI

HERNÁN ALEJANDRO TURIN

DIRECTORA : M AG. ALICIA L. MON

2009

DEDICATORIADEDICATORIADEDICATORIADEDICATORIA

A DIOS,DIOS,DIOS,DIOS, por haberme permitido llegar hasta este punto y darme la salud para lograr mis objetivos,

además de su infinita bondad y amor.

A mi esposa NormaNormaNormaNorma y a mi hija JazmínJazmínJazmínJazmín, por el tiempo que les robé y que debí compartir con ustedes.

A mis padres María María María María y CarlosCarlosCarlosCarlos, por apoyarme siempre y enseñarme el valor del esfuerzo.

A mis hermanos Fabricio Fabricio Fabricio Fabricio y Milton Milton Milton Milton, por motivarme siempre en mis emprendimientos.

AAAAGRADECIMIENTOSGRADECIMIENTOSGRADECIMIENTOSGRADECIMIENTOS

A la Universidad Tecnológica NacionalUniversidad Tecnológica NacionalUniversidad Tecnológica NacionalUniversidad Tecnológica Nacional, por abrirme siempre las puertas para cumplir con mis

estudios de grado y posgrado.

A mi directora de tesis M M M Maaaagggg. . . . Alicia MonAlicia MonAlicia MonAlicia Mon,,,, por haberme guiado e incentivado en el desarrollo de este

trabajo.

A mi profesor y colega Ing. Ing. Ing. Ing. Andrés PascalAndrés PascalAndrés PascalAndrés Pascal, por sus consejos y colaboración a lo largo de toda mi

formación profesional.

A la Lic. Lic. Lic. Lic. Luján GurmendiLuján GurmendiLuján GurmendiLuján Gurmendi, por ser la impulsora de mis investigaciones cuyos resultados hoy se

plasman en este trabajo.

A quienes colaboraron con el presenta trabajo en calidad de expertos, por su tiempo brindado y sus

críticas constructivas.

A todos mis amigos y colegas que, de una u otra forma, colaboraron conmigo brindándome su tiempo y

apoyo para alcanzar los objetivos planteados en esta tesis.

Modelo de Mejores Prácticas para la Administración del Factor Humano en los Proyectos de TI

Ing. Hernán A. Turin

i

INDICE

Lista de Tablas............................................................................................................. iii Lista de Figuras ........................................................................................................... iv Resumen ....................................................................................................................... v Preface ......................................................................................................................... vi

CAPITULO I: INTRODUCCION................................................................................ 1

1.1- Introducción...................................................................................................... 3 1.2- Objetivos y Metodología .................................................................................. 7

CAPITULO II: MARCO TEORICO ......................... ................................................ 11

2.1- Introducción.................................................................................................... 13 2.2- El Factor Humano y la Administración.......................................................... 13 2.3- Los Proyectos de TI........................................................................................ 17

2.3.1- Habilidades del Líder.............................................................................. 18 2.4- La Gestión de los Proyectos de TI.................................................................. 23

2.4.1- El Desarrollo de Software....................................................................... 31 2.4.2- Resistencia al Cambio ............................................................................ 34

2.5- Técnicas Utilizadas......................................................................................... 39 2.5.1- Scrum...................................................................................................... 39 2.5.2- Joint Application Development (JAD)................................................... 41 2.5.3- Programación Extrema (Extreme Programming) ................................... 44

2.6- Resumen ......................................................................................................... 46

CAPITULO III: PLANTEAMIENTO DEL PROBLEMA........... ........................... 47

3.1- Los Proyectos de TI y las personas ................................................................ 49 3.2- El software y las personas .............................................................................. 51 3.3- Las mejores prácticas...................................................................................... 53 3.4- Resumen ......................................................................................................... 54

CAPITULO IV: SELECCIÓN DE MEJORES PRÁCTICAS ........ ........................ 55

4.1- Introducción.................................................................................................... 57 4.2- Practicas Genéricas......................................................................................... 57

4.2.1- Reuniones..................................................................................................... 57 4.2.2- Wikis ............................................................................................................ 64 4.2.3- Foros de Discusión....................................................................................... 66 4.2.4-Listas de Correo ............................................................................................ 67 4.2.5- Mensajería Instantánea................................................................................. 68

4.3- Practicas Específicas....................................................................................... 69 4.3.1- Comités de Desarrollo.................................................................................. 70 4.3.2- Programación de a Pares .............................................................................. 71 4.3.3- Comités de Usuarios .................................................................................... 72 4.3.4- Grupos de Apoyo ......................................................................................... 73 4.3.5- Mesa de Ayuda............................................................................................. 75 4.3.6- Estructura Desglosada de Trabajo................................................................ 76 4.3.7- CPM ............................................................................................................. 78 4.3.8- PERT............................................................................................................ 84 4.3.9- Diagramas de Gantt...................................................................................... 86 4.3.10- COCOMO .................................................................................................. 88



ii

4.3.11- Puntos de Función ...................................................................................... 94 4.2.12- Técnica de Grupo Nominal ........................................................................ 99 4.3.13- Técnica Delphi ......................................................................................... 100 4.3.14- Análisis Estadístico .................................................................................. 101

CAPITULO V: MODELO DE ADMINISTRACION DE PERSONAS

PROPUESTO.............................................................................................................. 103

5.1- Introducción.................................................................................................. 105 5.2- Esquema Seleccionado ................................................................................. 105 5.3- Modelo de Gestión Propuesto ......................................................................107 5.4- Aplicación de Prácticas a las Diferentes Fases de un Proyecto ........................ 108

5.4.1- Iniciación.................................................................................................... 109 5.4.2- Planificación............................................................................................... 115 5.4.3- Ejecución.................................................................................................... 124 5.4.4- Seguimiento y Control ............................................................................... 132 5.4.5- Cierre.......................................................................................................... 139

CAPITULO VI: VALIDACION............................ ...................................................145

6.1- Sistema de Validación Seleccionado............................................................ 147 6.2- Expertos Seleccionados ................................................................................ 148 6.3- Resultado de la Evaluación de los Expertos................................................. 150

CAPITULO VII: CONCLUSIONES........................................................................ 153

7.1- Aspectos Generales....................................................................................... 155 7.2- Cumplimiento de los Objetivos Planteados.................................................. 156 7.3- Líneas de Investigación Futuras ................................................................... 158

CAPITULO VIII: BIBLIOGRAFIA ........................ ................................................ 159

CAPITULO IX: ANEXOS......................................................................................... 165

9.1- Anexo I - Extracto del Modelo Enviado a los Expertos............................... 167 9.2- Anexo II – Cuestionario Utilizado................................................................189 9.3- Anexo III – Respuestas del Cuestionario del Experto 1............................... 192 9.4- Anexo IV – Respuestas del Cuestionario del Experto 2............................... 195 9.5- Anexo V – Respuestas del Cuestionario del Experto 3................................ 198 9.6- Anexo VI – Respuestas del Cuestionario del Experto 4............................... 201



iii

L ISTA DE TABLAS Tabla I – Relación entre grupos de procesos y áreas de conocimientos del PMBOK. .........26

Tabla II – Índice de Resistencia al cambio por el desarrollo de un S.I. en el área de RRHH

...............................................................................................................................................36

Tabla III – Relación entre el IRC y las variables Sociolaborales.........................................36

Tabla IV – Relación entre el IRC y los factores de la personalidad.....................................37

Tabla V – Relación entre el IRC y los factores organizacionales ........................................37

Tabla VI – Importancia de los factores de éxito de un proyecto..........................................38

Tabla VII – Ejemplo de cuadro se criterios de selección. ....................................................64

Tabla VIII – Ejemplo de actividades de un proyecto para un CPM......................................80

Tabla IX – Ejemplo de actividades de un proyecto para un PERT.......................................85

Tabla X – Ejemplo de actividades de un proyecto para un PERT con varianza calculada...85

Tabla XI – Coeficientes de COCOMO según submodelo y modo utilizado [Boehm, 2000].

...............................................................................................................................................89

Tabla XII – Valores para los atributos del Submodelo INTERMEDIO de COCOMO ........91

[Boehm, 2000].......................................................................................................................91

Tabla XIII – Tabla de para el cálculo de puntos de función no ajustados.............................97

Tabla XIV – Esquema de prácticas por fases del proyecto .................................................108



iv

L ISTA DE FIGURAS

Figura 1 – Relación entre las variables que influyen en el éxito de un proyecto. ...................4

Figura 2 – Relación de los cinco procesos principales de un proyecto según el PMBOK

[PMI, 2004] ...........................................................................................................................24

Figura 3 – Secuencia de fases típica de un ciclo de vida según el PMBOK [PMI, 2004].....25

Figura 4 – Relación entre los interesados y el proyecto según el PMBOK [PMI, 2004]......27

Figura 5 – Esquema gráfico de la interacción entre las etapas de SCRUM..........................41

Figura 6 – Representación Ejemplo de un diagrama Causa - Efecto. ...................................62

Figura 7 – Esquema de una EDT propuesto por el PMBOK [PMI, 2004]............................77

Figura 8 – Representación gráfica de una tarea.....................................................................79

Figura 9 – Representación gráfica de dos tareas en secuencia..............................................79

Figura 10 – Diagrama de red que representa las actividades de la Tabla VIII......................80

Figura 11 – Identificación del camino crítico........................................................................81

Figura 12 – Fecha más temprana de B. .................................................................................81

Figura 13 – Fecha más temprana de C. .................................................................................82

Figura 14 – Diagrama con el cálculo de fechas más tempranas............................................82

Figura 15 – Diagrama con el cálculo de fecha más tardía para le nodo H. ...........................83

Figura 16 – Diagrama completo con fechas tardías y tempranas. .........................................83

Figura 17 – Diagrama de Gantt para las actividades de la tabla VIII....................................87

Figura 18 –Representación gráfica del esquema de la solución planteada..........................107

Figura 19 – Interacción entre los grupos de procesos según el PMBOK [PMI, 2004]. ......133



v

RESUMEN

En la actualidad de las organizaciones, la Tecnología de la Información (TI) y su

aplicación en los diferentes procesos de negocio, representa un factor crítico de éxito

para el cumplimiento de los objetivos organizacionales. La implementación de estas

tecnologías se lleva adelante a través de la ejecución de proyectos. Estos proyectos

deben ser gestionados de manera eficiente para poder alcanzar las metas planteadas y,

de esta manera lograr la correcta implementación de las tecnologías en la organización.

Todo proyecto se ve afectado por una serie de variables entre las cuáles se

encuentran las personas y que se denominan “Factor Humano”. El factor humano está

conformado por las personas y por todos aquellos aspectos que forman parte de la

relación entre ellas y con la organización en si misma.

Esta investigación tiene como objetivos identificar cuáles son los componentes

más importantes del factor humano que inciden en el resultado final de un proyecto de

TI, cuál es su impacto y determinar cuáles son las prácticas mas adecuadas para poder

realizar una correcta gestión de las personas. A partir de estas prácticas, se construirá un

“Modelo de Gestión de Personas” el cual propone las prácticas a aplicar en cada grupo

de procesos de un proyecto. Además en dicho modelo se mencionan los detalles a

considerar para aplicar cada práctica.

El proceso metodológico a seguir para poder cumplir con los objetivos descritos,

consiste en la revisión del estado del arte de modo que se pueda plasmar cuáles son los

elementos más estudiados respecto del tema, posteriormente se plantean los objetivos

específicos y la hipótesis. Luego, se presenta el marco teórico del problema de modo

que se dejan en claro todos los conceptos relacionados con el presente estudio, para

luego realizar el planteamiento del problema.

Finalmente se describe el modelo propuesto para dar solución al problema de la

gestión del factor humano en los proyectos de TI., se realiza la validación de dicho

modelo a través del juicio de expertos, se elaboran las conclusiones y se determinan las

líneas futuras de investigación.



vi

PREFACE

In Contemporary Organizations, the Information Technology (IT) and its

application in different business processes, represents a critical success factor for the

accomplishment of organizational goals. The implementation of these technologies is

achieved through the execution of projects. These projects must be managed efficiently

in order to accomplish the goals and thus achieve the successful implementation of

technologies in the organization.

Every project is affected by a number of variables which include the so-called

"Human Factor". The human factor is made up of people and of all those aspects that

are part of the relationship between them and the organization.

This research aims at identifying the most important components of the human

factor affecting the outcome of an IT project, their impact and the best practices to be

followed for the proper management of people. From these practices, we will build up a

"Model of Personnel Management," which proposes the practices to be applied on each

group of processes that form a project. This model also includes details for

implementing each practice.

The methodology to be followed in order to accomplish the above mentioned

objectives is to review the state of the art so as to recognize what are the most studied

topics with regard to this subject; then, specific objectives and hypotheses are given.

After that, we present the theoretical framework of the problem so as to make clear all

the concepts related to this study and then we make the approach to the problem.

Finally, the proposed model to solve the problem of managing the human factor

in IT projects is described; model validation is carried out through expert opinions;

conclusions are made, and as a conclusion, lines for future research are given.

CAPITULO

I

INTRODUCCION

Modelo de Mejores Prácticas para la Administración del Factor Humano en los Proyectos de TI Facultad Regional Buenos Aire


3

1.1- INTRODUCCIÓN

En toda empresa u organización los proyectos representan la forma a través de la

cual se llevan a la práctica las estrategias de la misma. Es por ello que la finalización

exitosa de un proyecto es de vital importancia y requiere de una administración especial

para asegurar que se cumplirán con los objetivos planteados.

El éxito o fracaso de un proyecto está directamente relacionado con una serie de

indicadores denominados “Factores de Éxito” y que pueden agruparse básicamente en

cuatro grupos: Tiempo, Presupuesto, Prestaciones y Personas.

Cada uno de dichos factores impactan de una u otra manera en el resultado final

del proyecto, pero además existe una relación entre los mismos de modo que, por

ejemplo, si el líder no coordina correctamente al equipo de proyecto es probable que el

trabajo sea desorganizado y que el proyecto no termine ni en el tiempo esperado ni con

el presupuesto planificado. De la misma manera, si no se cuenta con el presupuesto

necesario para ejecutar el proyecto, no se podrán contratar a las personas con los

conocimientos requeridos para llevarlo a cabo. Además, los tiempos serán mucho

mayores a los esperados y probablemente las prestaciones del producto final no

satisfagan las necesidades del cliente.

También que debe existir un equilibrio entre los cuatro grupos y, la importancia

que se le asigne a cada uno debe tener como objetivo principal el logro de un equilibrio

que permita llevar adelante el proyecto de forma exitosa.

En la Figura 1 se puede observar la relación entre el proyecto y los diferentes

grupos de factores que lo afectan.



4

Proyecto Finalizado Exitosamente

Tiempo

Presupuesto

Prestaciones

Personas

Figura 1 – Relación entre las variables que influyen en el éxito de un proyecto.

A lo largo del tiempo y con el avance de la tecnología han ido surgiendo

diversas herramientas, técnicas y metodologías que intentaron dar soporte a los

proyectos de Tecnología de la Información, en adelante TI.1, y a los factores de éxito

del mismo. Algunas de ellas se centraron sólo en algunas etapas de todo el proyecto,

mientras que otras ofrecieron una visión más integral con soluciones que puedan ser

aplicadas en cualquier instancia del proyecto.

En el marco de las herramientas aparecieron Scrum [Schwaber, 2004] y JAD2

[Wood, 1995], dos herramientas que se concentran básicamente en la etapa de

desarrollo de los proyectos de TI, y que proponen una serie de actividades que tiene

como objetivo optimizar los tiempos de desarrollo, mejorar la comunicación entre los

miembros del proyecto y brindar resultados que cumplan con las expectativas del

clientes. Pero estas técnicas presentan un problema importante: están orientadas sólo a

proyectos de TI que requieren desarrollo de software, por lo cual quedan fuera de su

alcance los demás proyectos de TI (tales como la implementación de un nuevo

hardware).

1 Se define como Tecnología de la Información al estudio, diseño, desarrollo, implementación, soporte o dirección de los sistemas de información computarizados, en particular de software de aplicación y hardware de computadoras 2 Joint Application Development: Técnica utilizada en el desarrollo de software, la cual incluye a los usuarios como participantes activos en el proceso de desarrollo.



5

Por el lado de las metodologías se encuentra la Programación Extrema (XP)

[Beck, 1999], la cual pertenece a la familia de las metodologías denominadas “ágiles”.

Esta nace para dar solución a los problemas más recurrentes de la ingeniería del

software, y provee una serie de prácticas aplicables a los proyectos de desarrollo de

software y que apuntan a evitar desvíos en los tiempos y en las prestaciones del

producto final.

Si bien la XP está basada en principios probados y brinda una serie de técnicas

que, bien aplicadas, dan muy buenos resultados, adolece del mismo problema que

Scrum y JAD: está apuntada sólo a proyectos de TI que involucran desarrollo de

software. Además su enfoque es incompleto debido a que se centra solo en la etapa de

desarrollo, dejando afuera las instancias de planificación e implementación.

Finalmente se encuentra el PMBOK (Project Management Body of Knowledge)

que, no solo representa la mejor alternativa en cuanto a metodologías de administración

de proyectos, sino que también es un estándar avalado por un organismo internacional

como lo es el PMI (Project Management Institute). Este estándar contiene todos los

aspectos que se deben considerar dentro de un proyecto de TI y abarca todas las etapas,

desde el inicio del proyecto hasta la finalización (cierre del mismo).

La ventaja fundamental de PMBOK es el hecho de que provee una guía fácil de

entender, pero el problema es que se indica qué es lo que se debe realizar pero no se

especifica cómo debe hacerse lo que, en algunos casos, suele ser el gran problema:

llevar la teoría a la práctica.

En la presente tesis se analizarán las diferentes visiones (y su evolución) acerca

de la administración de personas dentro de las organizaciones y, en particular, dentro de

los proyectos de TI. También se estudiará las características particulares de los

proyectos de TI, la administración de los mismos y las habilidades que deben poseer las

personas involucradas en los mismos, fundamentalmente, los encargados de liderar

dichos proyectos.

Además se presentarán y analizarán algunos de los problemas más recurrentes en

los proyectos y que tienen relación con la administración del factor humano, como es el

caso de la resistencia al cambio.

Finalmente se presentarán las técnicas y metodologías mas utilizadas en dicha

administración indicando las debilidades y fortalezas de cada una para luego plantear



6

una alternativa que permita dar una visión integral al problema de la administración del

factor humano en los proyectos de TI.

La administración de personas es un tema transversal a toda la organización, ya

que afecta a todas las áreas de la misma. Es por ello que el presente modelo resulta

aplicable a cualquiera de estas áreas, pero especialmente en todas aquellas que se vean

afectadas en forma directa por la realización de un proyecto de TI. Además provee

técnicas que resultará muy útiles para quien tenga la responsabilidad de liderar el

proyecto como así también para sus colaboradores.

En la actualidad existe una gran cantidad de técnicas que se aplican a la gestión

de las personas involucradas en los proyectos, algunas de ellas son aplicables en

cualquier momento y tipo de emprendimiento. Pero otras solo pueden aplicarse en

etapas específica y sólo en proyectos con características muy particulares.

La importancia del problema que se pretende resolver, radica en la escasa

importancia que, en muchos casos, se le da a la influencia que tienen las personas sobre

el resultado del proyecto. Esto se da especialmente cuando se trabaja en proyectos de TI

donde los usuarios finales suelen presentar una gran resistencia a los cambios

propuestos y a las tecnologías a implementar. Además, otro de los aspectos que dan

relevancia al tema, es la escasa atención que se presta al manejo de las relaciones dentro

del propio equipo del proyecto. En muchos casos se pondera el cumplimiento de los

cronogramas y de los presupuestos por sobre el bienestar y la comodidad de los

miembros del equipo, de modo que se genera un desgaste en los mismos que finalmente

impacta en forma negativa sobre los resultados del proyecto. Estos problemas se pueden

evitar si se plantea un esquema para la administración del factor humano, de modo que

se evitan impactos negativos en las demás variables.

En la actualidad no existe un modelo que integre todos los aspectos a considerar

respecto de la administración de personas ni que provea técnicas específicas a utilizar

para ello. Uno de los modelos en el que se menciona este aspecto es el PMBOK, el cual

en sus Capítulos 9 y 10 se dedica completamente a la administración de los recursos

humanos y a la gestión de las comunicaciones del proyecto. El inconveniente de este

modelo es que si bien indica muchas de las variables a considerar, no especifica las

técnicas a utilizar para cada caso. Esta ausencia de técnica, si bien puede parecer poco

importante, puede resultaren un problema para aquellos casos de personas con poca

experiencia en manejo de grupos de personas o con formación escasa en el tema.



7

Además, estos dos capítulos del PMBOK hacen hincapié en el manejo del

equipo del proyecto, pero dejan de lados a los clientes y demás interesados en el mismo.

La hipótesis formulada en el presente trabajo, es que se puede generar un

modelo específico para TI que permita administrar en forma eficiente todos los aspectos

relacionados con las comunicaciones, motivación y, en general, las relaciones entre las

personas involucradas en un proyecto.

Lo que se propone es un Modelo para la Gestión del Factor Humano

involucrados en los Proyectos de Tecnología de la Información. Este modelo integrará,

por un lado un modelo estructurado y ampliamente utilizado en la administración de

proyectos, como lo es el PMBOK, y las diferentes técnicas utilizadas para la

administración de todos los aspectos relacionado con el manejo de personas dentro de

un organización. De este modo, se proveerá de una serie de “Mejores Prácticas”

fácilmente aplicables a este tipo de proyecto y que redundarán en beneficios en cuanto

al manejo de las personas involucradas en el proyecto.

Quedan fuera del alcance del presente trabajo, todos aquellos temas referidos al

área de Recursos Humanos propiamente dicha. Esto significa que no se enfocará en todo

lo que respecte a definición de puestos, reclutamiento y selección de personal y gestión

de personal debido a que el modelo se orienta a los administradores de proyectos y no a

las áreas de Recursos Humanos del as organizaciones.

1.2- OBJETIVOS Y METODOLOGÍA

El objetivo principal de este trabajo de tesis consiste en elaborar un modelo de

mejores prácticas para la gestión del factor humano dentro de los proyectos de TI y que

contenga prácticas que sean aplicables a las diferentes etapas del proyecto. Además se

plantean los siguientes objetivos específicos:

� Especificar las características de la Gestión del Factor Humano en proyectos de

TI.

� Analizar los diferentes modelos utilizados para la gestión de personas en los

proyectos de TI.

� Definir el alcance y las limitaciones de cada una de las prácticas utilizadas en

cada modelo.

� Elaborar un modelo de mejores prácticas de acuerdo a cada una de las etapas de

un proyecto de TI.



8

� Evaluar el modelo obtenido y analizar los resultados.

A fin de alcanzar los objetivos propuestos en el presente trabajo de tesis, se ha

dividido el desarrollo de la misma en cinco etapas. La primera etapa tiene como

objetivo principal una revisión bibliográfica para determinar el estado del arte de la

temática involucrada. La segunda etapa consiste en analizar los diferentes modelos

utilizados para la administración del factor humano en los proyectos de TI.

La tercera etapa tiene como objetivo el relevamiento de las diferentes prácticas y

técnicas que se utilizan para la administración de las personas involucradas en los

proyectos de TI definiendo el alcance y las limitaciones de cada una. La cuarta etapa

consiste en el armado del modelo de mejores prácticas, organizando el mismo de

acuerdo a las diferentes etapas de un proyecto de TI. Finalmente la quinta etapa

consiste en el análisis y evaluación del modelo desarrollado a través del juicio de

expertos.

Etapa 1

� Profundización del estado del arte de la administración de personas en proyectos

de TI mediante la lectura de bibliografía e investigación en bibliotecas

electrónicas y congresos relacionados al tema.

� Especificación de las características de la administración del factor humano en

los proyectos de TI.

Etapa 2

� Relevamiento de los diferentes modelos para el manejo de personas utilizadas en

casos y proyectos con características diferentes. Esto se realizará a través de la

búsqueda exhaustiva a través de bibliotecas electrónicas y en proyectos

provistos por la directora.

Etapa 3

� Análisis de las características de las diferentes prácticas y técnicas relevadas.

� Determinación del alcance y limitaciones de cada una en las diferentes etapas de

un proyecto de TI. Esto se logrará mediante la comparación de las características

de cada práctica versus las necesidades de cada etapa del proyecto.



9

Etapa 4

� Armado del modelo de mejores prácticas, organizando el mismo de acuerdo a

las diferentes etapas de un proyecto de TI.

Etapa 5

� Evaluación del modelo obtenido a través del juicio de expertos. Para ello se

realizará un cuestionario con preguntas a través de las cuales se pueda

determinar la utilidad o no del modelo elaborado.

� Análisis de los resultados a través de las respuestas de los cuestionarios.

� Realización de ajustes al modelo si fuera necesario.

� Elaboración de conclusiones y líneas de investigación futuras.

CAPITULO

II

MARCO TEORICO



13

2.1- INTRODUCCIÓN

En el presente capítulo se analizará la historia y evolución del manejo del factor

humano dentro de las organizaciones y el impacto de este factor en las mismas. Además

se estudiarán las características particulares de los proyectos de TI y los aspectos que

influyen en el éxito o fracaso de los mismos.

Por otro lado también se enumerarán las características que debería tener la

persona encargada de liderar un proyecto y se pondrá especial atención en uno de los

inconvenientes más comunes en proyectos de TI relacionados con la implementación

de un producto software: La Resistencia al Cambio.

Finalmente, se analizará el PMBOK como un estándar para la administración de

proyectos y se enumerarán algunas técnicas y metodologías las cuales ponen especial

atención en las personas como un componente fundamental dentro de todo el proyecto.

2.2- EL FACTOR HUMANO Y LA ADMINISTRACIÓN

El factor humano y la administración de las personas dentro de las

organizaciones, desde hace mucho tiempo, han sido uno de los temas mas ampliamente

tratados dentro de las teorías administrativas. Uno de los primeros que se ocupó del

tema fue Frederick Taylor, creador de la Administración Científica, quien a través de

sus trabajos obtuvo una serie de premisas acerca de la actitud de los trabajadores

[Taylor, 2005] y que sirvieron como bases para el resto de sus estudios y publicaciones.

Dentro de dichas premisas las más importantes fueron:

� El trabajador es incapaz de reflexionar o pensar.

� El trabajador considera negativo el trabajo en grupo.

� El trabajador no desea tener iniciativa propia en su trabajo.

� El trabajador siempre aplica la ley del menor esfuerzo.

Si bien esta teoría es una de las primeras en analizar y sentar precedentes sobre

el comportamiento de las personas dentro de las organizaciones, se le han hecho muchas

críticas por haberse centrado más en la función y en la tarea que en la persona en si

misma. Además, se consideró al trabajador como un elemento individual sin tener en

cuenta la interacción con los demás trabajadores o las consecuencias psicológicas

acarreadas por algunos fenómenos como por ejemplo por la fatiga.



14

Otro de los que se ocupó del estudio de los individuos como parte de las

organizaciones fue Henry Fayol [Fayol, 1985], quien a través de sus estudios logró

establecer catorce principios acerca de la administración, la mayoría de los cuales

giraba entorno al comportamiento del empleado y de cómo era considerado el mismo

dentro de la organización. De estos catorce principios, los más importantes referidos al

manejo de las personas en las organizaciones son los siguientes:

� Subordinación de intereses particulares: Por encima de los intereses de los

empleados están los intereses de la empresa.

� Los miembros de una organización tienen que respetar las reglas y convenios

que gobiernan la empresa.

� Remuneración personal: La remuneración y los métodos de retribución deben

ser justos y propiciar la máxima satisfacción posible para los trabajadores y para

el empresario.

� Espíritu de equipo: Hacer que todos trabajen dentro de la empresa con gusto y

como si fueran un equipo, hace la fortaleza de una organización.

� Equidad: Los administradores deben ser leales y respetuosos con el personal, y

demostrar cortesía y justicia en su trato.

� Estabilidad en el empleo: Se debe dar estabilidad en el cargo al personal. Los

cambios en las asignaciones de los empleados son necesarios, pero si ocurren

con demasiada frecuencia pueden perjudicar la moral y la eficiencia.

Además esta teoría planteaba dos tipos de comunicación dentro de la

organización: las descendentes (impartir órdenes a los subordinados) y ascendentes

(eleva información a los superiores).

A pesar de que esta teoría fue una de las primeras en tener mayor consideración

con las personas que integran una organización, puso demasiado enfoque en la

organización formal dejando de lado casi por completo a la organización informal y sus

aspectos sociológicos dentro de la empresa.

Desde 1920 y hasta la Segunda Guerra Mundial, las monarquías fueron

reemplazadas progresivamente por regímenes democráticos, haciendo que los sistemas

autoritarios pasasen a ser más participativos. Simultáneamente, se producen importantes

cambios en las ciencias como la Sociología y la Psicología. Es entonces cuando aparece

la teoría de las Relaciones Humanas [Mayo, 2003] como una reacción inmediata al

Experimento de Hawthorne (1927) y que representó un complemento a la teoría clásica

de la administración.



15

Esta teoría planteó los siguientes postulados:

� El trabajo es una actividad típicamente grupal.

� El obrero no actúa como individuo aislado sino como miembro de un grupo

social.

� La tarea básica de la administración es formar una élite capaz de comprender y

de comunicar, compuestas por jefes democráticos, persuasivos y apreciados por

todo el personal.

� La persona humana es motivada esencialmente por la necesidad de “estar en

compañía”, de “ser reconocida”, de acceder a una comunicación adecuada.

A partir del experimento de Hawthorne, aparecen otros autores que realizan

nuevos aportes a esta teoría, tal como es el caso de Roethlisberger y Dickson, quienes

aportan los conceptos de Función Económica y Función Social de una organización,

donde la función social tiene como objetivo brindar satisfacciones a los miembros de la

organización [Dickson, 2003].

Algunos años mas tarde, Abraham Maslow desarrolló la Teoría de las

necesidades [Maslow, 1991] en la cuál se plantea cuáles son las causas que mueven a

las personas a trabajar en una empresa y a aportar parte de su vida en ella. Estas

necesidades fueron estructuradas en forma de pirámide de modo que las necesidades

más básicas o simples del individuo se colocaron en la base de la pirámide, mientras

que las más relevantes se colocaron en la parte superior de la misma. A medida que se

satisface uno de los niveles de la base se pasa a otro superior y así hasta llegar al nivel

mas alto de la pirámide donde el individuo alcanza un estado denominado

“Autorrealización”, en el cual la persona alcanza un nivel de felicidad y armonía plena.

El aporte mas importante de la teoría de Maslow es que da el puntapié ara

adentrarse en cuales son las necesidades que mueven a la persona en su

comportamiento, sea en un grupo de personas como en una empresa. Pero presenta

algunos problemas al intentar definir el estado de autorrealización, que parece ser mas

un ideal al que se intenta llegar mas que un estado en si mismo.

En la misma línea de la Teoría de las Necesidades, surge la denominada “Teoría

de la Motivación e Higiene” [Herzberg, 1993] en la que se plantea que las personas son

influenciadas por dos factores:

� Factores de Higiene: Son aquellos factores que hacen que una persona se sienta

cómoda en su trabajo.



16

� Factores de Motivación: Son aquellos que hacen que la persona deposite su

esfuerzo y su colaboración en la realización de sus actividades dentro de la

organización.

Dentro de una organización la falta de cobertura de los factores higiénicos puede

provocar una falta de satisfacción en sus miembros, lo que generará también un estado

de falta de motivación. Por su parte los factores de motivación, son aquellos que

producen un efecto de satisfacción más duradero y que incluyen sentimientos de

realización y crecimiento mediante el cumplimiento de las tareas ofreciendo también

desafíos nuevos para la persona.

En 1960, inspirado por la teoría de Maslow, el sociólogo Douglas McGregor

plantea las teoría X e Y [McGregor, 2007] donde la primera asume que las personas

son desinteresadas con su trabajo, haraganas y que lo único que los motiva a realizar

sus actividades es la constante amenaza de que perderán su empleo. Por otro lado, la

teoría Y supone que los individuos son creativos, comprometidos con su trabajo y que

siempre están en búsquedas de nuevos retos y responsabilidades. Esta segunda teoría es

la que mas ha sido mas ampliamente adoptada en la actualidad para la administración de

los recursos humanos en las organizaciones.

Por otro lado, complementando a las teorías de la administración que se

encargaron de estudiar el factor humano dentro de las empresas, se presenta la

psicología que, a través del estudio de las dinámicas de grupos y los roles que cada

individuo juega dentro de los mismos, proporciona otro enfoque interesante del tema.

Pichón Riviere define a un grupo como “un conjunto restringido de personas que,

ligadas por constantes espacio temporales, el cual, articulado en su mutua

representación interna, se propone en forma implícita y explícita una tarea que

conforma su finalidad, interactuando a través de complejos mecanismos de asunción y

adjudicación de roles” [Pichón-Riviere, 1999] y también define a un rol como “un

modelo organizado de conducta , relativo a una cierta posición del individuo en una red

de interacciones ligado a expectativas propias y de los otros”.

En el marco de la dinámica de grupos de trabajo y de los papeles (roles) de cada

integrante, se definen los siguientes:

� El Vocero es el encargado de comunicar todo lo que sucede dentro del grupo.

� El Chivo Emisario es aquel en el cual se depositan todos los aspectos negativos

del grupo. En él todo el grupo deposita todo lo que no se tolera dentro de la



17

estructura del grupo, también se habla del “enfermo del grupo” [Pichón-Riviere,

1999].

� El Líder es aquel integrante del grupo en el cual todos los demás depositan los

aspectos positivos del grupo. Es el encargado de estimular a los demás para que

se alcancen los objetivos del grupo y se superen las metas.

� El Saboteador es el encargado de realizar la resistencia al cambio. Es el

encargado de obstaculizar la consecución de una tarea.

Si se considera a una organización como una “asociación de personas regulada por un

conjunto de normas en función de determinados fines” [R.A.E., 2007], los roles antes

mencionados pasan a jugar un papel importante en el análisis y entendimiento de las

actitudes y comportamiento de los miembros de la misma frente a los demás, y es por

ello que estos conceptos se deben tener presentes en el actual trabajo.

2.3- LOS PROYECTOS DE TI

Antes de comenzar a analizar este tema, es importante definir que se entiende

por “Proyecto” y por “Gestión de Proyectos”. Según el Project Management Institute

[PMBOK, 2004] las definiciones de dichos conceptos son las siguientes:

� Gestión de proyectos consiste en aplicar los conocimientos, habilidades,

herramientas y técnicas a las actividades de un proyecto de forma tal de cumplir

con los requerimientos del mismo.

� Proyecto se define como una empresa temporal que se asume con el fin de crear

un producto o servicio único.

Para el caso de la definición de proyecto, se considera que es temporal porque tiene un

comienzo y un final definido, lo cual lo diferencia de las operaciones normales dentro

de una organización la cuales, además, crean productos o servicios que son repetitivos.

Como ya mencionamos antes, los proyectos deben ser llevados a cabo bajo una serie de

restricciones que, además, se influencian una a la otra.

Si bien estas las restricciones se clasifican en grupos diferentes, estos grupos

están relacionados entre si, de modo que una modificación el alguna de ellas podría

impactar en las demás. Es por ello que resulta importante contar con una buena gestión

de proyecto y con las herramientas y técnicas adecuadas que permitan, a todo el equipo

de proyecto, organizar su trabajo para poder cumplir con todas las restricciones

planteadas.



18

Por otro lado, todo proyecto, y en especial los proyectos de TI, se ven altamente

influenciado por los grupos de personas que serán involucrados en la realización del

mismo. En estos grupos existen 2 tipos de afectados: quienes impulsan el proyecto (por

razones políticas, económicas etc.), denominados “Sponsors” y quienes serán los

usuarios de dicho proyecto y que convivirán día a día con el resultado del mismo,

denominados “Usuarios Finales” o “Stackeholders”. Es por ello que resulta de gran

importancia para el éxito de un proyecto de TI que se identifiquen claramente quienes

son los componentes de cada uno de los grupos humanos que se ven impactados por la

realización del mismo. Hoy dos aspectos importantes a considerar en este punto:

� Determinar las necesidades y expectativas de cada miembro del grupo.

� Manejar e influenciar las expectativas de modo que se asegure la realización de

un proyecto exitoso.

Otro de los puntos fundamentales es el manejo de lo que se puede denominar

“interfases” del proyecto, que son fundamentalmente las comunicaciones formales e

informales entre las diferentes personas que trabajarán dentro del proyecto, como

también sus relaciones con los usuarios finales del mismo.

Para poder realizar un correcto manejo de todos los aspectos que se enumeraron

anteriormente y que tienen impacto directo sobre el resultado final de un proyecto, es

necesario que la persona que conduce dicho proyecto (líder de proyecto) reúna una serie

de habilidades. A continuación se analizarán en detalle cuáles son las más importantes y

la utilidad de cada una de ellas.

2.3.1- HABILIDADES DEL L ÍDER

Según Konosuke Matsushita [Matsushita, 1993], el empleado ideal es “alguien

que tenga una gran capacidad para el desarrollo personal, alguien que pueda crecer no

solo dentro del trabajo sino también junto con el mismo”. Basado en ésta definición,

Luís Bravo Salomón [Salomón, 2003] sostiene que existen habilidades que favorecen al

desarrollo personal y otras que nos permiten mejorar la interacción con las personas con

las que se comparte el lugar de trabajo y las actividades correspondientes. Ambas son

necesarias para poder liderar correctamente un equipo y mantener una buena

comunicación.

Dentro de las habilidades que favorecen al desarrollo personal encontramos las

siguientes:



19

� Inteligencia Emocional: La inteligencia emocional esta conformada por la

capacidad de comunicación, la comprensión hacia los problemas de los demás,

la participación afectiva y emocional en el entorno, la capacidad para lograr un

buen rendimiento cuando se trabaja en equipo y sintetizar a partir de

experiencias de los demás y la capacidad de saber consultar y preguntar entre

otras cosas. Esta inteligencia indica las aptitudes que tiene una persona para

manejar la relación entre las emociones y la razón como así también el dominio

de los sentimientos y la disposición para el trabajo en equipo.

Como líder de proyecto, es importante reconocer cuales son las emociones

involucradas en cada proceso, reconocer cada uno de los roles que cumplen los

integrantes del equipo de trabajo y realizar todas las acciones necesarias para

evitar posibles conflictos improductivos dentro del grupo.

Lograr un buen desarrollo de la inteligencia emocional permitirá mejorar el

manejo de las relaciones con los demás.

� Empatía y Confianza: Se define como empatía a la capacidad personal de

establecer relaciones positivas, rápidas, auténticas y con gran facilidad para

ponerse en el lugar del otro de modo que se puede comprender emocionalmente

a la otra persona. Quien posee esta capacidad, puede no necesitar que los demás

le comuniquen verbalmente sus sentimientos; sino que la persona puede

captarlo a través de signos corporales como el tono de voz, la postura corporal,

la expresión del rostro, etc.

Por otro lado se encuentra la confianza, que representa otro de los factores

importantes en la relación entre personas. Los individuos que generan confianza

son aquellos que tienen la capacidad de transmitir credibilidad y apertura para

poder responder todas las preguntas que se le realicen. Quienes generan

confianza también tienen una característica más: poseen confianza en sí

mismos, lo cual les permite asumir nuevos riesgos y desafíos con la seguridad

de poder cumplirlos.

� Proactividad: La proactividad es la capacidad de una persona de contribuir y

adelantarse para lograr los resultados de la mejor manera posible, siempre se

preocupa por participar e intentar mejorar las actividades que realiza.



20

Una persona preactiva siempre decide libremente, y sin sentirse presionado, lo

que desea hacer tanto en los aspectos personales como laborales, asume sus

responsabilidades y toma la iniciativa para enfrentar y solucionar las

dificultades.

� Asertividad: Se conoce como asertividad a la habilidad de una persona para

expresar los sentimientos, pensamientos, ideas, opiniones y creencias a otros de

una manera efectiva y cómoda que no altera ni afecta su relación con quienes lo

rodean. Aristóteles en Ética a Nicómano citaba lo siguiente “Cualquiera puede

ponerse furioso, eso es fácil, pero estar furioso con la persona correcta, en el

momento correcto, por el motivo correcto y de la forma correcta… eso no es

fácil” (Año 2001, Libro Octavo); esta frase sigue siendo de mucha utilidad para

definir y enfocar el significado de la asertividad y es muy simple de

comprender.

Es muy importante que un líder de proyecto tenga una conducta asertiva ya que

la misma favorece a la comunicación y evita las reacciones agresivas o

defensivas por parte de los miembros del grupo de trabajo.

� Motivación: La motivación es el motor que empuja a la acción. Una persona

motivada siempre está predispuesta a actuar, y realizar todo lo necesario para

lograr el objetivo deseado o solicitado.

La motivación puede ser intrínseca o extrínseca. Se dice que la motivación es

intrínseca cuando la misma no proviene desde el exterior de la persona sino que

nace como un interés de la persona en hacer o adquirir conocimientos acerca de

algo, mientras que se dice que es extrínseca cuando el origen de la motivación

se encuentra en el entorno de la persona, es decir, en los halagos y/o

reconocimientos que pueda lograr como consecuencia de haber alcanzado los

objetivos.

Las personas que se encargan de gerenciar y liderar proyectos deben tener

siempre presente que es necesario motivar al personal para generar un mejor

clima de trabajo y lograr que el proyecto se realice de la mejor manera posible.

� Trabajo en Equipo: El concepto que se relaciona directamente con el trabajo

en equipo es el de sinergia, es decir que el trabajo en equipo (o el todo) es



21

mayor que la suma de los esfuerzos individuales (suma de las partes). Es

importante tener siempre presente esto, sobre todo quines lideran los equipos,

ya que existen diferentes roles de un equipo y una buena convivencia entre los

diferentes roles ayudará a que el equipo sea efectivo.

También es necesario que se defina claramente a todo el equipo cuales son las

normas de convivencias, las metas a alcanzar, los procedimientos a seguir, etc.

Para que se pueda alcanzar la sinergia necesaria dentro del grupo.

� Liderazgo: Se define como liderazgo a la capacidad o habilidad de una persona

de hacer que las demás la sigan aun a aquellos lugares donde no irían solas.

Las relaciones de confianza se construyen con un comportamiento ético, con el

cual se logra influir en los demás e incluso despertar en ellos el deseo de que lo

sigan. Es por ello que el líder debe estar centrado en principios y esforzarse en

mantener y cumplir sus compromisos. Los principios son verdades naturales y

universales que están presentes en todo grupo aunque no se hayan reconocido

explícitamente. La honradez, la equidad, la lealtad, la responsabilidad y la

dignidad son algunos ejemplos de valores. Cuando una persona asume aunque

sea alguno de estos principios para basar su comportamiento, los transforman

fácilmente en valores y son parte de lo que nutre al liderazgo.

Pro supuesto que un gerente de proyecto debe tener capacidades de líder de

modo que se pueda encausar a todo el grupo de trabajo hacia un mismo camino,

y aunque algunas veces el liderazgo es innato también se aprende.

� Comunicación Efectiva: La comunicación es el intercambio de información y

comprensión entre dos personas. Dicho intercambio es en dos direcciones

siendo responsabilidad del emisor hacer que la información que se transmite sea

clara, completa y concisa. Mientras que el receptor es el encargado de asegurar

la correcta comprensión de la misma.

Existen ocho pasos para comunicarse: desarrollo de la idea del emisor,

codificación del mensaje en símbolos, transmisión a través del canal

correspondiente, recepción del mensaje, comprensión de la información por

parte del receptor y retroalimentación.

Es de vital importancia que el líder de proyecto tenga siempre presente los

pasos involucrados en la comunicación, para poder cumplir correctamente con



22

cada uno de ellos y asegurar que efectivamente los mensajes se transmiten e

interpretan correctamente entre los involucrados en el proyecto.

� Negociación: Es el proceso por el cual se llega a un acuerdo entre los

involucrados en un proyecto con relación a aspectos inherentes a él. Es un

proceso persuasivo, y por tanto, una de las habilidades muy necesarias para el

logro exitoso del mismo.

Dentro de un proyecto existen negociaciones con proveedores, clientes,

contratistas, otros gerentes, grupo de trabajo, etc. para acordar diferentes temas

con cada uno de ellos. También es importante evitar los conflictos durante el

proceso de negociación de modo que se evite perjudicar a los intereses

individuales de las partes.

Como líder de proyecto se debe tener siempre claramente identificados los

objetivos de la negociación, los intereses de cada una de las partes y tratar de

crear un planteamiento que genere satisfacciones mutuas. También se deben

tener presentes otros aspectos que influyen en la negociación, tales como la

religión, la cultura, el lenguaje, la educación y las creencias de cada uno.

Según lo expuesto por Bravo Salomón, un gerente / líder de proyecto no solo

debe tener conocimientos y habilidades referidos a su profesión; sino que también debe

tener conocimientos de otras áreas debido a que va a tener mucha relación con el

personal y será el encargado de dirigir al mismo. Esto implica saber comprender las

necesidades de cada persona, poder negociar tanto con el equipo como con el resto de

los involucrados en un proyecto, saber manejar la motivación de las personas, dirigir las

diferentes reuniones y fomentar la comunicación.

Además debe realizar todas las actividades necesarias para fomentar el

desarrollo personal y profesional de los miembros del equipo de trabajo. Todas estas

habilidades se deben adquirir y desarrollar a través del estudio y de la experiencia.

Pero, además de las habilidades personales de un líder, también existe un segundo

aspecto a considerar: La organización y de un proyecto y la metodología adoptada para

administrar el mismo. Este aspecto es tan importante como las habilidades que debe

tener un líder de proyectos, ya que sin metodología resulta muy engorrosa la

organización de un proyecto y, por consecuencia, lograr una finalización exitosa.



23

A continuación se analizará en detalle como se lleva a cabo la gestión de un

proyecto de IT y cuáles son los aspectos más importantes a considerar. Para ello se ha

elegido las pautas delineadas por el Project Management Institute a través del PMBOK.

2.4- LA GESTIÓN DE LOS PROYECTOS DE TI

Según el PMBOK, la gestión de proyectos se puede dividir en cinco grupos de

procesos: Iniciación, Planificación, Ejecución, Control y Cierre. Cada uno de estos

grupos, está compuesto por actividades que se ejecutan y permiten alcanzar los

resultados esperados para dicho grupo de proceso. Estas actividades pueden solaparse

unas con otras como también puede ocurrir con los procesos dentro de un mismo

proyecto.

La finalidad del PMBOK no es exponer disciplinas, herramientas y técnicas

aplicables a la gestión de proyectos sino proveer de un grupo seleccionado de ellas y

que son consideradas como buenas prácticas. Además, el grupo de conocimientos de

este estándar se encuentra distribuido entre los miles de colaboradores alrededor del

mundo y es por esta razón que no se lo presenta como un manual con pasos a seguir

para culminar un proyecto en forma exitosa.

Los cinco procesos en los que se estructura el PMBOK son:

1. Inicio

2. Planificación

3. Ejecución

4. Seguimiento y Control

5. Cierre

Y las nueve áreas de conocimiento son:

1. Gestión de la Integración

2. Gestión del Alcance

3. Gestión del Tiempo

4. Gestión de la Calidad

5. Gestión de Costos

6. Gestión de Riesgos

7. Gestión de Recursos Humanos

8. Gestión de la Comunicación

9. Gestión del Aprovisionamiento



24

A lo largo de un proyecto estos procesos se solapan e interactúan entre sí (Figura 2).

Cada proceso se describe en función de sus entradas, herramientas y técnicas y

finalmente la salida del mismo.

Figura 2 – Relación de los cinco procesos principales de un proyecto según el PMBOK [PMI, 2004]

EL PMBOK remarca que es importante comprender que los proyectos se

pueden dividir en proyectos más pequeños o fases. Estas fases comprenden lo que se

denomina Ciclo de Vida de un Proyecto. Este ciclo de vide indica la serie de fases que

se sucederán desde el principio hasta el fin del proyecto.

El traspaso formal de una fase a la otra, dentro del ciclo de vida, está dada por la

conclusión y aprobación de lo que se denominan “entregables”. Dichos entregables no

son ni más ni menos que el resultado final de la ejecución de dicha fase, y puede estar

representado por un documento, un producto, etc. que se considera necesario para el

comienzo de la fase siguiente. Generalmente los ciclos de vida establecen las fases que

componen el mismo y el orden en que se deben ejecutar, las áreas y personas que deben

participar en cada una de las fases, los entregables de cada una de las fases y los

mecanismos a través de los que se aprobarán los mismos, y los mecanismos de control

de cada una de las fases definidas.

Aunque los ciclos de vidas de diferentes proyectos se parecen, no todos son

exactamente iguales en cuanto a las fases que lo componen, ni requieren los mismos

entregables. En algunos casos se da la situación de solapamiento de fases, es decir, una

fase comienza aún cuando no ha finalizado la fase que la precede aunque no suele ser

una práctica recomendada. De todos modos la conclusión de una fase no implica



25

necesariamente el comienzo de otra, sino que puede ser que la conclusión de una fase

implique el final del proyecto.

En la figura 3 se puede observar el conjunto de fases sugeridas por el PMBOK y

las entradas y salidas de cada una de ellas.

Figura 3 – Secuencia de fases típica de un ciclo de vida según el PMBOK [PMI, 2004].

A continuación, el la Tabla I se puede ver la relación que existe entre las áreas

de conocimiento y los grupos de procesos propuestos por el PMBOK. Dicha tabla

permite visualizar claramente que áreas están involucradas en cada uno de los grupos de

procesos.



26

Grupos de

Procesos Áreas de Conocimiento

Iniciación

Planeamiento

Ejecución

Control

Cierre

Gestión de la Integración

X

X

X

Gestión del Alcance

X

X

X

Gestión del Tiempo

X

Gestión de Costos

X

X

Gestión de la Calidad

X

X

X

Gestión de los Recursos Humanos

X

X

Gestión de las Comunicaciones

X

X

X

X

Gestión de Riesgos

X

X

Gestión del Aprovisionamiento

X

X

X

Tabla I – Relación entre grupos de procesos y áreas de conocimientos del PMBOK.

Así como existe una relación entre los procesos y las áreas de conocimientos de

un proyecto, también existe una vinculación entre el proyecto y las personas de la

organización que se involucran con el mismo.

Según el PMBOK los interesados tienen diferentes niveles y responsabilidades

las cuales pueden ir cambiando a lo largo del ciclo de vida del proyecto y cada uno de

ellos puede influir positiva o negativamente en el resultado final del mismo. Es por ello

que es necesario identificar claramente los interesados, sus intereses, los requisitos que



27

deben cumplir y gestionar correctamente la relación de los mismos para con el resto del

equipo.

La Figura 4 ilustra las relaciones entre los integrantes y el proyecto de acuerdo a

lo expuesto anteriormente.

Figura 4 – Relación entre los interesados y el proyecto según el PMBOK [PMI, 2004].

La estructura de la organización también tiene influencia sobre le proyecto,

sobre todo en lo que se refiere a la disponibilidad de recursos y el manejo de los

mismos. A continuación se describirán brevemente cada uno de los grupos de procesos

mencionados.

Iniciación

El grupo de procesos de iniciación comprende a todos aquellos procesos

relacionados con la definición de los objetivos del proyecto, la justificación del mismo,

el estudio de factibilidad, la evaluación de las diferentes alternativas, la duración

aproximada y una primera estimación de los recursos necesarios para el proyecto.

También en esta etapa se definen las restricciones y se designa al director del proyecto.

Todo esto se realiza para lograr que finalmente se apruebe formalmente el proyecto en

caso de ser considerado viable.

En los procesos de este grupo, es fundamental la participación de los clientes,

sponsors y stakeholders del proyecto. Los clientes, son aquellas personas que se verán

afectadas por la ejecución del proyecto. Son aquellos individuos que convivirán día a

día con el resultado de la ejecución del proyecto, es decir, los usuarios del producto.



28

El sponsor, por ser quien avala institucionalmente al proyecto, es decir, quien

impulsa la realización del proyecto dentro del a organización. Es por ello que en los

procesos de iniciación es muy importante contar con la participación de esta persona

para lograr un apoyo por parte del resto de la organización y alcanzar la aprobación del

proyecto. Mientras que, por su parte, los stakeholders son todos los involucrados en el

proyecto y que se verán afectados por la ejecución del mismo, como así también

aquellos que influyen sobre dicho proyecto.

Dentro de los procesos que forman parte del grupo de iniciación, encontramos los

siguientes:

� Desarrollar el Acta de Constitución del Proyecto

� Desarrollar el Enunciado del Alcance del Proyecto

Planificación

El objetivo principal de este grupo de procesos y las interacciones entre ellos es

el de planificar y gestionar con éxito un proyecto dentro de una organización. Además,

los procesos que comprenden este grupo son los encargados de lograr una mayor

maduración del alcance del proyecto, y definir las actividades que se realizarán a lo

largo del proyecto.

En este grupo de procesos también se define las dependencias entre las tareas,

los requisitos, los riesgos y también las restricciones.

Durante la planificación del proyecto, el equipo debe involucrarse con todos los

interesados en el mismo y que pueden influir en el desarrollo del proyecto y sus

resultados. La finalidad principal de este contacto es la de aprovechar los conocimientos

y habilidades de cada uno de los implicados en beneficio de todo el proceso de

planificación. Pero este contacto no puede realizarse en forma aleatoria y desordenada,

sino que se debe propiciar el clima y el entorno para que la contribución de los

interesados sea más provechosa y para que los integrantes del equipo de proyecto

puedan obtener el mayor beneficio de dicha situación.

Los procesos que se ejecutan dentro del grupo de planificación son:

� Desarrollo del Plan de Gestión del Proyecto.

� Planificación del Alcance.

� Definición del Alcance.

� Crear el EDT.



29

� Definición de las Actividades.

� Definir la secuencia de Actividades.

� Estimación de Recursos de las Actividades.

� Estimación de la Duración de las Actividades.

� Desarrollo del Cronograma.

� Estimación de Costos.

� Preparación del Presupuesto.

� Planificación de la Calidad.

� Planificación de los Recursos Humanos.

� Planificación de las Comunicaciones.

� Planificación de la gestión de Riesgos.

� Identificación de Riesgos.

� Análisis Cuantitativo de Riesgos.

� Análisis Cualitativo de Riesgos.

� Planificación de la Respuesta a los Riesgos.

� Planificación de las Compras.

� Planificación de las Contrataciones.

Ejecución

El grupo de procesos de ejecución tiene como objetivo completar el trabajo

definido en el plan de gestión del proyecto, para poder alcanzar el cumplimiento de lo

requerimientos de proyecto.

Entre las actividades de este grupo de proyectos están implicadas todas aquellas

relacionadas con la coordinación de las personas involucradas, la administración de los

recursos y la integración de todas las actividades del proyecto.

Los procesos que se ejecutan dentro de este grupo son:

� Dirigir y Gestionar de la Ejecución del Proyecto.

� Realizar el aseguramiento de la calidad.

� Adquirir el Equipo del Proyecto.

� Desarrollar el equipo del Proyecto.

� Distribuir la Información.

� Solicitar Respuestas de Vendedores.

� Seleccionar los Vendedores.



30

Seguimiento y Control

El objetivo de este grupo de procesos es el de monitorear la ejecución de todo el

proyecto a fin de poder identificar los posibles inconvenientes a tiempo y tomar las

acciones correctivas correspondientes en caso de ser necesario.

Los procesos de este grupo buscan realizar un seguimiento continuo de manera

que se pueda proporcionar a todos los miembros del equipo una visión acerca de la

salud del proyecto. De esta manera se pueden identificar cualquier área que requiera

algún tipo de atención especial para evitar desviaciones en la ejecución.

El seguimiento y control no solo controla los procesos de n grupo sino que

realiza monitoreos sobre el avance de todo el proyecto. Esta supervisión también genera

la retroalimentación necesaria para poder mantener el proyecto dentro del plan de

gestión realizado.

Los procesos que forman parte de este grupo son los siguientes:

� Supervisar y Controlar el Trabajo del Proyecto

� Control Integrado de Cambios

� Verificación del Alcance

� Control del Alcance

� Control del Cronograma

� Control de Costos

� Realizar Control de Calidad

� Gestionar el Equipo del Proyecto

� Informar el Rendimiento

� Gestionar a los Interesados

� Seguimiento y Control de Riesgos

� Administración del Contrato

Cierre

El grupo de procesos de cierre esta comprendido por todos aquellos procesos

que se ejecutan para concretar la finalización formal del proyecto. Esta finalización

puede estar dada por la conclusión del mismo o por la cancelación del proyecto por

algún motivo en particular. Este grupo comprende los siguientes procesos:

� Cierre del Proyecto.

� Cierre del Contrato.



31

Además el cierre también se ejecuta cuando se finaliza una fase del proyecto, de modo

que se formaliza la conclusión de la misma.

En el PMBOK se considera que el cierre del proyecto concluye con la entrega

del producto. El concepto de “entrega” depende en gran medida de lo que se haya

definido en el contrato antes de comenzar el proyecto. Así, puede ocurrir que la entrega

del producto sea, por ejemplo, la entrega de la documentación del sistema y el producto

software para que luego el cliente se encargue de la implementación y puesta a punto

del mismo. O también puede que la entrega del producto implique que el sistema y los

productos software relacionados deben estar implementados y puestos en marcha.

A fin de abarcar una mayor gama de posibilidades, en el presente trabajo se

considerará que la entrega del producto se realiza con el sistema funcionando y con los

productos software instalados y puestos en marcha.

Para el caso particular de los proyectos de TI, se debe considerar que

generalmente implican desarrollo o adquisición de software, por lo que es importante

considerar las etapas que involucra, de modo que se puedan determinar las acciones a

realizar en cuanto a la administración del factor humano en cada etapa.

A continuación se presenta una metodología propuesta por James a Senn y en la

cual se pueden identificar las diferentes etapas que se ven involucradas.

2.4.1- EL DESARROLLO DE SOFTWARE

Según el ciclo de vida clásico del desarrollo del software [Senn, 1992], las

etapas involucradas son:

Investigación Preliminar:

La investigación preliminar se divide en tres partes. La primera de ella es la

aclaración de la solicitud, en la cual se especifica de manera clara y detallada que es lo

que el usuario desea. Muchas veces el cliente no tiene una idea bien clara y formada de

lo que realmente necesita, por lo cual es tarea del analista asistirlo para poder expresar

en forma clara lo que se colocará en la solicitud.

La segunda parte es el estudio de factibilidad, durante el cual se analizan la

Factibilidad Técnica (¿la tecnología y el software disponibles actualmente son

suficientes para llevar adelante el proyecto?), Económica (¿los beneficios de ejecutar el



32

proyecto justificarán los costos del mismo?) y Operacional (¿los usuarios utilizarán el

nuevo sistema o habrá resistencia al cambio?).

Finalmente la última parte de esta etapa es la aprobación de la solicitud, en este

momento es cuando se realiza la firma de la aprobación formal del proyecto. Una vez

aprobada la solicitud se deben realizar las estimaciones de costos, tiempo y personal de

modo que se le asigne una prioridad al proyecto dentro de la lista de proyectos de la

organización.

Determinación de Requerimientos:

En esta etapa se debe especificar cuales son las prestaciones que el cliente espera

que le brinde el nuevo sistema. En este momento el analista debe lograr (en conjunto

con el cliente) dar respuesta a las siguientes preguntas relacionadas con los procesos de

la empresa:

- ¿Qué es lo que se hace?

- ¿Cómo se hace?

- ¿Con qué frecuencia se presenta?

- ¿Qué tan grande es el volumen de transacciones y decisiones?

- ¿Cuál es el grado de eficiencia con que se realizan las tareas?

- ¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo

origina?

Para poder obtener esta información se deberán utilizar diferentes herramientas y

técnicas de recopilación de datos de modo que se pueda comprender el proceso en su

totalidad. La salida de esta etapa debe ser una lista con la descripción de las prestaciones

que debe cumplir el nuevo sistema (características funcionales) y las características no

funcionales (tales como los tiempos de respuestas).

Diseño del Sistema:

En esta etapa se establece cómo el sistema cumplirá con lo requerimientos

identificados en la etapa anterior. Este es el momento en que se realiza el “diseño

lógico” del sistema. En este momento se deberá realizar la especificación del software

y también reespecifican los procedimientos asociados.



33

Desarrollo del Software:

Esta es la etapa en la cual se debe analizar si el software a implementar será

desarrollado internamente en la organización o si se adquirirá alguno disponible en el

mercado. Para tomar esta decisión es importante tener bien en claro las prestaciones

indicadas en la lista de requerimientos, a fin de poder evaluar si existe un producto en el

mercado que cumpla con todos los ítems de la misma.

En caso de desarrollo interno se construye el software y la documentación

correspondiente, y en caso de adquirir un producto del mercado también se debe

solicitar la documentación del mismo.

Prueba del Sistema:

En esta fase se realizan todas las pruebas necesarias para asegurar que el

software no posea fallas y que cumple con los requerimientos especificados. Aquí se

utilizan datos de pruebas y generalmente es un grupo de usuarios los que llevan a cabo

dichas pruebas o al menos un grupo de personas ajenas al equipo que confeccionó el

software.

Implantación y Evaluación:

La implementación es el proceso por el cual se verifica e instala el nuevo

equipamiento, se entrena a los usuarios acerca del uso del software y sobre como se

realizarán los nuevos procedimientos, se realiza la carga de todos los datos que sean

necesarios para comenzar con la operación del nuevo sistema, y se realiza un

seguimiento para asegurar que todo funciona de acuerdo a lo planificado. La

implantación puede hacerse en paralelo (utilizando el nuevo y el viejo sistema a la vez y

abandonando progresivamente el primero) o desde cero (eliminando definitivamente el

viejo sistema de a un área por vez y reemplazándolo por el nuevo).

Durante todo el ciclo de vida de un proyecto software, pero principalmente en la

etapa de implantación, existe un factor que resulta determinante del éxito o fracaso del

mismo. Este aspecto debe ser considerado y analizado durante la etapa de Estudio de

Factibilidad al efectuar el estudio de la factibilidad operacional, según el cual se

determina que aceptación tendrá el software por parte de los usuarios finales. Este factor

es la Resistencia al Cambio.



34

2.4.2- RESISTENCIA AL CAMBIO

Otro de los temas que está involucrado en los proyectos de IT y que impacta

directamente sobre el éxito o el fracaso del mismo es la denominada “resistencia al

cambio”. El principio de “acción y reacción” de la física puede ayudar a comprender

que ante un cambio (acción) es natural y esperable que aparezca una resistencia

(reacción) [Álvarez, 2001].

El cambio por si mismo no es percibido como malo, sino que inicialmente puede

captarse como positivo o negativo de acuerdo a la capacidad de las personas que lo

impulsan de anticiparlo y controlar sus consecuencias. Es en este punto donde el quipo

de proyecto y el sponsor del proyecto deben tener en claro cuales son los principales

focos de resistencia, comprender el porque de la misma y tratar de realizar acciones que

tiendan a reducir o eliminar dicha resistencia.

Los cambios suponen crisis, ya que la propia tendencia a la continuidad por

parte del comportamiento social, la hace inevitable incluso en los casos más

insignificantes. La crisis continúa hasta que se alcanza alguna nueva forma de

adaptación en que los antiguos elementos se fusionan con los nuevos elementos. Esto

sucede porque los miembros de la organización pueden percibir los efectos del cambio

de diferentes maneras: como beneficiosos, perjudiciales o ambivalentes de acuerdo a sus

conveniencias personales y su capacidad de adaptación [Salinas, 1975].

De acuerdo a lo expuesto podemos concluir que cualquier cambio que se

introduzca en la organización producirá resistencia, y el caso de la implementación de

un proyecto de TI no es la excepción, ya que generalmente impactan en la estructura de

la empresa, los procesos y finalmente en las tareas que realizan los miembros de la

misma.

El proceso de cambio tiene varias etapas, Kurt Lewin define como etapas del

cambio a las siguientes [Cummings, 2007]:

Descongelamiento: Es la etapa en la cual se intenta reducir las fuerzas que mantienen a

la organización en su actual comportamiento. La idea de esta etapa es crear una

motivación en las personas para aceptar o buscar un cambio en la organización.

Cambio: Es la etapa en la cual se ejecutan los procesos a través de los cuales se

introducen los nuevos comportamientos. El objetivo de esta etapa es desplazarse desde

el estado anterior hacia un nuevo estado mediante la modificación de los hábitos,

valores, conductas y actitudes.



35

Recongelamiento: Esta es la etapa en la cual la organización se estabiliza en el nuevo

estado de equilibrio hacia el que fue desplazada. Se dice que el recongelamiento está

realizado cuando el nuevo comportamiento implementado pasa a formar parte de los

nuevos hábitos de la organización.

Existen diferentes tácticas para poder combatir la resistencia al cambio, dentro

de las cuales las más conocidas son: la comunicación, la participación y la negociación.

Cuando la comunicación es pobre o carece de veracidad en sus contenidos suele

debilitar el apoyo hacia el cambio por parte de los implicados y generar, en

consecuencia, una resistencia al mismo. Es por ello que es de gran importancia

mantener una comunicación fluida con los empleados a fin de ayudarlos a entender los

cambios, sus objetivos y los beneficios que el mismo acarreará. Esta comunicación debe

ser clara y su contenido creíble para generar una relación de confianza y una imagen de

credibilidad en quien comunica, evitando malos entendidos y que el proceso se

corrompa por la circulación de información errónea entre las personas. Por otro lado, la

participación de los empleados en la toma de algunas decisiones relacionadas con el

proyecto, evitará que los mismos se vuelvan en contra del proyecto en el que ellos

estuvieron participando y decidiendo. Es por esto que siempre se deben identificar a los

principales opositores del proyecto y escuchar con atención sus opiniones con el objeto

de hacerlos sentir partícipes del mismo y eliminar o reducir su fuerza opositora.

Finalmente se encuentra la negociación, que tiene como componentes a la

comunicación y la participación ya que ambas pueden ser utilizadas por el equipo que

lidera el cambio para intentar reducir la resistencia a la implementación de los cambios.

A continuación se presenta el resumen de las conclusiones de un estudio sobre la

resistencia al cambio tecnológico en las organizaciones durante el desarrollo de un

sistema de información en el área de Recursos Humanos [García, 2001]:

En la Tabla I se muestran los datos referidos a los índices de resistencia al

cambio promedio para cada una de las 6 empresas involucradas en el estudio, además de

un promedio general. Los Índices de Resistencia ala Cambio se definieron a partir de la

recolección de datos realizada y sus valores oscilan entre 0 y 168. La relación entre

dicho índice y la resistencia al cambio es inversa, o sea que a medida que el índice se

acerca más a 0, se habla de una mayor resistencia al cambio y a medida que se acerca

más a 168 se habla de una menor resistencia al cambio.



36

Empresa Índice de Resistencia

Expresión Cualitativa Índice de Resistencia Mínimo Registrado

1 144 Poca Resistencia 125 2 105 Mediana Resistencia 89 3 61 Mucha Resistencia 44 4 105 Mediana Resistencia 56 5 146 Poca Resistencia 144 6 143 Poca Resistencia 119

Promedio General

117,1 Poca Resistencia ---

Tabla II – Índice de Resistencia al cambio por el desarrollo de un S.I. en el área de RRHH

Los datos mostrados en la Tabla II reflejan que existen diferencias entre los

niveles de resistencia entre las empresas estudiadas, donde el nivel de resistencia varía

de acuerdo a la forma en que se implementó el proceso de cambio. Aunque el índice

promedio indica que hay poca resistencia al cambio en general, no se puede excluir el

dato de que el grupo seleccionado es muy heterogéneo en cuanto a la forma de

implementar el cambio y es por ello que no se deben perder de vista los índices

particulares de cada una.

La resistencia al cambio también tiene relación con los factores sociolaborales

(edad, sexo, nivel educativo, antigüedad, etc.). En la Tabla III se puede observar la

correlación entre el Índice de Resistencia al Cambio (IRC) y los factores sociolaborales.

Variables Relacionadas Índice de Correlación IRC y Edad 0,2 IRC y Sexo -0,1

IRC y Nivel Educativo 0,3 IRC y Cargo 0,2

IRC y Antigüedad 0,3

Tabla III – Relación entre el IRC y las variables Sociolaborales

De acuerdo a lo que se muestra en la Tabla III, no hay demasiada correlación

entre las variables sociolaborales y la resistencia al cambio, aunque un detalle a tener en

cuenta (y que resulta lógico) es que la resistencia al cambio tiene mayor correlación con

la antigüedad.

Finalmente se analizará la relación de la resistencia al cambio con los factores

ligados a la personalidad (Tabla IV) y ligados a la organización en si misma (Tabla V).



37

Empresa Índice Promedio Expresión Cualitativa

1 70 Mínima Resistencia 2 64 Poca Resistencia 3 34 Mediana Resistencia 4 63 Poca Resistencia 5 73 Mínima Resistencia 6 65 Poca Resistencia

Promedio General 62 Poca Resistencia

Tabla IV – Relación entre el IRC y los factores de la personalidad

Empresa Índice Promedio Expresión Cualitativa 1 73 Poca Resistencia 2 41 Mediana Resistencia 3 27 Mucha Resistencia 4 42 Mediana Resistencia 5 73 Poca Resistencia 6 60 Poca Resistencia

Promedio General 53 Mediana Resistencia

Tabla V – Relación entre el IRC y los factores organizacionales

Si bien en ambas tablas se muestra que no hay un alto nivel de relación entre los

factores de la personalidad y organizacionales respecto de la resistencia al cambio, sin

embargo se puede apreciar que los factores ligados a la organización, que son los que

generalmente se descuidan mas, son los que terminan teniendo un mayor peso con

respecto a la presencia de resistencia al cambio en la organización.

Aunque hay muchos factores que influyen en la resistencia al cambio que se

puede producir cuando se implemente un cambio en una organización, es necesario

recordar que, en gran medida, esto depende de las estrategias que se empleen para la

implementación de dicho cambio y luego de los demás factores relacionados.

De acuerdo a lo planteado, la resistencia al cambio es una de las consecuencias

de un manejo incorrecto del factor humano relacionado con un proyecto. Este manejo

ineficiente tiene su origen en la falta de habilidades por parte del líder para poder

gestionar correctamente este factor y lograr, de esta manera, evitar los problemas

causados por problemas personales entre los miembros del equipo o conflicto de

intereses entre las diferentes partes involucradas.

En la Tabla VI se puede observar un estudio realizado por el Standish Group

para determinar lo factores de éxito de un proyecto de TI [Standish Group, 1995] y

donde se muestran los porcentajes de cada factor sobre el total de respuestas obtenidas



38

en dicho estudio. Este estudio muestra que el 31 % de los proyectos son cancelados

antes de tiempo y que un 53 % sufre un desvío en sus presupuestos que ronda el 189 %

del presupuesto original.

Factores de Éxito de un Proyecto % de Respuestas 1. Participación del usuario 15,9 2. Apoyo de la gestión 13,9 3. Claridad de los requerimientos 13,0 4. Planificación adecuada 9,6 5. Expectativas realistas 8,2 6. Pequeños hitos dentro del proyecto 7,7 7. Personal competente 7,2 8. Sentido de pertenencia al equipo 5,3 9. Visión y Objetivos del proyecto claros 2,9 10. Trabajo duro y personal motivado 2,4 11. Otros 13,9

Tabla VI – Importancia de los factores de éxito de un proyecto.

De acuerdo al estudio realizado por el Standish Group, los recursos humanos no

se ubican en los primeros puestos entre los factores principales de éxito de un proyecto,

pero hay varios aspectos que se sitúan entre los diez mas importantes (personal

competente, sentido de pertenencia, trabajo duro y personal motivado) cuya la suma de

porcentajes (14,9 %) es considerable y muestra la importancia de los mismos.

Finalmente, en el artículo “Success or Failure: Human Factors in Implementing

New Systems” [Bruke, 2001] se presentan estudios de diferentes casos de

implementación de proyectos de IT, se indicaron los siguientes factores de éxito de un

proyecto que tienen relación con la administración de las personas:

� Participación activa de todas las áreas, desde las gerenciales hasta las

operativas.

� Realización de reuniones periódicas.

� Mantenimiento de la visión global del proyecto dentro de la organización.

� Identificación y control de los factores de fracaso.

� Fomento de la confianza en el personal.

� Capacitación correcta del personal.

Hasta aquí se han presentado los diferentes aspectos relacionados con los

proyectos de TI y los factores claves de éxitos de los mismos, pero no se ha hecho



39

mención de las metodologías y/o técnicas que se utilizan para poder administrar estos

factores.

En la siguiente sección se presentarán las técnicas más utilizadas actualmente y

se realizará un breve análisis de las características más importantes de cada una de ellas.

2.5- TÉCNICAS UTILIZADAS

2.5.1- SCRUM

Scrum [Schwaber, 2004] es una metodología de desarrollo ágil que se aplica en

proyectos en los cuales se trabaja con requisitos inestables y que requieren flexibilidad y

rapidez en el desarrollo. Scrum, más que una metodología de desarrollo de software, es

una forma de gestionar los grupos de programadores, ya que la idea fundamental de esta

técnica es fomentar el trabajo conjunto, con una misma dirección y objetivos. Además

esta herramienta permite realizar un seguimiento claro del avance de las tareas a realizar

por cada miembro del equipo de modo que el líder del mismo pueda tener un panorama

claro del progreso del trabajo.

Los principios de Scrum son:

� Para una nueva aplicación, los requerimientos no son totalmente conocidos hasta

que el usuario no haya utilizado la misma.

� Es imposible describir completamente un sistema iterativo.

� La incertidumbre es inherente e inevitable en el proceso de desarrollo de

aplicaciones.

Además de estos principios, Scrum tiene 3 elementos básicos que son: el “Sprint”, el

“Product Backlog”, el “Sprint Backlog”.

El “Product Backlog” es una lista con las funcionalidades que debe tener el

software que se está desarrollando. Esta lista debe estar ordenada por orden de

importancia de las funcionalidades comenzando por la más importante. En esta lista no

es necesario que figuren todas las funcionalidades, pero si se deben listar las mas

importantes.

De las funcionalidades listadas en el Product Backlog, se toman las más

importantes y se descomponen en una serie de tareas con las cuales se confecciona otra

lista denominada “Sprint Backlog” y que representa las tareas que se deberán ejecutar

en el próximo período, al cual se lo denomina “Sprint”. La duración de los sprints no



40

siempre es la misma e incluso puede ser diferente de acuerdo al momento del proyecto

en el que se esté.

La idea de Scrum es la de dividir el proyecto en varios sprints en cada uno de los

cuales se obtendrá como resultado una nueva versión del software que cumplirá con las

funcionalidades del Product Backlog abarcadas por el Sprint.

Según lo planteado por esta técnica, se propone tres etapas en las cuales tanto los

desarrolladores como los usuarios juegan un papel muy importante.

El proceso de Scrum se puede dividir en tres etapas (ver Figura 2):

1. Pre-Juego: En esta etapa se definen las funcionalidades que formarán parte del

Product Backlog y a partir de éste se define el Sprint Backlog que se utilizará en

el Sprint. Además, se define la arquitectura se realiza el diseño de alto nivel.

2. Juego: La etapa de juego es aquella durante la cual se desarrollan las tareas

definidas en el Sprint Backlog. Para poder realizar un seguimiento de la marcha

de las actividades a realizar en esta etapa se realizan reuniones diarias entre los

miembros del equipo, denominadas Stand Up Meetings, donde cada miembro

debe responder las siguientes tres preguntas:

� ¿Qué hice ayer?

� ¿Qué voy a hacer hoy?

� ¿Qué ayuda necesito?

3. Post Juego: Finalmente, en esta etapa se evalúan los resultados del Sprint una

vez finalizado el mismo. Aquí no sólo se verifica que se hayan cumplido con las

funcionalidades predefinidas para el Sprint sino que también se evalúan los

tiempos, el progreso del proyecto y de ser necesario se redefinen algunos

tiempos del proyecto. Si se trata de una iteración dentro del proyecto, se vuelve

a la Etapa 1 para planificar el próximo Sprint, en cambio si es la última iteración

se procederá a confeccionar toda la documentación necesaria para la

finalización del mismo.



41

Figura 5 – Esquema gráfico de la interacción entre las etapas de SCRUM

Como se mencionó antes, Scrum no es una metodología de desarrollo sino que es una

técnica que debe ser aplicada en conjunto con alguna metodología de desarrollo.

Generalmente Scrum suele aplicarse con desarrollo rápido tal como es el caso de la

Programación Extrema.

2.5.2- JOINT APPLICATION DEVELOPMENT (JAD)

JAD [Wood, 1995] es una técnica creada por IBM en el año 1978 cuya filosofía

consiste en hacer que los usuarios participen en forma activa en el proceso de desarrollo

de un producto software, fundamentalmente en la etapa de determinación y definición

de requerimientos.

En el ámbito de los sistemas de información y del desarrollo de software, JAD es

la implementación de lo que Henry Ford utilizó en la fabricación de automotores:

organizar cada uno de los componentes del proceso de fabricación de manera tal que un

automóvil pudiera ser fabricado en menor tiempo del que tomaría hacerlo con una línea

de montaje. Para el caso particular de los sistemas y proyectos de TI, el objetivo es

identificar lo que los usuarios realmente necesitan y, a continuación, establecer un

proceso que permita obtener un producto que satisfaga esas necesidades.

El problema que intenta solucionar esta técnica es, por un lado la brecha que

existe entre las prestaciones de los sistemas que se obtienen a través de un proceso

estándar y lo que los usuarios realmente necesitan, y por el otro reducir la demoras que



42

se producen muchas veces por la lenta comunicación entre los diferentes miembros del

equipo de proyecto e inclusive entre las partes interesadas del mismo.

Los talleres JAD están compuestos por una serie de de sesiones estructuradas en

las cuales:

� Todo el mundo se reúne en una habitación para hablar acerca del tema a

tratar.

� Todo el muerdo escucha lo que el resto del grupo tiene para decir.

� No hay demoras entre preguntas y respuestas y no se dejan temas

pendientes.

El Joint Application Development elimina muchos de los problemas de las reuniones

tradicionales ya que transforma las reuniones en talleres menos frecuentes, más

estructurados y más productivos. Además cada talles debe estar compuesto por un

equipo en el cual existen roles claramente definidos. Estos roles son:

� Sponsor: Es el encargado de patrocinar y proporcionar los recursos necesarios

para la realización del proyecto. Debe ser un miembro de la organización con

suficiente poder y jerarquía como para asegurar la continuidad del proyecto.

� Líder de Proyecto: Es el líder del equipo que lleva adelante la ejecución del

proyecto. Es el encargado de responder a las preguntas referidas a alcance,

tiempos, recursos y coordinación del proyecto. Debe participar en las reuniones

pero sin influenciar al resto de los participantes del taller.

� Usuarios Finales: Son los encargados de utilizar el sistema, es decir que

representan a los principales destinatarios del producto que se generará a partir

de los resultados de cada uno de los talleres realizados. Los usuarios finales son

los que conocen como será la interacción del sistema con el mundo real y su

conocimiento es fundamental para rectificar cualquier mala interpretación al

momento de definir los requerimientos del sistema o en cualquier otra etapa.

� Facilitador: Es el encargado de organizar y dirigir la reunión de modo que todo

el grupo se mantenga dentro de la agenda preparada para el taller. Además el

facilitador se encarga de identificar problemas que deben ser resueltos dentro del



43

taller y de asignar actividades al final de la reunión. Este rol solo coordina el

taller pero no contribuye con aportes de información en la reunión.

� Expertos en Documentación: Son los encargados de registrar todo lo ocurrido en

la reunión y generar la minuta/acta de reunión. Al igual que el facilitador no

aportan información a la reunión sino que simplemente aportan organización a la

misma.

� Observadores: Son personas que por algún interés en particular desean

presenciar la reunión pero no tienen participación en la misma. Generalmente se

trata de algunos miembros del equipo de proyectos tales como los

desarrolladores, quienes pueden tener interés en entender el proceso.

JAD debería abarcar todo el ciclo de vida de un proyecto de sistemas, pero para

el caso de grande proyecto es recomendable plantear un esquema incremental dentro del

cual se utilice JAD en cada uno de los incrementos.

Para que la aplicación de ésta técnica sea exitosa es necesario tener en cuenta

algunos factores, dentro de los cuales los más importantes son:

1- El objetivo de su aplicación debe estar claramente especificado y debe ser

compartido por todos los miembros del equipo JAD.

2- El equipo debe estar conformado por un grupo de personas que sea

representativo de todas las áreas involucradas en el proyecto.

3- Todos los miembros del equipo deben tener la misma responsabilidad y poder de

decisión dentro del mismo.

4- Se deben escuchar todas las ideas y considerarlas importantes hasta que se

demuestre lo contrario mediante un análisis de la misma.

5- No hacer talleres por el solo hecho de reunirse, los talleres solo se deben realizar

cuando hay algo realmente importante para tratar.

6- No debe transcurrir más de tres o cuatro semanas entre un taller y el otro.

Además es importante que en cada reunión cada integrante haya concluido las

tareas que se le asignaron en la reunión anterior.

7- Las decisiones se deben tomar por consenso.



44

Los beneficios fundamentales de esta técnica es que fomenta la comunicación

entre los involucrados en el proyecto, crea consenso y sentimiento de pertenencia entre

quienes participan en los talleres y como consecuencia de ello permite mejorar la

calidad del diseño haciendo que las soluciones sean transversales a toda la organización.

2.5.3- PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING )

La Programación Extrema [Beck, 1999] es una metodología de desarrollo rápido

basada en los principios de simplicidad, comunicación, retroalimentación y coraje y fue

diseñada para ser utilizada por equipos pequeños que necesitan realizar desarrollo de

software rápido y en un entorno donde los requerimientos varían con mucha frecuencia.

XP propone una fuerte interacción entre el equipo de desarrollo y los usuarios finales

del sistema, llegando a proponer que un representante del cliente trabaje en forma

conjunta con el equipo de desarrollo. También propone el trabajo de a pares y las

reuniones frecuentes para evaluar el estado y avance de las diferentes actividades.

La programación extrema propone doce prácticas o actividades que el equipo de

proyecto debe realizar día a día, las cuales tienen su origen en prácticas muy conocidas

y aplicadas en la ingeniería del software. Estas doce prácticas son:

1. Juego de Planificación: La idea de esta práctica es la de dividir la funcionalidad

de un proyecto en varios fragmentos mas pequeños denominados “Historias”.

Estos fragmentos se definen en común acuerdo con el cliente y luego se prioriza

cada uno y se realizan las estimaciones correspondientes.

2. Entregas Frecuentes: Se debe presentar una nueva versión del sistema tan

pronto como sea posible de modo que se aporte un nuevo valor agregado para el

cliente. La idea de esta práctica es fomentar y maximizar la retroalimentación de

modo que se pueda controlar el proyecto y la evolución de los requerimientos

más fácilmente.

3. Diseño Simple: El sistema debe ser lo mas sencillo posible siempre que cumpla

con las necesidades del cliente. La idea de tener un diseño sencillo es evitar las

complicaciones que podrían generar las futuras modificaciones sobre una

funcionalidad en particular.



45

4. Pruebas Automáticas: Se deben diseñar pruebas automáticas de modo que se

puedan ejecutar en cualquier momento sin necesidad de insumir demasiado

esfuerzo cada vez que se debe realizar una prueba.

5. Integración Continua: Para evitar los trastornos y problemas que se producen

cuando se realiza una integración de código al final del proyecto, se propone

realizar una integración continua (diaria, cada hora, etc.) de modo que se

minimicen los problemas que se pueden presentar en esta etapa al final del

proyecto.

6. Refactorización: La refactorización consiste en modificar el diseño de un

módulo pero sin afectar su comportamiento externo. Esto es posible siempre que

se realice un diseño sencillo que permita ser modificado para compatibilizar el

mismo con el diseño de otros módulos.

7. Programación de a Pares: La programación de a pares consiste en que dos

personas trabajen sobre una misma computadora compartiendo el desarrollo del

código. La idea de esta práctico es por un lado mejorar la calidad del código que

se desarrolla (uno escribe y el otro puede controlar lo que se hacer), y por el otro

fomentar la comunicación dentro del equipo de desarrollo del proyecto.

8. Propiedad colectiva del código: Esta práctica se aplica para evitar cuellos de

botella, es decir que se busca que todos los desarrolladores conozcan la mayor

parte del código de modo que al memento de realizar mantenimiento del mismo

cualquiera pueda hacerlo. Además esta práctica facilita la transferencia de

conocimiento entre los miembros del equipo de desarrollo.

9. Semana de 40 Horas: Los programadores cansados son más propensos a

cometer errores, por eso se sugiere que la semana laboral no debe exceder las 40

horas. Si esto no ocurre es porque algo dentro del proyecto está funcionando

mal.

10. Cliente en el Equipo: Uno de los pilares fundamentales de la XP es la

retroalimentación, es por ello que la participación de un cliente o usuario final



46

dentro del equipo permite que se agilice la comunicación y que la

retroalimentación sea más rápida.

11. Metáfora: Las metáforas representan la manera en que los programadores y el

cliente pueden entenderse ya que a partir de la utilización de las mismas se crea

un lenguaje común entre ellos.

12. Estándares de Codificación: Los estándares de codificación permiten que todo

el equipo encare la producción de código respetando ciertos lineamientos, lo

cual se traduce en código más fácil de mantener.

Esta metodología, como se puede ver, hace mucho hincapié en el trabajo en

grupo. Los desarrolladores, los clientes y los administradores son todos partes de un

mismo equipo dedicado a la producción de software de calidad. XP se parece a un

rompecabezas, donde cada una de las piezas por separado no significan nada pero

cuando se combinan permiten ver un cuadro completo.

2.6- RESUMEN

A partir de todo lo estudiado, el próximo capítulo centrará su atención en

analizar cada técnica y metodología mencionada (SCRUM, XP, PMBOK, JAD) desde

el punto de vista de la administración de personas, a fin de poder identificar los puntos

fuertes y débiles de las mismas y, a partir de esto, plantear claramente el objetivo del

presente trabajo.

CAPITULO

III

PLANTEAMIENTO

DEL PROBLEMA



49

3.1- LOS PROYECTOS DE TI Y LAS PERSONAS

En el capítulo anterior, cuando se analizó la influencia de la resistencia al

cambio a través del estudio de un caso presentado por el Standish Group [Standish

Group, 1995] referido a la implementación de un sistema de recursos humanos, y a

partir de ello se confeccionó una lista de los principales factores que influyen en el

proyecto. Esta lista incluye los siguientes ítems:

� Participación del usuario

� Apoyo de la gestión

� Claridad de los requerimientos

� Planificación adecuada

� Expectativas realistas

� Pequeños hitos dentro del proyecto

� Personal competente

� Sentido de pertenencia al equipo

� Visión y Objetivos del proyecto claros

� Trabajo duro y personal motivado

A partir del estudio de los puntos antes enumerados resulta que muchos de los

mismos tienen estrecha relación con las personas que están involucradas en el proyecto

(Participación del usuario, Expectativas realistas, Personal competente, Sentido de

pertenencia al equipo y Personal motivado). Algunos de ellos están más orientados

hacia las responsabilidades que le competen al área de Administración de Recursos

Humanos (como por ejemplo reclutar personal competente) y por ende no tienen gran

dependencia de la dirección del proyecto. Pero otros escapan a las competencias de

Recursos Humanos y recaen directamente sobre los encargados de llevar adelante la

dirección del proyecto y es en este aspecto donde se centrará la atención en el presente

trabajo.

Así se mencionó previamente los factores relacionados con la administración de

personas que influyen en el éxito de un proyecto, también se deben considerar los

aspectos que la dirección del proyecto debe tener en cuenta para encarar y llevar

adelante en forma exitosa dichos factores. En otras palabras, cuales son las

características que debe tener un líder de proyecto para poder gestionar en forma

correcta los factores claves de éxito relacionados con el manejo de personas. En este



50

sentido, previamente se mencionó como características fundamentales para un líder a las

siguientes:

� Inteligencia Emocional

� Empatía y Confianza

� Proactividad

� Asertividad

� Motivación

� Trabajo en Equipo

� Liderazgo

� Comunicación Efectiva

� Negociación

Cada una de estas características afectan en forma directa a la forma en que se

lleva a cabo la gestión de un proyecto de IT ya que la inteligencia emocional es la que le

permitirá al líder manejar la motivación del equipo, incentivarlo y entender las

necesidades de cada uno de los miembros del equipo. De esta manera se pueden evitar

los efectos negativos de tener un equipo cuyo rendimiento se ve degradado, por

ejemplo, porque no todas las expectativas de sus miembros fueron cubiertas o porque

hay necesidades no satisfechas y no identificadas por el líder.

Relacionado con la inteligencia emocional, también se encuentra la confianza, es

decir, la capacidad del líder de generar confianza en los integrantes del equipo de modo

que los mismos se sientan seguros de poder plantear sus dudas o inquietudes sin el

temor de ser juzgados o de recibir alguna represalia por ello. Además está la empatía,

que es la capacidad del líder de entender y vivenciar las necesidades que se le plantean

y poder entender de mejor estos planteos.

Entro otras características, de las mencionadas anteriormente, y que no son

menos importantes están la asertividad, la negociación y la comunicación efectiva. Estas

características tienen más relación con la forma en que el líder puede lograr que el

equipo cumpla con ciertas pautas o se encamine en cierto rumbo de acuerdo a las

necesidades del proyecto. La comunicación efectiva es fundamental para evitar los

malos entendidos y las suspicacias que se despiertan cuando los lineamientos a seguir

dentro del proyecto no están claramente especificados.



51

Finalmente se encuentran la motivación, la proactividad y el trabajo en equipo,

que son características que están netamente relacionadas con la forma en que se realizan

las actividades del equipo. Es necesario que el líder motive al equipo, fomente la

proactividad y el trabajo en equipo de modo que cada una de las actividades que se

llevan a cabo se vean enriquecidas por el aporte de todo el equipo.

Si bien hasta el momento se ha hablado solamente de las características a

cumplir por parte del encargado de liderar el equipo de trabajo de un proyecto, no se

debe dejar afuera a los demás integrantes de dicho equipo. Estas personas también

deben cumplir ciertos requisitos que resultan tan importantes y vitales para el proyecto

como las habilidades del líder.

En el caso de los integrantes del equipo de proyecto, se debe poner especial

atención en las características que tienen relación con el factor humano pero que,

además, están relacionadas con el rol que cumplirá dentro del equipo. Es por ello que el

conjunto de características se reduce en cada caso de modo que, por ejemplo hay casos

en los que las habilidades ligadas con el liderazgo no son necesarias. El presente trabajo

se enfocará solamente en las características relacionadas con el factor humano ý en las

técnicas para poder administrar correctamente las mismas. Pero no se profundizará en la

definición de puestos.

3.2- EL SOFTWARE Y LAS PERSONAS

Dentro de los proyectos de TI que se llevan a cabo dentro de las organizaciones,

hay un gran número que involucra la implementación de algún tipo de software. En

algunos casos dicho software es desarrollado a medida para la organización, mientras

que en otros el producto se adquiere y se configura de acuerdo a las necesidades del

negocio.

En cualquiera de los casos ya se ha estudiado que las etapas que componen el

ciclo de vida del software son:

� Investigación Preliminar

� Determinación de Requerimientos

� Diseño del Sistema

� Desarrollo del Software

� Prueba del Sistema

� Implantación y Evaluación



52

Cada una de estas etapas también requiere de habilidades para el manejo del

factor humano. En la investigación preliminar es muy importante la capacidad de

comunicación ya que en esta etapa el manejo de los involucrados en el proyecto,

especialmente los stakeholders y sponsors es vital, ya que si el mismo resulta viable,

será el sponsor quien respaldará la ejecución del proyecto. Por su parte los stakeholders

son uno de los roles claves para obtener parte importante de la información necesaria

para confeccionar la lista de requerimientos.

Durante la determinación de requerimientos se vuelve a tornar muy necesaria la

capacidad de realizar una comunicación eficiente y efectiva. La empatía y la confianza

también son importantes porque cuanto mejor sea el clima y la confianza generada con

los principales actores de esta etapa (usuarios claves y stakeholders), mejor y mas útil

será la información que se obtenga para especificar los requerimientos del producto

software. Finalmente la negociación juega un papel vital en esta etapa, sobre todo al

momento de determinar que aspectos serán considerados por el producto y cuales no.

En la etapa de diseño, las características más importantes son la inteligencia

emocional, la asertividad y el trabajo en equipo. Las dos primeras características están

netamente ligadas a la forma en que se enfocará todo el trabajo de diseño, por lo que

cuanto mas asertivos y emocionalmente inteligentes sean quienes llevan a cabo la

ejecución de esta etapa, mejor será el resultado logrado. Por su parte el trabajo en grupo

enriquecerá el resultado gracias al ya conocido emergente sistémico.

Durante la etapa de pruebas es muy importante la inteligencia emocional y la

proactividad de modo que las pruebas resulten lo mas representativas posibles del uso

que se le dará finalmente al producto.

En la última instancia se encuentra la implantación y evaluación. Esta etapa es la

que quizás requiere mayos entrenamiento y capacidades para administrar el factor

humano, ya aquí un mal manejo de este factor puede resultar letal para la

implementación y puesta en marcha del producto. La empatía, la confianza, la

asertividad, la negociación y la motivación deben estar centrados fundamentalmente en

conseguir la aceptación completa del producto por parte de los usuarios finales.

Mientras que el trabajo en grupo, el liderazgo y la proactividad deben centrarse más

específicamente en asegurarse que el producto implementado funcione de acuerdo a los

estándares fijados para el mismo. De este modo si se logra una mejor aceptación del



53

producto por parte de los usuarios y, si además dicho software cumple con todos los

requisitos solicitados, las probabilidades de éxito se incrementan considerablemente.

De este modo resulta claro que cuando existe desarrollo de software en un

proyecto de TI, también es de vital importancia la correcta administración de las

variables relacionadas con la administración de personas. Pero no se debe dejar sin

considerar que en todos los proyectos se debe respetar una estructura que indique como

llevar adelante el mismo desde su concepción hasta la implementación.

Es en este contexto donde el concepto de “Mejores Prácticas” comienza a

transformase en otro punto importante a considerar.

3.3- LAS MEJORES PRÁCTICAS

Se entiende como mejores prácticas al conjunto de acciones que guardan cierta

coherencia entre si y que han sido aplicadas en forma exitosa en ciertas situaciones

determinadas y que se espera que, aplicadas en contextos similares, obtengan los

mismos resultados. En general las mejores prácticas suelen obtenerse a partir de

actividades que se realizaron en un determinado proyecto y cuyos resultados fueron

exitosos, y si bien guardan cierta coherencia entre sí, muchas veces dependen de las

tendencias y de la moda que se encuentre en auge en el momento en que se aplican, por

lo cual puede suceder que existan conjunto de mejores prácticas que resulten

contradictorias entre sí. De todos modos y a pesar de las críticas que se les puedan

resultar, han representado una herramienta muy útil para plasmar la experiencia de las

personas que han participado en diferentes proyectos con diversos resultados, de modo

que muchas de estas experiencia resultan sumamente útiles para quienes se embarcan en

la tarea de tener que encarar proyectos con características similares.

Las mejores prácticas son ampliamente utilizadas en diferentes áreas, desde la

informática hasta la medicina, pasando por la administración, las organizaciones

públicas, los sistemas educativos y la gestión de proyectos. En general este tipo de

prácticas son utilizados por las organizaciones para estandarizar sus procesos de modo

que se creen modelos a utilizar dentro de dicha organización.



54

3.4- RESUMEN

De todo lo antes dicho, se desprende que algunos factores claves para el éxito de

cualquier proyecto de TI están vinculados en mayor medida a aspectos organizacionales

más que a aspectos relacionados con la tecnología. Es importante contar con las

personas correctas y tener los procesos claramente definidos para poder tomar y

gestionar correctamente el proyecto. También es importante obtener la aprobación de

todos los actores involucrados, definir claramente los roles, conocer cómo se tomarán

las decisiones, y tener claramente definidos cuáles son los resultados que se consideran

críticos para que el proyecto resulte exitoso. Es aquí donde la administración de las

personas cobra vital importancia y donde se encuentran los motivos para analizar

detalladamente las acciones a realizar para evitar un fracaso en el proyecto.

En cuanto a técnicas y metodologías, es claro que las más utilizadas actualmente

no logran abarcar todos los aspectos ya que cada una provee una solución parcial al

problema de la administración del factor humano. Es por ello que se propone relevar las

diferentes técnicas y herramientas utilizadas actualmente (en diferentes casos y

proyectos variados) y organizar las mismas en un modelo de “mejores prácticas”.

La idea de dicho modelo es proveer, a los líderes de proyectos, diferentes

alternativas según las características del proyecto a coordinar y transformar dicho

modelo en una guía práctica que permita mejorar el manejo de las personas

involucradas en un proyecto de IT y reduzca los riesgos asociados con ellas.

El planteo de organizar un modelo de “mejores prácticas” se basa en el hecho de

que en los últimos años las mejores prácticas han cobrado vital importancia; y es por

ello que diferentes instituciones se han dedicado a elaborar modelos para las diferentes

áreas tales como Administración de Proyectos [PMI, 2004], Gestión de servicios de IT

(ISO20000) [ISO/IEC, 2005], Ingeniería de Software [ISO/IEC, 2008], Calidad [ISO,

2000], Manejo de Stock [Monden, 1998] e incluso algunos autores han tomado como

propias algunas prácticas aprendidas a través de su experiencia.

CAPITULO

IV

SELECCIÓN DE

MEJORES

PRÁCTICAS



57

4.1- INTRODUCCIÓN

En éste capítulo se analizarán todas las prácticas relacionadas con la

administración de personas. Dichas prácticas se clasificarán de acuerdo a si las mismas

son utilizables en cualquier instancia del proyecto o si solamente son aplicables en

algún momento en particular. De este modo se establecerán dos grupos de prácticas:

Prácticas Genéricas y Prácticas Específicas.

En primer lugar se analizarán las Prácticas Genéricas. Estas prácticas se

denominan genéricas debido a que se podrán aplicar en cualquiera de los grupos de

procesos del proyecto, variando simplemente algún aspecto en particular para poder

adaptarla mejor cada grupo. Luego se presentarán las que se denominarán Prácticas

Específicas. Éste grupo de prácticas son aquellas que sólo tienen aplicación en algún

grupo de procesos en particular pero no al resto de los grupos.

4.2- PRACTICAS GENÉRICAS

En esta sección se analizarán las características de aquellas prácticas

relacionadas con la administración de personas y que son aplicables a los

diferentes grupos de procesos dentro de un proyecto de IT. Las prácticas que se

analizarán son las siguientes:

� Reuniones

� Wikis

� Foros de discusión

� Listas de Correo

� Mensajería instantánea

4.2.1- REUNIONES

Para asegurar el éxito de una reunión [Wong, 2007], es fundamental la correcta

organización de de la misma a fin de que se asegure la participación de cada uno de los

presentes y se propicie el ámbito para que expresen sus ideas y necesidades en relación

con el proyecto. Una habilidad muy importante con la que deben contar los gerentes y

líderes de proyectos, es la de poder facilitar (coordinar) correctamente las reuniones en

las cuales cumpla con dicho rol.

La facilitación es el arte de dirigir las reuniones de un equipo en forma eficaz.

Esto implica diseñar y utilizar los procesos que permitan al equipo arribar, en tiempo y



58

forma, a las conclusiones deseadas a través del debate. Un buen facilitador de reuniones

deberá tener conocimientos sobre herramientas y técnicas de reuniones, dinámicas de

grupos y manejo de personas. Una buena facilitación de un equipo ayudará al mismo a

tomar buenas decisiones.

Para muchas personas, realizar en forma correcta una reunión se resume

simplemente a que el equipo se centre en una agenda prefijada y distribuida

previamente a cada participante, alcanzar el objetivo definido para el encuentro y

conseguir un lugar confortable para llevar a cabo la reunión. Pero, la mayoría de los

facilitadores se olvida de uno de los componentes más importantes a tener en cuenta: el

proceso de facilitación.

En general se presupone que una reunión fracasa debido a que no se ha

preparado correctamente la agenda o porque no ha habido un comportamiento adecuado

por parte de los participantes. Sin embargo nadie repara en el hecho de que la mayoría

de las reuniones no fracasa por los aspectos antes mencionados sino que lo hacen por un

solo motivo: un proceso de coordinación pobre.

En algunos casos suele ocurrir que aun con un proceso de facilitación malo, se

alcancen los objetivos de la reunión, sin embargo esto puede hacer que cada reunión

resulte lenta, aburrida, frustrante y altamente propensa a cometer errores en la toma de

decisiones. La mayoría de los coordinadores insume mucho tiempo en redactar

correctamente la agenda del día y organizar los contenidos de la reunión, pero deja

completamente de lado la elección y armado del proceso por el cual se facilitará dicho

encuentro. En algunos casos, el no armado del proceso se debe simplemente al

desconocimiento de su importancia, pero en otros se lo deja de lado debido a que se lo

considera como una pérdida de tiempo. Sin embargo se ignoran las ventajas de utilizar

un buen proceso de facilitación.

La elección de un proceso de facilitación adecuado ayuda al equipo a generar

mejores ideas, maximiza la producción de soluciones y facilita la toma de decisiones

dentro del equipo de trabajo. El facilitador debe centrarse en diseñar el proceso de modo

que soporte los objetivos planteados para la reunión, explicar y dejar en claro el proceso

a todos los miembros del equipo de trabajo, ejecutar dicho proceso y finalmente

verificar que tan bien está funcionando el mismo. El secreto de todo proceso es lograr

que se canalice toda la energía en alcanzar el objetivo deseado, lo cual en algunos casos

puede resultar muy poco sencillo.



59

A continuación veremos algunos aspectos importantes que deben ser tenidos en

cuenta al momento de determinar el proceso a utilizar en una reunión:

1. Dedicar el tiempo que sea necesario para organizar las actividades y dejar

en claro los objetivos y contenidos del encuentro: Muchas veces se considera

que dedicar demasiado tiempo en estas actividades es una pérdida de tiempo,

sin embargo esto no es así. En muchos casos la ansiedad por comenzar a

trabajar y ponerse “manos a la obra” hace que no se comprendan

completamente la metodología de trabajo y los objetivos de la reunión. Esto

puede generar conflictos y malos entendidos ya avanzada la reunión.

Es conveniente que se dedique este tiempo al comienzo del encuentro para

luego evitar pérdidas de tiempo en aclaraciones y resoluciones de conflictos

derivados de una mala comprensión de las pautas de la reunión.

Para comprender mas en profundidad este aspecto, se puede hacer una

analogía con un proyecto cualquiera en el cual, si no se insume el tiempo

suficiente en realizar una planificación correcta y detallada del mismo y no

se deja en claro cuál es el objetivo de dicho proceso, probablemente

fracasará. Lo mismo ocurre con las reuniones si no se planifican y aclaran

los objetivos correctamente.

2. Monitorear constantemente el proceso: Muchas veces se da el caso de que

un proceso planificado para facilitar una reunión no funciona como se

esperaba. Esto suele ocurrir cuando hace que las personas comiencen a

preocuparse por otros aspectos y se alejen del objetivo principal del

encuentro. Es importante evitar que el proceso maneje los contenidos.

Siempre debe fijarse primero los contenidos de la reunión y luego

seleccionar el proceso que mejor se adapte a los mismos.

Cuando se verifique que la energía del grupo decae, la atención se dispersa o

se centra en temas secundarios, o se comienza a trabajar sobre demasiados

supuestos, entonces es momento de verificar si no es necesario realizar

cambios en el proceso. Hay que tener muy en claro que no siempre el mismo

proceso será útil en todos los casos.

3. Trabajar en un tema a la vez: Una de las situaciones que se suelen dar mas a

menudo en las reuniones de equipos es cuando se están discutiendo mas de



60

un tema a le vez. Esto se suele dar cuando en el debate de un tema surgen

diferentes posturas ante lo cual, las personas que compartan opiniones

seguirán por un camino y el resto del equipo encarará otra alternativa o

incluso trataré de aclarar mejor el problema. Esto genera que en el mismo

instante de tiempo existan dos o más grupos discutiendo temas diferentes

sin que ello resulte notorio para todo el equipo, pero convirtiendo a la

reunión en algo inútil e improductivo.

Es muy importante que antes de comenzar una discusión sobre un nuevo

tema, se cierre correctamente la discusión del tema anterior. De esta manera

todo el trabajo se realiza en forma mas ordenada y se asegura que finalizado

el encuentro no habrán quedado temas sin definición.

4. Asegurarse de abrir y cerrar los debates en forma adecuada: En general las

reuniones se encaran como una discusión libre de temas de acuerdo a una

lista elaborada previamente y distribuida a los miembros del equipo. Si bien

este concepto es correcto, se deben tener en cuenta un ítem importante y que

ayuda a que la discusión sea ordenada: abrir y cerrar correctamente las

discusiones.

Generalmente en un encuentro de trabajo hay personas que poseen la

capacidad innata de ser creadores de temas o debates, mientras que hay otros

que tienden a ser los encargados de cerrar los temas y elaborar las

conclusiones correspondientes. El problema de estos extremos es que los

primeros tienden siempre a seguir analizando y escuchando opciones

mientras se pueda, en tanto que los segundos pretenden manejar una

solución lo antes posible. Es importante poder manejar este tipo de

comportamientos y lograr un equilibrio que permita abrir cada discusión,

generar el debate suficiente como para obtener una conclusión adecuada y

finalmente dar un cierre a dicho debate.

Tanto para iniciar una discusión como para cerrar la misma y obtener las

conclusiones, existen técnicas muy conocidas y sumamente útiles para cada

caso. A continuación listaremos las más conocidas y se hará una breve

exposición de su utilidad, pero no se entrará en el detalle de su

implementación ya que esto excede los límites del presente trabajo.



61

Técnicas para apertura de debates

Tormenta de Ideas (Brainstorming): Este es uno de los métodos más utilizados

para iniciar el debate de un equipo entorno a un tema en particular. La idea es

lograr que el equipo presente la mayor cantidad de ideas posible acerca del tema

a analizar y luego ir reduciendo la lista. En este proceso no se debe descartar

ninguna idea por mas ridícula que esta parezca, debido a que con el correr de la

discusión dicha idea puede terminar cobrando valor e importancia. La reducción

de la lista se deberá realizar en consenso con el grupo y, en especial, con la

aprobación de quien generó cada idea a eliminar.

Diagramas de Influencia: Los diagramas de influencia son un tipo de diagrama

que permite representar problemas de decisión tal y como las percibe quien debe

tomar la misma: acciones, incertidumbre y preferencias. Este diagrama permite

que todos puedan tener muy presentes cuales son los factores claves para el éxito

de un proceso. Además, permite analizar cual es la relación que existe entre

estos factores, de modo que se pueda identificar si existen dependencias entre sí

y poder tenerlas presentes.

Este tipo de diagrama permite crear una visión compartida de todos los procesos

que influyen en un proyecto, de modo que se puedan establecer prioridades para

cada factor y establecer un plan de trabajo para cada uno de dichos factores.

Diagramas Causa – Efecto: Este es un diagrama muy conocido y utilizado para

identificar cuales son las posibles causas que provocan un determinado efecto o

producen un resultado en particular. El objetivo de aplicar este tipo de diagramas

es obtener tantas causas como sea posible y que se considera, influyen en el

efecto que se está analizando. Esta técnica también incluye una tormenta de

ideas, ya que las causas se obtendrán a partir de una tormenta de ideas y luego se

estructurarán en forma ordenada en el diagrama según corresponda. La Figura 8

muestra un ejemplo de un diagrama de este tipo para analizar el bajo

rendimiento de un sistema.

Este tipo de diagramas es especialmente útil cuando se desea obtener la causa de

un determinado problema.



62

Figura 6 – Representación Ejemplo de un diagrama Causa - Efecto.

Técnicas para cerrar debates

Votación por Puntos: Esta es una técnica muy rápida y fácil de implementar en

los casos en que la discusión de un tema arroja una lista considerable de ítems, la

cual es necesario reducir. La técnica consiste básicamente en que a cada ítem se

le asigna un valor único que lo identifica unívocamente, luego se le pide a cada

uno de los presentes que exponga su opinión sobre cada ítem. Esto se realiza

para asegurarse de que todos los presentes han comprendido correctamente el

significado de cada uno de los puntos indicados. Una vez finalizada la ronda de

opiniones se reasigna una cantidad de votos a cada miembro. Esta cantidad se

obtiene dividiendo la cantidad de ítems por 3.

Una vez asignados los votos cada miembro asigna sus votos a algún ítem,

teniendo en cuenta que:

i. No se pueden asignar 2 puntos a un mismo ítem.

ii. Cada punto puede ir ponderado por importancia (de 1 a 3) por

ejemplo.

Luego de finalizada la ronda revotación sólo se eligen los ítems mas populares y

se pasa a una segunda ronda de votación con el mismo sistema. Esta técnica



63

resulta fácil de aplicar, rápida, divertida y es muy similar a la votación común y

corriente por lo cual es muy recomendable su aplicación.

Primero de Cinco: Esta es una técnica que su utiliza para poder ponderar una

serie de ítems que se están discutiendo en una reunión de equipo, asignando un

número a cada ítem, el cual indica el grado de acuerdo de cada miembro con

dicho ítem. El valor que se asigna se representa con los dedos de la mano, de

modo que el valor puede ir de uno a cinco. El significado de cada valor es el

siguiente:

• Cinco dedos significan "apoyo totalmente la moción"

• Cuatro dedos significan "doy mi apoyo"

• Tres dedos significan "no estoy totalmente de acuerdo con la

moción pero la acepto como válida "

• Dos dedos significan "Necesito que debatamos más esta moción"

• Un dedo significa "Estoy en contra de esta opción"

Ésta técnica permite revelar fácilmente cuáles son los puntos en los cuales el

equipo está de acuerdo y cuales necesitan ser debatidos con mayor profundidad.

Además logra que fluyan nuevas ideas, esto se da en los casos en que una

persona solo asigna uno o dos dedos a cada moción, tras los cual se puede

indagar sobre el porqué de este comportamiento y descubrir que la opción con la

cual éste miembro está totalmente de acuerdo no está en la lista y, de esta

manera, agregarla al debate.

Criterios de Selección: Aún después de un proceso de reducción de opciones,

nada garantiza que se llegue tan fácilmente a una decisión. Tal es el caso de que

no exista consenso alguno entorno a ninguna de las posibilidades analizadas. En

estos casos el equipo necesita que la toma de decisión se haga más explícita. Un

método eficaz para esto es el establecimiento de los denominados criterios de

selección.

Estos criterios se especifican a través de un cuadro que luego sirve al equipo

como base para tomar una decisión. Se trata de una lista de factores críticos a

considerar para hacer una selección entre diferentes alternativas.



64

Los criterios de selección son una herramienta sumamente útil para revelar lo

que motiva a las personas a elegir una alternativa por sobre la otra. La razón de

la falta de consenso puede deberse a diferencias en lo que la gente cree son los

factores más importantes en la toma de una selección. De modo que resulta de

gran utilidad hacer explícitos todos estos factores y, una vez logrado esto, el

equipo puede trabajar en desarrollar una combinación criterios a considerar para

tomar la decisión.

Normalmente, un cuadro criterios de selección se configura como una tabla en la

cual la primer columna contiene los criterios, y luego cada una de las

alternativas a lo largo de la fila superior. A cada alternativa se le asigna una

etiqueta y se puede describir más en detalle en una hoja aparte. Cada criterio

puede ser ponderado si es necesario, y cada una de las opciones valorada, por

cada criterio, con una escala de 1 a 5. En el ejemplo de puntuación en la Tabla

VII, la opción C recibió el más alto puntaje general (15) y la opción B la más

baja (11).

Alternativas Criterios Peso A B C D

Beneficios Económicos 50% 2 3 4 5 Relación costo Beneficio 25% 3 3 4 5 Capacidad de administrar riesgos 15% 2 2 3 2 Facilidad de implementación 10% 5 3 4 2 Total 12 11 15 14

Tabla VII – Ejemplo de cuadro se criterios de selección.

En algunos casos las puntuaciones finales de cada opción pueden tener

diferencias ínfimas, especialmente cuando la lista de criterios es corta. En estos

casos es conveniente ampliar la lista de criterios o bien utilizar los pesos de cada

criterio. En este último caso el cálculo del puntaje para la opción B sería:

B= (3 x 50) + (3 x 25) + (2 x 15) + (3 x 10) = 285

4.2.2- WIKIS

El término Wiki [Ebersbach, 2006] es de origen hawaiano y representa la

abreviatura de la palabra “Wiki Wiki” que significa “Rápido”. En términos de software



65

y tecnológicamente hablando, el término remite a un software para la creación de

contenidos en forma colaborativa.

Básicamente una wiki es un sitio Web en el cuál el contenido de las páginas

puede ser editado por múltiples usuarios mediante la utilización de un navegador Web

(browser). En este sitio los usuarios pueden agregar, modificar o eliminar información

en un mismo artículo que está compartido entre ellos.

La ventaja principal de una wiki es que permite crear páginas en forma

instantánea o mejorar el contenido de las mismas mediante la utilización de una interfaz

muy simple y fácil de utilizar por todos los usuarios (aunque no tengan demasiados

conocimientos de informática). Además, según como se defina la wiki, no es necesario

que los usuarios estén registrados para poder ver, modificar o agregar información a la

wiki o agregar una nueva página a la misma. Este tipo de páginas suelen crearse con la

idea de que sea fácil corregir los errores cometidos en lugar de intentar que sea difícil

cometerlos. Es por ello que la mayoría de las wikis tienen una parte donde se pueden

visualizar los cambios más recientes donde se puede encontrar los artículos modificados

(y las modificaciones hechas) dentro de cierto período de tiempo.

Desde el punto de vista de la comunicación dentro de un equipo de trabajo, la

wiki representa una perspectiva diferente sobre el manejo de las comunicaciones

internas. Esta herramienta permite controlar muy fácilmente la información del equipo

permitiendo que el conocimiento circule entre los diferentes miembros del mismo

manteniendo a todos mejor comunicados.

Tener una wiki en una Intranet permite desde compartir el listado de teléfonos y

direcciones de correo electrónico de los miembros de un equipo u organización, hasta

publicar mensajes sobre actividades varias (reuniones de trabajo, actividades

recreativas, etc.) incluso hasta compartir documentos de un proyecto en particular.

La wiki es una herramienta que fomenta principalmente el trabajo en grupo y el

compartimiento del conocimiento de todos los participantes, y es por ello que dentro de

un proyecto es recomendable poseer una Web de este tipo y fomentar su utilización.

Esta recomendación se basa fundamentalmente en el hecho de que la tendencia dentro

de los grupos de trabajo, y en la sociedad en general, es la de crear una cultura de

trabajo colaborativo y de conocimiento compartido y enriquecido por los aportes de los

diferentes participantes. Es en este escenario donde las wikis se transforman en una

herramienta vital para compartir información y hacer que todos los miembros de un



66

equipo estén al tanto de las comunicaciones y de las diferentes actividades y eventos

que se suceden dentro del proyecto.

4.2.3- FOROS DE DISCUSIÓN

Los foros de discusión son aplicaciones Web que permiten dar soporte al

intercambio de opiniones o discusiones en línea. Estas herramientas provienen de los

sistemas de noticias conocidos como BBS (Bulletin Board System) que tuvieron su

auge en las décadas del ‘80 y el ’90. Puede compararse a los foros con el sistema de

Chat, con la diferencia de que en el caso del foro el intercambio de opiniones no es en

tiempo real y que los mensajes persisten por un determinado período de tiempo

(dependiendo de cada foro).

Un foro de discusión permite compartir información sobre un tema en particular

o sobre un determinado grupo de temas. Permiten el intercambio de opiniones acerca de

un determinado tema (tópico) y favorecen la formación de comunidades que comparten

intereses comunes y que incluso, en algunos casos, hasta crean sus propias reglas de

convivencia e incluso un lenguaje propio acorde al tema que los reúne. En estos foros

existe lo que se denomina “moderador” que es la persona encargada de supervisar los

contenidos de los mensajes publicados y, si lo considera necesario, modificar o suprimir

dicho mensaje.

A diferencia de las wikis, los foros no permiten que cualquier usuario modifique

la información publicada por otro usuario, al menos que el mismo posea permisos

especiales como el caso del moderador que se mencionaba anteriormente.

Existen diversos tipos de foros y cada uno de ellos posee su propia forma de

publicar los mensajes y visualizar los mismos, aunque la mayoría de ellos opta por

agrupar todos los mensajes que se dan en respuesta a otro mensaje publicado con

anterioridad. La idea es mantener la coherencia de los mensajes y evitar el caos en la

publicación.

Al igual que en el caso de las wiki, la utilización de un foro como parte de un

proyecto de TI, facilita la comunicación entre los miembros del equipo y es

especialmente útil en los casos en que diferentes grupos del mismo proyecto se

encuentran en ubicaciones físicas (edificios) diferentes por lo que resulta engorroso

tener que movilizarse para hacer una consulta breve (y que telefónicamente sería difícil



67

de hacer). También ayuda a lograr una mayor informalidad en las relaciones y facilitar

la relación entre los miembros de un equipo. Esto último es posible, por ejemplo,

cuando sucede que en respuesta a un post aparece algún integrante sin demasiada

relación con el resto y a partir de allí comienza a familiarizarse con el resto.

4.2.4-LISTAS DE CORREO

Las Listas de correo son una forma especial de utilizar el correo electrónico a

través de la cual se facilita la distribución masiva de contenidos en forma simultánea a

una gran cantidad de usuarios mediante Internet. Para ello solo se envía el correo

electrónico con el contenido que se desea distribuir (imagen, texto, documento, etc.) a la

dirección que corresponda a la lista y, automáticamente, todos los suscriptos a la lista

recibirán dicho mail con todo su contenido.

Estas listas son esencialmente útiles para mantener informados a los integrantes

de un grupo acerca de las novedades que se producen dentro del mismo o para enviar

información de interés. En los últimos años las listas de correo se han transformado en

una herramienta corporativa y especialmente útil para dar soporte técnico a usuarios y

realizar discusiones de carácter técnico a través de Internet.

Junto con los foros, las listas de correo ha ido invadiendo el terreno de los

denominados “canales de noticias”. Dentro de una empresa, la utilidad de esta

herramienta está dada por:

� La facilidad para discutir temas tales como la elección de una u otra

alternativa de acción.

� La posibilidad de tener un registro cronológico del orden en que se

generaron los temas y el momento en que participó cada usuario.

� La facilidad para notificar a un grupo de personas sobre un tema en

particular en muy poco tiempo.

� Es el medio ideal para comunicaciones del tipo pregunta-respuesta.

Además junto con la wiki, los foros y la mensajería instantánea y el correo electrónico

tradicional, constituye el pilar esencial y básico para la comunicación moderna dentro

de una organización.

Todos los beneficios listados anteriormente y enunciados para una empresa

entera, son aplicables a un proyecto de IT, ya que recordemos que definimos a un



68

proyecto como “una empresa temporal” por lo que todos los conceptos aplicables a una

empresa son aplicables también a un proyecto. De todo este es que se desprende la

importancia de contar con una lista de correo para poder mejorar la comunicación y

facilitar la administración del factor humano dentro de un proyecto de TI.

4.2.5- MENSAJERÍA INSTANTÁNEA

La mensajería instantánea es una herramienta que se diferencia del correo

electrónico en el hecho de que las conversaciones se realizan en tiempo real. Permite a

cada usuario visualizar el estado de los demás, compartir archivos, e incluso realizar

conferencias de voz. Hoy por hoy la mensajería instantánea ha ganado muchísimo

terreno en el área de las comunicaciones gracias a la flexibilidad que presenta para

compartir contenidos e información. Además, posee la ventaja de poder entablar una

comunicación con cualquier persona en cualquier lugar del mundo de modo que las

distancias y los costos dejan de ser un problema.

En la actualidad hay empresas en las que la comunicación entre sus miembros es

casi totalmente vía mensajería instantánea, como es el caso de las empresas que trabajan

con teletrabajo, donde las personas trabajan desde sus hogares y se comunican con sus

compañeros y su jefe mediante el sistema de mensajes instantáneos. Esto demuestra el

nivel de incursión de esta herramienta, la gran utilidad que aporta y como puede resultar

mucho mas amigable que, por ejemplo, un teléfono.

Sin embargo en muchas empresas el uso de este tipo de herramientas en muchas

empresas está (o estaba) limitado debido a los problemas de seguridad que las mismas

exhibían, haciendo vulnerable a todo el sistema de la organización. Para contrarrestar

este problema, empresas como Microsoft y Yahoo se dedicaron a desarrollar

herramientas de colaboración en tiempo real que disminuyan los riesgos empresariales

en materia de seguridad. Es entonces como aparecen nuevas herramientas de mensajería

instantáneas muy simples de utilizar y muy seguras desde el punto de vista informático.

Es por ello que hoy por hoy, los problemas de seguridad informática ya no son

un motivo de negativa para el uso de esta herramienta y, mucho menos, si se analizan

las ventajas de la misma.



69

Dentro de un proyecto de IT se considera importante contar con una herramienta

de este tipo, sobre todo en aquellos casos donde hay ubicaciones físicas muy distantes y

donde resulta difícil coordinar una reunión personalmente.

Como con cualquier herramienta, hay que ser racionales con la aplicación y uso

de las mismas, es importante recordar que los extremos no son buenos. Siempre se debe

tener en cuenta que tanto las wikis como los foros, las listas de correos y las

herramientas de mensajería instantáneas deben usarse con precaución y teniendo

presente que no deben transformarse en la única vía de comunicación dentro de un

proyecto. No resulta conveniente que los mensajes en los foros o un mail a una lista

termine reemplazando a las reuniones diarias o de avances. La idea es que estas

herramientas fomenten la interacción y el intercambio de opinión entre los miembros

del equipo, pero no que se transformen en la única vía de comunicación.

4.3- PRACTICAS ESPECÍFICAS

En esta sección se analizarán las características de aquellas prácticas que se

pueden implementar solamente en algunos de los grupos de procesos dentro de un

proyecto de IT y que están relacionadas con la administración del factor humano. Las

prácticas que se analizarán son las siguientes:

� Comités de Desarrollo

� Programación de a Pares

� Comités de Usuario

� Grupos de Apoyo

� Mesa de Ayuda

� Estructura Desglosada de Trabajo

� CPM

� PERT

� Diagramas de Gantt

� COCOMO

� Puntos de Función

� Técnica de Grupo Nominal

� Técnica Delphi

� Análisis Estadístico



70

4.3.1- COMITÉS DE DESARROLLO

Se define como comité de desarrollo [Gurmendi, 2006] a aquel encuentro donde

participan parte del equipo de proyecto y un grupo de usuarios expertos en las funciones

de la empresa afectadas por el proyecto. El objetivo de este comité es el de validar cada

uno de los requerimientos del sistema, tanto funcionales como no funcionales. Quedan

fuera de esta lista aquellos aspectos técnicos que tengan que ver con, por ejemplo, la

tecnología a utilizar. También forma parte de las decisiones que toma este comité la

validación de las interfases como así también de los circuitos administrativos que se

definan o modifiquen como parte del proyecto.

Este tipo de comité tiene la ventaja de que es aplicable a cualquier tipo de

proyecto de TI, desde aquellos que implican desarrollo de algún producto software hasta

los que solo implican la implementación de una nueva tecnología. Este comité debe

estar conformado de la siguiente manera:

� El líder del Proyecto.

� Un grupo de usuarios claves (Key Users) con conocimientos avanzados

sobre las tareas afectadas por el proyecto.

� Uno o dos integrantes del equipo con perfil y conocimientos sobre la

tecnología que se utilizará para llevar adelante el proyecto.

� Dos integrantes del equipo de proyecto con perfil de analista funcional o

similar.

� Un integrante del equipo encargado de documentar lo sucedido en el

comité y que confeccione el acta correspondiente.

La cantidad de usuarios no debería ser menor a tres ni mayor a ocho. Este

número está basado en el hecho de que ya que si son menos de tres es difícil que esos

usuarios tengan una visión completa de los procesos involucrados en el proyecto. En

cuanto a la cantidad máxima se debe tener en cuenta que cuanto mayor es la cantidad de

involucrados mayor será el esfuerzo requerido para lograr unificar posturas y lograr

consenso respecto de los temas tratados.

Es necesario remarcar que los usuarios que participan en estos comités no deben

variar de un comité a otro. Debe existir una permanencia de las personas que integran

este grupo para que se mantenga la coherencia en cuento a las decisiones que se toman.

En aquellos casos que se considere necesario la presencia de algún usuario más, por

algún tema particular, se lo puede incluir excepcionalmente en dicho comité.



71

En lo que respecta ala frecuencia con que se deben realizar, esta variará de

acuerdo con el avance del proyecto. Inicialmente, se recomienda que estas reuniones se

realicen cada 15 días o semanalmente (de acuerdo a los avances del equipo y las

necesidades de aprobación) ya que en las primeras instancias de la ejecución es donde

se confecciona y valida la lista de requerimientos y se validan las interfaces. A medida

que avance el proyecto estas reuniones se planificarán con una frecuencia menor según

se considere necesario.

Además de las reuniones, donde los participantes se ven “cara a cara” y discuten

o presentan los temas por los cuales fueron convocados, existen otras herramientas que

resultan particularmente útiles para agilizar y fomentar la comunicación dentro del

equipo de proyecto, sobre todo cuando se trata de temas que no ameritan la realización

de una reunión para su discusión. Además, estas herramientas sirven como

complemento a las reuniones antes planteadas para conseguir una comunicación

eficiente.

Dentro de estas herramientas las más importantes y útiles para un proyecto son:

el foro de discusión, las wikis, las listas de correos y la mensajería instantánea.

4.3.2- PROGRAMACIÓN DE A PARES

La programación de a pares [Beck, 1999] es un concepto utilizado en el mundo

de la programación extrema y que, si bien está mas específicamente orientado al

desarrollo de software, también resulta importante su inclusión dentro de la lista de

técnicas propuesta. Esto se basa fundamentalmente en dos aspectos: el primero de ellos

es que las técnicas a utilizar para la administración de personas dentro de un proyecto de

TI deben cubrir todos los niveles dentro del proyecto, o sea desde la coordinación hasta

quienes ejecutan cada tarea. El segundo aspecto es que la mayoría de los proyectos de

tecnología de la información incluyen el desarrollo o modificación de un producto

software, razón por la cuál nuevamente es importante contar con alguna técnica

específica del desarrollo de software.

La programación de a pares consiste en que dos desarrolladores participen y

trabajen sobre un proyecto en una misma estación de trabajo. Cada miembro lleva a

cabo el trabajo que el otro no está haciendo en ese momento, e incluso puede que



72

mientras uno codifica el otro simplemente observe y trate de ver si se esta codificando

correctamente o si existe algún error u omisión.

La idea de esta técnica es que una persona experimentada le enseñe a una menos

experimentada y de esta manera se logra que la persona menos capacitada pueda

aprender directamente de la experiencia de su par y recibiendo explicaciones “a

medida” de lo que necesita. Así, por ejemplo, cuando se trabaja frente a una

computadora la persona inexperta utilizará el teclado, para que el conocimiento de la

persona experimentada tenga que fluir a través del novato hacia la computadora.

Cuando se implementa esta técnica de colocar a un inexperto a trabajar con un

experto, el aprendizaje es mucho mayor que con un plan de capacitación convencional

ya que es puramente práctico y las indicaciones teóricas se harán solo cuando sean

necesarias. Además, un beneficio adicional es que frente a un problema es probable que

aparezcan dos alternativas diferentes de solución y que, luego de un análisis detallado

de ambas, el resultado probablemente tendrá lo mejor de cada uno y será más eficiente.

Por otro lado, el hecho de colocar dos personas a trabajar juntas los obligará a organizar

sus tiempos para coordinar el trabajo y de este modo todo resulta más provechoso.

Finalmente, esta técnica resulta muy motivadora para quien cumple el rol de

principiante ya que tiene la posibilidad de aprender de alguien experto en la materia.

Mientras que para el experto la motivación está en poder transferir sus conocimientos,

compartir sus ideas y mejorar su capacidad de comunicación. Pero siempre debe haber

compromiso y predisposición en los participantes ya que de lo contrario no se verán las

ventajas.

4.3.3- COMITÉS DE USUARIOS

Así como los comités de desarrollo sirven para formalizar la participación de los

usuarios en la ejecución del proyecto mediante el aporte de opiniones, sugerencias y la

aprobación de entregables durante la ejecución, los comités de usuarios [Gurmendi,

2006] tienen como finalidad la formación de una comunidad de práctica donde los

usuarios puedan plantear sus inquietudes y dudas referidas a la utilización del producto

obtenidos por la realización del proyecto.

La base de los comités de usuarios es la conformación de las comunidades de

prácticas, en las cuáles los usuarios comparten sus experiencias de modo que se realiza



73

en forma natural la transferencia de conocimiento. La realización de este tipo de comité

requiere de un grupo de personas pertenecientes al equipo del proyecto que coordine las

actividades y guíe el encuentro. En los encuentros los usuarios plantean sus inquietudes,

problemas y presentan las oportunidades de mejoras detectadas. Además, el resto de los

presentes puede colaborar con los demás proponiendo soluciones a alguno de los

problemas planteados.

La idea de este tipo de grupo es generar una red de colaboración en la cuál sean

los propios usuarios los que generen conocimiento y debates, de modo que puedan

detectarse mejora u oportunidades nuevas para enriquecer el proyecto.

Al igual que las reuniones, se requiere de un lugar específico para su realización,

se debe definir la duración y una agenda básica a seguir. Además debe definirse el

proceso de facilitación. El espacio físico deber permitir que todos los asistentes puedan

verse y escucharse para que todos puedan opinar y brindar su punto de vista respecto de

los temas tratados.

La frecuencia con que se deben realizar dependerá del proyecto y de la

necesidad de los usuarios. Por lo general, en tiempo de ejecución de un proyecto estos

comités sean mas frecuentes. Mientras que, si se decide continuarlos durante la

implementación, se realizarán con menor frecuencia.

Este tipo de encuentros tienen la ventaja de que se pueden seguir realizando aun

finalizado un proyecto ya que, dependiendo de las características del producto generado,

podría ser necesario mantenimiento y detección de oportunidades de mejoras, lo cual se

puede detectar muy fácilmente en este tipo de encuentros.

Estos comités son especialmente útiles cuando el proyecto implica la

implementación de un producto software o cuando se trata de la implementación de una

nueva tecnología en la organización.

4.3.4- GRUPOS DE APOYO

Muchas veces cundo se implementa un proyecto de TI que involucra la

instalación de un nuevo producto software, uno de los inconvenientes mas comunes

suele ser la dificultad de los usuarios para comprender el mismo o, en otros casos, para

utilizar correctamente y en su totalidad las prestaciones del mismo. En algunos de estos

casos puede identificarse claramente la resistencia al cambio. Pero en otros la



74

resistencia al cambio puede no ser el motor de la no utilización, sino que la situación se

produce por o bien falta de tiempo para dedicarse a comprender el producto y sus

funcionalidades (adicionalmente a la capacitación que se les brinde como parte de la

implementación) o por dificultades propias de la formación de las personas encargadas

de operar dicho producto. Es en este segundo caso, donde se transforman en una técnica

muy útil los grupos de apoyo.

Un grupo de apoyo [Gurmendi, 2006] consiste en un grupo de personas con los

conocimientos y habilidades suficientes como para dar soporte a los usuarios finales de

un sistema y que brindan apoyo y colaboración “in situ”. Esto significa que,

adicionalmente con el personal estable del o de las áreas en las cuales se utiliza el

sistema, se envía un grupo de personas que colaborarán en la nueva operatoria

diagramada a partir de la implementación puesta en funcionamiento del nuevo sistema.

Básicamente estas personas estarán ayudando a los usuarios a realizar sus actividades

pero no en forma independiente sino que trabajarán en conjunto y en forma colaborativa

funcionando como un consultor de modo que, ante cualquier duda, el usuario pueda

consultarlo con esta persona e incluso pedirle la realización de un caso de ejemplo para

comprender mas claramente el mecanismo.

Se debe tener en cuenta que las personas que integren este grupo de apoyo deben

tener una gran habilidad para relacionarse con todo tipo de usuarios y ser muy buenos

comunicadores, de forma tal que todo lo que ellos transmitan sea claro y fácil de

entender para lo usuarios. Además, en el caso de que haya un producto software

involucrado, deben tener un alto grado de conocimiento de las funcionalidades del

mismo para poder evacuar las dudas de los usuarios.

Es importante aclarar que la implementación de este tipo de prácticas no se debe

realizar por tiempo indeterminado, sino que debe tener una duración definida que debe

ser conocida por los usuarios, quienes tendrán que procurar obtener el mayor provecho

posible de esta experiencia.

La proporción ideal en cuanto a la cantidad de personas que deben integrar el

grupo varía de acuerdo a la carga de trabajo del área a la que vayan a brindar soporte y

de la cantidad de personas afectadas a la misma, pero lo ideal es que por cada tres

usuarios del área haya una persona del grupo de apoyo.

En cuanto a la duración del servicio del grupo en el área, también depende del

tamaño del área y de la cantidad de la complejidad de los procesos / procedimientos



75

sobre los cuales se deben dar soportes. Normalmente el tiempo no debería ser menor a

una semana ni superior a tres semanas.

4.3.5- MESA DE AYUDA

La mesa de ayuda es una de las técnicas más populares y mas utilizadas en las

organizaciones para dar soporte a los usuarios. La idea de la mesa de ayuda es que los

usuarios tengan disponible en todo momento un lugar al cual se puedan dirigir en caso

de tener algún inconveniente en la utilización de un sistema.

Esta técnica es típicamente utilizada para dar soporte en los casos en que hay un

producto software de por medio y no para ayudar a resolver problemas con

procedimientos administrativos. Esta característica es una de las que lo diferencia

fundamentalmente de los grupos de apoyo. Además en este caso el grupo de soporte no

se encuentra “in situ” donde están trabajando los usuarios, sino que se encuentra

físicamente en un lugar separado y la comunicación se puede dar tanto por vía

telefónica como por medio de mensajería instantánea.

Una característica particular de la mesa de ayuda es que esta no se utiliza

solamente cuando se implementa un sistema/proyecto y durante un período de tiempo

estipulado, sino que debería transformarse en un área mas, con personal estable y

perdurable a través del tiempo.

La mesa de ayuda tiene dos propósitos, el primero es ayudar al usuario a resolver

cualquier problema que tenga referido al sistema, y el segundo es ayudarlos a utilizar el

mismo de forma efectiva. Además pueden diagramarse de modo que no solo ofrezcan

ayuda desde el punto de vista funcional sino que también sirvan como soporte técnico.

En este último caso la solución puede ser que se brinde instantáneamente o que se

ingrese una solicitud de servicio para que sea atendida por personal apropiado cuando el

mismo esté disponible.

Es importante considerar que este servicio puede ser brindado por un área que

forma parte de la organización o puede organizarse como un servicio tercerizado que,

incluso, puede no estar en el mismo lugar físico que el resto de la organización.

Respecto del tamaño del grupo que forma parte de la mesa de ayuda,

nuevamente depende de la carga de trabajo y del tamaño de la organización, pero el

equipo puede variar entre 2 y 10 personas para el caso de grandes organizaciones.



76

4.3.6- ESTRUCTURA DESGLOSADA DE TRABAJO

La Estructura Desglosada de Trabajo (EDT) o Work Breackdown Structure

[PMI, 2004], es una técnica de planeación que permite definir y cuantificar el trabajo

que se debe realizar a lo largo de todo el proyecto. Esta técnica permite organizar y

definir el ámbito total del proyecto y consiste en una representación gráfica de las

diferentes actividades que se han de llevar a cabo para la realización de un proyecto.

Dichas actividades estarán agrupadas en paquetes de trabajo.

El propósito de una EDT es dividir el proyecto en porciones que luego sean

fáciles de planificar en cuanto a tiempo, costos y recursos necesarios.

En el nivel más alto de la estructura de una EDT, se encontrará el objetivo del

proyecto o la fase del mismo que se esté gestionando. En el segundo nivel se indican

cuáles son las metas más importantes que se deben conseguir para lograr el objetivo del

nivel superior. Mientras que en el tercer nivel se divide cada una de las metas en hitos

mas pequeños. Así la estructura del proyecto se divide en niveles y sub-niveles hasta

alcanzar las denominadas unidades de trabajo.

Cada una de las tareas tiene asignado un código numérico gracias al cual es

posible identificar a que paquete de trabajo pertenece cada tarea y en que nivel de la

estructura se encuentra ubicado.

Las unidades de trabajo son actividades pequeñas cuya duración no debería

exceder la semana de trabajo y que son asignables a una persona. El algoritmo que se

sigue en general para poder realizar la construcción de una WBS es el siguiente:

1- Se identifica una tarea a realizar y se la suma a la lista de tareas.

2- Se identifican las entradas, salidas y recursos necesarios para la ejecución

de esa tarea. Además se determina si esa tarea puede ser llevada a cabo

con una meta exacta.

3- Si se puede llevar a cabo dicha tarea, ir al paso siguiente. En caso

contrario, continuar con las demás tareas y convertir la anterior en un

hito.

4- Repetir desde el paso 2 con cada una de las tareas identificadas en el

paso 1 hasta finalizar con las tareas identificadas.

5- Verificar la lista de tareas procesadas y acumular la duración de las

mismas en los hitos.

El número de niveles que comprende la EDT depende de la complejidad del

proyecto. Las tareas resultantes de dicha división de trabajo deben resultar de modo tal



77

que al culminar con la realización de todas y cada una de las tareas definidas,

automáticamente se de por finalizado el proyecto.

Existen varias maneras de representar gráficamente una EDT. Las más comunes

son la representación a través de un árbol o un listado. En la Figura 9 se muestra un

esquema de ejemplo para una EDT propuesto por el PMBOK.

Figura 7 – Esquema de una EDT propuesto por el PMBOK [PMI, 2004]

Este tipo de esquemas puede ir acompañado de una tabla en la cual

además se indiquen datos tales como el responsable de la tarea, la fecha de inicio, la

fecha de finalización y la duración total de la tarea. La EDT es una herramienta muy

útil para tener una visión completa del trabajo que implica un proyecto y también para

poder realizar estimaciones con mayor exactitud. En general, los proyectos pueden

fracasar aún cuando tengan una buena planificación y se ejecuten de manera correcta,

pero en muchos casos los fracasos se remontan a una EDT pobre o mal desarrollada.



78

4.3.7- CPM

CPM [Winston, 2005] es un método usado por la dirección de un proyecto para,

con los medios disponibles, realizar la planificación de dicho proyecto y lograr su

objetivo con éxito. Este método no pretende sustituir las funciones de la dirección, sino

que busca darle soporte a las mismas La función de CPM no es la de resolver problemas

sino que relaciona todos los factores de un problema de manera que presenta una

perspectiva más clara para su ejecución.

En un proyecto muchas veces la toma de decisiones no resulta fácil para la

dirección debido a la gran incertidumbre. La idea de CPM es la de ofrecer un medio

eficaz de reducir ésta incertidumbre, y que las decisiones tomadas y acciones

emprendidas sean las mas adecuadas al problema, mejorando en gran medida las

posibilidades de éxito.

Uno de los principales inconvenientes que se presentan en la realización de

proyectos grandes y complejos es cómo lograr una correcta coordinación entre las

diversas actividades para alcanzar el objetivo deseado. Este problema deriva del hecho

de que cada una de las áreas que participa en el proyecto suele tener su propio plan de

trabajo o planificaciones pero en forma independiente del resto. Esta independencia es

la causa de la falta de coordinación en del proyecto en su totalidad.

CPM es una técnica que provee una visión integral de todas las actividades

involucradas en el proyecto y de la relación que existen entre las mismas. El Método de

Ruta Crítica (CPM) es un método determinístico, el cual permite visualizar de manera

muy sencilla cuál es la ruta crítica de un proyecto.

Se define como ruta crítica a la secuencia de tareas de mayor duración dentro del

proyecto que definen la duración del mismo, de modo que si alguna de estas tareas sufre

una demora, de retrasará la finalización del proyecto.

La formulación de un CPM se basa en:

1- Identificar cuáles son todas las actividades que se deben realizar dentro del

proyecto.

2- Construir la red de actividades utilizando nodos y flechas, de modo que todas

las actividades identificadas estén representadas en dicha red.

3- Realizar todos los cálculos que sean necesarios para determinar cual es el

camino crítico y cuáles son las holguras del proyecto.



79

En todos los proyectos existen actividades que cuentan con cierta flexibilidad en

cuanto al tiempo en que deben comenzar y terminar. Pero hay otras en las cuales esto no

ocurre. A estas últimas se las denomina “tareas críticas”, y son las que constituyen el

camino crítico, mientras que las primeras se denominan “tareas no críticas”.

En la construcción de la red de actividades del proyecto, una actividad está

compuesta por dos partes: la ejecución del trabajo (que se representa por una flecha de

izquierda a derecha) y los sucesos iniciales y finales (que se representan con dos

círculos al inicio y al final de la flecha). En la Figura 9 se muestra como quedaría

graficada la tarea A.

Figura 8 – Representación gráfica de una tarea.

Es importante destacar que la longitud de las flechas no tiene relación alguna

con la duración de la tarea, mientras que la orientación de la flecha simplemente se

realiza de esta manera debido a que el tiempo no retrocede sino que siempre avanza.

En el armado de la red, cuando una tarea precede a otra, el suceso final de la

primera será el inicial de la segunda (ver figura 10). Es importante que al momento de

construir la red, se tenga muy presente la relación entre las tareas, de modo que siempre

se sepa que tarea precede y sucede a otra.

Figura 9 – Representación gráfica de dos tareas en secuencia.

El suceso inicial del proyecto, no posee una actividad que lo preceda, mientras

que el suceso final del proyecto no tiene ninguna actividad que lo continúe. Cada uno de

los nodos de la red debe ir numerado. El estándar mas usado para la nomenclatura es

utilizar números y la forma de asignación de los mismos es ascendente se izquierda a

derecha y desde arriba hacia abajo.

Existen algunos casos en que existe una dependencia entre dos actividades, pero

no por la necesidad de ejecutar un trabajo en particular, sino por circunstancias muy

particulares generalmente cuando se necesita mostrar la relación de precedencia en

forma visual. Para estos casos se utilizan las denominadas “Tareas Ficticias”. Estas



80

tareas se representan por flechas con línea punteada y no tienen una duración, por lo

cual se les asigna tiempo 0.

Para poder llevar adelante el armado del diagrama es necesario determinar

claramente cual es el objetivo del proyecto, de modo que éste estará representado en el

último nodo del diagrama. Luego se deberá establecer la lista de tareas a realizar para

alcanzar dicho objetivo y finalmente establecer la precedencia de dichas tareas. Esto

último es fundamentalmente importante para el correcto armado de la red de modo que

se visualice claramente cual tarea va antes y cual la subsigue.

Una vez construida la red, se deben asignar las duraciones a cada una de las

tareas. En el caso de CPM, se habla de un método determinístico, por lo cual habrá solo

una duración y exacta. A continuación se muestra la tabla de actividades con las

duraciones y predecesoras de cada una:

Tarea Duración Predecesoras A - Reingeniería de Procesos 2 B - Análisis Funcional 5 A C - Diseño Técnico 8 B D - Conversión de datos 6 C E - Personalización del sistema 9 B F – Capacitación de Procesos 5 A G – Prueba de la Solución 6 E H – Capacitación de Usuarios 9 D,G I – Producción 3 H,F

Tabla VIII – Ejemplo de actividades de un proyecto para un CPM

Luego de determinada la secuencia de actividades y las duraciones de cada un se

procede a construir la red como se muestra en la Figura 11.

Figura 10 – Diagrama de red que representa las actividades de la Tabla VIII.



81

Analizando la red se puede determinar fácilmente que el camino mas largo

dentro del diagrama es A-B-E-G-H-I y por lo tanto éste es el camino crítico del

proyecto. Este camino defina la duración del proyecto, que en este caso es de 34 días.

En la Figura 12 se remarcan las actividades que pertenecen al camino crítico.

Figura 11 – Identificación del camino crítico.

En el análisis de una red CPM aparece un nuevo concepto asociado que es el de

Holgura. Se define como Holgura a la cantidad de tiempo que se puede demorar una

actividad en particular, sin afectar la duración total del proyecto. Es decir que indica el

tiempo libre que existe dentro de la red.

Para poder analizar la holgura debemos analizar el gráfico de modo que se

puedan determinar la fecha más temprana y fecha más tardía. Para ello debemos:

1. Comenzar en 0 desde la primera actividad y sumarle la duración de la

misma, con lo que obtendremos la fecha más temprana de la actividad B

(Figura 13).

Figura 12 – Fecha más temprana de B.

2. Sumar a la fecha más temprana de B, la duración de la actividad B. De

este modo se obtiene la fecha más temprana de C (Figura 14).



82

Figura 13 – Fecha más temprana de C.

3. Repetir el mismo cálculo para cada nodo. Teniendo en cuenta que si

desde dos caminos diferentes se llega a un mismo nodo, la fecha elegida

será la mayor. La figura 15 muestra el diagrama con el cálculo de las

fechas más tempranas.

Figura 14 – Diagrama con el cálculo de fechas más tempranas.

4. Comenzar el análisis hacia atrás, por el último nodo y restándole a 34 la

duración de la última actividad (o sea 9), de modo que se obtiene la fecha

más tardía para estar en el nodo H (Figura 16).



83

Figura 15 – Diagrama con el cálculo de fecha más tardía para le nodo H.

5. Continuar con el análisis de la misma manera para los demás nodos,

teniendo en cuenta que cuando dos tareas provienen del mismo nodo, se

tome el menor valor (Figura 17).

Figura 16 – Diagrama completo con fechas tardías y tempranas.

Como desventaja se puede mencionar que esta técnica adolece del problema de

que no tiene en cuenta la incertidumbre asociada al proyecto, por lo cual resulta

sumamente útil en proyectos repetitivos en los cuales las actividades ya tienen una

duración conocida, pero no es recomendable en proyectos con mayor nivel de

incertidumbre.

Ésta técnica resulta sumamente útil para tener un diagrama claro y fácil de

entender de las actividades que forman parte del proyecto. De este modo, sabiendo cuál

es la asignación de los recursos, se puede realizar una mejor distribución y asignación

de las personas involucradas en el mismo. Es en este punto en el que CPM se

transforma en un técnica importante en el manejo de del factor humano en los

proyectos, especialmente en los de TI.



84

4.3.8- PERT

Ésta es otra técnica que se utiliza para reflejar las actividades que forman parte

de un proyecto y las relaciones que existen entre ellas. Similar al CPM, PERT

[Winston, 2005] se diferencia en los siguientes aspectos:

� Es probabilístico.

� Considera que el tiempo es una variable desconocida sobre la cual solo se

pueden tener estimaciones.

� Supone que la distribución de los tiempos de las actividades son

independientes y que la varianza del proyecto es la suma de las varianzas de

las tareas que componen el camino crítico.

� La duración del proyecto está determinada por la suma de los tiempos

esperados de las tareas que componen el camino crítico.

En PERT cada actividad está compuesta por:

a- Tiempo Optimista (ta): Es el mínimo tiempo en el cual puede ser completada

una tarea o actividad en el caso de que todo funcione de acuerdo a lo

planificado.

b- Tiempo Pesimista (tb): Es el tiempo máximo en el cual puede ser completada

una tarea o actividad considerando que se dan las condiciones más

desfavorables posibles.

c- Tiempo Más Probable(tm): Como su nombre lo indica, es el tiempo mas

probable en el que se ejecutará una tarea o actividad. En otras palabras, el

tiempo mas probable es el tiempo normal de ejecución de una actividad si

esta se repitiera muchas veces (este tiempo es el que se utiliza en CPM como

duración de cada actividad).

d- Tiempo Esperado (te): Es el tiempo en el que se espera que sea ejecutada una

actividad o tarea. En PERT, el valor de este tiempo se calcula de acuerdo a la

siguiente fórmula:

6

4 bmae

tttt

++=

La Tabla IX muestra como serían los tiempos de las actividades analizadas en

CPM, pero con la aplicación del método PERT.



85

Tarea Predecesoras Ta Tm Tb Te

A – Reingeniería de Procesos 2 2 4 3 B - Análisis Funcional A 3 5 8 5 C - Diseño Técnico B 6 8 11 8 D - Conversión de datos C 6 6 10 7 E - Personalización del sistema B 7 9 10 9 F – Capacitación de Procesos A 3 5 7 6 G – Prueba de la Solución E 5 6 8 6 H – Capacitación de Usuarios D,G 9 9 15 10 I – Producción H,F 2 3 5 3

Tabla IX – Ejemplo de actividades de un proyecto para un PERT

En este caso, la duración del camino crítico A-B-E-G-H-I es de 36 días.

Otro de los conceptos que se incorpora en el método PERT es el concepto de

varianza, que es un concepto que indica la incertidumbre asociada con la estimación de

la duración de cada actividad. Si la varianza es grande, significa que hay gran

incertidumbre sobre el tiempo de finalización de la actividad. Por el contrario, si la

varianza es pequeña, significa que la estimación de la duración de la actividad en

cuestión es bastante precisa.

La fórmula para el cálculo de la varianza es la siguiente:

( ) 2

2

6

−= ab

te

ttσ

Tarea Predecesoras Ta Tm Tb Te Varianza A 2 2 4 3 0.11 B A 3 5 8 5 0.69 C B 6 8 11 8 0.69 D C 6 6 10 7 0.44 E C 7 9 10 9 0.25 F B 3 5 7 6 0.44 G D,E 5 6 8 6 0.25 H F 9 9 15 10 1 I G 2 3 5 3 0.25

Total 1

Tabla X – Ejemplo de actividades de un proyecto para un PERT con varianza calculada

La Tabla X muestra el cálculo de la varianza para cada una de las actividades de

un proyecto. De acuerdo a la información contenida en la tabla, se puede determinar que

la duración del proyecto será de 36 +/- 1 días.



86

Como se acaba de analizar, PERT aventaja a CPM en el hecho de que incorpora

el concepto de incertidumbre y permite tener una visión más integral sobre las fechas y

los tiempos asociados a un proyecto y las posibles variaciones en los mismos. Como

desventaja se puede mencionar el hecho de que se considera que la distribución de los

tiempos de las actividades es independiente.

Desde el punto de vista de la administración de proyecto, se transforma en una

herramienta muy útil especialmente para analizar ciertos ítems tales como la holgura en

una actividad, y por tanto, la disponibilidad de un recurso en un momento determinado.

Cuando los recursos son personas, es cuando comienza a cobrar importancia para la

administración de las personas.

4.3.9- DIAGRAMAS DE GANTT

El denominado “Diagramas de Gantt” [Kendall, 1997] es un tipo de gráfico

creado por Henry L. Gantt. La idea de este gráfico es la de resolver el problema de la

programación de actividades, es decir, la distribución de las mismas de acuerdo a un

calendario, de modo tal que se pudiese visualizar la duración de cada actividad, las

fechas de iniciación y terminación de cada una, como así también el tiempo total

requerido para la ejecución de un trabajo. Este diagrama permite además obtener un

seguimiento del curso de cada actividad, ya que proporciona información relacionada

con el porcentaje ejecutado de cada una de las tareas y el estado (adelanto o retraso) de

la misma con respecto al plazo previsto.

El gráfico de Gantt consiste simplemente en un sistema de ejes cartesianos en los

cuales se indica:

� En el eje Horizontal (tiempo): En este eje se indica el calendario, el

cual estará expresado en la unidad de medida mas adecuada al trabajo

que se realizará (horas, días, semanas, meses, etc).

� En el eje Vertical (actividades): En este eje se indican las actividades

que forman parte del total del trabajo a realizar. A cada una de las

actividades indicadas en este eje, le corresponde una línea horizontal

cuya longitud es proporcional a su duración de acuerdo a la escala

definida en el eje del tiempo.



87

� Símbolos Adicionales: De acuerdo a la herramienta utilizada para la

construcción de este tipo de diagramas, puede que se introduzcan

símbolos particulares y aplicables a ciertos tipos de proyectos. Entre

los símbolos más usuales se encuentran los hitos, inicio de tarea, fin

de tarea, etc.

Desde su creación, los diagramas de Gantt se han convertido en una herramienta

básica en la gestión de proyectos de todo tipo, ya que permite representar en forma muy

sencilla las diferentes fases, tareas y actividades programadas como parte de un

proyecto o para mostrar una línea de tiempo en las diferentes actividades haciendo el

método más eficiente.

La creación de un diagrama de este tipo consiste en los siguientes pasos:

1. Identificar las actividades que formarán parte del trabajo a realizar.

2. Determinar la duración de cada una de las actividades.

3. Identificar las dependencias entre las actividades como así también el

orden en que deben comenzar a ser ejecutadas.

4. Confeccionar el gráfico de acuerdo a las tareas definidas, su duración

y el calendario definido para las mismas.

En la Figura 17 se muestra el diagrama de Gantt para el ejemplo mostrado en la

Tabla VIII.

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

A

B

C

D

E

F

G

H

I

Act

ivid

ades

Duración (días)

Figura 17 – Diagrama de Gantt para las actividades de la tabla VIII.



88

La ventaja principal del diagrama de Gantt radica en que para su armado se

requiere un nivel mínimo de planificación por lo que pueden se r utilizados en las

primeras etapas de un proyecto.

Sin embargo, después de iniciada la ejecución actividad y cuando comiencen a

efectuarse modificaciones en la planificación, el gráfico puede volverse confuso. Por

eso se utiliza mucho la representación gráfica del plan, en tanto que los ajustes en la

planificación requieren por lo general de la formulación de un nuevo gráfico.

En términos de planificación, este diagrama adolece de una limitación bastante

grande en lo que refiere a la representación de planes de cierta complejidad. Gantt no

ofrece condiciones para el análisis de opciones, ni toma en cuenta factores como el

costo. Es fundamentalmente una técnica de prueba y error. No permite, tampoco, la

visualización de la relación entre las actividades cuando el número de éstas es grande.

En la actualidad existe una gran cantidad de herramientas informáticas que permiten

confeccionar y mantener muy fácilmente los diagramas de Gannt de un proyecto. Esto

hace que su facilidad de implementación sea aun mayor y más útil en todos los casos.

En resumen, para la planificación de actividades relativamente simples, el gráfico de

Gantt representa un instrumento de bajo costo y gran simplicidad de uso. Pero para

proyectos complejos, sus limitaciones llevan al uso adicionas de las técnicas de CPM o

PERT.

4.3.10- COCOMO

El método COCOMO (Constructive Cost Model) [Boehm, 2000] es un modelo

utilizado para realizar la estimación del costo de un producto software. Este modelo

incluye tres submodelos en el que cada uno ofrece un nivel de detalle y una

aproximación que varía de acuerdo al avance del proyecto.

Este modelo fue desarrollado por Boehm en 1981 de acuerdo con las técnicas de

desarrollo de software utilizadas en aquel momento, pero posteriormente (en el año

1997) se desarrollo COCOMO II el cuál puede ser utilizado con las técnicas modernas

de desarrollo.

COCOMO es un modelo que se basa en la estimación matemática y está

orientado a determinar cual será el tamaño del producto final, lo cuál se mide en

cantidad de líneas de código fuente. Los tres submodelos que componen a COCOMO



89

son: Básico, Intermedio y Avanzado. Estos tres modelos utilizan una función básica que

permite estimar el esfuerzo de de desarrollo. Esta función tiene la siguiente forma:

)(xbmaSE =

Donde:

S: es el número de miles de líneas de código fuente.

m(x): s un multiplicador que depende de 15 atributos.

a y b: son valores constantes definidos de acuerdo a cada submodelo.

Además, cada submodelo se divide en modos que representan los diferentes

tipos de proyectos. Estos modos pueden ser:

� Orgánico: El proyecto está desarrollado por un grupo pequeño de

programadores expertos que trabajan en un entorno conocido. En este caso el

tamaño del producto software varía entre un tamaño pequeño (algunas miles

de líneas de código) y un tamaño medio (decenas de miles de líneas).

� Semi-acoplado: En este caso el proyecto se desarrolla por un grupo de

desarrolladores mixto. Esto significa que existen desarrolladores

experimentados y no experimentados trabajando sobre el mismo proyecto.

� Empotrado: En este caso el proyecto es llevado a cabo por un grupo de

desarrollo no experimentado. Además, en este caso el proyecto tiene grandes

restricciones relacionadas con las funcionalidades del producto software a

construir o con las técnicas a utilizar en el mismo, lo cual se agrava con la

falta de experiencia del equipo de desarrollo.

De acuerdo con el modo al cual se asocie al proyecto, los valores de las

constantes a y b se obtendrán de acuerdo a lo que se muestra en la tabla XI.

Básico Intermedio ai bi ai bi Orgánico 2.40 1.05 3.20 1.05 Semi-acoplado 3.00 1.12 3.00 1.12 Empotrado 3.60 1.20 2.80 1.20

Tabla XI – Coeficientes de COCOMO según submodelo y modo utilizado [Boehm, 2000].



90

MODELO BASICO

Éste modelo se utiliza para tener una primera aproximación del esfuerzo

necesario para el desarrollo de un producto software. La idea de este modelo es obtener

una estimación rápida aunque no demasiado exacta del esfuerzo necesario para llevar

adelante el proyecto.

En este modelo se deben utilizar las constantes correspondientes a la columna

“Básico” de la Tabla XI. Si se observa con atención esta tabla, se puede observar como,

a medida que aumenta la complejidad del proyecto, aumenta en forma considerable la

constante relacionada con el personal (a). Esto implica que se debe ser muy cuidadoso

al utilizar este modelo debido a que no tiene en cuenta muchas características del

entorno en que se lleva a cabo el proyecto.

MODELO INTERMEDIO

Éste modelo añade al modelo básico quince atributos denominados

modificadores relacionados con el costo, para tener en cuenta el entorno de trabajo.

Estos modificadores aumentan la precisión de la estimación realizada. Los valores a

utilizar en las constantes, también se muestran en la Tabla XI, en la columna

“Intermedio”. Los quince atributos que se agregan en este modelo son los siguientes:

� Atributos de software

� RELY : Indica las posibles consecuencias para el usuario en el caso

que existan defectos en el producto. Este atributo puede ir desde la

sola inconveniencia de corregir una falla (muy bajo) hasta la posible

pérdida de vidas humanas (extremadamente alto)

� DATA : Indica el tamaño de la base de datos relación con el tamaño

del programa.

� CPLX : Indica la complejidad del producto.

� Atributos de hardware

� TIME : Indica las restricciones en los tiempos de ejecución.

� STOR: Indica las limitaciones en el porcentaje del uso de la

memoria.

� VIRT : Indica la volatilidad de la máquina virtual.

� TURN: Indica el tiempo de respuesta.



91

� Atributos de personal

� ACAP: Indica la capacidad de los analistas.

� AEXP: Indica la experiencia del personal en aplicaciones similares.

� PCAP: Indica la calificación de los programadores.

� VEXP: Indica la experiencia del personal en la máquina virtual.

� LEXP : Indica la experiencia en el lenguaje de programación a usar.

� Atributos de proyecto

� MODP: Determina el uso de prácticas modernas de programación.

� TOOL : Indica el uso de herramientas de desarrollo de software.

� SCED: Indica las limitaciones en el cumplimiento de la

planificación.

Los valores para cada uno de estos atributos están dados por la calificación

asignada a cada uno y se pueden visualizar en la Tabla XII.

Valor Atributos Muy

Bajo Bajo Nominal Alto

Muy Alto

Extra alto

Atributos de software RELY 0,75 0,88 1,00 1,15 1,40 DATA 0,94 1,00 1,08 1,16 CPLX 0,70 0,85 1,00 1,15 1,30 1,65

Atributos de hardware TIME 1,00 1,11 1,30 1,66 STOR 1,00 1,06 1,21 1,56 VIRT 0,87 1,00 1,15 1,30 TURN 0,87 1,00 1,07 1,15

Atributos de personal ACAP 1,46 1,19 1,00 0,86 0,71 AEXP 1,29 1,13 1,00 0,91 0,82 PCAP 1,42 1,17 1,00 0,86 0,70 VEXP 1,21 1,10 1,00 0,90 LEXP 1,14 1,07 1,00 0,95

Atributos del proyecto MODP 1,24 1,10 1,00 0,91 0,82 TOOL 1,24 1,10 1,00 0,91 0,83 SCED 1,23 1,08 1,00 1,04 1,10

Tabla XII – Valores para los atributos del Submodelo INTERMEDIO de COCOMO

[Boehm, 2000].



92

La valoración de cada atributo tiene cierta componente de subjetividad. En

algunos casos se pueden tener parámetros aproximados para asignar la valoración, pero

en otros casos esto no es tan sencillo.

Para el caso de RELY se considera lo siguiente:

Muy Bajo: el efecto de un fallo del software simplemente trae como consecuencia la

inconveniencia de corregir el fallo

Bajo: el efecto de un fallo software es una pérdida fácilmente recuperable para los

usuarios

Nominal: el efecto es una moderada pérdida para los usuarios, pero es una situación de

la que se puede salir sin excesiva dificultad

Alto: el efecto es una gran pérdida financiera o una inconveniencia masiva humana

Muy Alto: el efecto es una pérdida de vidas humanas.

Para el caso de DATA será:

Hay cuatro segmentos con la razón 10-100-1000, que determinan las puntuaciones de

Bajo a Muy Alto. Este se define por el siguiente cociente:

DSIenprogramadelTamaño

bytesendatosdebaseladeTamaño

____

_______

Para el caso de CPLX será Bajo si el módulo está formado por expresiones matemáticas

sencillas y Extra Alto para el caso de módulos que utilizan recursos que deben ser

planificados.

En el caso de TIME se considera que el valor es Nominal, si el tiempo disponible para

la ejecución es del 50 % del tiempo, mientras que si la restricción es del 95 % entonces

será Extra Alto.

Para STOR se considera Nominal el caso de que la reducción del almacenamiento

principal es del 50 %, mientras que se considera Extra Alto si la reducción es del 95 %.

En el caso de VIRT se considera Bajo cuando la máquina en que correrá la aplicación

casi no varía durante el desarrollo, mientras que si la variación es mucha será Muy Alto.

Para el caso de TURN, cuanto mayor sea el tiempo de respuesta, mayor será el esfuerzo

humano. Se considera Bajo cuando el sistema es muy interactivo y Muy Alto cuando el

tiempo de respuesta es de mas de 12 horas.

En el caso de ACAP, cuanto mayor sea la capacidad de los analistas, mas alto será el

valor del atributo.

Para AEXP, se considera que es Muy Bajo cuando se tiene menos de cuatro meses de

experiencia, Bajo cuando tiene un año de experiencia, Nominal para tres años de



93

experiencia, Alta para seis años de experiencia y Muy Alta cuando tienen mas de 12

años de experiencia.

El caso de PCAP, es similar que ACAP pero considerando a los desarrolladores como

grupo y no en forma individual.

Para VEXP, se considera que será Muy Bajo si la experiencia del grupo de

programación con el procesador es menor a un mes y será Alto cuando dicha

experiencia sea mayor a tres años.

Para LEXP , será Muy Bajo cuando la experiencia en promedio sea menor a un mes y

Alta cuando supere los tres años.

MODP, será Muy Bajo si no se utilizan técnicas de programación modernas, y Muy

Alto si tiene experiencia y habitualmente utiliza dichas técnicas.

En el caso de TOOL , va desde Muy Bajo para el caso en que no se utilicen

herramientas o sólo se utilicen algunas muy básicas, hasta Muy Alto cuando se utilizan

técnicas avanzadas y muy específicas.

Finalmente SCED, será Muy Bajo el proyecto se acelera y Muy Alto si el proyecto se

retrasa.

MODELO DETALLADO

Éste modelo introduce al intermedio dos características principales:

1- Multiplicadores de esfuerzo sensitivos a la fase: Algunas de las fases del

proyecto se ven mas afectadas que otras por algunos atributos tales como la

experiencia en la aplicación y los conocimientos de ciertas herramientas de

software. El modelo detallado incluye una serie de de multiplicadores cuyo

valor varía de acuerdo con la etapa del proyecto.

2- Jerarquía de productos de tres niveles: Se establecen tres niveles de

productos que son Módulo, Subsistema y Sistema. Esta cuantificación se

realiza de modo que los aspectos que representan gran variación se

consideran a nivel módulo, las que representan pocas variaciones, a nivel

subsistema; y los restantes a nivel sistema.

El COCOMO detallado se basa en dividir el esfuerzo de en fases, de modo que

en cada una de ellas se obtenga un factor de costo para finalmente obtener el costo total

a partir de la suma de los costos de cada fase. Las fases que se consideran son:

Determinación de requerimientos, diseño del producto, desarrollo y finalmente prueba.



94

En líneas generales se puede concluir diciendo que COCOMO es una técnica

muy útil para estimar el esfuerzo necesario para llevar adelante un proyecto de TI que

implica el desarrollo de un producto software. El principal inconveniente que posee es

que depende en gran medida de la experiencia en proyectos previos, cosa que en

muchas organizaciones no existe. Pero resulta útil debido a que permite tener una visión

global de la relación entre los diferentes factores que afectan al costo de un proyecto.

4.3.11- PUNTOS DE FUNCIÓN

La métrica de puntos de función [ISO/IEC, 2007], es una técnica utilizada para

medir el tamaño de un producto software. Este método fue creado en 1979 por Allan

Albrecht y tiene como objetivo la obtención de una medición del producto que se le

entrega al usuario independientemente de la tecnología utilizada para el desarrollo del

mismo. Este método puede ser utilizado en cualquiera de las etapas del ciclo de vida del

desarrollo de un producto software sea en el inicio del mismo o en cualquiera de las

demás etapas.

El tamaño de un producto software podría medirse en término de la cantidad de

bytes que el mismo ocupa en el disco rígido, o bien en términos de cantidad de líneas de

código fuente necesarias para alcanzar las funcionalidades deseadas. En otros casos se

puede medir el tamaño de un software en términos de las funcionalidades que el mismo

proporciona. El problema es seleccionar cual de estas alternativas es la mas

conveniente para obtener una medida que permita tener una correlación con el esfuerzo

necesario para llevar adelante dicho proyecto.

Una de las consideraciones que se deben hacer es que la sola utilización de

líneas de código para la medición del tamaño puede ser engañosa. Esto se basa en el

hecho de que la etapa de codificación es apenas una etapa dentro de todo el ciclo de

vida y que apenas representa un aproximadamente un 25 % del costo total del proyecto

(ya que no se consideran las etapas de análisis, documentación del proyecto, ejecución

de pruebas etc.).

Otro de los aspectos que se deben considerar es que el esfuerzo necesario para

generar cada línea de código, puede variar en forma sorprendente de una tecnología a

otra.



95

Todo lo antes dicho, lleva a considerar que es mas conveniente utilizar una

métrica que considere los requerimientos del usuario (funcionalidades) y que sea

independiente de la tecnología en que se realizará dicho desarrollo.

La métrica de puntos de función puede ser definida como una métrica funcional, debido

a que se enfoca en las prestaciones que el producto software debe proporcionarle al

usuario. La medición de la funcionalidad de un producto software ha sido estandarizada

por la Organización Internacional para la Estandarización (ISO) en la norma ISO/IEC

14143, la cual define cuales son los conceptos de una métrica basada en la

funcionalidad y qué características debe cumplir un método para ser homologado al

estándar y ser considerado como una medida del tamaño de la funcionalidad.

Los métodos más conocidos que están homologados por ISO 14143 [ISO/IEC, 2007]

son:

• IFPUG 4.1: El Unajusted Functional Size Measurement Method

[ISO/IEC, 2003] fue desarrollado en IBM y es el más conocido y

utilizado en Estados Unidos, al punto de que se está convirtiendo en el

método por defecto en toda la industria.

• NESMA: Es un estándar definido por la Netherlands Software Metrics

Users Association [NESMA, 2001] y que representa una pequeña

variante respecto del método IFPUG.

• Mk II : Fue desarrollado por la United Kingdom Software Metrics

Association [UKSMA, 1998] y es un método simplificado y adaptado

para las ideas de análisis y diseño estructurado.

• COSMIC FFP: Es un método desarrollado para ser utilizado con mayor

precisión en la medición de sistemas de tiempo real y fue definido por el

Common Software Measurement International Consortium [Abran,

2001].

El método que se analizará en el presente trabajo será el IFPUG ya que es el más

utilizado en la industria del software. El método IFPUG utiliza como unidad de medida

los puntos de función. Se basa principalmente en la identificación de cuales son los

componentes del sistema (transacciones y grupos de datos lógicos) que son relevantes

para el usuario. A cada uno de los componentes identificados se les asigna una cantidad

de puntos de función de acuerdo al componente y su complejidad. De acuerdo a esto, la



96

suma de los puntos de función de todos los componentes del producto software dará los

puntos de función del sistema sin ajustar. El ajuste es un proceso donde se modifica el

valor de acuerdo a ciertas características generales del producto a construir.

El procedimiento del IFPUG [ISO/IEC, 2003] es el siguiente:

1- Determinar el tipo de conteo

En este paso se determinará el tipo de medición de tipos de función. Las

mediciones pueden estar asociadas tanto a proyectos como a aplicaciones.

Existen tres tipos de mediciones de puntos de función:

- Puntos de función de un proyecto de desarrollo.

- Puntos de función de un proyecto de mejora.

- Puntos de función de una aplicación.

2- Identificar los alcances de la medición y los límites de la aplicación

En este paso se define que funcionalidades serán incluidas en la medición de

puntos de función a realizar (alcance) y cuales son los límites entre el

software a medir y el usuario (límites de la aplicación).

3- Determinar los puntos de función no ajustados

Los puntos de función no ajustados reflejan la funcionalidad cuantificable

proporcionada al usuario por parte del proyecto o aplicación. La

funcionalidad se evalúa en función de qué es lo que se entrega al usuario y

solo se cuentan los componentes solicitados y definidos por el usuario.

La medida de puntos de función no ajustados tiene dos tipos de función: de

datos y transaccional.

a- Medición de las funciones de datos

En este paso se identifican y cuentan las funciones que proporcionan al

usuario la capacidad de satisfacer los requisitos de almacenamiento de

datos tanto interno como externo. Las funciones de datos son archivos

lógicos internos o archivos de interfaz externos.

Un archivo lógico interno (ILF) es un grupo de datos lógicamente

relacionados, identificados por el usuario y que son mantenidos dentro de

los límites de la aplicación. Esto significa que los ILF almacenan datos

que son mantenidos a través de alguna transacción que está considerada

dentro del conteo de la aplicación.



97

Por su parte, los archivos de interfaz externos (EIF) son aquellos grupos

de datos relacionados lógicamente, identificables por el usuario y que son

referenciados por la aplicación pero que son mantenidos dentro de los

límites de otra aplicación. Esto significa que los EIF son mantenidos a

través de una transacción que no está incluida dentro del conteo.

El objetivo principal de los EIF es almacenar datos que son referenciados

por uno o más procesos que se encuentran fuera de los límites de la

aplicación que se está midiendo. Esto significa que un EIF de una

aplicación es un ILF de otra.

b- Medición de las funciones transaccionales

En esta etapa se identifica y cuenta la capacidad de realizar operaciones

por parte de la aplicación. Existen tres tipos de funciones transaccionales:

Entrada Externa, Salida Externa, Consulta Externa.

Una entrada externa (EI) es un proceso cuyo propósito principal es el de

mantener uno o mas ILFs. Mientras que una salida externa (EO) es un

proceso que tiene como objetivo presentar información al usuario

mediante un proceso lógico diferente de la sola recuperación de datos.

Finalmente la consulta externa (EQ) es un proceso por el cual se

presenta la información leída de uno o más grupos de datos al usuario.

A cada uno de los cinco componentes definidos anteriormente, se les

debe asignar una complejidad, la cual puede ser Baja, Media o Alta. Dicha

complejidad se asigna de acuerdo al número de datos utilizados en el proceso

y la cantidad de archivos referenciados.

De acuerdo a la complejidad asignada, se deberá utilizar la Tabla XIII para

poder calcular el total de puntos de función no ajustados.

Bajo Medio Alto Total EI __ x 3 __ x 4 __ x 6 EO __ x 4 __ x 5 __ x 7 EQ __ x 3 __ x 4 __ x 6 ILF __ x 7 __ x 10 __ x 15 EIF __ x 5 __ x 7 __ x 10

Total

Tabla XIII – Tabla de para el cálculo de puntos de función no ajustados



98

4- Determinar el valor de ajuste

En esta etapa lo primero que se debe hacer para obtener el valor del ajuste es

analizar los 14 atributos que impactan en el desarrollo y que deben ser

evaluados en forma independiente. A cada uno de dichos atributos se les

deberá asignar un valor entre 0 y 5 dependiendo del grado de influencia de

dicho atributo. Los posibles valores son:

0- Sin Influencia: El sistema no contempla este atributo.

1- Influencia mínima: La influencia es muy poco significativa.

2- Influencia moderada: Si bien el sistema contempla este atributo y su

influencia es pequeña, debe ser considerada.

3- Influencia apreciable: El atributo no es fundamental pero su influencia

debe ser tenida en cuenta.

4- Influencia significativa: El atributo tiene una gran importancia en e

sistema.

5- Influencia muy fuerte: El atributo es fundamental para el sistema y su

influencia debe ser tenida en cuenta en el diseño.

Los atributos son:

1. Comunicación de datos.

2. Funciones distribuidas.

3. Prestaciones.

4. Gran uso de la configuración.

5. Velocidad de las transacciones.

6. Ingreso de datos en línea.

7. Diseño para eficiencia del usuario final.

8. Actualización de datos en línea.

9. Procesos complejos.

10. Reusabilidad del código por otras aplicaciones.

11. Facilidad de instalación.

12. Facilidad de operación.

13. Instalación en múltiple sitios.

14. Facilidad de cambios.

Para obtener el factor de ajuste (AF) se debe sumar 0,65 a la sumatoria de los

grados de influencia de las 14 características generales del sistema (TDI,

Total Degree of Influence), multiplicado por 0,01, es decir:



99

)01.0( ×= TDIAF

5- Determinar los puntos de función ajustados

En este paso simplemente se debe multiplicar los puntos de función no

ajustados por el factor de ajuste.

La métrica de puntos de función está orientada a medir sistemas informáticos

completos y no programas. En este sentido se convierte en una herramienta muy

importante para la administración de un proyecto porque permite abarcar un panorama

más amplio que la sola aplicación. Esto lo convierte en una técnica útil para estimar el

esfuerzo necesario para llevar a cabo un proyecto, especialmente cuando se cuenta con

una base de conocimiento dentro de la organización, sobre la cual se puedan basar los

cálculos.

La existencia de una base de conocimiento es muy importante ya que de la

experiencia en otros proyectos es que se podré determinar la cantidad de horas

necesarias por cada punto de función y, de acuerdo a esto, la cantidad y distribución de

los recursos (entre ellos personas) a lo largo del proyecto.

4.2.12- TÉCNICA DE GRUPO NOMINAL

La técnica de grupo nominal [Kelly, 1999] es una técnica útil al momento de

realizar la planificación de los recursos humanos necesarios para llevar adelante un

proyecto. Esta técnica consiste en presentar a un grupo de gerentes un tema básico, por

ejemplo: ¿Cuál será el personal necesario para llevar adelante el nuevo proyecto que se

está analizando? Cada uno de los participantes procede a poner por escrito las

respuestas que estime pertinentes. Después de 10 minutos se discuten las ideas del

grupo se clasifican y se permite que cada integrante las numere en orden de

importancia, seleccionando las tres o cuatro mas importantes.

La técnica de grupo nominal es muy útil cuando se trate de una cuestión

delicada, polémica o importante y que generará opiniones encontradas en la cuál se

quiera asegurar la participación equitativa de todos los miembros del equipo. También

es útil cuando la selección de una alternativa entre varias, se hace sumamente difícil.

Ésta es una técnica de las que se denominan como “basadas en experiencia”.

Esto se debe a que, para poder realizar una estimación como la que se indica



100

anteriormente, es necesario que los participantes cuenten con cierta experiencia. Es

conveniente que estos conocimientos previos sean de proyectos con características

similares al proyecto que se está planificando.

En este caso los que deberían participar del proceso son el sponsor del proyecto,

el líder, y todas aquellas personas que cumplan algún rol gerencial dentro del proyecto.

4.3.13- TÉCNICA DELPHI

Delphi [Kelly, 1999] es una técnica de sondeo de opiniones. En esta dinámica se

solicitan estimados específicos de un grupo de expertos, por lo general a nivel gerencial.

Los en cargados de realizar la planificación de los recursos humanos necesarios para el

proyecto actúan como intermediarios, resumen las respuestas obtenidas e informan a los

expertos de los resultados. El proceso se repite hasta que el grupo empieza a concordar

en determinados factores. Generalmente cuatro o cinco fases sucesivas son suficientes

para llegar a resultados concretos. Las ocho etapas de esta técnica son [Kelly, 1999]:

1- Definir la decisión a tomar.

2- Recibir los comentarios del equipo para la primera ronda.

3- Resumir los comentarios de la primera ronda y solicitar los comentarios

de la segunda ronda.

4- Recibir los comentarios de la segunda ronda.

5- Resumir los comentarios de la segunda ronda y solicitar los comentarios

de la tercera ronda.

6- Recibir los comentarios de la tercera ronda.

7- Resumir los comentarios de la tercera ronda.

8- Dar por concluida la sesión.

La técnica delphi se diferencia del grupo nominal en que éste requiere que todos

los miembros están presentes físicamente en un mismo ambiente, mientras que en este

caso no se requiere esa presencia física.

Entre todos los miembros de la técnica delphi se da la búsqueda de un

comportamiento proactivo. La interacción entre miembros siempre va a ser controlada a

través de las respuestas de los miembros según estadísticas. Ésta buscará el grado de

consenso máximo entre opciones; cuando haya discrepancia o consenso se pedirá el



101

razonamiento. La técnica delphi se aplica para multitud de actividades empresariales

para realzar pronósticos, evaluar características de productos, sistemas, tecnologías;

resolver e identificar problemas; establecer metas y prioridades; para aclarar posiciones,

identificar diferencias, optar por determinados grupos de referencia, etc.

La técnica delphi es útil cuando se desea conocer las opiniones de varios

miembros del equipo evitando, a la vez, el efecto negativo del contacto cara a cara. Es

recomendable especialmente cuando los miembros del equipo no se encuentran en el

mismo lugar físico y se requiera lograr una decisión por consenso.

4.3.14- ANÁLISIS ESTADÍSTICO

El análisis estadístico es una técnica de mayor complejidad en la cual se utilizan

modelos computarizados, los cuales permiten predecir la necesidad de personal para un

proyecto u organización. Estos modelos incluyen factores tales como las variantes en la

demanda externa de producto. Los procedimientos estadísticos utilizan datos históricos

para proyectar la demanda futura. El Procesamiento de los modelos puede ofrecer una

representación simplificada de la demanda de los recursos humanos de toda la

organización o de un proyecto en particular. Alterando los datos de entrada pueden

contrastarse las necesidades recursos humanos en diferentes escenarios de demanda.

Entre las técnicas estadísticas de modelizar utilizadas para la previsión de las

necesidades de recursos humanos se encuentran las siguientes [Caldera Mejía, 2004]:

� Análisis de series temporales: Se utilizan niveles históricos de personal para

proyectar las necesidades futuras de recursos humanos. Se estudian los

niveles históricos de personal para aislar las variaciones estaciónales y

cíclicas, las tendencias a largo plazo y los movimientos aleatorios. Luego se

extrapolan las tendencias a largo plazo utilizando una media móvil, un

suavizado exponencial o la técnica de regresión.

� Ratios de personal: Se examinan los datos obtenidos del área encargada del

manejo del personal para determinar las relaciones históricas entre el número

de empleados en diversos puestos o categorías de puestos. A continuación se

utiliza el análisis de regresión o ratios de productividad para proyectar las

necesidades totales o de grupos claves de recursos humanos y se utilizan



102

dichos ratios para asignar necesidades totales a diversas categorías de

puestos o para estimar necesidades de grupos no claves.

� Ratios de productividad: Se utilizan datos históricos para examinar los

niveles históricos de un índice de productividad. La fórmula que se utiliza es:

personasdeNumero

trabajodeacP

__

__arg=

Si se encuentran relaciones constantes o sistemáticas, pueden calcularse las

necesidades de recursos humanos dividiendo las cargas previstas de trabajo

por P.

� Análisis de regresión: Se estudian los niveles históricos de varios

indicadores de carga de trabajo, como ventas, niveles de producción y valor

agregado, para encontrar relaciones estadísticas con los niveles de personal.

Cuando se encuentran relaciones suficientemente fuertes, se obtiene un

modelo de regresión (o de regresión múltiple). Los niveles previstos de los

indicadores mantenidos se pasan al modelo resultante y se utilizan para

calcular el nivel asociado de las necesidades de recursos humanos.

Los modelos de regresión presentan la ventaja de que son muy sensibles a

los cambios en la orientación de la organización, lo cual permite identificar

la necesidad de reasignar personal o de modificar los niveles de dotación.

Los modelos de regresión dan buenos resultados cuando se utilizan con

empresas que operan en un entorno estable.

CAPITULO

V

MODELO DE

ADMINISTRACION DE

PERSONAS

PROPUESTO



105

5.1- INTRODUCCIÓN

En el presente capítulo se expone como solución al problema planteado, un

Modelo de Gestión de Personas aplicable a los diferentes tipos de proyectos de TI. Lo

que se propone es la aplicación de diferentes técnicas de gestión de personas dentro de

una estructura de administración de Proyectos.

Las técnicas que se implementarán son todas aquellas relacionadas con

motivación de equipos de trabajo, gestión de las relaciones interpersonales dentro de un

equipo, relación con los clientes y manejo de la asignación y distribución de los

recursos. La idea es poder aprovechar al máximo las ventajas y beneficios de cada una

de estas técnicas, adaptándolas a cada momento del proyecto cuando se lo requiera.

Por otro lado, se plantea la utilización de un modelo de administración de

proyectos reconocido y ampliamente utilizado en el ámbito de la gestión de proyectos,

tal como lo es el PMBOK. Este modelo plantea un “conjunto de conocimientos” que

permiten dirigir un proyecto, y que está basado en la experiencia obtenida en diferentes

casos y empresas.

La idea es combinar por un lado un estándar reconocido de administración de

proyectos, que funcione como estructura para comprender las etapas o fases del

proyecto, y por el otro proponer el uso de las diferentes técnicas de acuerdo al momento

del proyecto en que se encuentre.

Finalmente se indicará como se debe implementar cada técnica en cada grupo de

proceso definido en la estructura del proyecto, y las consideraciones particulares que se

deberán realizar para poder llevarlo a cabo.

5.2- ESQUEMA SELECCIONADO

Para poder abordar y llevar adelante el planteo propuesto en el capítulo anterior,

es necesario primero definir cuál será el esquema / estándar de administración de

proyectos que se utilizará como guía para identificar las actividades relacionadas con la

administración del factor humano. En este sentido, se considera que la metodología más

completa de las conocidas y utilizadas actualmente, es aquella propuesta por el Project

Management Institute (PMI): El PMBOK (Project Management Body of Knowledge).

El PMBOK, como ya se analizó anteriormente, provee un estándar para la

dirección de proyectos que está estructurado en cinco grupos de procesos básicos y



106

nueve áreas de conocimientos que son comunes prácticamente a todos los proyectos. La

elección de este estándar se basa en que representa un conjunto muy actual y

sumamente amplio de conocimientos que resultan de la experiencia, el estudio y el

desarrollo de proyectos.

Lo interesante de este esquema es que su finalidad no es exponer disciplinas,

herramientas y técnicas aplicables a la gestión de proyectos sino proveer un grupo

seleccionado de ellas y que son consideradas como buenas prácticas. Esto permite que

se puedan encuadrar en su esquema todas aquellas técnicas y herramientas relacionadas

con la administración del factor humano que influyen en la administración de un

proyecto.

Por otra parte, el grupo de conocimientos del PMBOK se encuentra distribuido

entre los miles de colaboradores alrededor del mundo y es por esta razón que no se lo

presenta como un manual con pasos a seguir para culminar un proyecto en forma

exitosa.

Los cinco procesos en los que se estructura el PMBOK son:

1. Inicio

2. Planificación

3. Ejecución

4. Seguimiento y Control

5. Cierre

Y las nueve áreas de conocimiento son:

1. Gestión de la Integración

2. Gestión del Alcance

3. Gestión del Tiempo

4. Gestión de la Calidad

5. Gestión de Costos

6. Gestión de Riesgos

7. Gestión de Recursos Humanos

8. Gestión de la Comunicación

9. Gestión del Aprovisionamiento

Para el planteo de la solución propuesta al problema abordado en el presente trabajo, se

tomará como base esta estructura y dentro de ella es que se organizarán las técnicas y

herramientas propuestas como mejores prácticas.



107

5.3- MODELO DE GESTIÓN PROPUESTO

La solución al problema presentado se estructurará de modo que, se analizarán

en detalle las necesidades de cada uno de los grupos de procesos del PMBOK desde el

punto de vista de la administración del factor humano. Luego se especificará el modelo

final que combina las prácticas genéricas y específicas analizadas en el capítulo anterior

con cada grupo de procesos. En la Figura 6 se puede visualizar el esquema planteado

para el desarrollo de la solución.

Prácticas Genéricas

Reuniones

Wikis

Foros de discusión

Listas de Correo

Mensajería instantánea

Prácticas Específicas

Comités de Desarrollo

Programación de a Pares

Comités de Usuario

Grupos de Apoyo

Mesa de Ayuda

Estructura Desglosada de Trabajo

C.P.M.

P.E.R.T.

Diagramas de Gantt

COCOMO

Puntos de Función

Grupo Nominal

Delphi

Análisis Estadístico

Grupo de Procesos

Inicio

Planificación

Ejecución

Control y Monitoreo

Cierre

Modelo de Mejores Prácticas

Figura 18 –Representación gráfica del esquema de la solución planteada.



108

5.4- APLICACIÓN DE PRÁCTICAS A LAS DIFERENTES FASES DE UN PROYECTO

En esta sección se presentará cómo se relaciona cada una de las prácticas

definidas en las dos secciones anteriores con las diferentes fases de un proyecto de TI.

En la Tabla XIV se muestra un esquema que sintetiza cual es la aplicabilidad de cada

técnica según la fase del proyecto en que se encuentre.

Iniciación Planificación Ejecución Seguimiento y Control

Cierre

Reuniones X X X X X

Wikis X X X X

Foros de discusión

X X X X X

Listas de Correo X X X X X

Mensajería Instantánea

X X X X X


X


X

Comités de Usuarios

X X

Grupos de Apoyo X

Mesa de Ayuda X


X X X

Diagramas de Gantt

X X X

CPM X X

PERT X X

COCOMO X X

Puntos de Función

X X X

Grupo Nominal X

Delphi X


X

Tabla XIV – Esquema de prácticas por fases del proyecto



109

En general se ve claramente que las prácticas que se definieron como genéricas

son aplicables a casi todas las fases de un proyecto, mientras que las específicas solo se

aplican a uno o dos grupos de procesos.

Siempre se debe tener en cuenta que el conjunto de prácticas propuestas solo

conforma una guía. Es decir que no necesariamente se deben aplicar todas sino que se

seleccionarán solo aquellas que se adapten a las necesidades del proyecto.

A continuación se detallarán, para cada uno de los grupos de procesos de un

proyecto, cuál es su objetivo, necesidades y las técnicas aplicables de acuerdo a lo

definido en la Tabla XIV. Además se analizarán las particularidades de la aplicación de

cada técnica de acuerdo a los requerimientos de la fase analizada.

5.4.1- INICIACIÓN

1- Objetivo: El objetivo de este grupo es definir claramente que es lo que se hará y

lo que se espera del proyecto. En este grupo de procesos se debe establecer

también la viabilidad del proyecto o de la fase correspondiente y se plantean las

alternativas de solución.

En el grupo de procesos de iniciación, también se describe el mecanismo de

selección de alternativas de solución y se detallan los motivos que llevaron a la

selección de una determinada opción. Además es en la iniciación donde se

verifica que los objetivos del proyecto se encuentren alineados con el plan

estratégico de la organización.

2- Necesidades: En este grupo de procesos se debe poner espacial atención a como

se manejará la relación con las personas involucradas y, especialmente, como se

las interioriza y se les transmite la importancia y relevancia del proyecto como

así también el alcance y limitaciones del mismo. Para poder conseguir esto es

que se debe tender siempre a lograr un alto nivel de participación y compromiso

de los interesados, de modo que se sientan parte integrante del proyecto.

En la iniciación, el rol del sponsor y de los satkeholders es fundamental, ya que

son quienes avalarán e impulsarán el proyecto siempre y cuando lo que se

plantee en dichos documentos sea acorde a lo que ellos esperan. Además en este

grupo de procesos es necesario tener una primera aproximación de los tiempos

necesarios para llevar adelante el proyecto y de los costos asociados al mismo.



110

En este grupo de procesos, la mayoría de los encuentros con el cliente y las

actividades a realizar se suelen organizar bajo la forma de reuniones. Es por este

motivo que es de vital importancia tener muy en claro las pautas a considerar al

momento de organizar una reunión.

3- Técnicas a utilizar: De acuerdo al objetivo del grupo de procesos y de las

necesidades detectadas en el mismo respecto de la administración del factor

humano, en la Tabla XIV se indican como aplicables las Reuniones, Foros de

Discusión, Listas de Correo, Mensajería Instantánea, Puntos de Función y

Diagramas de Gantt.

Reuniones

En el caso de las reuniones que se llevan a cabo durante la iniciación, se

deben tener en cuenta algunos aspectos que tienen mayor importancia respecto de

los ya mencionados anteriormente.

En este caso particular es importante que se tomen en cuenta y se le preste

mucha atención a todas las opiniones y sugerencias de cada uno de los participantes,

se analicen y finalmente se determinen si influirán o no en el objetivo y alcance del

proyecto.

Otro aspecto en el que se debe poner atención, en la preparación y posterior

ejecución de la reunión, es el lugar físico donde se realizará el encuentro y la

disposición de cada uno de los participantes.

En cuanto al lugar de encuentro, es conveniente que cuente con buena

iluminación, silencio y que no existan interrupciones por parte de terceros. Es

conveniente que se cuente con material de apoyo necesario para poder expresar los

conceptos. En este sentido es importante contar con pizarrón, marcadores, proyectos

y PC, ya que de esta forma se puede desplegar una amplia gama de técnicas para

transmitir los conceptos y lograr que los mismos queden claros.

En lo que refiere a la disposición de los participantes, en las reuniones de

iniciación de proyecto el número de integrantes suele ser reducido, no más de 4 o 5

personas, por lo cual es conveniente que se realicen en una mesa redonda, donde

todos puedan verse y donde no haya mucha distancia entre las personas, de modo

que todos puedan escucharse mutuamente.



111

Otro de los aspectos que no se debe descuidar es el armado del proceso de

facilitación. Nunca se debe olvidar que la mayoría de las reuniones no fracasa por

un mal armado de la agenda sino por la ausencia o pobreza en el proceso de

facilitación de la misma.

La reunión debe comenzar con una breve presentación de cada uno de los

participantes (en caso de ser necesario) y luego una introducción que estará a cargo

de quien es el facilitador de la reunión. En dicha presentación se explicará el tema

que se tratará en el encuentro y para dicha explicación, el facilitador se puede valer

de transparencias, gráficos, cuadros, videos o cualquier otro elemento que se

considere útil para facilitar la comprensión del tema. Es importante que en los días

previos a la reunión, se haya entregado a los participantes el orden del día con los

temas a tratar.

Cada vez que sea necesario comenzar con la discusión de un nuevo tema, se

debe tener en cuenta las técnicas presentadas anteriormente para iniciar un debate.

Es conveniente además, que haya un encargado de documentar todo lo que

se discute en la reunión, de modo que queden plasmadas las diferentes opiniones

expuestas, lo que luego será de gran utilidad para poder elaborar las conclusiones de

la reunión. Respecto de las conclusiones, se deben tener siempre presentes las

técnicas para cerrar debates.

Una vez finalizada la reunión, se debe confeccionar una memoria con las

conclusiones y acuerdos alcanzados durante la misma, y repartir dichos documentos

entre todos los participantes a modo de recordatorio de los acuerdos realizados y los

pendientes (si es que existieran).

Las actividades del facilitador se reducen a tres acciones principales (además de

dirigir el proceso):

1. Preguntar: El facilitador debe estar muy atento al desarrollo de la reunión e

interrumpir para preguntar o repreguntar todo lo que crea necesario, ya sea para

aclarar algún tema o para fomentar la participación de todos los asistentes. Estas

preguntas deben ser breves y claras para no desviar el foco de la discusión.

2. Recopilar: Se debe ir recopilando las diferentes ideas expresadas durante el

desarrollo del encuentro, de modo que se vayan ordenando la producción de las

mismas.



112

3. Resumir: Se deben sintetizar las diferentes ideas expresadas durante el desarrollo

del debate para luego presentarlas como posibles alternativas de acción y

facilitar la toma de decisiones del grupo

Estas tres actividades deben realizarse con la mayor naturalidad posible y

evitando que esto afecte el desarrollo de la reunión.

Siempre se debe tener en cuenta que la duración de una reunión es un factor

que influye en los resultados de la misma. En el caso de las reuniones que se

realizan durante los procesos de iniciación, hay que tener en cuenta que los

principales implicados son miembros de la alta gerencia de la organización, por lo

cual se debe evitar quitarles demasiado tiempo ya sea por una reunión extensa o por

una cantidad excesiva de reuniones. Antes de convocar hay que analizar si

realmente el tema justifica la realización de la misma o si es algo que, o bien se

puede solucionar por otros medios o bien se puede aplazar para tratarlo en otro

encuentro junto con otros temas.

Hay que tener muy presente que una buena comunicación es fundamental

para lograr una reunión de trabajo exitosa, y es por ello que hay algunos puntos que

son importantes para mejorar la comunicación, dentro de ellos los más importantes

son:

� Las palabras tienen diferentes significados para las personas, por lo cual es

necesario asegurarse que al momento de utilizar un término todos entiendan

a que se está haciendo referencia.

� La comunicación no solo es verbal, sino que además tiene un componente no

verbal que muchas veces indican más que las propias palabras.

Foros de Discusión

En el caso de los foros utilizados durante el grupo de procesos de iniciación

tiene particular importancia en el hecho de hacer más dinámicas las comunicaciones

entre las partes interesadas.

De acuerdo al funcionamiento te esta herramienta, se puede crear un foro en

la cual los involucrados en el grupo de procesos puedan realizar sus consultas y

evacuar todas las dudas sin necesidad de realizar una reunión para ello. Además,

como las consultas son públicas pueden ser vistas por todos los participantes se

cuenta con la facilidad de que cada uno puede dejar su comentario/sugerencia

respecto de un tópico en particular.



113

Otra de las ventajas que tienen los foros es que son relativamente fáciles de

utilizar y no se requieren grandes conocimientos de informática para ello, con lo

cual, si alguno de los involucrados posee escasos conocimientos de informática,

podrá utilizarlos sin mayores inconvenientes. Esta herramienta es útil cuando los

involucrados en la iniciación del proyecto no se encuentran en ubicaciones

geográficas muy distantes, donde la organización de una reunión requiere de un

tiempo considerable e implica la necesidad de que los asistentes tengan que recorrer

distancias considerables para participar de la misma.

Listas de Correo

Las Listas de correo son sumamente útiles en este grupo de procesos. Esta

importancia radica, además de en la agilización de las comunicaciones, en la

efectividad para que los mensajes lleguen a los destinatarios. A diferencias de los

foros de discusión, las listas de correos hacen que los mensajes que se envían a las

mismas lleguen directamente a la casilla de correo electrónico de cada uno de los

integrantes de dicha lista. De esta manera se elimina la necesidad de que cada

persona deba ingresar específicamente al foro para verificar si existen mensajes

nuevos.

La ventaja principal es que en la actualidad el correo electrónico es una

herramienta de uso corporativo generalizado en todas las organizaciones y en todos

los niveles, por lo cual no hay prácticamente inconvenientes para su implementación

y no suelen requerir ninguna capacitación previa a la implementación.

Dado que la mayoría de los miembros de una organización chequean sus

casillas de correo electrónico varias veces en el día, los mensajes llegan con mayor

celeridad que en los foros.

La recomendación es que, independientemente del uso de otras herramientas

para la comunicación, es conveniente que siempre se utilice la lista de correo ya que

es una herramienta muy sencilla y fácil de implementar.

Aplicadas al grupo de procesos de iniciación, las ventajas de las listas de

correos son prácticamente las mismas que los foros de discusión, es decir: agilizar la

circulación de información, realizar discusiones sobre ciertos tópicos sin necesidad

de una reunión y evacuar las dudas que se generen. Además también son muy útiles

en caso de que haya involucrados en ubicaciones geográficas muy distantes.



114


Esta es una de las herramientas más nuevas dentro de las que se mencionan

para ser utilizadas en este grupo de procesos. La mensajería instantánea, como ya se

analizó anteriormente, cuenta con la ventaja de ser una herramienta en línea. Esto

significa que cuando dos personas se comunican a través de esta herramienta, la

comunicación se realiza en tiempo real.

Si se analizan las ventajas de la implementación de la mensajería

instantánea, se puede llegar fácilmente a la conclusión de que en cuanto al

dinamismo de la circulación de información es la más conveniente. Sin embargo

cuenta con una característica que pede tornarse en desventaja: requiere la presencia

instantánea de las partes para que la comunicación sea llevada a cabo. Esto es

necesario ya que si una de las personas abandona la herramienta, no hay forma

deque el otro reciba la información. Este inconveniente no se presenta en las listas

de correo ni en los foros, ya que la información se encuentra disponible en ellos el

100 % del tiempo, de modo que puede ser consultada en todo momento por los

involucrados.

En el caso particular de la iniciación de un proyecto, la mensajería

instantánea resulta sumamente útil cuando se deben resolver temas urgentes y no

hay tiempo de organizar una reunión, de modo que se puede iniciar una conferencia

de voz donde todos puedan participar de la discusión y resolver el tema con mayor

celeridad. Pero por otro lado requiere de algunos conocimientos más de informática

por parte de los involucrados. Aunque en la actualidad esta herramienta ha adquirido

mucha popularidad llegando a ser en muchos casos de uso corporativo.

De todos modos lo recomendable es que el uso de esta herramienta en el

grupo de procesos de iniciación vaya siempre acompañada del uso de al menos o

una lista de correo o un foro de discusión.

Puntos de Función

El uso de esta técnica durante la iniciación de un proyecto está orientado

específicamente a la obtención de una primera aproximación del tiempo necesario

para llevar a cabo el proyecto y del costo aproximado del mismo.

Como se analizó con anterioridad, esta técnica permite, con algunos datos

relacionados al proyecto, obtener una estimación del tamaño del proyecto y, por

consiguiente, del tiempo necesario para ejecutarlo y de su costo.



115

Si bien en el grupo de procesos de iniciación no se cuenta con demasiados

detalles acerca del proyecto, se puede obtener la información mínima a

indispensable para realizar un primer cálculo de su tamaño (utilizando puntos de

función) y de esta manera obtener un valor (en puntos de función) que permita

armar un presupuesto y determinar aproximadamente la duración del mismo.

Siempre se debe tener en cuenta que los resultados que se obtengan

carecerán de precisión debido al momento temprano del proyecto en que se aplica,

peor al menos permiten tener una guía para poder comenzar la discusión con las

partes interesadas en el proyecto.

Diagramas de Gantt

El uso de los diagramas de Gantt durante el grupo de procesos de iniciación

tiene como objetivo el permitir tener una visión aproximada de los tiempos que se

insumirán en las tareas que forman parte de un proyecto.

Dado que para su armado no se requiere demasiado nivel de detalle, el diagrama

de Gantt es una herramienta sumamente útil en este grupo. La idea es

fundamentalmente tener una aproximación de la distribución de tareas y dar una

primera impresión de cuál será la duración total de un proyecto. Además, usada en

combinación con la técnica de Puntos de Función permite tener un panorama mas

claro sobre todo el proyecto, aún en un momento muy temprano del mismo como lo

es la iniciación.

Desde el punto de vista de la administración de personas, la principal utilidad

está dada por el hecho de que se puede visualizar como deberán estar

aproximadamente distribuidas las personas. Esto es viable por el hecho de que este

diagrama muestra las dependencias entre tareas y, por lo tanto, se puede estimar sin

demasiado detalle donde deberá ponerse mayos esfuerzo humano.

5.4.2- PLANIFICACIÓN

1. Objetivo: El objetivo de este grupo es definir cuáles son las actividades que se

realizarán dentro del proyecto, la dependencia de las mismas, su duración como

así también los riesgos asociados al proyecto. En este grupo de procesos,



116

también se identifican cuales son las restricciones del proyecto y se definen

cuales son los entregables de cada una de las actividades.

2. Necesidades: En este grupo de procesos una de las necesidades mas importantes

es la de poder estimar aspectos del proyecto tales como el tamaño del mismo y

del producto a desarrollar, la duración total del proyecto y la duración de cada

una de las etapas. Estas estimaciones resultan fundamentales para poder

planificar correctamente cómo será la distribución del equipo a lo largo del

proyecto, cómo se asignarán las responsabilidades y qué tareas se asignarán a

cada integrante del equipo.

Durante este grupo de procesos se realiza la distribución de los recursos en las

diferentes etapas y actividades, y también se necesita tener una visión más

aproximada de cual será el costo del mismo. Esto significa que, durante la

planificación de un proyecto se necesitan técnicas que permitan obtener una

estimación lo mas certera posible sobre cada una de las variables que inciden

sobre el mismo. Es por ello que es uno de los grupos de procesos donde se

pueden aplicar la mayor variedad de técnicas.

Desde el punto de vista de la administración del factor humano, lograr una

correcta planificación de un proyecto, es fundamental para que luego, durante el

resto del mismo, las personas puedan manejarse con tranquilidad y con

comodidad, evitando sobrecarga de trabajo o realización de horas extras.

3. Técnicas a utilizar: Si se analiza el objetivo del grupo de procesos de

planificación y las necesidades planteadas en el mismo, se determina que las

técnicas aplicables en la administración del factor humano son: Reuniones,

Wikis, Foros de Discusión, Listas de Correo, Mensajería Instantánea,

COCOMO, Puntos de Función, Estructura Desglosada de Trabajo, Diagramas de

Gantt, CPM, PERT, Técnica de Grupo Nominal, Técnica Delphi y Análisis

Estadístico.

Reuniones

En el momento de realizar la planificación de un proyecto, las reuniones son

una técnica que tiene especial utilidad en la recopilación de información de

diferentes fuentes. Esta información es importante para poder hacer una

planificación confiable y exacta. En este caso son aplicables la mayoría de los ítems

mencionados para las reuniones que se llevan adelante durante la iniciación,



117

especialmente aquellos relacionados con la administración de los espacios físicos y

la disposición de los participantes. La diferencia radica en que, en este caso, los

asistentes pertenecen a áreas operativas de la organización, es decir, que son los

futuros usuarios del producto final.

El hecho de que quienes asistan a las reuniones sean los futuros usuarios del

producto o los responsables de las áreas impactadas por el mismo puede explicarse

por la necesidad de obtener información exacta y relevante. Esta información es

necesaria para conocer los aspectos específicos relacionados tanto con los procesos

como los procedimientos que serán afectados por el proyecto. De aquí es que se

hace necesaria la asistencia de personas con conocimientos de dichos procesos y

procedimientos. Este tipo de reuniones se denominan Reuniones de Relevamiento.

Las reuniones de relevamiento son encuentros focalizados en el objetivo

principal de obtener información acerca de ciertos temas en particular. En el caso de

los proyectos de TI, estas reuniones tienen dos objetivos: comprender las

necesidades de información de las áreas involucradas y comprender los procesos /

procedimientos afectados por el proyecto. En este tipo de reuniones, el facilitador

debe tener en claro cuales son los procesos, procedimientos y áreas afectadas, de

modo que se pueda dirigir el encuentro y guiarlo hacia el cumplimiento de las metas

de recopilación de información.

En cuanto a la cantidad y el tipo de asistente de las reuniones de

relevamiento, se puede decir que variarán de acuerdo con el proceso/procedimiento

y las áreas.

En el caso de procesos/procedimientos que involucran a más de un área, es

conveniente que asistan entre uno y dos representantes de cada área. La idea es

poder comprender todo el circuito, detectar las necesidades de información de cada

afectado e incluso determinar los casos en que desde lugares diferentes se requiere

la misma información. Además en estas reuniones se pueden determinar los

circuitos administrativos y detectar las mejoras que pueden realizarse en los mismos

(se debe tener presente que los proyectos de TI no solo involucran tecnología y

software sino también procedimientos administrativos realizados por personas).

Si bien anteriormente no se menciona, también pueden asistir a estas

reuniones otras áreas que, sin ser afectadas por el proyecto, tienen interés en el

mismo o en el tema a analizar en la misma. Además puede que en alguno de estos



118

encuentros se involucre al sponsor o a los stakeholders con el objetivo de conocer

sus necesidades de información asociadas al proceso/procedimiento analizado.

Finalmente se puede concluir diciendo que para las reuniones de

relevamiento es necesario:

� Identificar el/los procesos/procedimientos a relevar.

� Identificar las áreas afectadas por los mismos.

� Identificar las áreas que requieren información de los mismos.

� Identificar los actores claves de cada área.

� Focalizar el encuentro en lograr la obtención de información con el

mayor grado de exactitud posible y que resulte relevante para las

necesidades del proyecto.

Wikis

En el caso de la planificación de un proyecto, las wikis también se

transforman en una herramienta útil. Las mismas permiten dar soporte a las

actividades que en este grupo de procesos se realizan y que tienen relación con la

administración del factor humano. Dado que la recopilación de información y la

generación de documentos tales como el cronograma de actividades y precedencias,

las wikis cobran utilidad al momento de compartir esta información.

Dado que en general los documentos se crean y luego son revisados,

corregidos y versionados, esta herramienta permite fácilmente publicar la

información a todos los usuarios. Además, se pueden almacenar las diferentes

versiones del documento de modo que se encuentran accesibles desde una intranet

para todos los usuarios interesados en ver los mismos.

Si bien las wikis permiten que los demás usuarios puedan editar el contenido

de las mismas, también es posible que solo puedan visualizar el contenido de las

mismas sin poder editarlo. Además pueden dejar sus comentarios/agregados los

cuales luego pueden ser revisados en el transcurso de una reunión.

Desde el punto de vista de la administración del factor humano dentro de un

proyecto de TI, las wikis permiten lograr una mayor agilidad en las comunicaciones

y también fomentar la participación de los usuarios, ya que quienes tengan permiso

para hacerlo pueden comentar y/o modificar un contenido de modo que se enriquece

el mismo.



119

La única limitación que puede presentarse en esta herramienta, y que debe

ser considerada, es que es necesario que para editar un tema los usuarios deben tener

ciertos conocimientos mínimos. Es por ello que se recomienda el uso de la Wiki

solo para grupos o comunidades de personas que están altamente involucrados en el

proyecto y que, por lo tanto, cuentan con los conocimientos necesarios para la

utilización de la Wiki.

Listas de Correo

En el caso de las listas de correo, su implementación y utilidad dentro del

grupo de procesos de planificación es básicamente el mismo que para la iniciación

de un proyecto. Esto se puede resumir en los siguientes puntos:

� Proveer mayor dinamismo en las comunicaciones.

� Permitir distribuir en forma muy sencilla y rápida documentos

generados por los procesos de planificación.

� Proveer una herramienta simple y accesible para todos los

involucrados.

� Facilitar el intercambio de opiniones acerca de ciertos tópicos cuando

los involucrados en la discusión se encuentran en ubicaciones

geográficas muy distantes.


El caso de las ventajas de mensajería instantánea aplicada al grupo de

procesos de planificación también es coincidente con el grupo de procesos de

iniciación. Es decir que nuevamente se trata de agilizar las comunicaciones de modo

que, cuando los interesados están en línea, se pueden resolver en pocos minutos

ciertas cuestiones que de otra manera tomarían mayor tiempo.

Al estar frente a una herramienta que tiende a ser de uso corporativo en

muchas organizaciones, su aplicación tiene un costo muy bajo y redunda en grandes

mejoras en la comunicación.

En cuanto a las restricciones e inconvenientes, se deben considerar los

mismos aspectos mencionados en la iniciación, es decir que se recomienda que su

aplicación vaya acompañada de otra herramienta tal como las listas de correos o los

foros de discusión.



120

Puntos de Función

El método de estimación por Puntos de Función se transforma en una

técnica útil para la planificación debido a la necesidad que se presenta en este grupo

de procesos de poder tener una primera aproximación del tamaño del proyecto. En el

grupo de procesos de planificación es necesario conocer el costo asociado al

proyecto para poder comenzar a construir el cronograma del proyecto, la EDT

(Estructura de Desglose del Trabajo), determinar la distribución de cada uno de los

miembros del equipo a lo largo de todo el proyecto y determinar cuáles serán los

hitos del mismo. Es por ello que se requiere el uso de técnicas que permitan tener

una estimación lo mas aproximada posible de dichos aspectos.

La estimación por puntos de función, es una técnica muy conocida y

utilizada en todos los proyectos y debido a ello es que se recomienda su uso durante

este grupo de procesos. Si bien es probable que aún no se conozcan con exactitud

algunos ítems requeridos para tener una estimación mas exacta, su uso puede

combinarse con otras técnicas tales como COCOMO de modo que se puedan tener

varios resultados que ayuden a tener un panorama mas claro al respecto.

Desde el punto de vista de la administración de las personas dentro de un

proyecto, los puntos de función tienen importancia debido a que, cuanto mas exacta

sea la estimación de tiempos, mejor será la distribución del equipo y se llegará con

mayor tranquilidad a la finalización del proyecto. Pero se debe considerar que, para

que esta técnica resulte más eficiente en la administración de personas, es

conveniente contar con una base de conocimientos de proyectos anteriores. Esto se

debe a que no todos los equipos realizan las mismas tareas en iguales tiempos, por

lo cual es conveniente que se cuente con antecedentes de proyectos. De este modo

se pueden tomar como base de cálculo aquellos antecedentes de proyectos similares

que hayan sido desarrollados con equipos de similares características y obtener una

aproximación de mayor exactitud.


La utilización de esta técnica durante la planificación de un proyecto, tiene

especial utilidad cuando se debe realizar las estimaciones de tiempo, costos y

recursos necesarios para el mismo.

Complementaria con las técnicas de estimación, la Estructura Desglosada de

Trabajo permite tener una clara visión de todas las tareas involucradas en el



121

proyecto. De este modo se puede comenzar a analizar las tareas desde el nivel mas

bajo de la estructura e ir subiendo en la misma para, al llegar al nivel más alto, tener

una estimación más certera de todo el proyecto.

En lo que respecta a la administración de personas en los proyecto, se puede

decir que en combinación con los diagramas de Gantt, la Estructura Desglosada de

Trabajo provee una clara visión acerca de la distribución de todos los recursos a lo

largo del proyecto. Esto permite que se detecten sobrecargas de trabajo o mala

distribución del personal a lo largo de todo el proyecto.

COCOMO

Al igual que los puntos de función, COCOMO permite obtener una

estimación del tamaño del proyecto y del tiempo y esfuerzo necesario para

concluirlo. Dado a que esta técnica consta de 3 modelos aplicables para la

estimación, es posible aplicarlo en diferentes momentos del avance del proyecto, de

modo que se obtiene estimaciones con diferentes grados de exactitud.

Nuevamente, la utilidad de COCOMO (al igual que los Puntos de Función)

en la administración del factor humano dentro de un proyecto está dada por la

información que provee para la organización del equipo del proyecto. Siempre que

se obtiene una estimación del tamaño de un proyecto, se puede realizar el cálculo

aproximado de las horas/hombre necesarias para llevar adelante el mismo. Si estas

estimaciones son certeras, la distribución del equipo en cada tarea será adecuada y

permitirá que las personas trabajen sin las presiones que se generan cuando los

tiempos se estiman mal y se deben dedicar más horas de las que se habían

planificado para cada persona.

En comparación con la estimación por Puntos de Función, COCOMO posee

la ventaja de ser mas adaptable a diferentes proyectos y además es mas sencillo de

aplicar ya que no requiere demasiada formación previa. Sin embargo en ambas

técnicas de estimación se debe tener en cuenta: ambos métodos están orientados

hacia el desarrollo de software. Esto significa que son muy útiles en el ámbito de los

proyectos que se estudian en el presente trabajo debido a que involucran Tecnología

de Información que generalmente requieren algún desarrollo de software. Pero en

aquellos proyectos donde no hay desarrollo de software, estas técnicas carecen de

utilidad. Es en este punto donde las bases de conocimiento cobran vital importancia,



122

ya que es a través de la experiencia en otros proyectos similares como se obtendrá

una estimación más realista.

Diagramas de Gantt

Dado de estos diagramas fueron concebidos para ser utilizados durante la

planificación de un proyecto, su uso en este grupo de procesos es tanto o más

importante que en cualquier otro grupo.

En la planificación de un proyecto, el diagrama de Gantt permite ver en

forma simplificada todo lo relacionado con la distribución de actividades a lo largo

del tiempo y las dependencias entre las mismas.

También se pueden utilizar este tipo de diagramas para analizar la carga de

trabajo de cada una de las personas. Este gráfico es semejante al de la distribución

de actividad pero tiene por objetivo proporcionar una visión de carga total de trabajo

aplicada a cada recurso. En él se indica el periodo durante el cual el recurso estará

disponible para el trabajo (representado por una línea fina) y la carga total de trabajo

asignada a este recurso (representado por una línea gruesa).

Dado que esta técnica presenta ciertas limitaciones en grandes proyecto, su uso

se recomienda en combinación con CPM o PERT de acuerdo a las necesidades de

cada proyecto.

CPM

Una de las necesidades del grupo de procesos de planificación, es poder

tener una visión clara de cuáles son las actividades que se deberán realizar dentro

del proyecto, la secuencia de las mismas, sus dependencias y la duración de cada

una. Es en esto donde el Método del Camino Crítico (CPM) cobra relevancia y

utilidad ya que permite visualizar muy fácilmente la distribución y dependencia de

cada una de las actividades de modo que su análisis resulta muy sencillo. Además

con dicha distribución se puede tener una visión mas acertada de cómo deberá

distribuirse el equipo dentro del proyecto. Es en este sentido donde su aplicación es

importante al momento de administrar el factor humano ya que permite detectar

sobrecarga de trabajo sobre algunas personas y holguras en otras.



123

PERT

El uso de PERT como una técnica importante en la administración de las

personas involucradas en un proyecto de TI, tiene la misma utilidad que las

mencionadas para CPM Esto significa que la ventaja principal de su uso está

asociada a la “visibilidad” de la distribución de las tareas y los tiempos dentro del

proyecto. De esta forma se puede determinar cuáles serán las tareas que marcarán el

camino crítico del proyecto, de modo que se brinde mayor atención a como se

asignan las personas a las tareas que forman dicho camino.

Por otro lado se pueden detectar ítems como la holgura de una tarea, de

modo que se puede manejar de modo eficiente la asignación de personas, evitando

que éstas tengan períodos prologados sin actividad dentro del proyecto, lo cual

puede causar desmotivación o frustración.

En comparación con CPM, la ventaja de PERT es que es probabilístico y

que, al considerar al tiempo como una variable desconocida, puede resultar es una

distribución más realista de los tiempos.

Técnicas de Grupo Nominal y Delphi

La aplicación de este tipo de técnicas durante el grupo de procesos de

planificación tiene como objetivo dar soporte a todas las actividades relacionadas

con la planificación de los recursos humanos. En todo proyecto es fundamental la

determinación de la cantidad de personas que serán necesarias para llevar adelante

el mismo. En algunos casos, la cantidad de personas disponibles es conocida de

antemano y por tanto tenida en cuenta para la planificación y estimación de tiempos.

Pero en otros casos, se desconoce la cantidad de personas con que se contarán y, por

consiguiente, se deberá contar con una estimación de los recursos necesarios. Es en

este punto donde estas dos técnicas cobran importancia.

Ambas técnicas se basan en la experiencia de las personas que participan, de

modo que es importante realizar una correcta selección de quienes estarán

involucrados en las mismas.


Al igual que el Grupo Nominal y Delphi, esta técnica tiene como objetivo

dar soporte a la planificación de los recursos humanos necesarios para llevar

adelante el proyecto. En este caso no se trata de una técnica en la cual participan



124

personas en el proceso de estimación, sino que solo se proveen datos históricos a un

proceso computarizado el cual, de acuerdo a ciertas variables, determinará la

disponibilidad de recursos.

La importancia de su implementación radica en que, al utilizarse información

histórica de la organización, la predicción es más cercana a la realidad. Además

puede ahorrar tiempo en las estimaciones aunque, como contrapartida, posee la

desventaja de ser más compleja y requerir ciertos conocimientos previos para poder

aplicarla.

5.4.3- EJECUCIÓN

1. Objetivo: El objetivo del grupo de procesos de ejecución es poner en marcha

todas las actividades y las personas que están involucradas en el proyecto para

llevar adelante todo lo definido durante la planificación.

2. Necesidades: Este grupo de procesos implica coordinar todos los recursos y las

personas involucradas en el proyecto de acuerdo a lo planificado. Es en este

momento donde la administración de personas resulta crítica. Esto se ocurre

debido a que la mayor parte de las actividades que se ejecutan a lo largo de todo

el proyecto se concentran en este grupo de procesos y es donde, por lo general,

se suelen suceder los conflictos y las diferencias en el modo de resolver los

problemas o abordar las diferentes situaciones. También hay que tener en cuenta

que la mayoría de los retrasos en un proyecto se dan durante la ejecución y esto

es probable que ocurra por una mala organización del trabajo, dentro de lo que

también se enmarca la administración de las personas (coordinación,

organización, motivación y comunicación). Es por ello que se debe prestar

especial atención a este aspecto y seleccionar las técnicas mas adecuadas para

que esta administración resulte exitosa y redunde en beneficios para todos.

3. Técnicas a Utilizar: Considerando las necesidades planteadas para este grupo de

procesos, se determina que las técnicas a utilizar son: Reuniones, Wikis, Foros

de Discusión, Listas de Correo, Mensajería Instantánea, Comités de Desarrollo,

Programación de a Pares y Comités de Usuarios.



125

Reuniones

En el caso de las reuniones aplicadas al grupo de procesos de desarrollo,

permite realizar un análisis más detallado y exhaustivo acerca de las formas de

aplicación de las mismas. Esto se da a causa de que la ejecución involucra una gran

cantidad de variables que deben ser tenidas en cuenta y, por lo tanto, requieren de

reuniones de diferentes características para poder tener la información necesaria. A

continuación se presentarán los diferentes tipos de reuniones aplicables durante la

ejecución de un proyecto de TI.

La primera reunión que se tendrá al momento de comenzar con el grupo de

procesos de ejecución es la Reunión Inicial. Quizás resulte redundante hablar sobre

esta reunión ya que, en casi todos los proyectos, de una u otra manera esta reunión

se lleva a cabo. Pero de todos modos se le dedicará tiempo para listar que ítems

deben estar presentes en la misma.

- El primer aspecto que se debe considerar es el objetivo de la reunión: Este

encuentro se realiza para dejar en claro a todo el equipo de proyecto cual es el

objetivo del mismo, como será la metodología de trabajo, cuáles son los tiempos

con los que se dispone, como se manejarán formalmente las comunicaciones

(algo que ya estará definido en el Plan de Comunicaciones) y cuales son las

pautas de trabajo.

- El segundo aspecto que se debe tener en cuenta es que este encuentro debe

realizarse una vez que el equipo de proyecto está conformado y deben estar

presentes todos los integrantes de dicho equipo. La razón para exigir esto es

simple: esta reunión resulta clave para que cada uno comience a tomar contacto

con el proyecto y con la metodología de trabajo que se pretende implementar. Si

bien la mayoría del equipo ya ha participado de una u otra forma en las los

procesos anteriores, puede que haya miembros del equipo que se integren recién

al momento de comenzar con la ejecución del mismo.

- El cuarto aspecto a considerar es como se llevará adelante esta reunión y en que

orden se realizará cara actividad planteada para la misma. En este caso se

propone el siguiente cronograma:

� Presentación formal del líder de proyecto y breve explicación de las

actividades que realizará y de sus responsabilidades.

� Breve introducción al proyecto indicando objetivos del mismo y los tiempos

con los que se cuentan para su finalización.



126

� Presentación de cada uno de los integrantes del equipo de proyecto

indicando el rol que cumplirá dentro del equipo.

� Presentación de la estructura del equipo, es decir, explicar como se

distribuyen las responsabilidades y que roles dependen de cada responsable.

En este caso puede resultar útil el armado de un organigrama en el cual se

indique en que lugar del mismo se encuentra cada uno de los presentes.

� Breve presentación en la cuál se explica la filosofía de trabajo y de cuáles

serán las pautas básicas a seguir, tanto en las comunicaciones (de acuerdo a

lo definido en el Plan de Comunicaciones) como el la ejecución de las tareas

de cada miembro del equipo.

� Atención de cualquier consulta por parte de los presentes y referida al

proyecto y los temas presentados previamente.

Esta reunión debería realizarse o bien el primer día de trabajo de todo el

equipo, o bien en algún día previo al mismo. Lo recomendable es que se haga el

primer día de trabajo y que una vez finalizada la misma cada grupo se dirija a su

lugar de trabajo y comience con sus actividades.

Si bien esta reunión está presentada y planteada para el líder del proyecto,

puede ser tomada también por los mandos intermedios del equipo para luego

presentar a su grupo de trabajo todo lo relacionado con las actividades que le

competen. Esto es posible cuando cada grupo se concibe como un subproyecto, sin

perder de vista los objetivos del proyecto principal.

Las Reuniones Diarias tienen lugar una vez que comienzan las actividades

en cada grupo de trabajo dentro del proyecto ya que es muy importante realizar un

seguimiento muy minucioso del avance de las actividades. Esto es esencial para

poder identificar puntos críticos o problemas que puedan causar retrasos o generar

inconvenientes en la realización de las tareas del equipo de trabajo.

Las reuniones diarias son una herramienta que, bien aplicada, resulta muy

útil para detectar problemas en forma temprana y evitar los desvíos que surgen en el

día a día de cada proyecto. Pero estas reuniones deben cumplir con una serie de

características para que sean eficaces y útiles al proyecto. A continuación se

presentan los ítems a tener en cuenta:



127

� El encuentro se debe realizar al principio del día antes de comenzar la

jornada laboral.

� La duración no debe exceder los 10 o 15 minutos como máximo.

� Deben estar presentes todos los integrantes del quipo.

� Cada integrante debe responder brevemente las siguientes preguntas:

a. ¿En qué estado están sus actividades?

b. ¿Qué tiene planeado hacer en el día de hoy?

c. ¿Necesita ayuda con algo?

La idea de este encuentro es que cada integrante del equipo este al tanto del

avance de las actividades del resto. Además se favorece la comunicación y la

participación de todos ya que si algún miembro presenta algún problema

relacionado con sus actividades dentro del proyecto, quizás alguien del resto del

quipo pueda colaborar con alguna propuesta de solución.

Por otra parte esto permite, al responsable del equipo, detectar a tiempo

cualquier retraso e iniciar las acciones que crea convenientes para corregir dicho

desvío.

En caso de que se manifieste un inconveniente que necesite ser tratado más

en detalle, se dejará pendiente dicho punto para continuar la rueda con los demás

integrantes y, al finalizar la reunión, se seguirá el tema con le involucrado. Esto es

para evitar que el encuentro se extienda más allá del tiempo sugerido y se permita al

resto del equipo continuar con sus actividades.

Una vez finalizada la reunión, cada uno vuelve a sus actividades habituales.

Por otro lado, las Reuniones de Avance, si bien son aplicables a todos los

grupos de trabajo de un proyecto, representan una herramienta fundamentalmente

útil para el líder de proyecto ya que permite medir el grado de avance general de los

diferentes grupos de trabajo dentro del proyecto. Estas reuniones se recomienda que

sean realizadas cada 15 días, aunque este plazo puede extenderse o reducirse de

acuerdo a las características de cada proyecto y, fundamentalmente, de los tiempos

del mismo.

El objetivo de la reunión de avance es proveer al líder de proyectos de una

visión global del estado de las diferentes actividades dentro del proyecto. En esta

reunión deben participar el líder del proyecto y los encargados de los diferentes

grupos de trabajo. Allí cada uno de los encargados expondrá el grado de avance de

su grupo y, en caso de existir, expondrás las dificultades con las que se ha



128

encontrado y las consecuencias de las mismas en el cumplimiento de los objetivos

de su grupo.

La duración recomendada de esta reunión es de no más de dos horas,

dependiendo de la cantidad de asistentes y de la frecuencia con la que se fije la

realización de dicho encuentro. Se debe tener en cuenta que cuanto menor es la

frecuencia de reunión, probablemente mayor será la duración de la misma.

Wikis

En el caso de la ejecución de un proyecto, las wikis también se transforman

en una herramienta útil. Al igual que en los casos anteriores, tienen como utilidad

principal el dar soporte a las actividades que en este grupo de procesos se realizan y

que tienen relación con la administración del factor humano. En este caso particular,

las wikis permiten que todo el grupo pueda encontrar en ella toda la información

necesaria para su trabajo. Esto incluye: información de contacto de los diferentes

grupos/miembros del equipo, documentos relacionados con la planificación,

plantillas para la generación de documentación, calendario de reuniones y cualquier

otra información que se decida colocar en el sitio. También se pueden almacenar las

diferentes versiones del documento de modo que se encuentren accesibles desde una

intranet para todos los usuarios interesados en ver los mismos.

Si bien las wikis permiten que los demás usuarios puedan editar el contenido

de las mismas, también es posible que los usuarios solo puedan visualizar el

contenido sin poder editarlo. Además pueden dejar sus comentarios/agregados los

cuales luego pueden ser revisados en el transcurso de una reunión. Todo esto

nuevamente apunta a lograr una mayor agilidad en las comunicaciones y también

fomentar la participación de los usuarios y la colaboración entre los miembros del

equipo de trabajo.

Listas de Correo

En el caso de las listas de correo utilizadas durante la ejecución el proyecto,

sus beneficios son los mismos que los planteados para el grupo de planificación, es

decir:

� Proveer mayor dinamismo en las comunicaciones ya que durante los

procesos de ejecución, el dinamismo y la agilidad en todos los

sentidos resulta un factor crítico de éxito.



129


generados.


involucrados.

� Facilitar el intercambio de opiniones acerca de ciertos tópicos cuando

los involucrados en la discusión se encuentran en ubicaciones


Foros de Discusión

El caso de los foros de discusión aplicados a los procesos de ejecución,

tienen la ventaja de permitir la comunicación de los miembros del equipo sin la

necesidad de tener que movilizarse a otras ubicaciones físicas.

Básicamente este caso es una combinación de algunas de las ventajas de las

wikis (compartir información y contenidos) y las ventajas de las listas de correo

(simplicidad de uso y facilidad de implementación). Esta combinación de ventajas la

convierte en muy atractiva para mejorar la comunicación dentro de un proyecto. Sin

embargo, en comparación con las demás ventajas que ofrecen las dos alternativas

antes mencionadas, no resulta tan conveniente aunque para algunos proyectos con

una estructura mas reducida, su simplicidad puede resultar más atractiva que las

wikis.


El caso de la mensajería instantánea aplicada al grupo de procesos de

ejecución, resulta una herramienta casi indispensable para la comunicación tanto

entre los grupos dentro del equipo como entre los miembros de cada grupo. En este

caso, los beneficios de la mensajería instantánea están más relacionados con los

beneficios de las listas de correo y con el beneficio adicional de ser una herramienta

online.

Esta herramienta se hace especialmente interesante cuando el equipo de

trabajo está distribuido en oficinas diferentes, de modo que las consultas breves o

pedidos simples pueden gestionarse mediante esta herramienta. Sin embargo

siempre se debe tener presente que no es conveniente que reemplace el trato “cara a

cara” excepto que las características del proyecto así lo requieran.



130


Cuando hablamos de la influencia del factor humano en los proyectos de TI,

uno de los primeros factores que se menciona es la influencia que tienen los

usuarios finales del proyecto sobre el éxito o fracaso del mismo. Esta influencia de

los usuarios sobre el resultado final de un proyecto puede ser positiva o negativa de

acuerdo como se maneje esta variable. Es entonces donde aparece la necesidad de

involucrar a los mismos en algunos procesos del proyecto, de modo que se sientan

parte del mismo y que sus opiniones y sugerencias sean tenidas en cuenta por el

equipo de proyecto.

La participación activa de los usuarios dentro del proyecto tiene sus bases en

tres hechos fundamentales:

1- Los usuarios son los encargados de hacer el trabajo y, por lo tanto, son

quienes mejor comprensión tienen del mismo.

2- Los integrantes del equipo de proyecto son lo que poseen el

entrenamiento y la visión sobre las tecnologías de la información y, por

lo tanto, son los que pueden comprender cómo aplicar esas tecnologías

para realizar el trabajo de los usuarios o facilitarles la realización del

mismo.

3- El trabajo en grupo siempre enriquece el resultado final. En este caso si

el grupo de los usuarios (que son los que conocen el trabajo) y el grupo

del proyecto (que conocen las tecnologías) trabajan en conjunto, podrán

lograr un resultado que satisfaga las expectativas de los usuarios con las

tecnologías que considere el equipo de proyecto.

Si se tiene en cuenta estos tres aspectos, puede lograrse un muy buen equipo

de trabajo donde los usuarios formen parte activa del mismo de modo que se cree un

sentido de pertenencia a dicho grupo. Además se aleja la posibilidad de una eventual

resistencia a los cambios generados por la implementación del proyecto. Todo esto

cobra mayor relevancia cuando se trata de un proyecto que incluye el desarrollo de

un producto software destinado a dar soporte a las tareas de las personas que

trabajan dentro de la organización.

Es en este contexto que radica la importancia de la implementación de los

comités de desarrollo, ya que esta técnica facilita la administración de las personas

involucradas en el proyecto y que, como se menciona antes, tienen gran influencia

en el éxito o el fracaso del mismo.



131

Otra de las ventajas en el uso de esta técnica es su adaptabilidad a los

diferentes tipos de proyectos de TI. Su versatilidad permite que no solo se utilice

para aquellos proyectos que involucran desarrollo de software, sino también a

aquellos en los que, por ejemplo, solo se implementan nuevas tecnologías.


Uno de los conceptos asociados al mundo de los sistemas es el concepto de

sinergia, según el cuál “el todo es más que la suma de las partes”. Es exactamente

éste el concepto que transforma a la programación de a pares en una herramienta

muy importante al momento de administrar las personas involucradas en un

proyecto de TI.

La programación de a pares permite que dos personas puedan trabajar sobre

el mismo código, de modo que se poseen dos visiones sobre un mismo tema y se

enriquece el desarrollo. Pero no sólo esta es una ventaja sino que también hay otro

factor que es de gran valor para la administración de personas: la transferencia de

conocimientos.

En los proyectos, la transferencia de conocimientos es otro de los factores

muy importantes a tener en cuenta, ya que es conveniente que varias personas

tengan conocimiento acerca de las actividades que se realizan. Esto facilita la

rotación de las personas y además funciona como plan de contingencia para casos en

que se pierda alguno de los miembros del equipo. Además, sirve como plan de

capacitación para los eventuales ingresos que se produzcan durante la marcha del

proyecto.

La desventaja que se presenta en este caso, es que la programación de a pares

es solo aplicable a proyectos que involucran desarrollos de software, de modo que

todas sus bondades no pueden aprovecharse cuando se trata de otro tipo de

proyectos de IT, aunque algunos ítems podrían adaptarse (por ejemplo en caso de un

proyecto de implementación de nuevas tecnologías, colocar a una persona “novata”

a trabajar con un experto en la instalación del nuevo hardware de modo que se

produzca la transferencia de conocimientos).



132


Para comprender con mayor facilidad la utilidad de esta técnica, es

conveniente primero definir un concepto que está muy relacionado con ella:

Comunidades de Práctica.

Las comunidades de práctica son grupos sociales constituidos con el fin de

desarrollar un conocimiento especializado, compartiendo aprendizajes basados en la

reflexión compartida sobre experiencias prácticas. Una comunidad de práctica

vuelve explícita la transferencia informal de conocimiento dentro de redes y grupos

sociales ofreciendo una estructura formal que permite adquirir más conocimiento a

través de las experiencias compartidas dentro del grupo. Es a partir de estos

conceptos donde queda claro el porqué de la utilidad de los comités de usuarios, ya

que éstos son simplemente espacios donde los usuarios involucrados en el producto

final de un proyecto pueden compartir sus experiencias y trasferir conocimientos a

partir de las mismas.

Si bien se está frente a una técnica que puede ser implementada en más de un

grupo de procesos, su implementación durante la ejecución del mismo tiene

fundamentalmente dos razones:

� Disminuir al máximo el riesgo de resistencia al cambio: se busca que los

usuarios se sientan identificados con el nuevo producto involucrándolos en

las discusiones relacionadas con ciertos aspectos funcionales del mismo.

� Obtener mayor cantidad de información acerca de ciertos requisitos del

proyectos e incluso obtener soluciones creativas y alternativas frente a

ciertos problemas. Esto último se logra gracias a que los usuarios no están

tan compenetrados en el detalle del proyecto y por lo tanto sus ideas pueden

fluir sin ningún tipo de sesgo.

5.4.4- SEGUIMIENTO Y CONTROL

Una de las particularidades de la estructura de grupos de procesos propuestos

por el PMBOK es que la ejecución de los mismos se solapa y que existe una

interacción entre los mismos. Esta interacción está dada por las entradas y salidas

necesarias para cada proceso (la salida de un proceso representa la entrada de otro).



133

Además la superposición hace que muchas veces se estén ejecutando mas de un

grupo de proceso a la vez solo que con diferente intensidad.

La interacción entre los grupos de procesos se puede ver claramente en la

Figura 16.

Figura 19 – Interacción entre los grupos de procesos según el PMBOK [PMI, 2004].

Si analizamos la interacción del grupo de procesos de seguimiento y control

para con los demás grupos, resulta claro que la mayor interacción se da con el grupo

de ejecución. Es a partir de este análisis que se puede plantear como técnicas y

herramientas para la administración del factor humano, a algunas de las

mencionadas en el grupo de ejecución. Para ello habrá que poner mayor atención en

algunos aspectos de dichas técnicas de modo que la información que se obtenga en

las mismas sea útil también para el control y el seguimiento.

A continuación se analizarán que aspectos deben priorizarse y considerarse

en las técnicas aplicadas en la ejecución, para que resulten también útiles en el

control y seguimiento del proyecto.

1. Objetivo: El objetivo de este grupo de procesos es el de monitorear la ejecución

de modo que se puedan detectar problema en forma temprana y poder aplicar

acciones correctivas en caso de que sea necesario.

2. Necesidades: Desde el punto de vista de la administración del factor humano, en

este grupo de procesos, las necesidades se centran básicamente en la



134

recopilación de información y la identificar los posibles puntos de conflictos. La

información de de gran importancia para poder realizar los controles, pero

también para detectar posibles problemas antes de que tengan consecuencias

graves en el proyecto.

Por su parte, la detección de posibles puntos de conflictos es quizás el aspecto

más importante a tener en cuenta ya que es aquí donde la administración de

personas debe poner especial atención.

3. Técnicas a Utilizar: De acuerdo a las necesidades planteadas y según los

objetivos que se persiguen en el grupo de procesos de control, las técnicas a

aplicar son: Reuniones, Wikis, Foros de Discusión, Listas de Correo, Mensajería

Instantánea, Diagramas de Gantt, Estructura de Desglose de Trabajo, PERT,

CPM, COCOMO y Puntos de Función.

Reuniones

Conservando las mismas características que se mencionaron anteriormente

para cada tipo, la reunión es una técnica que claramente permite obtener

información muy valiosa para poder realizar el seguimiento y control del avance del

proyecto. Además también resultan muy importantes para detectar posibles puntos

de conflictos entre integrantes del equipo del proyecto, o entre el equipo y algún

usuario del proyecto.

Durante el seguimiento y control de un proyecto se pueden utilizar los

mismos tipos de reunión que se mencionaron para la ejecución, solo que en este

caso se deberá ponderar algunos otros aspectos para poder obtener información

específica de control. A continuación se analizarán cada uno de los tipos ya

mencionado remarcando los aspectos a considerar para convertirlas en una técnica

útil para el seguimiento de proyectos.

En el caso de las reuniones diarias, se debe prestar especial atención a la

respuesta que se obtiene en las preguntas:

a. ¿En qué estado están sus actividades?

b. ¿Qué tiene planeado hacer en el día de hoy?

c. ¿Necesita ayuda con algo?

Este aspecto es muy importante ya que la respuesta que se obtenga puede

develar algunos problemas que no tengan que ver con la tarea que esté realizando la

persona y que tal vez estén dificulte o haga incómodo su paso por el proyecto.



135

Si bien anteriormente se señaló que este tipo de reuniones no debe

extenderse demasiado en el tiempo y que, si hay inconvenientes y otros temas, se

deben tratar con posterioridad, es importante darle tratamiento a los mismos. En este

sentido lo más recomendable es que una vez que se da por finalizada la reunión, el

facilitador de la misma dedique inmediatamente un tiempo extra a cada uno de los

que plantearon problemas. La idea de este tiempo es poder analizar en más detalle lo

planteado para tratar de encontrar una solución y lograr que la persona se sienta

contenida y escuchada.

Por el lado de las reuniones de avance aplicadas al seguimiento y control de

un proyecto, permiten también controlar el avance del trabajo e identificar

problemas a tiempo para así realizar las acciones correctivas que se consideren

necesarias, e incluso tomar acciones preventivas si así se cree conveniente.

Cuando se realiza una reunión de este tipo es conveniente que el moderador

de la misma tenga presente cuáles son los parámetros dentro de los cuales debería

encontrarse el proyecto para que todo esté en orden. Se debe prestar atención a la

forma en que se avanza en cada uno de los temas como así también la velocidad de

dicho avance. En aquellos casos en que se verifiquen dificultades en el avance, se

debe dedicar un momento a analizar el porqué de las dificultades de forma tal que se

trate de dejar lo mas claro posible las causas para que cada responsable pueda

dedicarse a trabajar en el mejoramiento de las mismas.

Si bien las reuniones de avance tienen la ventaja de tener una duración

mayor que las diarias, cuentan con la desventaja de que la cantidad de temas a tratar

es mayor. Además no se puede ir a un nivel de detalle tan profundo con todos los

temas, de modo que debe tratarse de ahondar solo en aquellos puntos donde se

detectaran problemas o probables conflictos. También se recomienda su uso

combinado con las reuniones diarias de modo que lo que no pueda ser tratado en las

reuniones de avance pueda tratarse en las diarias y, si fuese necesario, solicitar otro

tipo de encuentro para tratar el problema.

Wikis, Foros de Discusión y Listas de Correo

El caso de las Wikis, los Foros de Discusión y las Listas de Correo en este

caso se analizarán en conjunto ya que la utilidad de las tres técnicas aplicadas al

seguimiento y control de un proyecto es básicamente la misma, con las diferencias

que marcan simplemente su forma de funcionamiento.



136

En cualquiera de los tres casos la utilidad está dada fundamentalmente por

dos aspectos: la facilidad para distribuir / recopilar información necesaria para

monitorear el avance del proyecto y la facilidad para imprimir dinamismo en las

comunicaciones. Este segundo aspecto es el que mas importa en lo que respecta a la

administración del factor humano dentro de un proyecto.

Tanto las wikis, como los foros y las listas de correo permiten una fluida y

rápida comunicación entre los miembros de un equipo de modo tal que, si surgiera

algún inconveniente, este puede ser comunicado en forma rápida a todo el resto del

equipo. Además, si en lugar de tratarse de un problema se tratase de un pedido de

información o una consulta acerca de algún tema en particular, el hecho de tratarse

de técnicas que hacen pública información, permitirá tener diferentes opiniones o

sugerencias por parte de los miembros.

Sin embargo, el hecho de que todo lo que se publica es visto por todos los

miembros genera un inconveniente: cuando la consulta debe ser privada porque

afecta a las relaciones con algún otro integrante del equipo o es un tema muy

delicado, no permiten tener privacidad. Esto lleva a sugerir que estas herramientas

se utilicen en conjunto con otras técnicas las cuales permiten tener mayor privacidad

en ciertos temas.


El caso de la mensajería instantánea es justamente la técnica que provee la

solución al problema de privacidad planteado con lo foros, las wikis y las listas de

correo. En este caso la ventaja principal es que la mensajería instantánea permite

mantener contacto entre personas en forma privada, de moso que el resto del equipo

no conozca dicho contacto. La prestación de contacto “persona a persona” es

fundamental en casos donde hay conflictos personales o problemas que requieren un

tratamiento discrecional. Además también tienen la ventaja de que cuando se

requiere información de solo una persona, sólo se contacta a ésta sin molestar al

resto con mensajes que no le corresponden ni interesan.

Como contrapartida, la distribución de contenidos a todo un grupo es un

poco más compleja ya que actualmente no hay herramientas que permitan, por

ejemplo, transferir un archivo a múltiples destinatarios. Es por esto que la

utilización de la mensajería instantánea para este caso se recomienda en

combinación con un Foro, Wiki o Lista de correo.



137

Diagramas de Gantt

Básicamente, el uso de esta técnica en el seguimiento y control de un

proyecto, tiene como objetivo el poder comparar el avance real del proyecto con lo

planificado. Nuevamente en este caso su simplicidad es el factor determinante para

su inclusión en este grupo de procesos.

La ventaja radica en que con una simple revisión de este diagrama y con un

resumen del estado actual del proyecto, se puede determinar si el mismo está

avanzando de acuerdo a lo planificado o si es necesario realizar algún tipo de ajuste.

Uno de los tipos de diagramas de Gantt que se puede utilizar en este grupo

de procesos es el Diagrama de Gantt para seguir la marcha de las actividades. En

este tipo de diagrama se usa el eje vertical para representar actividades, mientras que

los recursos aplicados a cada actividad se indican indicados por medio de claves

sobre la línea que representan la duración de la actividad.

Desde el punto de vista de la administración del factor humano, la utilidad

principal se encuentra en el hecho de poder detectar retrasos en el proyecto en forma

temprana. De este modo se pueden tomar medidas preventivas y/o correctivas para

evitar retrasos en la finalización del mismo y evitar sobrecarga de trabajo en las

personas en las instancias finales del proyecto.


La utilización de esta técnica durante el seguimiento y control de un

proyecto, tiene especial utilidad cuando se debe realizar un seguimiento acerca del

avance de las distintas tareas que comprenden el proyecto.

Las planillas que se obtienen a partir del desglose en tareas, en algunos casos

pueden contener una columna denominada “Porcentaje de Seguimiento” la cual se

actualiza periódicamente según el avance. De este modo, de acuerdo al avance de

cada tarea, se puede subir de nivel y determinar en que estado se encuentra el avance

total del proyecto.

Desde el punto de vista de la administración de personas en los proyecto, se

puede decir que la principal utilidad de esta técnica es la de detectar retrasos en los

cronogramas y evitar sobrecargas sobre el final del proyecto, como así también

evitar las tensiones que conlleva un retraso el en cronograma.



138

En este caso es conveniente su uso en combinación con alguna otra técnica

como lo son CPM o PERT, además de los diagramas de Gantt, los cuales proveen

un panorama más claro sobre el avance del proyecto.

PERT y CPM

Si se observa la Tabla XIV, se notará que ambas técnicas son aplicables

solamente a los grupos de proceso de planificación y de seguimiento y control. El

porque de esto es simple: durante la planificación se utilizan para determinar la

distribución de los recursos a lo largo de todo el proyecto y la asignación de los

mismos a cada una de las tareas. Mientras que en el seguimiento y control del

proyecto, se utilizan los documentos generados el la planificación para monitorear el

avance del proyecto.

En el caso del seguimiento y control visto desde el punto de vista de la

administración de personas, la utilidad de los documentos generados por CPM y

PERT radica en determinar la carga de trabajo de las personas. En muchos casos se

realiza una determinada distribución de tareas durante la planificación, pero luego,

durante la marcha del proyecto, puede que se noten deficiencias en esa distribución.

Esto puede darse porque las estimaciones no fueron lo suficientemente precisas o

porque el desempeño de las personas no es el previsto. Es para detectar este tipo de

inconvenientes que se necesitan de las dos técnicas mencionadas.

Por lo general por si solas no tienen demasiada utilidad ya que, quien se

encarga de hacer el seguimiento del proyecto, debería ir grupo por grupo o persona

por persona viendo como están respecto de lo planificado. Lo ideal es que se utilicen

como material de soporte para las reuniones (diarias y de avance) para poder tener

un panorama de lo que se espera del desempeño del equipo. Además la idea de su

aplicación es monitorear el avance del trabajo de cada persona y detectar cuando

haya sobrecargas y retrasos de modo que se pueda ayudar y evitar tensiones en el

trabajo.

COCOMO y Puntos de Función

El caso de COCOMO y de los Puntos de función aplicados al seguimiento y

control de un proyecto de TI tiene su importancia en el hecho de que durante la

marcha del proyecto pueden surgir cambios. Estos cambios pueden ser menores o

pueden ser cambios sustanciales que impacten en la duración del mismo. En este



139

último caso es que se dará la necesidad de utilizar estas técnicas para redefinir

algunos tiempos y determinar si, de acuerdo a las nuevas definiciones y los nuevos

tiempos calculados, la marcha del proyecto es la correcta.

Nuevamente, al igual que con PERT y CPM, lo que se utiliza en estos casos

son los resultados de éstas técnicas para monitorear la marcha del proyecto y

detectar inconvenientes en la carga de trabajo o cualquier inconveniente que afecte a

los miembros del equipo y que pudiese generar conflictos.

Si bien puede considerarse que, el recálculo de los tiempos cuando se

realizan cambios en las definiciones del proyecto, forma parte del proceso de

planificación, en el presente trabajo también se los incluye en el seguimiento y

control debido al impacto que pueda tener sobre el trabajo el hecho de modificar los

tiempos y la distribución del equipo.

5.4.5- CIERRE

Antes de comenzar con el análisis de este grupo de procesos es necesario

hacer una salvedad: si bien en el caso particular del PMBOK se considera que el

cierre del proyecto concluye con la entrega del producto. El concepto de “entrega”

depende en gran medida de lo que se haya definido en el contrato antes de comenzar

el mismo. Así, puede ocurrir que la entrega del producto sea, por ejemplo, la entrega

de la documentación del sistema y el producto software para que luego el cliente se

encargue de la implementación y puesta a punto del mismo. También puede que la

entrega del producto implique que el sistema y los productos software relacionados

deben estar implementados y puestos en marcha.

A fin de abarcar una mayor gama de posibilidades, en el presente trabajo se

considerará que la entrega del producto se realiza con el sistema funcionando y con

los productos software instalados y puestos en marcha. Realizada esta aclaración se

comenzará con el análisis correspondiente.

1. Objetivo: El objetivo de este grupo de procesos es el de dar por finalizadas cada

una de las actividades de un proyecto, de modo que se pueda dar por terminado

formalmente el mismo.

2. Necesidades: En este caso, considerando la salvedad hecha previamente sobre lo

que se considera como parte del grupo de procesos de cierre, las necesidades de



140

administración de personas se centra especialmente en los usuarios finales. Esto

es de debido a que la mayoría de las actividades que se llevan a cabo están

relacionadas con la implementación y puesta a punto del sistema. Es en este

momento donde resulta crítico el logro de la aceptación del producto por parte

de los usuarios finales.

En el cierre del proyecto es donde aparece con fuerza la posibilidad de

encontrarse con resistencia al cambio por parte de quienes serán los encargados

de operar de acuerdo a las nuevas normas implementadas con el proyecto. De

modo que, cuanto mayor sea la atención que se le dedique al tema y cuanto

mejor organizadas estén las técnicas a implementar para evitar la resistencia al

cambio, mayores serán las probabilidades de obtener una implementación

exitosa.

3. Técnicas a Utilizar: Según lo expuesto en la Tabla XIV, las técnicas a utilizar en

este grupo de procesos son: Reuniones, Wikis, foros de Discusión, Listas de

Correo, Mensajería Instantánea, Comités de Usuarios, Grupos de Apoyo, Mesa

de Ayuda y Estructura Desglosada de Trabajo.


Nuevamente en este caso se analizarán las tres técnicas en conjunto dado que

su utilidad y aplicabilidad es muy semejante entre sí.

La idea de utilizar estas técnicas durante el grupo de procesos de cierre está

fundamentalmente orientada a dar soporte a los usuarios finales. Esto se basa en el

hecho de que, al implementar un nuevo proyecto en una organización, surgirán

dudas acerca del uso tanto del software que se implemente como de las tecnologías

involucradas. En este sentido es que las wikis, los foros y las listas de correo pueden

ser muy bien explotados.

Estas herramientas permiten que los usuarios se puedan comunicar

fácilmente con el grupo del proyecto encargado de la puesta en marcha del mismo,

de modo que sus dudas o comentarios puedan ser recibidos y atendidos en forma

muy simple.

La idea fundamental del uso del foro es el de poder crear un foro de

discusión donde todos los usuarios puedan dejar sus consultas para que el equipo del

proyecto pueda darles una respuesta, o bien lo pueda hacer otro usuario con mas

conocimientos. De este modo se puede crear una comunidad virtual sumamente útil



141

y que además sirve como base de conocimiento. Lo mismo ocurre con las wikis,

aunque en este caso la información será un poco mas estática. Este hecho radica en

que en las wikis se puede colocar documentación y cualquier otro tipo de

información que pueda ser consultada por los usuarios frente a una duda o

requerimiento de información relacionada con el proyecto que se está

implementando.

Finalmente están las listas de correo. Ésta es la más dinámica de las tres

técnicas ya que, al ser el correo electrónico una herramienta de uso masivo y

generalmente corporativo, las respuestas se darán con mayor rapidez que en el caso

de un foro. Además pueden montarse sitios donde todos los mails conformen

también una base de conocimiento en la cuál puedan definirse diferentes criterios de

búsquedas. De este modo los usuarios podrían buscar todos aquellos mails con

consultas relacionadas a un tema particular y, de esta forma, hallar una respuesta a

su consulta sin la necesidad de volver a reiterar un tema vía correo electrónico a la

lista.

La desventaja principal radica en que, al no ser herramientas en línea, las

respuestas a consultas urgentes estarán sujetas a la frecuencia con que el equipo de

proyecto o el resto de los usuarios ingresen al foro, el correo electrónico o la Wiki.


La idea de implementar la mensajería instantánea en el grupo de procesos de

cierre es básicamente la misma que se menciona para el caso de los foros y las listas

de correo, es decir: dar soporte a los usuarios durante la implementación del

proyecto de forma tal que se disminuya todo lo posible la resistencia al cambio.

Además, se genera confianza en los usuarios ya que, por contar con este tipo de

mecanismos para evacuar dudas, se da una sensación de respaldo y acompañamiento

en la implementación.

La diferencia fundamental de la mensajería instantánea es que se encuentra

en línea, lo cual es muy bueno para los usuarios. Pero también tiene una implicancia

no menor en el equipo encargado de implementar el proyecto: probablemente se

requerirá una persona con dedicación completa para atender las consultas. Este es un

dato no menor porque y que se debe tener en cuenta al momento de decidir si se

implementa o no. Por lo general esto puede hacerse a través de una página Web



142

donde los usuarios pueden acceder y conectarse con la persona encargada de atender

las consultas.

La ventaja es clara: las consultas urgentes son atendidas y respondidas de

inmediato, generando satisfacción y aceptación por parte del usuario. La desventaja,

es la ya mencionada: requiere personal con dedicación casi exclusiva para estas

tareas. Dependiendo del tamaño y características del proyecto, la persona encargada

de recibir las consultas puede tener asignadas otras actividades ya que

probablemente no habrá consultas constantes, pero en otros casos la dedicación será

de tiempo completo.

Cada equipo deberá definir el uso o no de ésta técnica en función del grado

de criticidad de la implementación y de la percepción de resistencia al cambio que

se detecte en los usuarios finales.


La implementación de ésta técnica obedece a fundamentalmente a las dos

razones:


usuarios se sientan identificados con el nuevo producto involucrándolos en

las discusiones relacionadas con ciertos aspectos funcionales del mismo de

modo que se asegure una mejor comprensión.

� Generar un espacio donde los usuarios puedan compartir sus experiencias y

compartir su conocimiento, y generar una verdadera comunidad de práctica.

Ésta segunda razón es quizás la mas importante porque ninguna de las demás

técnicas mencionadas apunta a lograr la creación de este tipo de comunidades. Si

bien en proyecto de pequeño o mediano tamaño puede resultar poco convincente el

uso de este tipo de comités, en proyectos de gran tamaño, que se implementa en

diferentes lugares u organizaciones, se transforma en una técnica sumamente útil.

Lo que se busca lograr formando este tipo de comunidades es generar un

sentido de pertenencia por parte de los usuarios para con el proyecto, de forma tal

que no se vean como algo externo al proyecto sino como un componente mas del

mismo. Esto resulta de gran ayuda para lograr una finalización exitosa de proyecto.



143

Nuevamente la decisión de si utilizar o no este tipo de técnicas, deberá ser

evaluado por el equipo de acuerdo a las características del proyecto, ya que insume

tiempo y recursos para realizarlo.

Grupos de Apoyo

La utilización de los grupos de apoyo en el cierre de un proyecto tiene como

objetivo lograr una implementación rápida y exitosa.

Como se mencionó anteriormente, los grupos de apoyo son equipos de personas que

brindan soporte “in situ” en los lugares afectados por la implementación del

proyecto. Estos grupos son aplicables fundamentalmente en proyectos que

involucran la implantación de un nuevo producto software, de modo que los

usuarios necesitarán soporte para comenzar a utilizarlo (además de la capacitación

previa).

Sin embargo se debe tener especial cuidado en como funciona esta clase de

grupos, ya que la idea es “dar soporte en la realización de tareas” y no “hacer el

trabajo por los usuarios”. Además de tiene que definir el período que durará este

soporte ya que debe realizarse por un período acotado de tiempo.

Nuevamente la idea de esta técnica es generar confianza en los usuarios y

mostrarles que, en el equipo de proyecto, existe preocupación por su comodidad.

La ventaja principal es que, el hecho de tener personas que los ayuden en sus

tareas con el nuevo sistema, tiene un efecto muy positivo sobre los usuarios quienes

se sentirán contenidos. Pero como contrapartida, la desventaja es que requiere de

personas del proyecto con un tiempo importante dedicado a estas actividades.

Aademás, en algunos casos, se puede generar en el usuario una sensación de

invasión de su espacio y su trabajo. Es por ello que se debe analizar muy

detenidamente tanto a los usuarios como al proyecto antes de decidir implementar

esta técnica, ya que si no se lo analiza se corre el riesgo de lograr el efecto contrario

al esperado.

Mesa de Ayuda

Al igual que los grupos de apoyo, la mesa de ayuda tiene como objetivo

brindar soporte a los usuarios del proyecto de modo que se pueda lograr una

implementación exitosa del mismo. Desde el punto de vista de la administración de



144

las personas, el objetivo es minimizar la resistencia al cambio y generar confianza y

seguridad en los usuarios respecto de la implementación del sistema.

Existen diferentes formas de implementar la mesa de ayuda, una de ella es

utilizando la mensajería instantánea, lo cuál ya se analizó con anterioridad. Otra de

las formas es a través de los denominados “Call Center” que operan en forma

telefónica. Finalmente también se puede utilizar el call center combinado con

mensajería instantánea de modo que se puedan tener ambas opciones.

Dependiendo de la organización y del tipo de proyecto, la implementación

de la mesa de ayuda puede ser muy simple, ya que hay muchas organizaciones que

cuentan con grupos de este tipo para atender las necesidades de los usuarios. De este

modo solo se requeriría contar con personas que tengan conocimiento del proyecto y

que formen parte del grupo de la mesa.

Finalmente las mesas de ayuda tienen la ventaja de que pueden ser

perdurables a través del tiempo. Es decir que si el proyecto se da por finalizado, la

organización puede decidir la continuidad de la mesa de ayuda para dar soporte a los

usuarios no solo en aspectos relacionados con el proyecto puntual que le dio origen,

sino también a todos aquellos temas (tecnología y otras aplicaciones) que la

organización defina.


La utilización de esta técnica durante el cierre de un proyecto, tiene su

principal utilidad cuando se debe verificar si se ha cumplido con todas las tareas que

conforman dicho proyecto.

Dado que el cierre formal del mismo se puede declarar una vez que todas las

tareas se han cumplido totalmente, la Estructura Desglosada de Trabajo permite

visualizar si la totalidad de las tareas tienen un porcentaje de cumplimiento de

100%. De este modo se evita dar por finalizado un proyecto cuando aun no se

culminó con alguna tarea.

Básicamente funciona como lista de control para verificar cada actividad y,

en el caso de la administración de personas, señalarle a cada responsable si es que

hay alguna tarea pendiente.

CAPITULO

VI

VALIDACION



147

6.1- SISTEMA DE VALIDACIÓN SELECCIONADO

La validación del modelo planteado en el presente trabajo de tesis consistió en

determinar si el mismo puede ser, o no, aplicado en forma exitosa en la gestión de un

proyecto de TI dentro de una organización. Las alternativas para poder realizar esto eran

acotadas y se redujeron a dos opciones:

1- La realización de una prueba piloto en la cuál se implemente el

modelo de gestión propuesto en un proyecto real y evaluando los

resultados obtenidos al finalizar dicha prueba.

2- La utilización del sistema de juicio de expertos, a través del cual el

modelo será sometido al análisis exhaustivo de un grupo de expertos

en la gestión de proyectos.

De las dos alternativas planteadas, la seleccionada fue la número dos, es decir, la

validación a través del juicio de expertos en la materia. Esta selección se basó

fundamentalmente en que no se contaban con los recursos necesarios para poder llevar

adelante una prueba piloto en la cuál se pueda gestionar el factor humano de un

proyecto mediante el la implementación del Modelo de Gestión de Personas propuesto.

Para llevar adelante la validación, se seleccionaron cuatro profesionales cuya

formación y experiencias estén relacionadas con la gestión de proyectos y de los

diferentes factores de éxito que afectan a los mismos. A cada uno de estos expertos se le

entregó un extracto de la solución planteada a través del trabajo de tesis, en el cuál se

indicaba el modelo seleccionado un breve detalle acerca de la implementación de cada

una de las prácticas (Ver Anexo I). Además se les entregó, juntamente con el extracto

del modelo, un cuestionario que a ser contestado por el experto y en el cuál se hacían

todas las preguntas necesarias para poder obtener un juicio de valor por sobre la utilidad

del modelo (Ver Anexo II).

El cuestionario estaba estructurado en tres secciones: la primera de ellas contenía

preguntas orientadas a la evaluación del modelo utilizado para la estructuración de la

solución (estructura del modelo, aplicabilidad del mismo y división de prácticas en

genéricas y específicas). La segunda sección, estaba orientada a la evaluación de las

prácticas genéricas seleccionadas (utilidad de las mismas y aspectos de implementación)

y, finalmente, la tercera sección dedicada a la evaluación de las prácticas específicas del

modelo (utilidad de las mismas y aspectos de implementación).

Cada una de las secciones, contenía preguntas abiertas y cerradas, de modo tal

que no sólo se pueda evaluar la conformidad del experto para con el modelo sino que



148

también se le permitía al experto poder sugerir modificaciones o mejoras sobre los

aspectos evaluados.

Finalmente, una vez recibidas las devoluciones de cada experto, se procesaron

los resultados de los cuestionarios y se determinó la utilidad o no del Modelo de Gestión

de Personas propuesto.

6.2- EXPERTOS SELECCIONADOS

Considerando que la naturaleza del problema abordado en esta tesis está ligada

fundamentalmente a las Tecnologías de la Información y a la Gestión de Proyectos, el

perfil que debían tener los expertos que realizaran la evaluación, debía también estar

orientados a estos dos temas.

Del análisis realizado para definir las condiciones que debía cumplir el perfil de

cada experto, se determinaron tres aspectos importantes:

� Cada experto debía tener título de grado y posgrado (o especialización)

en áreas relacionadas con Tecnologías de Información o Gestión de

proyectos. Esta condición se considera como obligatoria en la selección

de los expertos.

� Cada experto debía tener experiencia en la gestión de proyectos de

Tecnologías de la Información. Esta condición también era de carácter

obligatorio.

� El experto debía tener conocimientos sobre el PMBOK o certificación de

PMI. Esta condición no se consideró obligatoria para la selección de los

evaluadores, pero sí deseable.

A partir de las características indicadas como necesarias para la selección de los

expertos que se encargarían de realizar la evaluación del modelo planteado, se

determinó que los cuatro evaluadores serán los siguientes:

Experto 1

Título de Grado:

Ingeniero Electrónico

Título de Posgrado o Especialización:

Magíster en Ingeniería en Sistemas de Información.



149

Experiencia Laboral Relacionada:

- Ex CEO de Texas Instruments Cono Sur, Verbano S.A. y Fiplasto S.A.

- Creador dos PyMEs de TI.

- Docente de posgrado en la Universidad Tecnológica Nacional.

- Consultor de Management.

Experto 2

Título de Grado:

Ingeniero en sistemas de Información


Especialista en Ciencias de la Computación.


- Ex Director de la carrera de Ingeniería en Sistema de información en una

Facultad Regional de la Universidad Tecnológica Nacional.

- Docente de la carrera de Ingeniería en Sistema de información en la Universidad

Tecnológica Nacional.

- Líder de varios proyectos de desarrollo de software tanto en el ámbito público

como en el privado.

Experto 3

Título de Grado:

Ingeniero en sistemas de Información


Magíster en Ciencias de la Computación con Orientación en Bases de Datos.


- Secretario de Informática en Facultad Ciencias de la Salud de la Universidad

nacional de Entre Ríos.

Encargado de: asesoramiento a la gestión sobre la adquisición de equipamiento

informático, gestión de los recursos humanos del área informática de la facultad

(selección y coordinación de actividades relacionadas con proyectos) y gestión

de proyectos de S.I./TI



150

- Docente de la carrera de Ingeniería en Sistema de información en la Universidad

Tecnológica Nacional.

Experto 4

Título de Grado:

Ingeniero en Informática


PMP Certificado


- Sr. Manager, Product Development en Teletech S.A..

- Ex Docente de grado en Universidad Nacional de La Matanza

6.3- RESULTADO DE LA EVALUACIÓN DE LOS EXPERTOS

Del análisis de los resultados obtenidos a través de los cuestionarios realizados a

cada uno de los expertos mencionados (Anexos III, IV, V y VI), se pueden obtener las

siguientes conclusiones:

Modelo Utilizado

En cuanto al modelo utilizado para el planteo de la solución, todos los expertos

coincidieron en la estructura seleccionada para el mismo es adecuada y que dicho

modelo es aplicable a cualquier tipo de proyecto de TI. Además todos los expertos

coincidieron en que la agrupación de prácticas en Genéricas y Específicas resulta

acertada.

Sólo se recibieron algunas sugerencias para mejorar el mismo, tal como la

inclusión de un análisis más detallado sobre cómo integrar las diferentes prácticas.

Además se recibe la observación de que el PMI está reevaluando el PMBOK debido a

que no es aplicable a ciertos proyectos de TI, aspecto a tener en cuenta al momento de

aplicar el modelo planteado en este trabajo.



151

Prácticas Genéricas

En cuanto a las prácticas Genéricas, los expertos concordaron en que el conjunto

de prácticas seleccionado es acertada, como así también los detalles de implementación

de cada una en los diferentes grupos de procesos de un proyecto.

Se recibió la sugerencia por parte de uno de los expertos de agregar “Cadena

Crítica” como práctica genérica a fin de ampliar el conjunto de prácticas propuestas.

Prácticas Específicas

En lo que respecta a las prácticas Específicas, nuevamente hubo coincidencia en

la evaluación de los expertos. En este caso todos concordaron en que el conjunto

seleccionado es adecuado. Se incorporaron por sugerencia de uno de los expertos, los

Diagramas de Gantt y la Estructura Desglosada de Trabajo, la cuales se consideran de

gran utilidad en la administración de proyectos. Por otro lado, también se recibió la

sugerencia de que, solo a modo de mejora, se podría incluir alguna otra práctica

relacionada con la comunicación interpersonal.

De acuerdo a los resultados obtenidos, se pudo determinar el Modelo de Gestión

de Personas planteado en el presente trabajo de tesis, es factible de ser utilizado en

forma exitosa en la administración de proyectos de TI. Además, en todos los casos se

observó que hay interés por parte de los expertos en poder adaptar el modelo para

hacerlo aplicable a cualquier tipo de proyecto. Esto demuestra que su aplicación no es

solo factible sino que también resulta de gran utilidad e importancia.

CAPITULO

VII

CONCLUSIONES



155

7.1- ASPECTOS GENERALES

Siempre que se analiza cuáles son los factores claves de éxito en un proyecto se

mencionan aspectos relacionados con costos, tiempo y prestaciones, y se enfocan todos

los esfuerzos en mejorar la administración de estos tres factores. Si bien este enfoque es

correcto, existe un cuarto factor igualmente importante y que tiene gran influencia en la

finalización del proyecto, este factor es el constituido por las personas y se lo denomina

como el factor humano.

El factor humano tiene la particularidad de que no sólo en el resultado final del

proyecto, sino que además es una variable transversal al presupuesto, el tiempo y las

prestaciones. Esto es debido a que cada una de las actividades es ejecutada por personas

y que depende de éstas que se cumplan o no con los objetivos fijados para cada uno de

los otros tres factores.

En la actualidad existen algunas metodologías de desarrollo ágiles, aplicadas al

desarrollo del software, que incorporan en mayor o menor medida muchos de los

conceptos relacionados con el manejo de las personas. Pero lo cierto es que todas estas

metodologías proporcionan un enfoque incompleto del problema ya que lo que

proponen muchas veces no es aplicable a otros proyectos de IT o a proyectos de gran

tamaño. Además, los estándares definidos para la administración de proyectos presentan

el tema de la administración de las personas pero no brindan detalles acerca de técnicas

a utilizar, y por ello muchas veces es muy difícil de implementar un manejo correcto del

factor humano.

En el presente Modelo de Gestión de Personas se combinó uno de los estándares

mas utilizados en la administración de proyectos, como lo es el PMBOK, con las

técnicas que aplican algunas metodologías ágiles de desarrollo referidas al anejo de

personas y otras técnicas obtenidas a través de la experiencia del autor del presente

trabajo. A partir de esto se obtuvo un esquema de “Mejores Prácticas” aplicables a cada

uno de los grupos de procesos que conforman un proyecto. Para ello se definieron dos

grupos de prácticas: prácticas genéricas y prácticas específicas.

Dentro del grupo de las prácticas genéricas están aquellas que, por sus

características y utilidad, son aplicables a cualquiera de los grupos de procesos de un

proyecto de TI, mientras que las prácticas específicas son sólo aplicables a ciertos

grupos de procesos en particular.

A partir de esto se definió un esquema de aplicación de prácticas por grupos de

procesos donde, a partir del análisis de las necesidades de cada grupo se definió que



156

prácticas aplicar. Además se estudiaron las particularidades a tener en cuenta en la

aplicación de las mismas según el grupo de procesos en que se utilizan.

De este modo se obtuvo una guía muy fácil de entender y de aplicar por parte de

los líderes de proyecto y que permite lograr una mejor administración del grupo de

personas involucradas en el proyecto y así encaminar el proyecto hacia una finalización

exitosa.

Finalmente, la evaluación a través del juicio de expertos arrojó resultados muy

positivos en lo que respecta al modelo planteado. Esto permitió verificar que el modelo

es factible de ser implementado en la gestión de personas en los proyectos de TI.

Además se pudo determinar un interés por parte de los expertos en la ampliación del

conjunto de prácticas presentadas, de modo que se puedan incluir nuevas prácticas que

permitan adaptar el modelo a todo tipo de proyectos.

7.2- CUMPLIMIENTO DE LOS OBJETIVOS PLANTEADOS

A continuación se analizará cada uno de los objetivos planteados para el

presente trabajo de tesis y el cumplimiento de los mismos a lo largo de todo el

desarrollo del presente:

� Especificar las características de la Gestión del Factor Humano en proyectos de

TI.

Para poder determinar las características más importantes de la Gestión

del Factor Humano en los proyectos de TI, en el Capítulo II del presente trabajo

de tesis, se analizaron todos aquellos aspectos relacionados con esta clase de

proyectos. En primer lugar se estudió la evolución de los conceptos relacionados

con la administración de personas a lo lago de la historia en las

administraciones.

Finalmente, se estudiaron las características específicas de los proyectos

de TI y los factores relacionados con las personas que influyen en el éxito o el

fracaso de los mismos (como por ejemplo las habilidades del líder y la

resistencia al cambio).

� Analizar los diferentes modelos utilizados para la gestión de personas en los

proyectos de TI.



157

Para cumplir con este objetivo, en el Capítulo II se realizó el estudio

algunas metodologías y técnicas que implementan conceptos importantes en

cuanto al manejo de personas. La mayoría de ellas relacionadas con el desarrollo

de software, aunque también se analizó un estándar utilizado para la gestión de

proyectos, como lo es el PMBOK.

Finalmente, en el Capítulo III, se planteó el impacto sobre las personas

de los proyectos de desarrollo de software y se mencionaron algunos ítems

importantes a considerar en estos casos.

� Definir el alcance y las limitaciones de cada una de las prácticas utilizadas en

cada modelo.

En este caso, en los Capítulos IV y V, se planteó un modelo compuesto

por un grupo de prácticas que se dividen en genéricas y específicas, analizando

las características de cada una y las ventajas de su aplicación en la gestión del

factor humano en los proyectos de TI.

� Elaborar un modelo de mejores prácticas de acuerdo a cada una de las etapas de

un proyecto de TI.

Para este punto, en el capítulo V se propuso, en primer lugar una

estructura para la administración de proyectos basada en el PMBOK. Esta

estructura divide al proyecto en cinco grupos de procesos en los cuáles pueden

ser aplicadas las prácticas seleccionadas.

Para finalizar, se planteó un esquema en el cuál se propone cuáles de las

prácticas analizadas son aplicables en cada uno de los grupos de procesos y que

consideraciones se deberán tener en la aplicación de cada una de ellas.

� Evaluar el modelo obtenido y analizar los resultados.

Para la validación del modelo, en el capítulo VI, se propuso la evaluación

del mismo a través del Juicio de Expertos. Se definió el perfil básico que debe

cumplir cada experto y se seleccionó 4 de ellos para cumplir con el proceso de

evaluación. Este proceso consistió en enviar un extracto del modelo a cada

experto, acompañado de un cuestionario. Dicho cuestionario permitió obtener las

respuestas necesarias para determinar si el experto considera que el modelo es o

no aplicable en forma exitosa a la gestión de un proyecto de TI.



158

Finalmente se analizaron las respuestas obtenidas y se determinó la

viabilidad en la implementación del modelo propuesto y de analizaron posibles

mejoras en el mismo.

7.3- LÍNEAS DE INVESTIGACIÓN FUTURAS

A partir del presente trabajo de tesis, existen aspectos que quedan fuera del

alcance planteado y que forman parte de las líneas de investigación futuras. Entre ellas

las más importantes son:

� Aplicación dentro del modelo de técnicas relacionadas con la motivación de los

equipos de trabajo, tales como los Programas de Calidad de Vida en el Trabajo.

� Ampliación del campo de estudio de la presente tesis, para su aplicación en

cualquier tipo de proyectos.

� Profundización del estudio del presente modelo para determinar la conveniencia

o no de aplicar ciertas técnicas de administración de personas de acuerdo con el

tipo de proyecto.

� El estudio de las diferentes plataformas en las cuales se pueden integrar las

distintas técnicas mencionadas en el presente trabajo (redes sociales y/o

plataformas colaborativas).

CAPITULO

VIII

BIBLIOGRAFIA



161

[Abran, 2001] Abran A.; Desharnais J. M.; Oligny S.; St-Pierre D. & Symons Charles

S., “COSMIC FFP Manual de Medición Versión 2.1”, Common Software

Measurement International Consortium, 2001

[Álvarez, 2001] Álvarez, R., “Echange, el Lado Humano de la Economía Digital”.

Ediciones Granica, 2001

[Beck, 1999] Beck, K., “Extreme Programming Explained”. Editorial Addison Wesley,

1999.

[Beckhard, 1998] Beckhard, R. & Reuben, H., “Transiciones organizacionales:

Administración del cambio”. Editorial Addison–Wesley Iberoamericana, 1998.

[Boehm, 2000] Boehm, B.; Abts, C.; Winsor Brown, A.; Chulani, S.; Clark, B.;

Horowitz, E.; Madachy, R.; Reifer, D. & Steece, B., “Software cost estimation with

COCOMO II”. Editorial Prentice Hall, USA, 2000.

[Burke, 2006] Burke, R.; Kenney, B.; Kott, K & Pflueger, K. “Success or Failure:

Human Factors in Implementing New Systems”. Educause, Article 0152, 2001

[Caldera Mejía, 2004] Caldera Mejía, R., “Conceptos y Teoría Sobre Planeación

Efectiva de Recursos Humanos”. Editorial Estrategika-Consultoria, 2004

[Chiavenato, 2003] Chiavenato, I., “Introducción a la Teoría General de la

Administración”. Editorial McGraw-Hill Latinoamericana S.A., 2003.

[Cuevas Agustín, 2003] Cuevas Agustín, G.; de Amescua Seco, A., “Gestión del

Proceso del Software”. Editorial Ramón Areces, 2003.

[Cummings, 2007] Cummings, T.; Worley, C., "Desarrollo Organizacional Y Cambio".

Cengage Learning Editores, 2007

[Dickson, 2003] Dickson, W. & Roethlisberger F., “Management and the Worker”.

Editorial Routledge, 2003.

[Ebersbach, 2006] Ebersbach, A.; Glaser, M.; Heigl, R. & Dueck, G., “Wiki Web

Collaboration”. Editorial Springer, 2006.

[Fayol, 1985] Fayol, F., “Administración industrial y general”. Ediciones Orbis, 1985.

[García, 2001] García, G. & Rangel, J., “Resistencia al Cambio Tecnológico en las

organizaciones durante el desarrollo de un sistema de información en el área de

Recursos Humanos”. Universidad Católica Andrea Bello, 2001.



162

[Gurmendi, 2006] Gurmendi, L.; Williams, R. , “Desarrollo Informático Colaborativo

en el Sistema Universitario: La Experiencia SIU-Guarani”. Buenos Aires 2006.

[Herzberg, 1993] Herzberg, F. & Bloch Snyderman, B., “The motivation to work”.

Editorial Transaction Publishers, USA, 1993.

[Hiebeler, 2000] Hiebeler, R., “Las Mejores Prácticas”. Editorial Gestión, 2000.

[IEEE, 2004] IEEE Std. 1490-2003, “Adoption of PMI StandardA Guide to the Project

Management Body of Knowledge”. IEEE Standars Association, 2004.

[ISO, 2000] ISO, “ISO9001:2000 – Sistemas de Gestión de Calidad. Requisitos”. ISO,

2000

[ISO/IEC, 2003] ISO/IEC, “ISO/IEC 20926:2003 - Software engineering - IFPUG 4.1

Unadjusted functional size measurement method - Counting practices manual”.

ISO/IEC, 2003

[ISO/IEC, 2005], ISO/IEC, “ISO/IEC 20000-1 - Information Technology - Service

management - Part 1: Specification”, ISO/IEC, 2005

[ISO/IEC, 2007] ISO/IEC, “ISO/IEC 14143-1:2007 Information technology - Software

measurement - Functional size measurement - Part 1: Definition of concepts”. ISO/IEC,

2007.

[ISO/IEC, 2008] ISO/IEC, “ISO/IEC 12207:2008 Systems and software engineering -

Software life cycle processes”, ISO/IEC, 2008

[Kelly, 1999] Kelly, K., “Técnicas para la Toma de Decisiones en Equipo”. Ediciones

Granica, 1999

[Kendall, 1997] Kendall, K. & Kendall, J. “Análisis y Diseño de Sistemas”. Editorial

Pearsona Addison – Wesley, 2005

[Lagrange, 1983] Lagrange, J., “Resistencia al Cambio Tecnológico”. Edicion UCAB,

1983.

[Maslow, 1991] Maslow, A., “Motivación y personalidad”. Ediciones Díaz de Santos,

1991.

[Matsushita, 1993] Matsushita, Konosuke, “Claves para un Buen Gerente”. Editorial

PHP Institute, 1993.



163

[Mayo, 2003] Mayo, E., “The Political Problems in an Industrial Civilization”.

Editorial Routledge, 2003.

[McGregor, 2007] McGregor, D., “El lado humano de las empresas”. Editorial McGraw

– Hill, 2007.

[Monden, 1998] Monden, Y. “Toyota Production System: An Integrated Approach to

Just - In -Time”. Engineering and Management Press, USA, 1998

[NESMA, 2001] NESMA, “Function Point Analysis for Software Enhacement”.

Netherlands Software Metrics Users Association, 2001

[Norman, 2008] Norman, E; Brtotherton, S. & Fried, R., “Work Breakdown Structures:

The Foundation For Project Management Excellence”. John Willey & Sons, 2008.

[Pichón-Riviere,1999] Pichón-Riviere, E., “El Proceso Grupal”. Editorial Nueva Visión,

Buenos Aires, 1999

[PMI, 2004] Project Management Institute, “A Guide to the Project Management Body

of Knowledge (PMBOK Guide)”. Project Management Institute, 2004.

[Quintero, 2005] Quintero, M., “Evaluación del Impacto de los sistemas de

Información En el desempeño Individual del Usuario. Aplicación en Instituciones

Universitarias”. Tesis Doctoral.

[R.A.E.,2007] Real Academia Española, “Diccionario de la Lengua Española”. Editorial

Espasa Calpe, 2000.

[Salinas, 1975] Salinas, Alberto, “La Reforma Administrativa”. Editorial FCE México,

1975.

[Salomón, 2003] Bravo Salomón, L., “El Factor Humano y el Éxito en la Gerencia de

Proyectos”. Editorial Fundación Diego de Sagrado, 2003.

[Schwaber, 2004] Schwaber, K., “Agile Project Management with Scrum”. Microsoft

Press, 2004.

[Senn, 1992] Senn, James A., “Análisis y Diseño de Sistemas de Información”.

Editorial McGrawHill, 1992.

[Sommerville, 2005] Sommerviile, I., “Ingeniería del Software”, Editorial Pearson

Educación, 2005



164

[Soto, 2004] Soto, E., “Comportamiento Organizacional - Impacto De Las Emociones”.

Thomson Editores, 2004.

[Standish Group, 1995] Standish Group, “Chaos Report”. Educase, Article 08083B,

1995

[Taylor, 2005] Taylor, F., “The Principles of Scientific Management”. Editorial

Adamant Media Corporation, 2005.

[UKSMA, 1998] UKSMA, “MKII Function Points Analysis Counting Practices

Manual”. United Kingdom Software Metrics Association, 1998

[Wake, 2000] Wake, W., “Extreme Programming Explored”. Editorial Addison-Wesley,

2000.

[Wenger, 1998] Wenger, E., “Communities of Practice: Learning, Meaning, and

Identity”. Cambridge University Press, 1998.

[Winston, 2005] Winston, W., “Investigación de Operaciones: Aplicaciones y

Algoritmos”. Cengage Learning Editores, 2005.

[Wood, 1995] Wood, J. & Silver, D., “Joint Application Development”. Editorial John

Willey & Sons, 1995.

[Wong, 2007] Wong, Z., “In Human Factors in Project Management”. Editorial John

Wiley & Sons, 2007.

Sitios WEB:

http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

http://www.softwaremetrics.com/freemanual.htm

http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm

http://www.rrhhblog.com/2008/08/23/tipos-de-tecnicas-iii/

http://www.cosmicon.com/

http://www.ifpug.org/

http://www.carolla.com/wp-jad.htm

http://www.programacionextrema.org/

http://es.wikipedia.org/wiki/Foro_(Internet)

http://www.elmundo.es/nuevaeconomia/index.html

CAPITULO

IX

ANEXOS



167

9.1- ANEXO I - EXTRACTO DEL MODELO ENVIADO A LOS EXPERTOS INTRODUCCIÓN

En el presente capítulo se expone como solución al problema planteado, un

Modelo de Gestión de Personas aplicable a los diferentes tipos de proyectos de TI. Lo

que se propone es la aplicación de diferentes técnicas de gestión de personas dentro de

una estructura de administración de Proyectos.

Las técnicas que se implementarán son todas aquellas relacionadas con

motivación de equipos de trabajo, gestión de las relaciones interpersonales dentro de un

equipo, relación con los clientes y manejo de la asignación y distribución de los

recursos. La idea es poder aprovechar al máximo las ventajas y beneficios de cada una

de estas técnicas, adaptándolas a cada momento del proyecto cuando se lo requiera.

Por otro lado, se plantea la utilización de un modelo de administración de

proyectos reconocido y ampliamente utilizado en el ámbito de la gestión de proyectos,

tal como lo es el PMBOK. Este modelo plantea un “conjunto de conocimientos” que

permiten dirigir un proyecto, y que está basado en la experiencia obtenida en diferentes

casos y empresas.

La idea es combinar por un lado un estándar reconocido de administración de

proyectos, que funcione como estructura para comprender las etapas o fases del

proyecto, y por el otro proponer el uso de las diferentes técnicas de acuerdo al momento

del proyecto en que se encuentre. Las prácticas se clasificarán de acuerdo a si as mismas

son utilizables en cualquier instancia del proyecto o si solamente son aplicables en

algún momento en particular. De este modo se establecerán dos grupos de prácticas:

Prácticas Genéricas y Prácticas Específicas.

Finalmente se indicará como se debe implementar cada técnica en cada grupo de

proceso definido en la estructura del proyecto, y las consideraciones particulares que se

deberán realizar para poder llevarlo a cabo.

ESQUEMA SELECCIONADO

Para poder abordar y llevar adelante el planteo propuesto en el capítulo anterior,

es necesario primero definir cuál será el esquema / estándar de administración de

proyectos que se utilizará como guía para identificar las actividades relacionadas con la



168

administración del factor humano. En este sentido, se considera que la metodología más

completa de las conocidas y utilizadas actualmente, es aquella propuesta por el Project

Management Institute (PMI): El PMBOK (Project Management Body of Knowledge).

El PMBOK, como ya se analizó anteriormente, provee un estándar para la

dirección de proyectos que está estructurado en cinco de procesos básicos y nueve áreas

de conocimientos que son comunes prácticamente a todos los proyectos. La elección de

este estándar se basa en que representa un conjunto muy actual y sumamente amplio de

conocimientos que resultan de la experiencia, el estudio y el desarrollo de proyectos.

Lo interesante de este esquema es que su finalidad no es exponer disciplinas,

herramientas y técnicas aplicables a la gestión de proyectos sino proveer de un grupo

seleccionado de ellas y que son consideradas como buenas prácticas. Esto permite que

se pueda encuadrar en su esquema todas aquellas técnicas y herramientas relacionadas

con la administración del factor humano que influyen en la administración de un

proyecto.

Por otra parte, el grupo de conocimientos del PMBOK se encuentra distribuido

entre los miles de colaboradores alrededor del mundo y es por esta razón que no se lo

presenta como un manual con pasos a seguir para culminar un proyecto en forma

exitosa.

Para el planteo de la solución propuesta al problema abordado en el presente trabajo, se

tomará como base esta estructura y dentro de ella es que se organizarán las técnicas y

herramientas propuestas como mejores prácticas.

MODELO DE GESTIÓN PROPUESTO

La solución al problema presentado se estructurará de modo que, en primer lugar

se analizarán las Prácticas Genéricas. Estas prácticas se denominan genéricas debido a

que se podrán aplicar en cualquiera de los grupos de procesos del proyecto, variando

simplemente algún aspecto en particular para poder adaptarla mejor cada grupo. Luego

se presentarán las que se denominarán Prácticas Específicas. Éste grupo de prácticas son

aquellas que sólo tienen aplicación en algún grupo de procesos en particular pero no al

resto de los grupos. Luego se analizará en detalle las necesidades de cada uno de los

grupos de proyectos del PMBOK desde el punto de vista de la administración del factor

humano, para finalmente poder especificar el esquema final de prácticas aplicadas a

cada grupo. En la Figura 6 se puede visualizar el esquema planteado para el desarrollo

de la solución.



169

Figura 6 –Representación gráfico del esquema de la solución planteada.



170

APLICACIÓN DE PRÁCTICAS A LAS DIFERENTES FASES DE UN

PROYECTO

Finalmente en esta sección se presentará cómo se relaciona cada una de las

prácticas definidas en las dos secciones anteriores con las diferentes fases de un

proyecto de TI. En la Tabla XII se muestra un esquema en el cual se sintetiza cual es la

aplicabilidad de cada técnica según la fase del proyecto en que se encuentre.

Inicio Planificación Ejecución Control Cierre

Reuniones X X X X X

Wikis X X X X

Foros de discusión X X X X X

Listas de Correo X X X X X

Mensajería Instantánea X X X X X

Comités de Desarrollo X

Programación de a Pares X

Comités de Usuarios X X

Grupos de Apoyo X

Mesa de Ayuda X

CPM X X

PERT X X

COCOMO X X

Puntos de Función X X X

Grupo Nominal X

Delphi X

Análisis Estadístico X

Tabla XIII – Esquema de prácticas por fases del proyecto

En general se ve claramente que las prácticas que se definieron como genéricas

son aplicables a casi todas las fases de un proyecto, mientras que las específicas solo se

aplican a una o dos etapas.



171

A continuación se detallarán, para cada uno de los grupos de procesos de un

proyecto, cuál es su objetivo, necesidades y las técnicas aplicables de acuerdo a lo

definido en la Tabla XIII. Además se analizarán las particularidades de la aplicación de

cada técnica de acuerdo a los requerimientos de la fase analizada.

INICIACIÓN

1- Técnicas a utilizar: De acuerdo al objetivo del grupo de procesos y de las

necesidades detectadas en el mismo respecto de la administración del factor

humano, en la Tabla XIII se indican como aplicables las Reuniones, Foros de

Discusión, Listas de Correo, Mensajería Instantánea y Puntos de Función.

Reuniones

En este caso particular es importante que se tomen en cuenta y se le

preste mucha atención a todas las opiniones y sugerencias de cada uno de los

participantes, se analicen y finalmente se determinen si influirán o no en el

objetivo y alcance del proyecto.

Otro aspecto en el que se debe poner atención, en la preparación y

posterior ejecución de la reunión, es el lugar físico donde se realizará el

encuentro y la disposición de cada uno de los participantes.

En cuanto al lugar que de encuentro, es conveniente que sea un lugar con

buena luz, silencioso y donde no existan interrupciones por parte de terceros. Es

conveniente que se cuente con material de apoyo necesario para poder expresar

los conceptos. En este sentido es importante contar con pizarrón, marcadores,

proyectos y PC, ya que de esta forma se puede desplegar una amplia gama de

técnicas para transmitir los conceptos y lograr que los mismos queden claros.

En lo que refiere a la disposición de los participantes, en las reuniones de

iniciación de proyecto el número de integrantes suele ser reducido, no más de 4

o 5 personas, por lo cual es conveniente que se realice en una mesa redonda,

donde todos puedan verse y donde no haya mucha distancia entre las personas,

de modo que todos puedan escucharse mutuamente.

Otro de los aspectos que no se debe descuidar es el armado del proceso

de facilitación. Nunca se debe olvidar que la mayoría de las reuniones no fracasa

por un mal armado de la agenda sino por la ausencia o pobreza en el proceso de

facilitación de la misma.



172

La reunión debe comenzar con una breve presentación de cada uno de los

participantes (en caso de ser necesario) y luego una introducción que estará a

cargo de quien es el facilitador de la reunión. En dicha presentación se explicará

el tema que se tratará en el encuentro y para dicha explicación, el facilitador se

puede valer de transparencias, gráficos, cuadro, videos o cualquier otro elemento

que se considere útil para facilitar la comprensión del tema.

Cada vez que sea necesario comenzar con la discusión de un nuevo tema,

se debe tener en cuenta las técnicas presentadas anteriormente para iniciar un

debate.

Es conveniente además, que haya un encargado de documentar todo lo

que se discute en la reunión, de modo que queden plasmadas las diferentes

opiniones expuestas, lo que luego será de gran utilidad para poder elaborar las

conclusiones de la reunión. Respecto de las conclusiones, se deben tener

siempre presentes las técnicas para cerrar debates.

Una vez finalizada la reunión se debe confeccionar una memoria con las

conclusiones y acuerdos alcanzados durante la misma y repartir dicho

documentos entre todos los participantes a modo de recordatorio de los acuerdos

realizados y los pendientes (si es que existieran).

Siempre se debe tener en cuenta que la duración de una reunión es un

factor que influye en los resultados de la misma. En el caso de las reuniones que

se realizan durante los procesos de iniciación, hay que tener en cuenta que los

principales implicados son miembros de la alta gerencia de la organización, por

lo cual se debe evitar quitarles demasiado tiempo ya sea por una reunión extensa

o por una cantidad excesiva de reuniones. Antes de convocar hay que analizar si

realmente el tema justifica la realización de la misma o si es algo que, o bien se

puede solucionar por otros medios o bien se puede aplazar para tratarlo en otro

encuentro junto con otros temas.

Hay que tener muy presente que una buena comunicación es fundamental

para lograr una reunión de trabajo exitosa, es por ello que hay algunos puntos

que son importantes para mejorar la comunicación, dentro de ellos los más

importantes son:

� Las palabras tienen diferentes significados para las personas.

� La comunicación no solo es verbal, sino que además tiene un

componente no verbal.



173

Foros de Discusión

De acuerdo al funcionamiento de esta herramienta, se puede crear un foro

en la cual los involucrados en el grupo de procesos puedan realizar sus consultas

y evacuar todas las dudas sin necesidad de realizar una reunión para ello.

Además, como las consultas son públicas pueden ser vistas por todos los

participantes se cuenta con la facilidad de que cada uno puede dejar su

comentario/sugerencia respecto de un tópico en particular.

Otra de las ventajas que tienen los foros es que son relativamente fáciles

de utilizar y no se requieren grandes conocimientos de informática para ello, con

lo cual, si alguno de los involucrados no posee demasiados conocimientos de

informática, no tendrá mayores inconvenientes para utilizarlos. Esta herramienta

es particularmente útil cuando los involucrados en la iniciación del proyecto no

se encuentran en locaciones geográficas muy distantes, donde la organización de

una reunión requiere de un tiempo considerable e implica la necesidad de que los

asistentes tengan que recorrer distancias considerables para participar de la

misma.

Listas de Correo

A diferencia de los foros de discusión, las listas de correos hacen que los

mensajes que se envían a las mismas lleguen directamente a la casilla de correo

electrónico de cada uno de los integrantes de dicha lista. De esta manera se

elimina la necesidad de que cada persona deba ingresar específicamente al foro

para verificar si existen mensajes nuevos.

Aplicadas al grupo de procesos de iniciación, las ventajas de las listas de

correos son prácticamente las mismas que los foros de discusión, es decir:

agilizar la circulación de información, realizar discusiones sobre ciertos tópicos

sin necesidad de una reunión y evacuar las dudas que se generen. Además

también son muy útiles en caso de que haya involucrados en locaciones




174


En el caso particular de la iniciación de un proyecto, la mensajería

instantánea resulta sumamente útil cuando se deben resolver temas urgentes

donde no hay tiempo de organizar una reunión, de modo que se puede iniciar

una conferencia de voz donde todos puedan participar de la discusión y resolver

el tema con mayor celeridad. Pero por otro lado requiere de algunos

conocimientos más de informática de los involucrados aunque en la actualidad

esta herramienta ha adquirido mucha popularidad llegando a ser en muchos

casos de uso corporativo.

De todos modos lo recomendable es que el uso de esta herramienta en el

grupo de procesos de iniciación vaya siempre acompañada del uso de al menos o

una lista de correo o un foro de discusión.

Puntos de Función

El uso de esta técnica durante la iniciación de un proyecto esta orientada

específicamente a la obtención de una primera aproximación del tiempo

necesario para llevar a cabo el proyecto y del costo aproximado del mismo.

Como se analizó con anterioridad, esta técnica permite, con algunos

datos relacionados al proyecto, obtener una estimación del tamaño del proyecto

y, por consiguiente, del tiempo necesario para ejecutarlo y de su costo. Si bien

en este grupo de procesos no se cuenta con demasiados detalles acerca del

proyecto, se puede obtener la información mínima a indispensable para realizar

un primer cálculo y de esta manera obtener un valor (en puntos de función) que

permita armar un presupuesto y determinar aproximadamente la duración del

mismo.

Siempre se debe tener en cuenta que los resultados que se obtengan

carecerán de precisión debido al momento temprano del proyecto en que se

aplica, peor al menos permite tener una guía para poder comenzar la discusión

con las partes interesadas en el proyecto.

PLANIFICACIÓN

1. Técnicas a utilizar: Si se analiza el objetivo del grupo de procesos de

planificación y las necesidades planteadas en el mismo, se determina que las



175

técnicas a utilizar en la administración del factor humano son: Reuniones, Wikis,

Foros de Discusión, Listas de Correo, Mensajería Instantánea, COCOMO,

Puntos de Función, CPM, PERT, Técnica de Grupo Nominal, Técnica Delphi y

Análisis Estadístico.

Reuniones

En el momento de realizar la planificación de un proyecto, las reuniones

son una técnica que tiene especial utilidad en la recopilación de información de

diferentes fuentes. Esta información es importante para poder hacer una

planificación confiable y exacta. En este caso son aplicables la mayoría de los

ítems mencionados para las reuniones que se llevan adelante durante la

iniciación, especialmente aquellos relacionados con la administración de los

espacios físicos y la disposición de los participantes. La diferencia radica en que,

en este caso, es que los asistentes pertenecen a áreas operativas de la

organización, es decir, que son los futuros usuarios del producto final.

El hecho de que quienes asistan a las reuniones sean los futuros usuarios

del producto o los responsables de las áreas impactadas por el mismo radica en

la necesidad de obtener información exacta y relevante. Esta información es

necesaria para conocer los aspectos específicos relacionados tanto con los

procesos como los procedimientos que serán afectados por el proyecto. De aquí

es que se hace necesaria la asistencia de personas con conocimientos de dichos

procesos y procedimientos. Este tipo de reuniones se denominan Reuniones de

Relevamiento.

Las reuniones de relevamiento son encuentros focalizados en el objetivo

principal de obtener información acerca de ciertos temas en particular. En el

caso de los proyectos de TI, estas reuniones tienen dos objetivos: comprender las

necesidades de información de las áreas involucradas y comprender los procesos

/ procedimientos afectados por el proyecto. En este tipo de reuniones, el

facilitador debe tener en claro cuales son los procesos, procedimientos y áreas

afectadas, de modo que se pueda dirigir el encuentro y guiarlo hacia el

cumplimiento de las metas de recopilación de información.

En cuanto a la cantidad y el tipo de asistente de las reuniones de

relevamiento, se puede decir que variará de acuerdo con el

proceso/procedimiento y las áreas. En el caso de procesos/procedimientos que



176

involucran a más de un área, es conveniente que asistan entre uno y dos

representantes de cada área. La idea es poder comprender todo le circuito,

detectar las necesidades de información de cada afectado e incluso determinar

los casos en que desde lugares diferentes se requiere la misma información.

Además en estas reuniones se pueden determinar los circuitos administrativos y

detectar las mejoras que pueden realizarse en los mismos (se debe tener presente

que los proyectos de TI no solo involucran tecnología y software sino también

procedimientos administrativos realizados por personas).

Finalmente se puede concluir diciendo que para las reuniones de

relevamiento es necesario:

� Identificar el/los procesos/procedimientos a relevar.

� Identificar las áreas afectadas por los mismos.

� Identificar las áreas que requieren información de los mismos.

� Identificar los actores claves de cada área.

� Focalizar el encuentro en lograr la obtención de información con

el mayor grado de exactitud posible y que resulte relevante para

las necesidades del proyecto.

Wikis

En el caso de la planificación de un proyecto, las wikis también se

transforman en una herramienta útil. Las mismas permiten dar soporte a las

actividades que en este grupo de procesos se realizan y que tienen relación con

la administración del factor humano. Dado que la recopilación de información y

la generación de documentos tales como el cronograma de actividades y

precedencias, las wikis cobran utilidad al momento de compartir esta

información.

Desde el punto de vista de la administración del factor humano dentro de

un proyecto de TI, las wikis permiten lograr una mayor agilidad en las

comunicaciones y también fomentar la participación de los usuarios, ya que

quienes tengan permiso para hacerlo pueden comentar y/o modificar un

contenido de modo que se enriquece el mismo.

La única limitación que puede presentarse en esta herramienta, y que

debe ser considerada, es que es necesario que para editar un tema los usuarios

deben tener ciertos conocimientos mínimos. Es por ello que se recomienda el



177

uso de la Wiki solo para grupos o comunidades de personas que están altamente

involucrados en el proyecto y que, por lo tanto, cuentan con los conocimientos

necesarios para la utilización de la Wiki.

Listas de Correo

En el caso de las listas de correo, su implementación y utilidad dentro del

grupo de procesos de planificación es básicamente el mismo que para la

iniciación de un proyecto. Esto se puede resumir en los siguientes puntos:

� Proveer mayor dinamismo en las comunicaciones.


generados por los procesos de planificación.


involucrados.

� Facilitar el intercambio de opiniones acerca de ciertos tópicos

cuando los involucrados en la discusión se encuentran en

locaciones geográficas muy distantes.


El caso de las ventajas de mensajería instantánea aplicada al grupo de

procesos de planificación también es coincidente con el grupo de procesos de

iniciación. Es decir que nuevamente se trata de agilizar las comunicaciones de

modo que, cuando los interesados están en línea, se pueden resolver en pocos

minutos ciertas cuestiones que de otra manera tomarían mayor tiempo.

Al estar frente a una herramienta que tiende a ser de uso corporativo en

muchas organizaciones, su aplicación tiene un costo muy bajo y redunda en

grandes mejoras en la comunicación.

En cuanto a las restricciones e inconvenientes, se deben considerar los

mismos aspectos mencionados en la iniciación, es decir que se recomienda que

su aplicación vaya acompañada de otra herramienta tal como las listas de correos

o los foros de discusión.

Puntos de Función

Desde el punto de vista de la administración de las personas dentro de un

proyecto, los puntos de función tienen importancia debido a que cuanto mas



178

exacta sea la estimación de tiempos, mejor será la distribución del equipo y se

llegará con mayos tranquilidad a la finalización del proyecto. Pero se debe

considerar que, para que esta técnica resulte más eficiente en la administración

de personas, es conveniente contar con una base de conocimientos de proyectos

anteriores. Esto se debe a que no todos los equipos realizan las mismas tareas en

iguales tiempos, por lo cual es conveniente que se cuente con antecedentes de

proyectos. De este modo se pueden tomar como base de cálculo aquellos

antecedentes de proyectos similares que hayan sido desarrollados con equipos de

similares características y obtener una aproximación de mayor exactitud.

COCOMO

Nuevamente, la utilidad de COCOMO (al igual que los Puntos de

Función) en la administración del factor humano dentro de un proyecto está dada

por la información que provee para la organización del equipo del proyecto.

Siempre que se obtiene una estimación del tamaño de un proyecto, se puede

realizar el cálculo aproximado de las horas/hombre necesarias para llevar

adelante el mismo. Si estas estimaciones son certeras, la distribución del equipo

en cada tarea será adecuada y permitirá que las personas trabajen sin las

presiones que se generan cuando los tiempos se estiman mal y se deben dedicar

más horas de las que se habían planificado para cada persona.

CPM

Una de las necesidades del grupo de procesos de planificación, es poder

tener una visión clara de cuáles son las actividades que se deberán realizar

dentro del proyecto, la secuencia de las mismas, sus dependencias y la duración

de cada una. Es en esto donde el Método del Camino Crítico (CPM) cobra

relevancia y utilidad ya que permite visualizar muy fácilmente la distribución y

dependencia de cada una de las actividades de modo que su análisis resulta muy

sencillo. Además con dicha distribución se puede tener una visión mas acertada

de cómo deberán distribuirse el equipo dentro del proyecto. Es en este sentido

donde su aplicación es importante al momento de administrar el factor humano

ya que permite detectar sobrecarga de trabajo sobre algunas personas y holguras

en otras.



179

PERT.

El uso de PERT. como una técnica importante en la administración de las

personas involucradas en un proyecto de TI, tiene la misma utilidad que las

mencionadas para CPM Esto significa que la ventaja principal de su uso está

asociada a la “visibilidad” de la distribución de las tareas y los tiempos dentro

del proyecto. De esta forma se puede determinar cuáles serán las tareas que

marcarán el camino crítico del proyecto, de modo que se brinde mayor atención

a como se asignan las personas a las tareas que forman dicho camino.

Por otro lado se pueden detectar ítems como la holgura de una tarea, de

modo que se puede manejar de modo eficiente la asignación de personas,

evitando que éstas tengan períodos prologados sin actividad dentro del proyecto,

lo cual puede causar desmotivación o frustración.

En comparación con CPM, la ventaja de PERT. es que es probabilístico y

que, al considerar al tiempo como una variable desconocida, puede resultar es

una distribución más realista de los tiempos.

Técnicas de Grupo Nominal y Delphi

La aplicación de este tipo de técnicas durante el grupo de procesos de

planificación tiene como objetivo dar soporte a todas las actividades

relacionadas con la planificación de los recursos humanos. En todo proyecto es

fundamental la determinación de la cantidad de personas que serán necesarias

para llevar adelante el mismo. En algunos casos, la cantidad de personas

disponibles es conocida de antemano y por tanto tenida en cuenta para la

planificación y estimación de tiempos. Pero en otros casos, se desconoce la

cantidad de personas con que se contarán y, por consiguiente, se deberá contar

con una estimación de los recursos necesarios. Es en este punto donde estas dos

técnicas cobran importancia.

Ambas técnicas se basan en la experiencia de las personas que participan,

de modo que es importante realizar una correcta selección de quienes estarán

involucrados en las mismas.



180


La importancia de su implementación radica en que, al utilizarse

información histórica de la organización, la predicción es más cercana a la

realidad. Además puede ahorrar tiempo en las estimaciones aunque, como

contrapartida, posee la desventaja de ser más compleja y requerir ciertos

conocimientos previos para poder aplicarla.

EJECUCIÓN

1. Técnicas a Utilizar: Considerando las necesidades planteadas para este grupo de

procesos, se determina que las técnicas a utilizar son: Reuniones, Wikis, Foros

de Discusión, Listas de Correo, Mensajería Instantánea, Comités de Desarrollo,

Programación de a Pares y Comités de Usuarios.

Reuniones

En el caso de las reuniones aplicadas al grupo de procesos de desarrollo,

permite realizar un análisis más detallado y exhaustivo acerca de las formas de

aplicación de las mismas. Esto se da a causa de que la ejecución involucra una

gran cantidad de variables que deben ser tenidas en cuenta y, por lo tanto,

requieren de reuniones de diferentes características para poder tener la

información necesaria. A continuación se presentarán los diferentes tipos de

reuniones aplicables durante la ejecución de un proyecto de TI.

La primera reunión que se tendrá al momento de comenzar con el grupo

de procesos de ejecución es la Reunión Inicial. Quizás resulte redundante hablar

sobre esta reunión ya que, en casi todos los proyectos, de una u otra manera esta

reunión se lleva a cabo.

Esta reunión debería realizarse o bien el primer día de trabajo de todo el

equipo, o bien en algún día previo al mismo. Lo recomendable es que se haga el

primer día de trabajo y que una vez finalizada la misma cada grupo se dirija a su

lugar de trabajo y comience con sus actividades.

Las Reuniones Diarias tienen lugar una vez que comienzan las

actividades en cada grupo de trabajo dentro del proyecto ya que es muy

importante realizar un seguimiento muy minucioso del avance de las actividades.

Esto es esencial para poder identificar puntos críticos o problemas que puedan



181

causar retrasos o generar inconvenientes en la realización de las tareas del

equipo de trabajo.

Las reuniones diarias son una herramienta que, bien aplicada, resulta

muy útil para detectar problemas en forma temprana y evitar los desvíos que

surgen en el día a día de cada proyecto. Pero estas reuniones deben cumplir con

una serie de características para que sean eficaces y útiles al proyecto.

La idea de este encuentro es que cada integrante del equipo este al tanto

del avance de las actividades del resto. Además se favorece la comunicación y la

participación de todos ya que si algún miembro presenta algún problema

relacionado con sus actividades dentro del proyecto, quizás alguien del resto del

quipo pueda colaborar con alguna propuesta de solución.

Las Reuniones de Avance, si bien son aplicables a todos los grupos de

trabajo de un proyecto, representan una herramienta fundamentalmente útil para

el líder de proyecto ya que permite medir el grado de avance general de los

diferentes grupos de trabajo dentro del proyecto. Estas reuniones se recomienda

que sean realizadas cada 15 días, aunque este plazo puede extenderse o reducirse

de acuerdo a las características de cada proyecto y, fundamentalmente, de los

tiempos del mismo.

El objetivo de la reunión de avance es proveer al líder de proyectos de

una visión global del estado de las diferentes actividades dentro del proyecto. En

esta reunión deben participar el líder del proyecto y los encargados de los

diferentes grupos de trabajo. Allí cada uno de los encargados expondrá el grado

de avance de su grupo y, en caso de existir, expondrás las dificultades con las

que se ha encontrado y las consecuencias de las mismas en el cumplimiento de

los objetivos de su grupo.

Wikis

En el caso de la ejecución de un proyecto, las wikis también se

transforman en una herramienta útil. Al igual que en los casos anteriores, tienen

como utilidad principal el dar soporte a las actividades que en este grupo de

procesos se realizan y que tienen relación con la administración del factor

humano. En este caso particular, las wikis permiten que todo el grupo pueda

encontrar en ella toda la información necesaria para su trabajo. Esto incluye:



182

información de contacto de los diferentes grupos/miembros del equipo,

documentos relacionados con la planificación, plantillas para la generación de

documentación, calendario de reuniones y cualquier otra información que se

decida colocar en el sitio. También se pueden almacenar las diferentes versiones

del documento de modo que se encuentran accesibles desde una intranet para

todos los usuarios interesados en ver los mismos.

Listas de Correo

En el caso de las listas de correo utilizadas durante la ejecución el

proyecto, sus beneficios son los mismos que los planteados para el grupo de

planificación, es decir:

� Proveer mayor dinamismo en las comunicaciones ya que durante

los procesos de ejecución, el dinamismo y la agilidad en todos los

sentidos resulta un factor crítico de éxito.


generados.


involucrados.

� Facilitar el intercambio de opiniones acerca de ciertos tópicos

cuando los involucrados en la discusión se encuentran en

locaciones geográficas muy distantes.

Foros de Discusión

Básicamente este caso es una combinación de algunas de las ventajas de

las wikis (compartir información y contenidos) y las ventajas de las listas de

correo (simplicidad de uso y facilidad de implementación). Esta combinación de

ventajas la convierte en muy atractiva para mejorar la comunicación dentro de

un proyecto. Sin embargo, en comparación con las demás ventajas que ofrecen

las dos alternativas antes mencionadas, no resulta tan conveniente aunque para

algunos proyectos con una estructura mas reducida, su simplicidad puede

resultar más atractiva que las wikis.



183


El caso de la mensajería instantánea aplicada al grupo de procesos de

ejecución, resulta una herramienta casi indispensable para la comunicación tanto

entre los grupos dentro del equipo como entre los miembros de cada grupo. Esta

herramienta se hace especialmente interesante cuando el equipo de trabajo está

distribuido en oficinas diferentes, de modo que las consultas breves o pedidos

simples pueden gestionarse mediante esta herramienta.


Esta técnica facilita la administración de las personas involucradas en el

proyecto y que, como se menciona antes, tienen gran influencia en el éxito o el

fracaso del mismo.

Otra de las ventajas en el uso de esta técnica es su adaptabilidad a los

diferentes tipos de proyectos de TI. Su versatilidad permite que no solo se utilice

para aquellos proyectos que involucran desarrollo de software, sino también a

aquellos en los que, por ejemplo, solo se implementan nuevas tecnologías.


En los proyectos la transferencia de conocimientos de otro de los factores

muy importante a tener en cuenta ya que es conveniente que varias personas

tenga conocimiento acerca de las actividades que se realizan. Esto facilita la

rotación de las personas y además funciona como plan de contingencia para

casos en que se pierda alguno de los miembros del equipo. Además, sirve como

plan de capacitación para los eventuales ingresos que se produzcan durante la

marcha del proyecto.

La desventaja que se presenta en este caso, es que la programación de a

pares es solo aplicables a proyectos que involucran desarrollos de software, de

modo que todas sus bondades no pueden aprovecharse cuando se trata de otro

tipo de proyectos de IT, aunque algunos ítems podrían adaptarse (por ejemplo en

caso de un proyecto de implementación de nuevas tecnologías, colocar a una

persona “novata” a trabajar con un experto en la instalación del nuevo hardware

de modo que se produzca la transferencia de conocimientos).



184


Si bien se está frente a una técnica que puede ser implementada en más

de un grupo de procesos, su implementación durante la ejecución del mismo

tiene fundamentalmente dos razones:


usuarios se sientan identificados con el nuevo producto involucrándolos

en las discusiones relacionadas con ciertos aspectos funcionales del

mismo.

� Obtener mayor cantidad de información acerca de ciertos requisitos del

proyectos e incluso obtener soluciones creativas y alternativas frente a

ciertos problemas. Esto último se logra gracias a que los usuarios no

están tan compenetrados en el detalle del proyecto y por lo tanto sus

ideas pueden fluir sin ningún tipo de sesgo.

SEGUIMIENTO Y CONTROL

1. Técnicas a Utilizar: De acuerdo a las necesidades planteadas y según los

objetivos que se persiguen en el grupo de procesos de control, las técnicas a

aplicar son: Reuniones, Wikis, Foros de Discusión, Listas de Correo, Mensajería

Instantánea, PERT., C.P.M, COCOMO y Puntos de Función.

Las Reuniones

Durante el seguimiento y control de un proyecto se pueden utilizar los

mismos tipos de reunión que se mencionaron para la ejecución, solo que en este

caso se deberá ponderar algunos otros aspectos para poder obtener información

específica de control. A continuación se analizarán cada uno de los tipos ya

mencionado remarcando los aspectos a considerar para convertirlas en una

técnica útil para el seguimiento de proyectos.


El caso de las Wikis, los Foros de Discusión y las Listas de Correo en

este caso se analizarán en conjunto ya que la utilidad de las tres técnicas



185

aplicadas al seguimiento y control de un proyecto es básicamente la misma, con

las diferencias que marcan simplemente su forma de funcionamiento.

En cualquiera de los tres casos la utilidad está dada fundamentalmente

por dos aspectos: la facilidad para distribuir / recopilar información necesaria

para monitorear el avance del proyecto y la facilidad para imprimir dinamismo

en las comunicaciones. Este segundo aspecto es el que mas importa en lo que

respecta a la administración del factor humano dentro de un proyecto.

Sin embargo, el hecho de que todo lo que se publica es visto por todos

los miembros genera un inconveniente: cuando la consulta debe ser privada

porque afecta a las relaciones con algún otro integrante del equipo o es un tema

muy delicado, no permiten tener privacidad. Esto lleva a sugerir que estas

herramientas se utilicen en conjunto con otras técnicas las cuales permiten tener

mayor privacidad en ciertos temas.


El caso de la mensajería instantánea es justamente la técnica que provee

la solución al problema de privacidad planteado con lo foros, las wikis y las

listas de correo. En este caso la ventaja principal es que la mensajería

instantánea permite mantener contacto entre personas en forma privada, de moso

que el resto del equipo no conozca dicho contacto. La prestación de contacto

“persona a persona” es fundamental en casos donde hay conflictos personales o

problemas que requieren un tratamiento discrecional. Además también tienen la

ventaja de que cuando se requiere información de solo una persona, sólo se

contacta a ésta sin molestar al resto con mensajes que no le corresponden ni

interesan.

PERT. / CPM

En el caso del seguimiento y control visto desde el punto de vista de la

administración de personas, la utilidad de los documentos generados por CPM y

PERT. radica en determinar la carga de trabajo de las personas. En muchos casos

se realiza una determinada distribución de tareas durante la planificación, pero

luego, durante la marcha del proyecto, puede que se noten deficiencias en esta

distribución. Esto puede darse porque las estimaciones no fueron lo

suficientemente precisas o porque el desempeño de las personas no es el



186

previsto. Es para detectar este tipo de inconvenientes que se necesitan de las dos

técnicas mencionadas.

COCOMO y Puntos de Función

El caso de COCOMO y de los Puntos de función aplicados al

seguimiento y control de un proyecto de TI tiene su importancia en el hecho de

que durante la marcha del proyecto pueden surgir cambios. Estos cambios

pueden ser menores o pueden ser cambios sustanciales que impacten en la

duración del mismo. En este último caso es que se dará la necesidad de utilizar

estas técnicas para redefinir algunos tiempos y determinar si, de acuerdo a las

nuevas definiciones y los nuevos tiempos calculados, la marcha del proyecto es

la correcta.

CIERRE

1. Técnicas a Utilizar: Según lo expuesto en la Tabla XIII, las técnicas a utilizar en

este grupo de procesos son: Reuniones, Wikis, foros de Discusión, Listas de

Correo, Mensajería Instantánea, Comités de Usuarios, Grupos de Apoyo y Mesa

de Ayuda.


La idea de utilizar estas técnicas durante el grupo de procesos de cierre

está fundamentalmente orientada a dar soporte a los usuarios finales. Esto se

basa en el hecho de que, al implementar un nuevo proyecto en una organización,

surgirán dudas acerca del uso tanto del software que se implemente como de las

tecnologías involucradas. En este sentido es que las wikis, los foros y las listas

de correo pueden ser muy bien explotados.

Estas herramientas permiten que los usuarios se puedan comunicar

fácilmente con el grupo del proyecto encargado de la puesta en marcha del

mismo, de modo que sus dudas o comentarios puedan ser recepcionados y

atendidos en forma muy simple.

La desventaja principal radica en que, al no ser herramientas en línea, las

respuestas a consultas urgentes estarán sujetas a la frecuencia con que el equipo

de proyecto o el resto de los usuarios ingresen al foro, el correo electrónico o la

Wiki.



187


La idea de implementar la mensajería instantánea en el grupo de procesos

de cierre es básicamente la misma que se menciona para el caso de los foros y

las listas de correo, es decir: dar soporte a los usuarios durante la

implementación del proyecto de forma tal que se disminuya todo lo posible la

resistencia al cambio. Además, se genera confianza en los usuarios ya que, por

contar con este tipo de mecanismos para evacuar dudas, se da una sensación de

respaldo y acompañamiento en la implementación.


La implementación de ésta técnica obedece a fundamentalmente a las dos

razones:


usuarios se sientan identificados con el nuevo producto involucrándolos

en las discusiones relacionadas con ciertos aspectos funcionales del

mismo de modo que se asegure una mejor comprensión.

� Generar un espacio donde los usuarios puedan compartir sus

experiencias y compartir su conocimiento, de modo que se genere una

verdadera comunidad de práctica.

Ésta segunda razón es quizás la mas importante porque ninguna de las

demás técnicas mencionadas apunta a lograr la creación de este tipo de

comunidades. Si bien en proyecto de pequeño o mediano tamaño puede resultar

poco convincente el uso de este tipo de comités, en proyectos de gran tamaño,

que se implementa en diferentes lugares u organizaciones, se transforma en una

técnica sumamente útil. Lo que se busca lograr formando este tipo de

comunidades es generar un sentido de pertenencia por parte de los usuarios para

con el proyecto, de forma tal que no se vean como algo externo al proyecto sino

como un componente mas del mismo. Esto resulta de gran ayuda para lograr una

finalización exitosa de proyecto.

Grupos de Apoyo

La utilización de los grupos de apoyo en el cierre de un proyecto tiene

como objetivo lograr una implementación rápida y exitosa.



188

Nuevamente la idea de esta técnica es generar confianza en los usuarios y

mostrarles que existe preocupación por su comodidad de parte del equipo del

proyecto.

La ventaja principal es que, el hecho de tener personas que los ayuden en

sus tareas con el nuevo sistema, tiene un efecto muy positivo sobre los usuarios

quienes se sentirán contenidos. Pero como contrapartida, la desventaja es que

requiere de personas del proyecto con un tiempo importante dedicado a estas

actividades y que además, en algunos casos, se puede generar en el usuario una

sensación de invasión de su espacio y su trabajo.

Mesa de Ayuda

Dependiendo de la organización y del tipo de proyecto, la

implementación de la mesa de ayuda puede ser muy simple ya que hay muchas

organizaciones que ya cuentan con grupos de este tipo para atender las

necesidades de los usuarios, de modo que solo se requeriría contar con personas

que tengan conocimiento del proyecto y que formen parte del grupo de la mesa.

Finalmente las mesas de ayuda tienen la ventaja de que pueden ser

perdurables a través del tiempo. Es decir que si el proyecto se da por finalizado,

la organización puede decidir la continuidad de la mesa de ayuda para dar

soporte a los usuarios no solo en aspectos relacionados con el proyecto puntual

que le dio origen, sino también a todos aquellos temas (tecnología y otras

aplicaciones) que la organización defina.



189

9.2- ANEXO II – CUESTIONARIO UTILIZADO

CUESTIONARIO : MODELO PARA LA GESTIÓN DEL FACTOR HUMANO

Sobre el Modelo en General

1- ¿Considera adecuada la elección de la estructura utilizada para el planteo del

modelo?

SI NO

2- ¿Sugeriría alguna modificación a la estructura?

3- ¿Considera que el modelo planteado es efectivamente aplicable a todos los

proyectos de TI?

SI NO

4- En caso negativo, ¿Porqué?

5- ¿Considera que el Modelo puede ser llevado a la práctica en forma exitosa?

SI NO

6- En caso negativo: ¿Qué modificaciones sugeriría para que sea posible de llevar a

la práctica?

7- ¿Considera correcta la agrupación de prácticas en Genéricas y Específicas?

SI NO



190

8- ¿Por qué?

Sobre las Prácticas Genéricas

9- ¿Considera que la selección de las Prácticas Genéricas del modelo es acertado?

SI NO


11- ¿Sugeriría la inclusión de alguna otra práctica?

SI NO

12- En caso afirmativo, ¿Cuáles?

13- ¿Considera correctas las particularidades indicadas para la aplicación de cada

una de las prácticas en cada grupo de procesos?

SI NO

14- ¿Sugeriría alguna modificación?



191

Sobre las Prácticas Específicas

15- ¿Considera que la selección de las Prácticas Específicas del modelo es acertado?

SI NO



SI NO


19- ¿Considera correcta la distribución prácticas específicas / grupo de procesos

propuesta?

SI NO




192

9.3- ANEXO III – RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 1




modelo?

SI X NO



proyectos de TI?

SI X NO



SI X NO


la práctica?


SI X NO

Aunque es mejor el foco a lo largo de cada grupo de procesos, evitaría cierta redundancia al considerar cada práctica en cada uno de esos grupos.

Poner el foco en la integración de las prácticas.



193

8- ¿Por qué?



SI X NO



SI X NO




SI X NO


Porque las generales se tratan en todo el proyecto, y las específica en cada grupo de proceso o área de conocimiento

Cadena Crítica, porque pone en evidencia los fenómenos humanos que causan la gran mayoría de los fracasos de los proyectos, y provee un enfoque metodológico para resolverlos.



194



SI X NO



SI X NO



propuesta?

SI X NO


Comunicación interpersonal

Nada más allá de la sugerida en el punto 12.



195

9.4- ANEXO IV – RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 2




modelo?

SI X NO



proyectos de TI?

SI X NO



SI X NO


la práctica?


SI X NO

No,, la estructura es adecuada.



196

8- ¿Por qué?



SI X NO



SI X NO




SI X NO


Esta división es usual en los modelos de calidad, tiene coherencia, y ha sido verificada en suficientes casos.

Se podría analizar si la conveniencia de dividir la práctica “Reuniones” en tres tipos: “Reunión Objetivo”, que posee un único y claro objetivo e incluye la toma de decisiones; “Reuniones de Ideas” en las cuales se generan ideas sobre algún tema, pero no se toman decisiones y “Reuniones de relevamiento” cuyo objetivo es obtener información, también, sin tomar decisiones. También sería importante incluir “Reuniones Virtuales” a través de Internet (por ejemplo con Camfrog), sobre todo si los involucrados no residen en la misma localidad

En las Reuniones, creo que es conveniente informar a todos los participantes los temas a tratar en forma previa a la reunión (en el modelo se menciona que se lo informa al comenzar la reunión).



197



SI X NO



SI X NO



propuesta?

SI X NO


Las técnicas de CPM y PERT son complementarias a la técnica GANTT. Actualmente existen herramientas informáticas de gestión de proyectos que combinan las tres técnicas dando como resultado una representación más completa y útil. Sería interesante utilizar esta última solución. Las prácticas PF y COCOMO sólo sirven si el proyecto es de desarrollo de software o de sistemas de información. Debería haber alguna práctica alternativa de estimación, como por ejemplo Top-Down y/o Buttom-Up para otros tipos de proyectos..

No, considero que es adecuada.



198

9.5- ANEXO V – RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 3




modelo?

SI x NO



proyectos de TI?

SI x NO

4- En caso negativo, ¿Por qué?


SI x NO


la práctica?


SI x NO

No.



199

8- ¿Por qué?



SI x NO

10- En caso negativo, ¿Por qué?


SI NO x




SI x NO


La agrupación planteada y el detalle presentado de las prácticas permiten visualizar claramente las ventajas que se obtienen con su aplicación en cada una de las fases de un proyecto.

No.



200



SI x NO



SI NO x



propuesta?

SI x NO


No.



201

9.6- ANEXO VI – RESPUESTAS DEL CUESTIONARIO DEL EXPERTO 4




modelo?

SI X NO



proyectos de T.I.?

SI NO X



SI X NO


la práctica?


No. Considero correcto la utilización de la estructura propuesta y la división en Practicas Genéricas y Prácticas Específicas.

El modelo y conjunto de prácticas expuesto por el PMI ha tenido en sus comienzos una amplia aceptación en cuanto al estudio de cada una de las posibles fases y áreas de conocimiento existentes en un proyecto. Sin embargo, esta sumando día a día nuevos cuestionamientos respecto a la falta de dinámica propia de los proyectos “no tradicionales” (como los de TI). Esto está llevando al PMI a evaluar la posibilidad de revisar su metodología y orientar parte de la práctica hacia una versión más “ágil”, incluso en el área de Administración del Factor Humano.

NOTA: Considero puede ser positivo en el caso de proyectos tradicionales y de duración prolongada. Sugeriría observar con mayor detenimiento los lineamientos expuestos por SCRUM (una de las prácticas líder en TI) y a su vez, la visión de la Administración del factor humano por parte de CMMI (niveles 3 y 4).



202

SI X NO

28- ¿Por qué?



SI X NO



SI X NO




SI X NO


Todo proyecto, sea cual fuere su Industria de pertenencia contiene prácticas que son transversales a las etapas por las que pasa y otras, mas particulares, que tiene una inherencia una fase en cuestión. El desarrollo del equipo de trabajo, es un aspecto clave, tanto en la fase de Iniciación, de Ejecución, como de Cierre.

Plataformas Colaborativas y Redes Sociales. La utilización de plataformas colaborativas en el ámbito del TI es actualmente uno de los aspectos de Administración del Factor Humano que más está creciendo en las organizaciones. (ClearSpace, FaceBook, Sharepoint, etc)

No.



203



SI X NO



SI X NO



propuesta?

SI X NO


Creo que las seleccionadas son acertadas pero están faltando otras prácticas que hacen a la administración del factor humano. Una de ellas que resalta ampliamente PMI es la creación de la WBS (Estructura de desglose del Trabajo). La considera no solo una herramienta comunicacional sino también un elemento que da sentido de ubicación, pertenencia y motivador del equipo. Insisto en que pueden haber algunas mas, pocas en el caso de PMI, pero más si se evalúa la Gestión de Proyectos en su sentido más amplio. Recomiendo repasar el libro de Kim Heldman referido al PMBOK, dado que ella hace foco en el Factor Humano.

No.

Documents

Tesis para optar al grado de Magíster en Ingeniería de ...posgrado.frba.utn.edu.ar/investigacion/tesis/MIS-2009-Turin.pdf · 9.5- Anexo V – Respuestas del Cuestionario del Experto