Modelo para la Administración de la Documentación de un Proyecto de Tecnología de Información-Edición Única

Modelo para la Administración de la Documentación de un

Proyecto de Tecnología de Información-Edición Única

Title Modelo para la Administración de la Documentación de un Proyecto de Tecnología de Información-Edición Única Authors Arturo Fernando Soto Casado

Affiliation ITESM Issue Date 2002-01-01 Item type Tesis

Rights Open Access

Downloaded 19-Jan-2017 11:34:41

MODELO PARA LA ADMINISTRACIÓN DE LA DOCUMENTACIÓN DE UN PROYECTO DE TECNOLOGÍA DE INFORMACIÓN

TESIS

MAESTRÍA EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

ARTURO FERNANDO SOTO CASADO

MODELO PARA LA ADMINISTRACIÓN DE LA DOCUMENTACIÓN DE UN PROYECTO DE TECNOLOGÍA DE INFORMACIÓN

POR

ARTURO FERNANDO SOTO CASADO

TESIS

Presentada al Programa de Graduados en

Electrónica, Computación, Información y Comunicaciones.

Este trabajo es requisito parcial para obtener el título de Maestro en Administración de Tecnologías de Información

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE

MONTERREY

DEDICATORIA

A Dios

Por concederme las virtudes y habilidades para lograr todo lo que me propongo en la vida.

A mis padres

Por enseñarme con su ejemplo y por darme siempre su apoyo.

A Sofía

Por darme su ayuda, sus ánimos, su inspiración y sus consejos.

RECONOCIMIENTOS

• Al Ing. Miguel Ángel Pérez Guardado, por su guía y su paciencia durante todo el proceso de investigación, pero sobre todo, por su amistad.

• Al mis sinodales, Dr. David Ángel Alanís Dávila y Lic. José Luis Montes, por ser ambos la voz crítica que aseguró la calidad de este trabajo.

RESUMEN

MODELO PARA LA ADMINISTRACIÓN DE LA DOCUMENTACIÓN DE UN PROYECTO DE TECNOLOGÍA DE INFORMACIÓN

En la actualidad es asegurar que la información sea aprovechada al máximo por las organizaciones, particularmente en el desarrollo de proyectos de Tecnología de Información, donde el tiempo y el costo del desarrollo puede significar la diferencia entre el éxito y el fracaso del proyecto

En la bibliografía actual existen diferentes metodologías para la administración de proyectos, donde algunas de ellas emplean tecnología con diferente nivel de uso y otras se encuentran enfocadas al uso de estándares para los documentos. Sin embargo, no existe un modelo definido para la administración de la documentación generada como parte del proyecto de Tecnología de Información.

El objetivo de la presente tesis es la propuesta de un modelo para el soporte de la documentación de desarrollo de proyectos de TI en una empresa mexicana. El modelo busca mejorar la efectividad general del proyecto en sus dimensiones de costo, tiempo de desarrollo y funcionalidades desarrolladas como parte del proyecto. El alcance del resultado de la investigación cubre exclusivamente la propuesta del diseño del modelo.

La información utilizada para la creación del modelo propuesto fue recabada por medio de la consulta de bibliografía sobre administración de proyectos y publicación de documentación, y por medio de una investigación cualitativa utilizando la metodología de Grounded Theory, desarrollada por los sociólogos Barney G. Glaser y Anselm L. Strauss [Glaser 1967]. Esta metodología basa el análisis de la situación estudiada a través de valoración de documentos, de entrevistas, y de la propia experiencia del investigador.

TABLA DE CONTENIDO

1 Introducción 1 2 Marco Teórico 3 2.1 Metodologías y guías de documentación 3 2.2 Estándares de documentación 7 2.3 Documentación en proyectos de TI 8 2.4 La administración de la documentación 10 2.5 El repositorio de la documentación 11 3 Metodología de la Investigación 14

3.1 Grounded Theory 14

3.2 Herramientas utilizadas 17 3.3 Metodología 18 4 Proyecto de Investigación 21 4.1 Contexto del proyecto 21 4.2 Expectativas y Justificación 28 4.3 Desarrollo de la investigación 29 5 Resultados de la Investigación 34 5.1 Resultados de las entrevistas 34 5.2 Resultados del análisis de documentos 36 5.3 Resultados relevantes de la investigación 37 5.4 Observaciones intermedias 38 6 Modelo Propuesto 40 6.1 Objetivos específicos del modelo 40 6.2 Elementos principales del modelo 42 6.3 Flujo de la información en el modelo 47 6.4 Elementos no considerados en el modelo 50 6.5 Limitaciones del modelo propuesto 51 6.6 Factibilidad del modelo 54 6.7 Beneficios del modelo 55 7 Conclusiones y trabajos futuros 57 Anexo A - Guía de entrevistas de Primera y Segunda Ronda 59 Guía de la Primera Ronda 59 Guía de la Segunda Ronda 60 Anexo B - Preguntas particulares 62 Anexo C - Elementos encontrados en las entrevistas 63 Anexo D - Elementos encontrados en la documentación 65 Bibliografía 66 VITA 69

LISTA DE FIGURAS

Figura 1. Modelo de Amami [2000] 4 Figura 2. Modelo de Pakin [1984] 5 Figura 3. Modelo de Hackos [1994] 5 Figura 4. Modelo de Simpson [1998] 6 Figura 5. Organigrama del Proyecto de TI 22 Figura 6. Modelo Propuesto para la Administración de la Documentación 43 Figura 7. Flujo de un Documento Nuevo 48 Figura 8. Flujo de un Documento Actualizado 49

LISTA DE TABLAS

Tabla 1. Categorías de los elementos encontrados en las entrevistas 35 Tabla 2. Categorías de los elementos encontrados en los documentos analizados 36 Tabla Cl. Categorías de los elementos encontrados en las entrevistas 63 Tabla C2. Deficiencias de la documentación utilizada 63 Tabla C3. Patrones de uso de la documentación 63 Tabla C4. Actividades soportadas por la documentación 63 Tabla C5. Impactos sobre la efectividad provocados por la documentación 64 Tabla C6. Otros elementos relacionados con la documentación 64 Tabla DI. Categorías de los elementos encontrados en las documentos analizados 65 Tabla D2. Deficiencias de la documentación utilizada 65 Tabla D3. Patrones de uso de la documentación 65 Tabla D4. Características de la administración de la documentación 65 Tabla D5. Impactos sobre la efectividad provocados por la documentación 65

1 Introducción

En la actualidad, todas las compañías son en esencia organizaciones basadas en información. El valor de sus productos o servicios depende en gran parte de cómo se aprovecha la información dentro de ellas. Sin embargo, la mera existencia de la información dentro de una organización no asegura que será transmitida, compartida y utilizada de manera eficiente por todos sus miembros. Es por ello que se vuelve necesario establecer mecanismos que aseguren que la información sea aprovechada al máximo por las organizaciones.

Esto se vuelve crítico particularmente en el desarrollo de proyectos de Tecnología de Información (TI), donde el tiempo y el costo del desarrollo puede significar la diferencia entre el éxito y el fracaso del proyecto. Es aquí donde se vuelve relevante la documentación de los proyectos de TI, ya que a través de ella se define y se lleva el seguimiento de las funcionalidades y características que debe tener cada sistema, plataforma o solución desarrollada para satisfacer las necesidades de los clientes internos y externos de cada compañía. A través de la correcta administración de la documentación de un proyecto de TI se puede mejorar la comunicación entre los participantes del proyecto.

Existen actualmente diferentes metodologías para la administración de proyectos, donde algunas de ellas emplean tecnología con diferente nivel de uso y otras se encuentran enfocadas al uso de estándares para los documentos. Estas metodologías fueron estudiadas para tomar ¡deas que sirvieran para el desarrollo de un modelo que por sus características fuese factible y efectivo para implementarse en una empresa donde se desarrollan proyectos de TI. Una restricción importante de este modelo se basa en información recabada por medio de un estudio de investigación cualitativa, Grounded Theory, desarrollada por los

sociólogos Barney G. Glaser y Anselm L. Strauss [Glaser 1967], fundamentada por análisis de la situación real a través de valoración de documentos, entrevistas, y la propia experiencia del investigador.

De lo anterior, se establece el objetivo de la presente tesis es la propuesta de un modelo para el soporte de la documentación de desarrollo de proyectos de TI en una empresa mexicana. El producto final de la tesis será un modelo de documentación para el desarrollo de este tipo de proyectos, buscando mejorar la efectividad general del proyecto; y el cuál está basado en un estudio cualitativo en una empresa mexicana de telecomunicaciones. El alcance del resultado de la investigación cubre exclusivamente la propuesta del diseño del modelo.

asegurar su disponibilidad, distribución y validez a lo largo del desarrollo del mismo. Las ventajas logradas se reflejan en menos retrasos e incrementos en el costo del desarrollo de los proyecto de TI.

Dentro del capítulo de Marco Teórico se revisa la literatura existente sobre el tema. En él se describe el estado actual de las guías y metodologías para el desarrollo de documentación, los estándares propuestos por diferentes autores para la creación de documentos dentro de proyectos. Además se presentan los conceptos de administración de documentación y del repositorio de documentación.

El capítulo de Metodología contiene una descripción de la metodología utilizada dentro de la investigación de campo. Esta descripción incluye la historia de la metodología, sus características y sus herramientas. Además se describen las razones por las cuales fue seleccionada esta metodología, así como los pasos completos del desarrollo de la investigación de campo y un breve resumen acerca del caso de estudio.

El capítulo de Resultados y Modelo Propuesto presenta los resultados de la investigación de campo (entrevistas y análisis de documentos). Además, se describe el modelo propuesto para la administración de documentación de un proyecto de TI y de sus características, así como las limitaciones del modelo, su factibilidad de implantación y los beneficios esperados de ésta.

2 Marco Teórico

Hoy en día, todas las compañías son en esencia organizaciones basadas en información. Su valor y el valor de sus productos o servicios dependen en gran parte de la información que poseen sus miembros y de cómo la aprovechan. En las organizaciones, la información sólo tiene valor para cada usuario si le es útil para satisfacer sus necesidades.

Aunque la información exista dentro de una organización, su mera existencia no asegura que será transmitida, compartida o utilizada adecuadamente por sus miembros. Es por ello que se deben establecer mecanismos en toda la organización que aseguren la correcta generación, distribución y utilización de esta información. En otras palabras, mecanismos que mejoren la comunicación dentro de la organización.

De acuerdo a Thomas [1999], no hay habilidad más valiosa para una persona, Administrador de Proyectos o no, que la habilidad para comunicarse efectivamente con otros. Un elemento importante de la comunicación efectiva dentro de un proyecto de TI es la documentación que se genera como parte del proyecto. La buena documentación no es un accidente, sino que resulta de tomar una serie de decisiones acertadas a lo largo de los pasos del desarrollo del proyecto de TI [Pakin 1984].

2.1 Metodologías y guías de documentación

Work Breakdown Structure Docunuent Bieakdown Structure

Phase Breakdown

Structure

Figura 1. Modelo de Amami [2000]

El primer modelo de documentación estudiado es el de Document Breakdown Structure (DBS) (Figura 1), presentado por Amami [2000], el cual es un

complemento a la metodología de administración de proyectos Work Breakdown Structure (WBS). El modelo DBS exige asignar a cada actividad del proyecto un

documento específico, producto de dicha actividad.

El Administrador de Proyecto pueden enlazar actividades, recursos y metas cumplidas a través de esos documentos. Una fase no puede considerarse concluida hasta que todos sus documentos hayan sido generados. Sin embargo, la mayor debilidad del modelo DBS es que no especifica cuál debe ser el formato de los documentos a los que hace mención.

Por otro lado, Pakin [1984] propone la metodología de Document Development Methodology (DDM), mostrada en la Figura 2, para el desarrollo de

documentación. La metodología DDM está compuesta por los siguientes 10 pasos: • Planear la documentación del proyecto.

• Planear el contenido de la documentación. • Planear el formato de la documentación.

• Revisar del plan de documentación y comprometer a la escritura. • Escribir el primer borrador.

• Desarrollar las gráficas. • Revisar el detalle técnico.

• Rescribir y completar las gráficas.

Figura 2. Modelo de Pakín [1984]

En la metodología DDM, algunos de los pasos son secuenciales, mientras que otros se realizan de manera simultánea. Además, los pasos del 1 al 4 se realizan una sola vez, mientras que los pasos del 5 al 10 se realizan para cada documento creado. Aunque la metodología menciona que se debe planear el formato de la documentación, no menciona guías específicas sobre dicho formato.

Figura 3. Modelo de Hackos [1994]

Existen otras metodologías sobre el desarrollo de documentación, como las de Hackos [1994] y Simpson [1998]. Para el primero, la evaluación de la publicación es el último paso del modelo, pero no existe una retroalimentación. Es importante observar que este modelo (Figura 3) también incluye la Especificación de Contenido como un paso importante en el desarrollo de la documentación.

1 . Formar el equipo de desarrollo de

documentación

ir 2. Hacer que k documentar ion coincida para cada usuario.

ip

3. Preparar planes de documentación.

1

ir

5. Desarrollar plan de administración.

ip

6. Crear la documentación.

7. Conducir la revisión técnica.

8. Conducir la evaluación de bs usuarios.

9. Crear e 1 borrador final.

Figura 4. Modelo de Simpson [1998]

Ninguna de estas cuatro metodologías, Pakin [1984], Hackos [1994], Simpson [1998], y Amami [2000], hace referencia explícita a un administrador de esta documentación ni al uso de un repositorio central para la documentación del proyecto.

Además de los modelos encontrados en la literatura acerca de documentación, existen guías sobre el desarrollo de la misma. A diferencia de los anteriores, estos no son esquemáticos, sino que sólo presentan lineamientos para el desarrollo de documentación. Dos autores significativos para este trabajo de investigación fueron Ayer [1992] y Gómez [1998].

Ayer [1992] propone por un lado la utilización de una guía para el desarrollo de la documentación. Esta guía contiene los siguientes elementos:

• Opciones de administración. Se refieren al tamaño del documento, la

separación de un documento en varios, o la combinación de varios documentos en uno solo.

• Formato y estilo. Define las partes y sub­partes del documento, la

numeración de esas partes, el desarrollo de tablas e ilustraciones y el uso de mayúsculas en las sub­divisiones.

• Estándares de documentación. Definen los estándares a los que deben

apegarse todos los documentos que pueden ser producidos durante el desarrollo de un proyecto.

• Reglas de control de cambios. Definen cuáles documentos están sujetos al control de cambios, quiénes son los responsables de hacer los cambios, y cuál es el procedimiento para realizar y clasificar los cambios.

Ayer [1992] propone también que para asegurar que un documento en particular es completo y exacto debe estar sujeto a una revisión formal antes de ser publicado. De acuerdo a este modelo, los responsables de dicha revisión deben contestar las siguientes preguntas:

• ¿Interpretó el escritor la información de manera correcta? • ¿Se presenta la información de manera completa y exacta?

• ¿El documento transmite la información que tenía la intención de transmitir? Gómez [1998] además propone como guía dos caminos convergentes para obtener una documentación de proyecto legible y coherente:

• La estructuración de documentos, perfectamente diferenciados y complementarios.

• La ordenación del contenido de cada uno de los documentos.

Por último, la existencia de las guías para desarrollar documentos dentro de las organizaciones no basta para que sean acatadas. Es necesario que se emitan políticas al nivel de la alta gerencia que apoyen a dichas guías. Tanto Ayer [1992] como Gómez [1998] omiten hacer referencia explícita a cuál debe ser la "estructuración" de los documentos del proyecto. Esta estructuración es definida por los estándares de documentación de las organizaciones.

2.2 Estándares de documentación

En la literatura sobre desarrollo de documentación existen definiciones sobre los estándares de documentación que describen su concepto y objetivo. En general, un estándar de documentación es un conjunto de reglas utilizado para normar el diseño, el estilo y el formato de los documentos generados en una organización. El objetivo de los estándares de documentación es promover la consistencia entre sí de todos los documentos generados como parte de un proyecto de TI.

estándares de documentación deben ser establecidos para especificar el contenido de cada documento, los documentos finales a producir y las secciones que resultan de cada tarea del proyecto [Ayer 1992].

Además, las guías para el desarrollo de documentación deben coincidir con la metodología de desarrollo del proyecto, para tener un control eficiente sobre el mismo [Ayer 1992]. Gómez [1998] propone cinco criterios para establecer un estándar en cuanto a la ordenación de documentos:

• Ordenar de lo general a lo particular.

• La ordenación interna de cada documento debe ceñirse al estándar definido.

• Cada documento debe ser completo en sí mismo.

• Cada documento debe dividirse al menos en tantas partes como suministradores diversos existan, y cada parte debe tener sentido en sí misma y con el conjunto.

• Los documentos deben utilizar la clasificación decimal.

Apoyando las ideas de Gómez [1998], Thomsett [1999] propone que, dado que cada proyecto es diferente, no se puede establecer en los documentos un nivel de detalle que sea apropiado para todos los casos. Cada proyecto debe dictar el nivel de detalle en los documentos de acuerdo a las necesidades que se presenten a lo largo de su desarrollo.

Al igual que las guías y las metodologías de desarrollo de documentación, los estándares para el desarrollo de documentación no hacen referencia a las actividades de controlar, distribuir, almacenar, recuperar y desechar la documentación de un proyecto.

2.3 Documentación en proyectos de TI

Además de los estándares para la creación de documentación, es importante también asegurar que la documentación llegue a todos los participantes en el proyecto de TI. De acuerdo a Back [2001], es necesario poner énfasis sobre cómo mejorar el acceso y la calidad de la información del proyecto. Para ello, las necesidades de información de los participantes en el proyecto de TI deben ser definidas claramente y documentadas apropiadamente para ser implementadas con exactitud.

creciente tendencia en las organizaciones para crear equipos de trabajo en los que sus miembros están en lugares geográficamente separados. Estas dos características afectan la comunicación efectiva del equipo, la cual según Thomas [1999] es uno de los mayores retos a los que se enfrenta el éxito de un proyecto de TI.

En los proyectos técnicamente complejos y basados en calendarios de trabajo estrictos, los diversos antecedentes y la composición dinámica de los equipos de trabajo limitan el desarrollo de una comunicación crítica [Thomas 1999]. Ya que la comunicación efectiva está dentro de los factores más significativos que contribuyen al éxito de un proyecto de TI [Thomas 1999], ésta debe ser cultivada y planeada como un recurso más por el Administrador del Proyecto de TI [Jiang 2002].

De acuerdo a Jiang [2002], el Administrador de Proyecto debe administrar los recursos necesarios para entregar un producto que cumpla con las metas establecidas sin perder el control sobre el tiempo y el costo. Con la ayuda de la tecnología, el Administrador de Proyecto debe sobre todo hacer posible que varias personas trabajen de manera armoniosa e integrada hacia el objetivo del proyecto de TI. En otras palabras, el Administrador de Proyecto "es responsable de la ejecución efectiva del proceso de desarrollo del proyecto" [Jiang 2002].

Parte de la comunicación efectiva entre los miembros del equipo depende de que cada uno de ellos tenga claro cuál es su rol dentro del proyecto de TI. Así como hay participantes que elaborarán la documentación, también debe existir un administrador de la documentación que la recolecte, la valide, la clasifique, la distribuya y la actualice. Entre la funciones que propone Ayer [1992] para el administrador de la documentación se encuentran:

• Establecer un plan de documentación. • Controlar la publicación de documentos. • Asegurar el apego a los estándares.

2.4 La administración de la documentación

Aunque existe una gran cantidad de literatura sobre la administración de proyectos y el desarrollo de productos, poca de ésta se refiere a la generación, la distribución y los cambios de la documentación [Amami 2001]. De acuerdo a Megill [1999], el significado de un documento no sólo es controlado por su autor, sino también por el uso que se le da. Debido a este comportamiento dinámico de los documentos, se requiere establecer un mecanismo para administrarlos.

Si en un proyecto se trabaja basándose en la información, es lógico asumir que al documentar esa información se mejorará el desempeño del proyecto. Megill [1999] define que el propósito principal de la administración de documentación es incrementar el valor de la información. Las actividades de la administración de documentación buscan satisfacer las necesidades de información dentro del flujo de trabajo de la organización [Megill 1999].

La administración de la documentación es intrínseca al flujo de trabajo de una compañía. Comienza cuando la información es creada, compartida, utilizada, re­ utilizada, modificada, almacenada, recuperada y eliminada del sistema [Back 2001, Megill 1999]. La administración de documentación está enfocada a la forma en que la información, es decir, los documentos, se mueven dentro del proceso de trabajo de la organización [Megill 1999].

Para Back [2001] y para Megill [1999], la administración de documentación tiene los siguientes objetivos específicos:

• Estructurar la información • Conectar la información • Almacenar la información • Modificar la información • Utilizar de la información • Compartir la información • Intercambiar la información • Acceder la información

Como cualquier otra actividad dentro de la organización, la administración de documentación debe ser evaluada de acuerdo a la relación costo /beneficio que tiene para el proyecto de TI. En la medida que la administración de documentación eleve el valor de la información, estará generando un beneficio para la organización.

2.5 El repositorio de la documentación

Al igual que en el caso de la administración de documentación, existe poca literatura referente al uso de un repositorio de documentación. En el campo de Administración de Proyectos el rol de un sistema computacional para registrar, administrar y poner disponibles los documentos del desarrollo del proyecto ha sido relativamente ignorado. Un repositorio de documentación provee una locación central de almacenamiento para los documentos y una forma para propagar esos documentos hacia todos los participantes en un proyecto de TI.

El desarrollo e implementación efectivos de un sistema de documentación depende, en gran medida, del seguimiento de una metodología, del establecimiento de estándares de documentación y de una clasificación efectiva del contenido del repositorio [Megill 1999, Markus 2001]. Los beneficios esperados de la utilización de un repositorio de documentación son el compartir información propiedad de diferentes grupos, el tener una perspectiva holística de todo el proyecto y el trabajar dentro de un proceso definido con un punto de vista sistémico.

En la mayoría de los casos, los documentos generados dentro de un proyecto de TI contienen información no sólo en forma de texto, sino también en forma de diagramas, esquemas e imágenes fotográficas. El manejo de dichos documentos requiere, de acuerdo a Megill [1999], de un sistema electrónico de administración de documentos diseñado para manejar de manera integral documentos que integren por lo menos texto e imágenes. El mismo autor señala además que las tecnologías de administración de documentación permiten a los profesionales de los servicios de información convertirse en administradores de información, y no meros administradores de documentos [Megill 1999]. Además, los sistemas de administración de documentos electrónicos involucran las funciones relacionadas a la administración de documentación. Para este autor, los elementos de la administración de documentación deben ser cubiertos por las tecnologías de administración de documentación, e incluyen:

• La creación/ captura de documentos. • El almacenamiento de archivos.

• El registro e indexación de documentos de acuerdo al autor, tema, contenido, etc.

• La recuperación de documentos para consultas, impresiones, ediciones. • El registro y seguimiento de los cambios de estado en los documentos. • El administrar el flujo de trabajo.

El autor concluye que al cubrir los elementos anteriores, el uso de tecnologías de administración de documentación permite controlar el flujo de los documentos dentro de la organización.

Por su parte, Markus [2001] afirma que la creación de un repositorio debe tomar en cuenta las necesidades particulares de los usuarios a los que dará servicio. En general, al crear un repositorio se deben tener presentes los diferentes antecedentes de cada usuario. En otras palabras, el repositorio debe ser creado pensando en todos los diferentes usuarios que tendrán acceso a él.

Markus [2001] continúa, señalando la existencia de tres puntos importantes para el éxito de repositorio que deben ser considerados durante su planeación:

• Los costos involucrados en la creación del repositorio de documentación. • Los incentivos que los creadores de la documentación tienen para contribuir

a un repositorio que será utilizado por terceros

• La necesidad de que intermediarios hagan apropiados los registros del repositorio para que sean utilizados por terceros.

Estos tres puntos se describen a detalle en los siguientes párrafos.

En primer lugar, existen muchas opciones de TI económicamente accesibles para la creación de un repositorio. Dicho repositorio puede ser desde una simple computadora personal con uno o varios directorios compartidos en red, hasta un servidor altamente sofisticado con software para desplegar documentos en hipertexto. En general, existen dos factores que vuelven práctica la concentración de documentos en un repositorio centralizado [Markus 2001]:

• Las capacidades actuales de almacenamiento y procesamiento computacional.

• Las capacidades actuales de las redes y las telecomunicaciones.

Además de los costos en tecnología, la creación de un repositorio genera costos organizacionales, siendo uno de los principales los incentivos relacionados con él. La creación y utilización de un repositorio donde no existe previamente representa un esfuerzo por parte de los generadores y de los usuarios de la documentación. Sin embargo, en el mismo artículo Markus [2001] argumenta que este esfuerzo no sería necesariamente un problema si estuviera balanceado por los incentivos apropiados. Dichos incentivos deben estar soportados por la organización en la forma de recompensas y reconocimiento.

Finalmente, la necesidad de contar con un intermediario que administre el repositorio de información está cubierta con la función del administrador de la documentación. Dado que el administrador de la documentación debe de recolectarla, validarla, clasificarla, distribuirla y actualizarla, está en efecto, volviéndola apropiada para ser utilizada por terceros.

Al existir un repositorio de documentación para un proyecto, la documentación contenida en él contará con las siguientes características:

• Disponible. • Clasificada. • Vigente.

Estas características de la documentación del repositorio ofrecen dos ventajas. En primer lugar, permiten que la información del proyecto siempre sea congruente en su significado entre todas la áreas participantes. En segundo lugar, permiten que los participantes no pierdan tiempo buscando la versión más reciente de un documento entre varias fuentes. Además de lo anterior, estas características brindan apoyo a las actividades de soporte al desarrollo del proyecto de TI tales como la publicación de los avances, el registro de los compromisos, el seguimiento a las actividades y la difusión de los beneficios del proyecto.

Se estudiaron los modelos más recientes en torno al desarrollo de documentación como base para el desarrollo de esta investigación. En general, las guías, modelos y metodologías estudiados concuerdan en que todo documento derivado de un proyecto debe ser exacto, estar completo, y ser sujeto de una revisión formal antes y después de ser publicado [Amami 2000, Pakin 1984, Simpson 1988]. Sin embargo, ningún autor hace referencia explícita al establecimiento de un repositorio de documentación o al rol de un administrador de la documentación.

Ayer [1992] propone varias funciones que debe cumplir el administrador de la documentación tales como recolectarla, validarla, clasificarla, distribuirla y actualizarla. Megill [1999] y Markus [2001] proponen por otro lado la utilización de sistemas de administración de documentos electrónicos que cubran los requerimientos relacionados con esta función. La utilización de un repositorio para administrar la documentación permite controlar el flujo de la información entre los participantes de un proyecto de TI [Markus 2001].

Finalmente, la documentación contenida en el repositorio permanece disponible, clasificada y vigente, por lo que la información del proyecto de TI entre todas las áreas participantes siempre es congruente y siempre se cuenta con la versión más reciente de cualquier documento.

3 Metodología de la Investigación

3.1

Grounded Theory

Debido a la naturaleza de esta investigación, donde la experiencia y la perspectiva de los participantes son esenciales para fincar las bases del modelo propuesto, se ha seleccionado la metodología inductiva Grounded Theory. Esta

metodología toma elementos como la experiencia, la perspectiva individual y los modelos mentales para analizar situaciones y generar teorías que las expliquen.

Grounded Theory fue desarrollada por los sociólogos Barney G. Glaser y Anselm

L. Strauss en 1965 al estudiar la conciencia sobre su propia muerte entre pacientes terminales. Glaser y Strauss llamaron al método de investigación utilizado "Grounded Theory" y lo publicaron en el libro "The Discovery of Grounded Theory: Strategies for Qualitative Research" en 1967 [Glaser 1967].

La metodología inicia con una pregunta de investigación; y a lo largo del desarrollo del proyecto, la pregunta de investigación puede modificarse y derivar en un tema diferente. Lo anterior es porque Grounded Theory permite que la teoría

brote por sí misma a partir del análisis de los datos, ya que estos se convierten en los pilares de esa nueva teoría. De hecho, el propósito básico de la metodología es que la teoría emerja de los datos. En este sentido, Grounded Theory es la

generación sistemática de teoría a partir del análisis de los datos adquiridos a través de un riguroso método de investigación.

Por sus características, Grounded Theory ha sido ampliamente empleada en

investigaciones en las áreas de sociología, enfermería, educación y el trabajo social. Algunos ejemplos de situaciones estudiadas son innovación en el proceso de enseñanza superior [Kozma 1985], las necesidades de entrenamiento de los maestros de ciencias [Spector 1991], la participación de enfermeras en cursos de postgrado [Thompson 1992], la naturaleza del liderazgo en comunidades rurales [McCaslin 1993], y la interacción en una clase de educación básica para adultos [Courtney, Jha, & Babchuk 1994]. Como se puede observar, en cada uno de estos proyectos los elementos del factor humano como experiencia, perspectiva individual y modelos mentales conforman un contexto y grupo de ideas en torno a la situación estudiada. Este grupo de ideas puede ser explicado con la generación de una teoría, misma que permite al investigador entender y resolver la situación inicial.

Dado que la interacción entre los miembros de una organización es un proceso clave en el desarrollo de proyectos de TI, Grounded Theory se convierte en una

metodología ideal para el análisis de dichas situaciones. La percepción de cada

participante conforma el elemento principal de la situación estudiada, y el diseño de Grounded Theory permite precisamente crear un modelo de dicha situación a

partir del análisis de esas percepciones. Esta característica representa una ventaja sobre las metodologías cuantitativas, las cuales no se ajustan fácilmente a las dimensiones sociales de un problema o requieren de experimentos en medios controlados para probar sus teorías.

Grounded Theory [Glaser 1967] se basa en la primicia de que los fenómenos

de la vida social no son aleatorios, sino que existen como conjuntos de uniformidades de comportamiento que se repiten a lo largo del tiempo, es decir, como un grupo de elementos y sus relaciones. Otros supuestos en los que se apoya la metodología son:

• Las personas actúan basándose en los significados • Los significados son definidos a través de la interacción

• Las personas participan activamente en las situaciones problemáticas • La complejidad y variabilidad de la acción son fenómenos humanos

• El mundo está integrado en forma empírica, y no se encuentra modelado de manera lógica

Estos supuestos hacen de la metodología una herramienta apropiada para investigar los movimientos sociales, los fenómenos culturales y el funcionamiento organizacional. Su orientación práctica está dirigida hacia las interacciones sociales entre las personas.

Al utilizar Grounded Theory se espera desarrollar también un recuento del

fenómeno estudiado que identifique elementos, categorías y relaciones dentro del contexto, y así generar un conjunto de ideas que conlleven a una teoría sobre el fenómeno. Se espera que esta teoría resulte ser mucho más que una simple descripción del fenómeno [Lincoln 1985]. Es un requisito de la metodología generar un modelo o teoría a partir de la investigación; de lo contrario sólo se considera una descripción de un fenómeno o un caso de estudio [Straus 1998].

Una vez explicada la filosofía de la metodología, es importante describir las fases que la conforman. Grounded Theory especifica tres fases para la recolección

de datos en la investigación [Denzin 1994, Straus 1998]. En esta metodología la recolección de datos es guiada por un muestreo basado en elementos relevantes desde el punto de vista del investigador. Las fases de recolección y su tipo de muestro son:

a Fase inicial. Se utiliza el muestreo abierto de personas, sitios y documentos, involucrando procedimientos sistemáticos. En esta fase se busca descubrir e identificar los datos que son relevantes para la pregunta de investigación.

a Fase media. El muestreo relacional es utilizado para localizar datos que confirman, complementan o validan las relaciones entre las categorías y su

624097

aplicabilidad. En esta fase el investigador se apoya en las fuentes sugeridas por los datos ya recolectados.

a Fase final. Se utiliza el muestreo selectivo de personas, sitios y documentos. Esto permite verificar la categoría central y la teoría como un todo.

Para apoyar estas fases, Grounded Theory involucra tres procesos de

codificación de los datos recopilados por el investigador, de los cuales surge el análisis de los mismos. Estos procesos de codificación son aplicados sobre los datos obtenidos a través de las herramientas de Grounded Theory. Los procesos

de codificación y su orden son [Strauss 1998]:

• Codificación abierta. Comprende el análisis de datos por parte del investigador, para identificar categorías relevantes que permitirán la clasificación de los mismos.

• Codificación axial. En este punto, el investigador establece la definición y características de cada categoría; y revisa los datos para establecer las relaciones entre las categorías.

• Codificación selectiva. Aquí el investigador identifica la categoría "principal" o "central" que une a todas las demás categorías.

La metodología permite que los tres procesos se traslapen entre sí, pudiendo regresar si es necesario a un proceso anterior para identificar nuevas categorías [Straus 1998]. A partir de la categoría central, las categorías secundarias y sus interrelaciones se construye la teoría que describe el fenómeno estudiado [Straus 1998].

Como se puede observar, las fases de recolección de datos y los procesos de codificación están directamente relacionadas entre sí [Lincoln 1985, Straus 1998]. Durante la fase inicial, se utilizan el muestreo abierto y la codificación abierta para buscar al mismo tiempo los datos y las categorías relevantes. Durante la segunda fase, el muestreo relacional y la codificación axial son usados para validar y reforzar las categorías identificadas. Finalmente, se utiliza el muestreo selectivo para apoyar la identificación de la categoría central a través de la codificación selectiva.

A través de estos procedimientos, Grounded Theory recopila, registra y analiza

los datos que servirán de base para conformar el contexto que describe la situación estudiada, así como una solución a la misma. Obviamente, al seguir la mecánica de esta metodología el investigador requiere de una serie de herramientas para recopilar información de la situación, las cuales se describen en la siguiente sección.

3.2 Herramientas utilizadas

La metodología Grounded Theory se apoya en varias herramientas que

permiten guiar el análisis de los datos y ayudan a la creación de la teoría. Estas herramientas incluyen en su mayoría, pero no de manera exhuastiva, las herramientas utilizadas en estudios sociológicos. De acuerdo a Denzin [1994] y Straus [1998], las herramientas propuestas por Grounded Theory son:

• Preguntas

• Entrevistas • Observación • Escritura de notas • Participación activa • Microanálisis de textos

• Microanálisis de conversaciones

La metodología permite utilizar sólo una parte de las herramientas disponibles para el análisis de datos, y deja a discreción del investigador la selección de las herramientas más apropiadas para cada investigación [Straus 1998].

Para seleccionar las herramientas adecuadas a la presente investigación, se consideraron dos factores importantes. En primer lugar, era necesario tener un recuento de los hechos de primera mano de los actores principales del proyecto de TI. En segundo lugar, era importante cotejar la información presentada por los participantes contra la información registrada en los documentos del proyecto de TI. Por lo anterior, se seleccionaron las siguientes dos herramientas de Grounded

Theory:

• Entrevistas

• Microanálisis de textos

Se consideró que al utilizar estas herramientas sería posible encontrar suficiente información sobre el fenómeno estudiado para determinar los elementos, categorías y relaciones relevantes dentro del mismo. Además, cada participante puede ser entrevistado varias veces y el formato de la entrevista puede orientarse al interés y necesidad de la investigación, lo que facilita al investigador refinar la información recopilada durante las codificaciones axial y selectiva.

Antes de describir a detalle la metodología empleada, es importante mencionar brevemente el proyecto estudiado. El proyecto de TI estudiado para esta investigación fue el desarrollo de un Sistema de Mediación de Registros dentro de una empresa mexicana de telecomunicaciones. El objetivo del proyecto de TI fue implementar un sistema para recibir, mediar y transmitir los registros de llamada desde cada central telefónica hasta el sistema de facturación. Sin este sistema, el

servicio de telefonía local no podría ser cobrado por la empresa. El desarrollo del proyecto representó un reto para la organización debido a su complejidad por el número de áreas participantes (8), empleados involucrados (12), cantidad de funcionalidades requeridas, estilo de administración del proyecto y tiempo disponible para su realización. Al final, el proyecto tuvo un retraso de cuatro meses y solo se desarrolló el 80% de las funcionalidades originalmente requeridas.

Aunque el plan original del proyecto establecía que sería terminado en Diciembre del 2000, diferentes situaciones durante el desarrollo provocaron que se completara hasta Abril del 2001. Este retraso provocó que la empresa dejara de percibir los ingresos correspondientes a cuatro meses del nuevo servicio de telefonía local. Además, no todas las funcionalidades del sistema originalmente solicitadas pudieron ser desarrolladas, contando al final del proyecto con sólo el 80% de las funcionalidades requeridas. Por último, el costo del proyecto de TI se incrementó en un 15% con respecto al costo presupuestado originalmente tan sólo en la parte correspondiente a pagos al proveedor.

3.3 Metodología

De acuerdo a Grounded Theory y a las herramientas propuestas por ésta, el

investigador realizó un plan específico de la metodología a usar en el estudio del problema. Los pasos del plan de investigación fueron:

1. Definición de la pregunta de investigación e identificación de los elementos clave en las fuentes de datos del caso (entrevistas y documentos del proyecto).

2. Recopilación de información a través de entrevistas con los participantes y análisis de los documentos que se generaron dentro del proyecto de TI. 3. Análisis de la información a recopilada para identificar elementos similares

que permitan describir los lineamientos del modelo, utilizando las codificaciones abierta y axial de la metodología.

4. Construcción de un modelo de documentación a partir de los elementos identificados en la investigación con el apoyo de la codificación selectiva descrita por la metodología.

5. Validación del modelo a través de una segunda ronda de entrevistas con los participantes del proyecto de TI.

6. Descripción formal y detallada de los resultados de la investigación y del modelo propuesto.

Una de las ventajas de esta metodología es la facilidad de poder regresar a una etapa anterior cuando se requiere revalorar o redefinir algunos conceptos relevantes de la misma; y de esta manera ir refinando los hallazgos y resultados de la investigación. En los siguientes párrafos se describen a detalle cada uno de estos pasos.

El primer paso fue definir la pregunta de investigación de la siguiente manera: "¿Cómo afecta al desarrollo de un proyecto de TI la elaboración y disponibilidad de una documentación efectiva?". A partir de esta pregunta se estableció el objetivo del modelo propuesto. Dicho objetivo consistía en mantener un impacto positivo en el costo y tiempo de desarrollo del proyecto, así como en cumplir efectivamente con las funcionalidades del mismo, por medio de la creación y disponibilidad de una documentación del proyecto que fueran completa y actualizada. Además, la pregunta también ayudó a establecer los conceptos sobre los cuales se diseñaría el modelo propuesto y que formarían parte del proceso de investigación.

El segundo paso en la investigación fue llevar a cabo entrevistas a los participantes en el proyecto mencionado, y analizar los documentos relacionados con el desarrollo del mismo proyecto; siendo estas actividades relevantes para obtener los datos iniciales. Se entrevistó de manera presencial o por vía telefónica a 8 de los 12 participantes originales en el proyecto; el resto de los participantes no respondieron a las llamadas del investigador o simplemente ya no laboraban para la empresa. Posteriormente, se analizaron los documentos utilizados durante el desarrollo del proyecto para extender los elementos y relaciones encontradas en el análisis de las entrevistas. Los acuerdos relacionados sobre funcionalidad, especificaciones y entregables del proyecto fueron registrados en documentos electrónicos; además que gran parte de la comunicación entre los participantes se llevo a cabo a través de correo electrónico. Por lo tanto una actividad importante fue el análisis de 683 documentos electrónicos y de 1,496 correos electrónicos. Estos documentos fueron analizados en orden cronológico y por área departamental.

Dado que la perspectiva de los entrevistados podría arrojar información clave para la construcción del modelo, el propósito del tercer paso fue identificar y categorizar los elementos encontrados tanto en las transcripciones de las entrevistas como en los documentos analizados. El estudio y análisis de estas dos fuentes de información permitieron identificar hechos y datos importantes sobre la administración de documentos durante el proyecto. Estos elementos fueron organizados en categorías, mismas que fueron clasificadas en principal y secundarias. Dichos elementos se emplearon posteriormente para la definición del modelo.

En el cuarto paso de la investigación se construyó un prototipo preliminar del modelo en el que se integraron los elementos que aparecieron con mayor frecuencia, así como las interrelaciones entre ellos. Estos elementos son:

a Las Reglas de Contenido de la documentación. o El Repositorio de Documentación.

a El Administrador de la Documentación.

Cada uno de estos elementos fueron identificados también en la bibliografía consultada [Gómez 1998, Megill 1999 y Markus 2001]. Las características

particulares de cada uno de estos elementos son descritas a detalle en el capítulo acerca del modelo propuesto.

En el quinto paso de la investigación, el modelo preliminar fue validado a través de una segunda ronda de seis entrevistas. Nuevamente, las entrevistas se realizaron presencialmente o por vía telefónica, y en todos los casos el audio fue grabado para asegurar la calidad de la transcripción. En cada caso se pidió el consentimiento previo de los entrevistados para grabar la entrevista. En esta segunda ronda de entrevistas se buscó además aclarar algunos puntos particulares sobre los comentarios hechos por algunos participantes en la primera ronda de entrevistas. Con la información recabada en este paso de la investigación, además de las propias impresiones del investigador, se procedió a definir de manera formal y detallada tanto los resultados encontrados como el modelo propuesto.

En el último paso de la investigación, se describieron de forma detallada los resultados de la investigación y las características del modelo validado. Se redactaron los resultados de las entrevistas y del análisis de documentos describiendo las carencias identificadas en la documentación del proyecto de TI estudiado. Además, se describieron las características del modelo propuesto así como las interrelaciones entre los elementos que lo forman. Este punto fue de los más importantes porque permitió comparar, confirmar o modificar algunas de las observaciones personales que el propio investigador había percibido como participante activo en el mismo proyecto. Finalmente se definieron las limitaciones del modelo propuesto y los beneficios esperados en la organización con la implementación de dicho modelo. Se puede observar que la metodología seguida corresponde a los estándares establecidos de Grounded Theory; pero lo más

importante es que se adapta a las necesidades propias de la problemática y a los objetivos de esta investigación.

4 Proyecto de Investigación

En el presente capítulo se describe el contexto del proyecto de TI estudiado para esta tesis; además se presentan las expectativas del caso y la justificación de la selección de dicho caso. Por último, el capítulo presenta a detalle los pasos de la investigación y las lecciones aprendidas en ella.

4.1 Contexto del proyecto

La empresa referida en esta investigación fue fundada en 1995 para brindar servicios de telefonía de larga distancia e inició operaciones el 6 de Agosto de 1996. A principios de 1999, la empresa empezó a hacer planes para ofrecer al mercado el servicio de telefonía local además de sus productos ya existentes. Los objetivos de esta iniciativa eran, por un lado incrementar los ingresos de la compañía y por otro, generar un mayor reconocimiento de la empresa entre el público. De acuerdo al análisis del mercado realizado por el departamento de Mercadotecnia de la compañía, era necesario lanzar el servicio al público a finales del 2000, a fin de lograr la mayor penetración posible frente a la competencia en las ciudades de México, Monterrey y Guadalajara. Esta meta representaba un verdadero reto, ya que la compañía nunca había realizado un proyecto de semejante magnitud. El proyecto de telefonía local fue dividido en varios proyectos menores de acuerdo a las áreas funcionales relacionadas con ellos. Cada una de estos proyectos estaba relacionado con el diseño e implementación de la infraestructura y los sistemas necesarios para completar las llamadas de los clientes, monitorear el desempeño de la central telefónica y los sistemas de post­ procesamiento, capturar la información de cada llamada y facturar los servicios ofrecidos.

El proyecto de TI seleccionado para su análisis fue el desarrollo de un Sistema de Mediación de Registros. El objetivo de este proyecto era implementar un sistema adecuado para recibir, mediar y transmitir los registros de llamada desde cada central de conmutación hasta los sistemas de facturación. La fecha original de lanzamiento del sistema, Diciembre del 2000, fue impuesta por el plan de negocios de Mercadotecnia. Debido a problemas de comunicación, requerimientos confusos y re­trabajos en el proyecto, se fueron acumulando retrasos que provocaron un lanzamiento cuatro meses después de la fecha originalmente planeada. Además, se incurrió en un costo extra del 15% mayor al presupuestado, y sólo fueron desarrollaron el 80% las funcionalidades originalmente especificadas para el Sistema de Mediación de Registros. La evolución del desarrollo de este proyecto se describe en el resto de esta sección.

Las reuniones iniciales del proyecto se llevaron a cabo en Mayo de 1999. Las áreas involucradas en el desarrollo del Sistema de Mediación fueron invitadas a participar debido tanto a su experiencia como a sus roles funcionales dentro de la compañía; encabezados por el área de Ingeniería de Facturación, los grupos involucrados fueron los departamentos de Facturación, Mercadotecnia, IT Facturación, IT Interconexión, Ingeniería de Transmisión, Ingeniería de Conmutación e Ingeniería de Monitoreo. El esfuerzo del proyecto del Sistema de Mediación de Registros fue coordinado por la Oficina de Proyectos de la empresa. Contando al Administrador de Proyecto, se tuvo en total la participación de 12 empleados de tiempo completo.

Cada una de las áreas involucradas en el proyecto tenía un interés particular en asegurar ciertas características para el sistema de mediación; al mismo tiempo, su responsabilidad y capacidad para la toma de decisiones era limitada. El área de Ingeniería de Facturación era responsable de asegurar que estas características fueran satisfechas por el sistema desarrollado, además de cumplir con su objetivo principal, que era asegurar la entrega de los registros de llamadas en el formato requerido desde cada central telefónica hasta los sistemas de facturación. En otras palabras, la mayor responsabilidad del proyecto residía sobre el departamento de Ingeniería de Facturación.

A continuación se describen los intereses particulares de cada grupo involucrado en el proyecto, así como la cantidad de personas participantes por cada grupo. Es importante señalar que todos ellos eran empleados de tiempo completo de la compañía, organizados bajo un organigrama como el que se muestra en la Figura 5.

Dirección General

_L

Oficina de Proyectos (1 persona)

Mercadotecnia (3 personas)

J_

Ingeniería Tecnologías de Información

Ingeniería de Facturación (2 personas)

Ingeniería de Conmutación (1 persona)

IT Facturación (2 personas)

IT Interconexión (1 persona)

Ingeniería de Transmisión (1 persona)

Ingeniería de Monitoreo (1 persona)

Figura 5. Organigrama del Proyecto de TI

El área de Mercado­tecnia participó con tres personas en el proyecto de TI, y estaba interesada en asegurar ciertas características de las llamadas telefónicas y de los esquemas de cobro. Por su parte, el departamento de IT Facturación era el responsable de implementar en el sistema de facturación las reglas de negocio definidas por el departamento de Facturación, y participó en el proyecto con dos empleados. Otra área de IT, el departamento de IT Interconexión, participó con sólo una persona en el proyecto, y era responsable de entregar al área contable de Interconexión los balances sobre el intercambio de llamadas entre la empresa bajo estudio y el resto de las compañías telefónicas.

El departamento de Ingeniería de Transmisión participó con una persona y era responsable de implementar el medio de transporte adecuado para transmitir los registros de llamada desde la central telefónica hasta el sistema de mediación, basado en los requerimientos que recibiría del departamento de Ingeniería de Facturación. Por otro lado, se contó con la participación de un empleado del departamento de Ingeniería de Conmutación, responsable de configurar las centrales telefónicas para brindar el servicio con las características requeridas por Mercadotecnia.

El área de Ingeniería de Monitoreo participó en el proyecto con una persona quien era responsable de establecer e implementar un conjunto de requerimientos mínimos para monitorear constantemente el Sistema de Mediación de Registros. Por último, Ingeniería de Facturación era responsable de implementar el Sistema de Mediación de Registros cumpliendo con los requisitos de las demás áreas, y participó en el proyecto con dos personas.

El Administrador de Proyecto fue seleccionado por la Oficina de Proyectos, y tenía como responsabilidades el coordinar las actividades que se realizaban y el informar a la gerencia sobre los avances del proyecto. Los Administradores de Proyectos de la empresa estudiada eran elegidos por la Oficina de Proyectos de entre los miembros de las áreas de ingeniería. Sin embargo, no existía una política clara sobre las cualidades, características o perfil con el que debían cumplir.

Aunque el Administrador del Proyecto tenía libertad para convocar a los participantes a reuniones de trabajo, no tenía el poder organizacional necesario para establecer como prioritarias las actividades relacionadas con el proyecto en comparación con otras actividades de los participantes. Para ello se debía apoyar en los gerentes, coordinadores y líderes de equipo que tenían a su cargo dichos participantes. Debido a lo anterior, el Administrador del Proyecto dependía en gran medida de las prioridades que cada área asignara a sus subordinados.

Por otro lado, para el desarrollo del proyecto y de acuerdo a las políticas organizacionales de la empresa, algunas actividades no fueron consideradas como responsabilidad del Administrador de Proyecto tales como recolectar, revisar y distribuir la documentación que se iba generando a lo largo del mismo proyecto. Cada empleado que generaba un documento durante el desarrollo del proyecto

era responsable de distribuirlo entre el resto de lo participantes o, por lo menos, entre los participantes que pudieran necesitar la información contenida en dicho documento.

En Junio de 1999, los departamentos de Facturación, Mercadotecnia e IT Facturación hicieron el requerimiento formal a la Dirección de Ingeniería para contar con un Sistema de Mediación de Registros que entregara en un formato específico los registros de llamada del servicio telefónico local al sistema de facturación de la empresa. A partir de este requerimiento, al mes siguiente el área de Ingeniería de Facturación entregó vía correo electrónico a las áreas mencionadas un formato para listar sus requerimientos, estableciendo la fecha límite de recepción el mes de Septiembre del mismo año.

Una vez recolectadas las respuestas de los grupos involucrados, el área de Ingeniería de Facturación elaboró para mediados del mes de Octubre de 1999 un documento llamado Descripción del Producto que contenía todas las características deseadas por los grupos involucrados en el sistema de mediación de registros. Durante el mes de Noviembre este documento fue revisado por todas las áreas que mantenían un interés en el proyecto para recibir su aprobación. Entre Noviembre 8 y Noviembre 26 se realizaron tres reuniones, una por semana, durante las cuales se discutieron las opiniones y sugerencias de los participantes sobre el documento. Los resultados de cada una de estas reuniones fueron enviados a todos los participantes a través del correo electrónico por el Administrador del Proyecto. Por otro lado, el grupo de Ingeniería de Facturación fue el encargado de actualizar el documento. En la reunión final del 26 de Noviembre de 1999, se obtuvo la aprobación de todos los grupos involucrados en el proyecto de TI.

Tras haber obtenido esta aprobación, el documento fue distribuido a principios de Diciembre vía correo electrónico entre varios proveedores de sistemas de mediación para obtener de ellos propuestas técnicas y económicas. La compañía estableció como fecha límite para recibir estas propuestas el mes de Febrero del 2000. En el primer bimestre del año, se recibieron las respuestas de quince proveedores diferentes, pero en ninguna de ellas se cumplía al 100 % con los requisitos establecidos por la compañía. El Administrador de Proyectos obtuvo durante la última semana de este mes el consentimiento de cada una de las áreas involucradas para omitir del sistema de mediación aquellas características que no fueran indispensables para poder continuar con el proyecto.

Basado en las respuestas de los proveedores y en el consentimiento de las áreas participantes, el grupo de Ingeniería de Facturación seleccionó en la segunda quincena de Marzo del 2000 el producto que cumplía con la mayoría de los requerimientos contenidos en la Descripción de Producto, y su adquisición fue negociada por el Departamento de Compras durante el mes de Abril del mismo año. El producto seleccionado como Sistema de Mediación de Registros para el servicio de telefonía local de la empresa no sólo tenía la capacidad de entregar los

registros a los sistemas cliente en el formato deseado, sino que también ofrecía herramientas de reportes, de estadísticas y de recuperación de registros con errores.

Después de realizada la compra del sistema, se presentó al proveedor en una lista de requerimientos actualizados a mediados del mes de Mayo del 2000. Esta lista fue generada por las áreas interesadas en el proyecto, cuyos requisitos se habían modificado parcialmente durante los meses transcurridos desde el inicio del proyecto de TI. De inmediato se programaron conferencias telefónicas semanales entre el proveedor y las áreas la empresa involucradas en el proyecto de TI para resolver las dudas del proveedor sobre estos requerimientos. Las reuniones tuvieron lugar entre el 31 de Mayo y el 29 de Junio del 2000; en ellas el grupo Ingeniería de Facturación documentó los acuerdos alcanzados, envió por correo electrónico las minutas de las reuniones al proveedor y a los empleados de la compañía, y reportó periódicamente los avances de las negociaciones al Administrador de Proyecto. A pesar de haber sido documentados, estos acuerdos y minutas de las reuniones no se almacenaron en un punto de consulta común dentro de la compañía para ser accesados después a medida que avanzara el desarrollo del sistema. Igualmente, tampoco se llevó un inventario de los documentos generados dentro del proyecto.

Los acuerdos establecidos con cada área se incluyeron en un documento de Alcance de Trabajo que terminó de integrarse la segunda semana del mes de Julio de 2000. A las funcionalidades descritas en él se les asignaron prioridades por medio de negociaciones entre los directivos de la compañía llevadas a cabo durante primeros quince días del mismo mes. Por último, a finales de Julio el proveedor envío a través del correo electrónico un calendario de trabajo con fechas compromiso para la entrega de las funcionalidades especificadas basado en las prioridades asignadas por la compañía.

Dicho calendario de actividades especificaba las fechas de desarrollo, las fechas en que se realizarían pruebas de integración, y la fecha en que estaría listo el proyecto. Dichas pruebas serían realizadas entre el sistema de mediación y todos los equipos con los cuales tendría comunicación. Estos equipos incluían a la central telefónica, a la red de transmisión, al sistema de facturación, al sistema de interconexión y a los sistemas de monitoreo. De acuerdo al calendario de actividades, el Sistema de Mediación de Registros estaría listo para operar en Diciembre del 2000.

A medida que se avanzó en el desarrollo del sistema de mediación se sufrieron retrasos por diversos motivos y situaciones. En primer lugar, era común que los participantes en el proyecto invirtieran parte del tiempo de desarrollo en aclarar dudas sobre el contenido de los documentos que describían el sistema o en buscar dichos documentos. Aunque estos documentos habían sido generados por empleados de la misma compañía, no se seguía un formato estándar entre los documentos, incluso entre aquellos generados por dos personas del mismo

departamento. Otras situaciones frecuentes en el proyecto de TI fueron los re­ trabajos que fueron realizados debido a desarrollos erróneos causados por documentación incorrecta o por interpretaciones incorrectas de la información contenida en los documentos.

Por otro lado, una de las primeras situaciones en la que existieron retrasos en el desarrollo del proyecto fue durante la implantación de la red de transmisión del sistema de mediación de registros. Aunque el área de Ingeniería de Transmisión documentaba el avance y los resultados de sus tareas, los documentos generados por los miembros del departamento no seguían el mismo formato entre sí. Además, otra fuente de retrasos fue que dichos documentos no llevaban un control de versiones; debido a esto, al ser distribuidos entre los demás participantes del proyecto existían dudas sobre la veracidad de la información contenida en ellos. Cuando alguien necesitaba hacer uso de la información contenida en los documentos de esta área, era común que primero localizara al autor del documento para confirmar que poseía la versión más actual del mismo. Si no le era posible localizar al autor, el desarrollo del proyecto se detenía hasta encontrar alguien que pudiera confirmar la veracidad de la información recibida. Aunque varias veces fue sugerido que los autores enviarán por correo las actualizaciones de sus documentos tan pronto como las tuvieran listas, normalmente sólo se enviaba la primera versión de cada documento y no se almacenaba en ningún lugar específico.

Además, casi desde el inicio del proyecto el área de Mercadotecnia solía modificar sus requerimientos casi semanalmente. Durante los meses de Septiembre y Octubre de 1999, el Administrador del Proyecto e Ingeniería de Facturación trataron constantemente de comunicar al departamento de Mercadotecnia que estos continuos cambios retrasaban el desarrollo del proyecto y ponían en riesgo el cumplimiento de los objetivos del mismo. A pesar de ello, se seguían recibiendo nuevos requerimientos en documentos que no guardaban un formato estándar entre sí, a pesar de ser generados en un mismo departamento; incluso durante las reuniones del mes de Noviembre se llegaron a recibir requerimientos que contradecían a los originalmente recibidos. Esta situación provocó que durante el desarrollo del proyecto las participantes tuvieran que dedicar un mayor tiempo a descifrar y entender la documentación entregada por Mercadotecnia, ya que la información podía ser interpretada incorrectamente. A pesar de ello, en algunas ocasiones ya en transcurso del proyecto se realizaron trabajos que después tuvieron que ser corregidos debido a que la documentación había confundido a los desarrolladores.

El área que más se retrasó en entregar sus requerimientos en la fases previas a la definición del documento de Alcance de Trabajo (hecho en el mes de Julio de 1999) fue IT Interconexión. Esta área llegó incluso a entregar requerimientos posteriores a la fecha límite para la definición del documento. Además de esto, la mayoría de sus documentos utilizaba terminologías que no eran comunes con el resto de la documentación usada en el proyecto y rara vez incluían el nombre de

su autor. Estas situaciones provocaron que los desabolladores emplearan un tiempo considerable del proyecto en localizar al autor original de cada documento y aclarar las dudas que la terminología causaba, en lugar de emplearlo en implementar dichos requerimientos en el sistema de mediación de acuerdo a las fechas estipuladas originalmente en el calendario de trabajo. Esta actividad constante de búsqueda del autor y resolución de dudas provocó que se acumulara un retraso de cuatro semanas en el calendario total de trabajo del proyecto de TI.

Otra situación a la que se enfrentó el Administrador de Proyecto fue un requerimiento específico recibido por parte de IT Facturación. Dicho requerimiento no había sido documentado con anterioridad por el área de IT Facturación. A mediados de Octubre del 2000 se detectó que dicho requerimiento no había sido considerado en el desarrollo del Sistema de Mediación de Registros. Una vez revisado el requerimiento a detalle entre el proveedor, IT Facturación, e Ingeniería de Facturación, se determinó que su implementación provocaría un retraso en la implantación del proyecto y que además causaría un incremento de 15% en el costo original del sistema.

Debido a lo anterior, se convocó a una reunión urgente entre todas las áreas a finales de Octubre del 2000. En esta reunión se buscó el consentimiento de todas la áreas involucradas en el proyecto de TI para omitir parte de sus requerimientos originales para liberar recursos y así poder desarrollar el nuevo requerimiento. El acuerdo final fue alcanzado en la segunda semana de Noviembre del 2000, después de retirar del documento Alcance de Trabajo cerca del 20% de las funcionalidades originalmente solicitadas. A partir del nuevo documento, el proveedor envió por correo en la tercera semana de Noviembre un nuevo calendario de trabajo en el cual, a pesar del sacrificio en funcionalidades, las fechas de entrega fueron afectadas. El nuevo calendario fue recibido sólo por el Administrador del Proyecto y por el área de Ingeniería de Facturación, y en él se especificaba que las pruebas de integración se realizarían hasta el mes de Diciembre del 2000.

Por último, también durante los meses de Octubre y Noviembre del 2000, todas las áreas en general tuvieron que contactar a personas de otros departamentos involucrados en el proyecto de TI para encontrar respuesta a las dudas que surgían sobre los documentos generados. Era difícil para los participantes saber con quien dirigirse cuando se tenían dudas sobre la información de un documento específico. Esto era debido a dos razones principales. La primera era que no existía dentro del proyecto de TI un lugar común donde se almacenaran todos los documentos. La segunda era que no existía una persona designada como responsable de recolectar y distribuir la documentación del proyecto.

Las pruebas iniciales de integración entre el sistema de mediación, las centrales de conmutación, y los sistemas cliente iniciaron a mediados de Diciembre del 2000, lo que representó un retraso de por lo menos dos meses con respecto al objetivo inicial establecido por Mercadotecnia. Las pruebas

continuaron hasta el año siguiente y concluyeron en Marzo del 2001. Durante los meses de Abril y Mayo de ese mismo año se llevó a cabo un proceso de entrega del Sistema de Mediación de Registros de parte de Ingeniería de Facturación al área de Operaciones y Soporte Técnico. Este proceso incluyó establecer una lista de pendientes, responsables y fechas compromiso, así como la entrega de los manuales y documentos de referencia necesarios para operar el sistema. Además, se comprometieron diferentes niveles de servicio y se establecieron procesos de solución de fallas entre el área de Ingeniería de Facturación y el área de Operaciones y Soporte Técnico, así como con el proveedor mismo.

Aunque el plan original del proyecto de TI establecía como fecha de terminación el mes de Diciembre del 2000, no fue sino hasta finales de Abril del 2001 cuando se concluyó en realidad. Esto representó un retraso de cuatro meses con respecto al plan original. Además, debido al requerimiento revisado en Octubre del 2000, se incurrió en un incremento del 15% en el costo del proyecto así como una reducción del 20% en las funcionalidades originalmente establecidas para el proyecto. Por último, debido al retraso en la fecha de inicio de operaciones del Sistema de Mediación de Registros, la empresa dejó de obtener las ganancias correspondientes a cuatro meses de operación del servicio de telefonía local.

A continuación se presenta una lista con las fechas más importantes en el desarrollo del proyecto de TI descrito en este capítulo.

Junio 1999 Inicio del proyecto de TI con el requerimiento formal de un Sistema de Mediación.

Octubre 1999 Ingeniería de Facturación publica el documento de Descripción del Producto

Marzo 2000 Ingeniería de Facturación selecciona un proveedor para el Sistema de Mediación.

Julio 2000 Las áreas participantes elaboran el documento de Alcance de Trabajo.

Noviembre El documento de Alcance de Trabajo es reducido en cerca del 2000 20% de sus funcionalidades originales.

Marzo 2001 Se realizan pruebas de integración entre el Sistema de Mediación y el resto de los sistemas.

Abril 2001 El Sistema de Mediación es puesto en producción.

4.2 Expectativas y Justificación

Como resultado de la investigación se esperaba encontrar que los retrasos detectados en el proyecto de TI fueron causados particularmente por problemas de comunicación y de intercambio de información entre los participantes del proyecto. En particular, el investigador inició su trabajo con las ideas siguientes: