¿Te has percatado de la importancia que tienen los sistemas informáticos en tu entorno?

Es sorprendente darnos cuenta de que estamos rodeados de aplicaciones informáticas que nos facilitan la toma de decisiones en la vida diaria; sin embargo, para que éstas pudieran llegar a nuestras manos, fueron definidas, diseñadas y desarrolladas, tomando en cuenta las características y necesidades de cada una. Este proceso requirió que un grupo de personas se organizará y planificará un proyecto de TI, con el afán de que, al seguir varias etapas, las ideas se concretarán en los sistemas que ahora utilizas.

Como puedes darte cuenta, lo anterior implica conocer un poco más acerca de los sistemas informáticos, no sólo la programación sino también la planificación y la utilidad que ésta tiene en las organizaciones. La decisión de que un proyecto sea aceptado o rechazado recae en las áreas administrativas y la alta dirección, además del área de TI, quienes se encargarán de evaluar la viabilidad y determinar la aprobación de un proyecto, de acuerdo con los objetivos estratégicos de la empresa.

Para conocer más sobre el motivo por el que fracasan los proyectos de TI, te invitamos a leer el artículo ¿Por qué fracasan los proyectos de software?; un enfoque organizacional, de Zavala Ruiz (2004)  en el que podrás identificar la importancia de un software, la utilidad de un proyecto del software, los factores que determinan el fracaso y el éxito del proyecto, así como el enfoque organizacional que lo caracteriza.

 ¿Por qué fracasan los proyectos de software?; un enfoque organizacional.pdf

Después de leer el artículo, responde las preguntas en un archivo word para que no se te olviden. Ya que tengas tus respuestas, entra al foro Reflexión de lectura, compártelas con tus compañeros.  Realizada la acción anterior, comenta las respuestas de tus compañeros, con la finalidad de realimentar tus conocimientos sobre la importancia de planificar de forma correcta un proyecto de TI. Es importante que seas tolerante con la opinión de tus compañeros y utiliza un lenguaje respetuoso dentro del foro.

Foro Reflexión de lectura

Con apoyo en la lectura ¿Por qué fracasan los proyectos de software?; un enfoque organizacional, contesta las siguientes preguntas y realimenta la participación de al menos 2 de tus compañeros. Es importante que tengas en cuenta que debes ser muy respetuoso en la realimentación que realices, además intenta ser lo más asertivo posible y no dejes ir ningún comentario que consideres sea productivo.

¿Qué consideras que es un proyecto de software? ¿Cuál crees que es la función y uso de un  proyecto de software?

¿Por qué son importantes los proyectos de software en una organización?

¿Cuáles consideras que son los factores o fallas por los que fracasan los proyectos de software?

¿Para ti cuáles son los factores por los que tiene éxito un proyecto? De acuerdo con tu opinión, ¿cuál es la diferencia (si la hay) entre un

software y una aplicación de TI?

Es importante tomar en cuenta que el foro académico te permitirá reforzar tus conocimientos, al enriquecer los comentarios de por lo menos dos de tus compañeros.

Es momento de comenzar a conocer los conceptos claves de la administración de un proyecto de Tecnologías de la Información (TI).

¿Qué es un proyecto?

Existen diversas definiciones de proyecto, todas ellas válidas y fundamentadas de acuerdo con la perspectiva y rama del conocimiento; sin embargo, se presentan dos definiciones formales, por su grado de aceptación a escala internacional, y una tercera que será la propuesta del presente bloque.

De acuerdo con la Guía de Fundamentos de la Dirección de Proyectos (PMBOK Guide, por sus siglas en inglés) en su tercera edición: “Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único” (Project Management Institute, 2004, p. 5).

Según la Organización Internacional de Normalización (ISO) en su Norma Internacional 10006:2003, un proyecto “es un proceso único que consiste en un conjunto de actividades coordinadas y controladas con fechas de inicio y finalización, llevadas a cabo para lograr un objetivo conforme a requisitos y requerimientos que incluyen limitaciones de tiempo, costo y recursos”.

Por lo tanto, para fines del MOOC se definirá de la siguiente manera:

Un proyecto es una serie de actividades ordenadas de forma lógica, relacionadas entre sí,  en un tiempo finito para alcanzar un objetivo determinado.  

De forma ideal, los proyectos tienen sus etapas perfectamente definidas e identificadas, sin que sufran cambios en el ciclo de vida del proyecto. Esto no ocurre en la práctica, debido a que existen imprevistos que van desde modificaciones y atrasos hasta, en el peor de los casos, la cancelación del mismo.

Aquellos proyectos basados en el desarrollo de una solución informática que sirva de soporte a la toma de decisiones de una persona o grupo de gente son denominados “Proyectos de Tecnologías de Información”, y están orientados a resolver la necesidad de obtener datos estadísticos, reportes y automatizar procesos. Estos proyectos deben cumplir ciertos requisitos para que no sean clasificados solamente como Sistemas Informáticos. Por ello, de entre las características principales destacan las siguientes:

Tienen una relación típica con un grado de innovación. Contienen información de procesos y del entorno organizacional. Son realizados por equipos interdisciplinarios compuestos por más que

sólo desarrolladores (contadores, administradores, publicistas, entre otros).

Automatizan tareas operativas de acuerdo con la clasificación del tipo de información.

Se orientan a la alta dirección y sus beneficios deben ser visibles a corto plazo.

Son justificados debido a la necesidad de información estadística y gran volumen de datos que requieren procesar, usar y mostrar.

La relación costo-beneficio tiende a ser clara para justificar el precio de su desarrollo e implementación.

Es importante destacar que en este tipo de proyectos, de acuerdo con los Objetivos de Control para Información y Tecnologías Relacionadas (CoBIT, por sus siglas en inglés), existe un grado de incertidumbre al trabajar con tecnología, pues no puede ser controlada ni pueden hacerse demasiadas previsiones para problemas que surjan durante su empleo. Además de lo anterior, es necesario recalcar que la gestión de este tipo de proyectos se basa de forma general en las etapas que marca el PMBOK; sin embargo, en la etapa de ejecución es donde se evidencia la diferencia y donde tiene mayor peso para ser aplicado en el entorno de las Tecnologías de la Información.

A continuación conocerás cada una de las etapas que contemplan la administración de un proyecto de TI y su respectiva descripción. Si lo deseas, puedes hacer una búsqueda en la Web para obtener más información acerca de estas etapas. 

Una vez que hayas analizado las etapas para la administración de un proyecto, es importante que conozcas las etapas de gestión de un proyecto para comenzar a visualizarlo, por lo que a continuación se mencionan las características de cada una de ellas

Etapas para gestionar un proyecto

A continuación te presentaremos las tres etapas de gestión para un proyecto.

          Etapa 0. Anteproyecto

Todo proyecto surge como una idea para satisfacer una necesidad, resolver una problemática o por haber visualizado una oportunidad informática que no ha sido satisfecha. A esta primera etapa se le denomina Anteproyecto o Propuesta.

Los proyectos de Tecnologías de la Información (TI) formal deben contar con una ficha de anteproyecto, la cual permitirá evaluar su viabilidad.

La vida de esta etapa tiende a ser muy corta, dura de dos a tres semanas. Asignar más tiempo a esta parte del proceso convertiría al trabajo de definición y de delimitación en una actividad de mayor complejidad, que resultará en un desperdicio de esfuerzo.

Se considera una etapa donde las actividades llegan a ser informales porque se entablan reuniones de trabajo, pláticas, se revisa material no especializado y tendencias. Pero sobre todo se genera la lluvia de ideas donde se dan los primeros pasos para conocer las características generales que tendrá el proyecto.

Por un lado, las estimaciones del tiempo y costos se pueden realizar a partir de un supuesto, apoyándose en la recomendación de un experto en el tema o mediante la consulta de proyectos similares. Por otro lado, la conformación del equipo de trabajo, recursos materiales, equipamiento y entorno de desarrollo se

realiza de forma superficial para ubicar e ir delimitando el proyecto, sin que se lleve a cabo una evaluación profunda y detallada.

En esta primera etapa, el interesado en presentar un proyecto determinará el objetivo, los resultados esperados, el alcance y beneficios del desarrollo, por lo que la redacción debe ser clara y explícita.  

De esta primer etapa se crea un documento denominado “ficha de anteproyecto” o “protocolo” (en algunos casos específicos también es llamado “ficha técnica”). En este documento se insertará la información recabada del Proyecto de TI, el posible nombre o, si en su caso aplica, nombre clave y la información que permite caracterizar al proyecto que se ha logrado definir.

Para reforzar lo aprendido hasta este momento te invitamos a realizar la siguiente actividad donde tendrás que ordenar los elementos en la pirámide acordes a las características vistas.

Dentro de los documentos a entregar debe de existir la sesión de derechos y la debida constancia de la propiedad intelectual o derechos morales de quienes participaron en la elaboración y diseño de la Solución Informática.

Una vez que se ha comprendido la definición de un proyecto de TI  y cuáles son sus características principales, debemos centrar nuestra atención en las etapas que compondrán la administración del proyecto, que es la razón de ser del MOOC. 

A partir de este momento ya conoces las etapas que contemplan la administración de un proyecto de TI, por lo que ahora, conocerás las etapas de gestión para un proyecto donde partiremos de una idea para desarrollar una Tecnología de Información, su planificación, así como la implementación y, los planes de ejecución y control, así como la entrega y el cierre. 

Posteriormente, se realizará la tarea de la definición y delimitación de un Proyecto de TI, es decir que en el anteproyecto es necesario centrar los esfuerzos en conceptualizar y describir, mediante un plan inicial, las etapas para realizar el proyecto, donde se requiere verificar los alcances esperados, tiempos y costos; además de la organización, tareas, actividades y responsabilidades de los involucrados, para finalmente generar el equipo de trabajo.

            Etapa 1. Definición

Una práctica adecuada para poder definir un proyecto de TI consiste en realizar una investigación básica para conocer aspectos que pudieran ser relevantes para definirse y que no se hubieran considerado en la etapa anterior.

Ahora bien, para el bloque, y a modo de facilitar la definición del proyecto,  se recomienda responder once cuestionamientos que se presentan a continuación, los cuales permitirán delimitar y enfocar el proyecto de TI. Descarga la siguiente tabla.

 Definición del proyecto de TI.pdf

Entre mayor sea el número de respuestas solucionadas en esta etapa, mejor definido y enmarcado quedará el proyecto de TI; sin embargo, ésta no es una labor fundamental de este proceso ni se deben forzar las respuestas. Conforme se avance en la etapa de planeación se irán resolviendo las preguntas, incluso podrían ocurrir algunas modificaciones mientras se avanza, lo cual también es correcto.

               Objetivo del proyecto 

Se refiere a las actividades que deben realizarse para alcanzar el fin del proyecto, es decir, es el trabajo que se requiere hacer para satisfacer una necesidad o solucionar una problemática en el ámbito de las Tecnologías de la Información (TI). El objetivo de un proyecto se puede clasificar en dos tipos: el general y los específicos. Si el objetivo general cambiara, habría que analizar la situación y determinar la conveniencia de centrar los esfuerzos en adecuar lo ya realizado o finalizar el proyecto e iniciar uno nuevo con el objetivo redefinido.

Una vez planteado el objetivo, es momento de comenzar a describir el proyecto que se va a realizar, a este momento se le denomina iniciación. Si se toma la primicia de que un Proyecto de Tecnologías de la Información (TI) busca solucionar una problemática o necesidad en su entorno, estas oportunidades detectadas requieren ser evaluadas en un análisis inicial, donde se destaque su grado de importancia, originalidad e influencia en los procesos de una organización.

Esta primera etapa tiene como propósito describir el alcance que tendrá el proyecto, sus metas generales y participantes (equipo de desarrollo e involucrados). Además, se considera el bosquejo de la idea, de acuerdo con un esquema organizado, estructuralmente cercano a un documento formal, en el que se incluyen las funciones generales del sistema informático, conforme al concepto de solución de TI. Éste deberá describir claramente la funcionalidad del proyecto, su complejidad, características, tiempo dedicado y entorno de desarrollo.

         Etapa 2. Planeación

Una vez conceptualizado y definido el proyecto de TI, se requiere describir detalladamente las tareas y sus actividades. Esta etapa es considerada como el plan de trabajo para el proyecto, y se incluyen las principales líneas de acción del desarrollo del sistema informático, analizando los requisitos de hardware y software a partir de los objetivos fijados.

El líder del proyecto o responsable de presentar la propuesta se encarga de seleccionar la metodología de planeación que mejor se adapte a las características propias de la propuesta, para administrar de la mejor manera el proyecto de TI.

Los principales requisitos de esta etapa son:

Contar con una metodología de planeación Seleccionar el equipo de trabajo y roles de los integrantes Diseño de las líneas de acción de las tareas y actividades de trabajo Análisis y estudio de los requerimientos técnicos y tecnológicos para el

desarrollo Propuesta de solución

Si derivado de los trabajos de planeación se observa que el proyecto requiere reestructurarse o replantearse, será necesario retomar el anteproyecto, para reformular los puntos necesarios que permitan garantizar que se concluya de forma correcta y nuevamente pase por la iniciación y la planificación.

A continuación se te presenta un ejemplo del ciclo de planeación de un proyecto.

Como se había mencionado anteriormente, para realizar un proyecto no sólo basta tener en mente los objetivos propuestos a desarrollar, también es necesario plantear una metodología acorde al proyecto.

Una vez considerada la metodología, es importante tomar en cuenta hasta donde se podrá llevar a cabo el proyecto y el tiempo  adecuado para el mismo.

Alcance y tiempo

Para la administración de un proyecto de Tecnologías de Información es fundamental dejar establecido hasta dónde abarcará un sistema informático, es decir, qué procesos se automatizan o qué mejora se tendrá con el software desarrollado; si es claro el alcance, el éxito se encuentra prácticamente garantizado, debido a que la tareas y actividades se encontrarán alineadas.

De las tareas establecidas se obtienen los alcances parciales, que aumentarán el porcentaje de avance del proyecto a este nivel de detalles. Es imprescindible que el proyecto se encuentre bien definido y que los desarrolladores de la aplicación tengan conocimiento suficiente sobre lo que se quiere y lo que se espera obtener cuando el desarrollo haya concluido y se realicen las pruebas piloto.   

Es razonable que los integrantes del equipo de desarrollo tengan expectativas diferentes, unos de otros. Esto se debe al rol y las funciones que se hayan diseñado para cada persona del equipo, por ello es importante dar a conocer con claridad el proyecto. Una buena práctica hacia el interior del proyecto es documentar las dudas e inquietudes, para que se puedan integrar como un entregable en la etapa de cierre e integración de la documentación.

Si bien, en la planeación, el alcance busca que el proyecto de TI quede debidamente delimitado y enfocado por quienes lo diseñaron, es responsabilidad del equipo de desarrollo comunicar cuando alguna de las metas operativas no pueda alcanzarse, justificando la razón por la cual no se podrá llevar a cabo dicha tarea, para que se tomen las medidas pertinentes para modificar el proyecto y determinar el grado de impacto general para el mismo proyecto.

Por ello, en el alcance, los elementos que se incluyen en un proyecto son tan importantes como los que quedan fuera y es sólo mediante el consenso de los interesados en el sistema informático y de los participantes (equipo de trabajo) que se establece el límite real del proyecto de TI.

En el caso del curso, al haber seleccionado la metodología del Diagrama de Gantt, las tareas se encuentran en secuencia, lo que implica la participación de una o más personas, de acuerdo con la complejidad y características de la actividad; sin embargo, existe una interactividad entre ellas para lograr un alcance o porcentaje de avance.

La declaración del alcance del proyecto se constituye para generar el ciclo de vida del proyecto, y a ésta se le controla y monitorea a lo largo del proyecto hasta su fin o conclusión. El documento que hace referencia al alcance del proyecto puede quedar estructurado de manera formal  y general o formal y detallada, ello dependerá del caso particular del que se trate.

El tiempo

Todo proyecto formal de TI requiere contar con un cronograma para medir el grado de avance de las actividades, las cuales requieren estar ordenadas de forma coherente y secuencial donde se indique la duración y los recursos que

se van a emplear en cada una de las etapas, el grado de detalle del cronograma es variable dependiendo de la complejidad del proyecto mismo.

Para crear el cronograma del proyecto se deben tomar en cuenta las fechas de inicio y conclusión, en ese intervalo se debe administrar el tiempo que duren las actividades con los hitos que correspondan y las holguras programadas. Al elaborar el cronograma, es posible que se requiera modificar el plazo y los tiempos de entrega, ésta es una de las utilidades y ventajas de la administración de un proyecto.

La elaboración del cronograma es una etapa fundamental para visualizar el tiempo que durará un proyecto. La calendarización de las tareas y sus actividades se encuentra relacionada mayormente con la metodología de la Ruta Crítica, debido a las características que se han descrito de ella con anterioridad.

Con el cronograma se logra:

Definir las tareas y actividades Secuencia y orden Estimación y cálculo  de todos los recursos Duración general y específica del proyecto y sus etapas

Por ejemplo:

Ya que hayas visualizado el alcance y el tiempo del proyecto, debes de realizar el estudio financiero del proyecto. 

Administración financiera del proyecto

Al igual que todo proyecto formal, los relacionados con las TI deben contar con un estudio financiero, que les permitirá a los interesados (inversionistas o clientes) evaluar  los costos de desarrollo de un Sistema Informático. A quienes tomen la decisión de aprobar el proyecto, les resultará fundamental contar con el análisis financiero. Al elaborarse un correcto estudio donde los costos se encuentren especificados y distribuidos de forma ordenada y coherente, se puede lograr la aprobación de la propuesta de solución; sin embargo, este mismo punto puede ser la razón principal por la que un buen proyecto de TI llegue a ser rechazado.

El presupuesto que se asigne a la solución informática debe quedar integrado por la estimación de gastos en la vida del proyecto, así como el flujo de capital y el control de los costos. Para los proyectos donde el alcance es demasiado corto, el presupuesto asignado y el estimado de costos son considerados una misma etapa para facilitar la elaboración de estudio. En el caso de proyectos de TI, por lo regular su dimensión es amplia, por lo que se debe realizar por separado cada punto del estudio.

En ambos casos, el capital humano y el periodo de tiempo son directamente proporcionales, es decir, un proyecto de alcance corto requiere una persona o dos para realizar el estudio financiero en un periodo de tiempo corto, mientras que el un proyecto amplio se requiere del apoyo de un equipo de trabajo con un tiempo adecuado para elaborar el estudio.

Al determinar los costos es importante tomar en cuenta la ubicación geográfica del proyecto y el tipo de moneda local. Una práctica común en proyectos formales es poner los valores totales en la moneda local y en dólares estadounidenses.

En resumidas cuentas, la elaboración de un plan de costos permite, desde la perspectiva financiera, definir los criterios de planificación a partir del presupuesto asignado y distribución de los recursos.

Cabe señalar que en un proyecto de TI difícilmente se puede hablar de un retorno de la inversión directa, debido a que el sistema informático por sí mismo es un activo intangible para la organización, por lo tanto se debe comprender que una solución informática es, por lo regular, un medio para alcanzar un objetivo estratégico dentro de una organización. Por lo que es responsabilidad de quien elabora la propuesta general dejar especificado que los costos de inversión en un sistema informático se verán reflejados en el proceso central, los administrativos o de soporte en una empresa u organización, donde se obtendrán beneficios en términos de mejorar en la reducción de tiempo, personal, errores, flujo de información, automatización de procesos, por citar algunos ejemplos.

El siguiente diagrama muestra los principales componentes y sus elementos de la gestión de los costos de un proyecto, de acuerdo con el PMBOK. Es importante destacar que, si bien es una descripción detallada, se requiere adaptar a las características propias de cada proyecto, que para el caso del MOOC es en TI, ya que no es necesario que se cubran todos los puntos.  

Para una mayor comprensión sobre los elementos que debe cubrir un análisis financiero, se describen tres técnicas para la administración financiera, el presupuesto y los costos para un proyecto de TI.

           Presupuesto

Consiste en asignar el monto presupuestado a cada tarea y grupo de actividades; sin embargo, el presupuesto estimado no siempre es el asignado, ello dependerá de la habilidad de negociación del líder del proyecto para conseguir una mayor cantidad de recursos o, en caso de que sean limitados, de su habilidad para realizar las adecuaciones correspondientes para alcanzar el objetivo.

La elaboración del presupuesto debe considerar los siguientes elementos:

Estimado de costos por tareas Cronograma del proyecto Asignación de recursos Contratos y cláusulas de pago Presupuesto para equipamiento y herramientas de desarrollo Presupuesto reservado Límite del presupuesto asignado

Es importante también, considerar los costos o recursos económicos para desarrollar el proyecto.

Costos

Son los recursos económicos que permitirán desarrollar el proyecto. Para su estimación se requiere hacer uso de predicciones sobre los montos que se deben asignar a las etapas o a la correcta distribución de un monto especificado como primicia para crear la solución de TI. Los costos se encuentran dados a partir de lograr el equilibrio entre la salida y entrada de capital, aunado a los riesgos por asignar recursos financieros en un momento dado para solventar una necesidad dentro del proyecto para su avance.

Si bien los costos óptimos se redefinen a lo largo del proyecto, la estimación de los mismos se precisa en el ciclo de vida para garantizar que a todas las etapas del proyecto se le asignen recursos económicos suficientes para lograr su conclusión. Los dos tipos de costos que todo proyecto debe tener son los directos que se encuentran relacionados con las actividades para desarrollar el proyecto y los indirectos correspondientes al entorno de gestión que complementan a la planificación.

Ya en este punto, como material adicional para esta meta del MOOC, se te proporcionan los siguientes documentos:

Formato de Ficha de Anteproyecto

A continuación te presentaremos un ejemplo de una ficha de anteproyecto, te recomendamos descargar y revisar para que te sea más clara la información.

 Ficha de Anteproyecto.doc

Formato general para planificar un proyecto

Una vez revisadas etapas y la metodología, se te presenta un formato propuesto sobre la planeación de un proyecto, descargar el siguiente archivo denominado Planificación del proyecto para que tengas una noción sobre  el tipo de archivos que puedes ocupar para planear un proyecto de TI.

 Formato planificación del proyecto.doc

Cédula de Proyecto

Te recomendamos descargar el siguiente archivo Cédula del proyecto para que lo uses al desarrollar tu proyecto de TI.

 Cédula del proyecto.doc

De igual manera, se te proporcionará un ejemplo sobre Ejercicio de Análisis financiero para un proyecto de Tecnologías de la Información, por lo que te recomendamos descargar tambien este archivo.

 Ejercicio de Análisis financiero para un proyecto de Tecnologías de la Información.doc

Puedes usar y requisitar estos formatos para que compruebes tus conocimientos, además te sirvan de apoyo para presentar un proyecto de TI.

Bloque 2: Desarrollo del proyecto > Meta 2: Implementación de un proyecto de TI, tomando en cuenta factores de planeación de desarrollo de software y administración de riesgos > P2

Una vez analizada la información del bloque anterior, en donde se define un proyecto,  es momento de generar el expediente del proyecto, el cual integrará los formatos propuestos y desarrollados con la información relevante para continuar con el desarrollo del proyecto de TI. Esta buena práctica se realiza con la finalidad de reunir en un solo lugar todos los documentos y sean accesibles para su consulta y referencia en el futuro. 

En el presente bloque nos enfocaremos en el desarrollo del proyecto. Una de las cuestiones importantes a señalar antes de comenzar es que el equipo debe

unir esfuerzos para que el proyecto llegue a buen término. Para alcanzar el éxito, bajo ninguna circunstancia se debe permitir que una meta personal supere el objetivo colectivo o que tenga mayor peso que éste. 

Cabe aclarar que una planeación, sin importar qué tan bien estructurada esté, es un planteamiento teórico; siempre habrá factores y variables que modificarán el plan original del proyecto. Por ello, es recomendable contar con las etapas de control y de riesgos, mismas que permitan monitorear y minimizar los cambios y problemas durante la elaboración de una solución informática del tipo de Tecnologías de la Información. No obstante, también es importante seleccionar una metodología de desarrollo de software para administrar las etapas de la creación de una solución informática.  

En este bloque se te presentarán diversas técnicas que te apoyarán en la construcción de una Tecnología de la Información desde la perspectiva del desarrollo del software. Para lo anterior se ha seleccionado “El método rápido de Scrum”, con la finalidad de representar la etapa de desarrollo e implementación de un proyecto de TI. Posteriormente se abordarán las etapas de control y de riesgos de un proyecto, que por sus características propias guardan una relación inherente en las actividades para minimizar los posibles efectos adversos que puedan ocurrir y que pongan en riesgo la planeación y la vida del proyecto mismo. 

Aunado a lo anterior, nunca se debe olvidar que un proyecto, independientemente de su naturaleza, se encuentra encapsulado en un momento de la realidad en la vida de las personas. Para la administración estratégica, estas mismas personas son el activo más importante en las empresas u organizaciones, porque son ellas quienes dan vida a su entorno de trabajo y generan los cambios en él.     

Se ha seleccionado el marco de trabajo propuesto por John Zachman por ser considerado en la industria del desarrollo de software como una técnica  para crear un sistema informático dentro de una organización.

La matriz de Zachman

Esta herramienta es un marco de trabajo (Framework), cuya utilidad inicial se orienta al desarrollo de Sistemas Informáticos. Fue propuesta por John A. Zachman en su artículo titulado "A framework for information systems architecture", en el cual menciona: “Para guardar el negocio de la desintegración, el concepto de una arquitectura de los sistemas de información se está convirtiendo en menos de una opción y más de una necesidad”. Este marco emplea modelos y vistas desde las perspectivas de los participantes, lo que permite crear, para el caso del MOOC, las características técnicas y de información de una herramienta de Tecnologías de la Información.

La principal característica de la matriz de Zachman radica en presentar un nuevo modelo de comunicación y flujo de información, con base en distintas perspectivas, de entre las cuales se destacan las siguientes: 

Analista de sistemas, para presentar la lógica de negocio Diseñador, para crear la estructura del sistema Desarrolladores de sistemas, para aplicar tecnologías de desarrollo de

aplicaciones El sistema en sí mismo, es decir, el ciclo de vida del software  

De acuerdo con su autor (John a. Zachman), la matriz establece horizontalmente las siguientes cuestiones:

En forma vertical, se establecen los modelos que se encuentran orientados de acuerdo con el perfil de los participantes:

Una vez analizadas las tablas anteriores, a continuación se te mostrará una tabla donde se integran las cuestiones (primera fila) y modelos (primera columna) que mencionamos, los cuales se interrelacionan entre sí de acuerdo con el proceso de elaboración de la solución informática. 

A partir de revisar la matriz de Zachman, puedes observar que tiene distintas perspectivas que  son de gran interés para el MOOC de AP de TI. Éstas se presentan a continuación: 

El diseñador: el perfil se relaciona con la especificación de los planos conceptuales de  sistemas informáticos y de la información, que permiten soportar la operación de los procesos organizacionales. 

El constructor: este perfil se encarga de unir y elaborar los diversos componentes del  sistema informático, de acuerdo con las restricciones para desarrollar la Tecnología de la Información. 

El programador: es el perfil encargado de programar los componentes en la plataforma de desarrollo seleccionando, de acuerdo con las especificaciones del constructor. 

Ciclo de vida del software (CVS)

Cuando se habla de desarrollar un programa, sistemas informáticos o Tecnología de la Información, es importante hablar del proceso del software, en el que nace como una idea, se desarrolla como una aplicación y se libera

(termina). Este proceso se conoce como el Ciclo de vida del software y es una característica en común que comparten las soluciones informáticas.

De acuerdo con la Organización Internacional de Normalización (ISO, por sus siglas en inglés), en su norma 12207-2008, al ciclo de vida del software se le define de la siguiente manera:

[Es] Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta que finaliza su uso o deja de ser útil.

Como se puede ver, el desarrollo de una solución informática se encuentra relacionado con recursos, tiempo, requerimientos técnicos y no técnicos, actividades y productos intermedios (módulos o avances sustanciales) necesarios para desarrollar una herramienta informática. 

Por ello, la administración de un proyecto de TI requiere una planeación que abarque más que las etapas del ciclo de vida del sistema informático (software), es decir, que además tome en cuenta los objetivos, alcance, actividades, tareas, seguimiento, capital humano, recursos financieros, plan de riesgos y entrega de la solución al cliente.

Es necesario puntualizar que el objetivo de este ciclo es validar las actividades de una forma coherente y ordenada, para garantizar que el sistema informático cumpla con los criterios y requisitos funcionales solicitados. A continuación se ilustran los procesos del ciclo de vida del software. 

El proceso del CVS define tres tipos de procesos básicos para el desarrollo de software. Cada uno de ellos contiene distintas etapas, lo que facilita segmentar el trabajo, definir y administrar el progreso en la construcción de la aplicación informática. 

El proceso de desarrollo

De las distintas etapas del ciclo de vida del software, destaca el proceso de desarrollo, que es la descripción secuencial de actividades ordenadas coherentemente para crear el programa informático. Este proceso contempla seis actividades que guardan gran relación con la administración general del proyecto, por lo que es recomendable hacer uso de la información con que se cuenta, para hacer más rápida la integración del proceso de desarrollo de la aplicación, con base en los requerimientos técnicos que se han solicitado.

Es en esta parte donde se aprovecha el conocimiento previo obtenido de la definición y alcance del proyecto, con el objetivo de generar las actividades internas que permitirán seleccionar el modelo de CVS que se adapte mejor al tipo de proyecto planteado, para desarrollar el diseño de la aplicación, seleccionar el entorno de programación, requisitos y limitaciones tecnológicas, para que una vez que se tenga construida la solución informática se pueda iniciar con las pruebas y, finalmente, se entregue la solución informática.

La siguiente ilustración muestra de forma gráfica el proceso de desarrollo del software.

A continuación conocerás los modelos del ciclo de vida de un software, los cuales te servirán como guía para el desarrollo de una aplicación informática.

Modelos del Ciclo de vida del software

Los modelos de CVS se presentan como una pauta para guiar el desarrollo de aplicaciones informáticas, por lo que sirven de referencia para organizar las etapas, actividades, tareas y requerimientos. Estos marcos de gestión del desarrollo permiten controlar y coordinar las actividades de acuerdo con el tipo de proyecto. 

Por lo anterior, no existe un modelo único que se adapte a todas las necesidades y características de un sistema a ser desarrollado, por lo que dependerá del tipo de proyecto y la forma en que se busque coordinarlo para seleccionar uno o varios modelos.

Ahora se presentan algunos modelos que son muy conocidos y han sido usados en la industria del desarrollo de software.

A continuación descarga el siguiente archivo, en el cual se te mostrará una tabla comparativa de los modelos ya revisados y analizados.

 Tabla comparativa de modelos.pdf

La selección de una metodología de desarrollo es una tendencia y una buena práctica en la industria del software, pero no es solamente exclusiva de las empresas, pues los desarrolladores y administradores de proyectos de Tecnologías de la Información también se benefician de su uso y adopción.

Para este MOOC se ha seleccionado el método Scrum para describir el proceso de creación de una solución informática por la siguientes razones: permite desarrollar aplicaciones en poco tiempo e incluye al cliente, pueden

realizarse cambios mientras se motiva al equipo de desarrollo, se considera de fácil comprensión y se centra en la productividad en plazos cortos y la mejora continua.

Método Scrum

Este método tiene su origen en Japón. En 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaron el trabajo de investigación “El nuevo juego de desarrollo para productos nuevos”, en el que se menciona por primera vez este término. A este método también se le conoce como Manufactura sin Desperdicios y su concepto se centra en agilizar la manufactura de un producto.

Sin embargo, fueron los norteamericanos Ken Schwaber y Jeff Sutherland quienes de forma separada usaron el término Scrum (melé) para referirse al concepto de manufactura rápida,  que viene del juego inglés de Rugby y se refiere a una jugada donde los participantes de cada equipo se agrupan en una posición (Scrum) para luchar por la obtención del balón que se pondrá en el centro. En 1995, trabajando de forma conjunta, crean este método (Framework) que permite simplificar las etapas de desarrollo del software minimizando los costos y tiempos de entrega.

Una vez explicado lo anterior, podemos decir que el principio de Scrum se enfoca en que los proyectos informáticos tienen requerimientos y riesgos inciertos. Por esta razón se elimina la documentación innecesaria, para centrarse en la productividad con base en etapas cortas y bien definidas que incluyen al cliente. Con ello se busca minimizar los problemas que conlleva la gestión de un proyecto de desarrollo que requiere una pronta implementación y entrega.

Cabe resaltar que el trabajo colaborativo es importante en Scrum para la solución de  problemas de desarrollo y programación y la atención de cambios o errores en la aplicación. También la motivación del equipo es fundamental para mantener su alto desempeño en el proyecto, por lo que se realizan diariamente juntas rápidas, donde se da seguimiento continuo a los avances programados. Por otro lado, la inclusión del cliente en el proyecto, desde un inicio, permite que éste conozca su avance real, mientras que el equipo puede conocer su punto de vista en cada etapa del desarrollo y efectuar con rapidez los cambios que se presenten, además de enterarse directamente si el cliente aprueba el trabajo realizado. Esta unidad y capacidad de comunicación mantienen el trabajo alineado con el objetivo del proyecto y su alcance.

Por otra parte, en el método Scrum, se llama iteraciones a los pequeños bloques que arrojan un resultado significativo en un tiempo corto y debidamente acotado, donde hay pruebas y realimentación de las funciones por parte del equipo de pruebas y el cliente. La suma de cada una de estas iteraciones da como resultado el producto terminado, listo para ser entregado en el tiempo pactado o mucho antes de ser posible, con lo que se reducen los costos para el cliente. Éste concepto de mínimo esfuerzo es uno de los diferenciadores de Scrum. El plan de desarrollo parte de una lista de requerimientos y objetivos priorizados del sistema informático que es dictado

por el cliente, estos quedan descritos como iteraciones y avances programados.

También los costos son un aspecto importante en este método, así que al tener al cliente como una parte activa del proyecto, se logra optimizar los recursos financieros en aquellas iteraciones  que requieran una atención urgente.

A continuación se muestra el diagrama  con el método Scrum.

Una vez revisado y analizado el diagrama, conocerás las seis actividades del Scrum que a continuación se te presentan:

Después de revisar la información anterior, con la siguiente animación, conocerás los cuatro actores o participantes dentro del método Scrum.

Una buena planificación de un proyecto requiere incluir las etapas de control y gestión de riesgos para monitorear y minimizar los cambios y las amenazas que puedan surgir en el ciclo de vida de un proyecto.

Etapa de control y seguimiento

Todo proyecto requiere contar con una etapa que permita verificar su grado de avance y desarrollo. A diferencia de otras fases de la administración de un proyecto que tienen un inicio y un fin claro, el control se relaciona con varios procesos del ciclo de vida, ya que  vigila, revisa y da el seguimiento con respecto a la planificación que se ha elaborado. 

De la diferencia que exista entre la planeación y el desarrollo real de las actividades se pueden generar acciones preventivas y correctivas que permitan efectuar los cambios necesarios que garanticen  el correcto progreso del proyecto.

La principal meta que persigue la etapa de control en un proyecto es lograr que el objetivo del mismo sea alcanzado al realizar, en caso de que sea necesario, los ajustes a la planificación de las actividades del proyecto. Como resultado de los ajustes efectuados, el cronograma sufrirá actualizaciones, por lo cual debe ajustarse la calendarización de las actividades y el tiempo.  Dependiendo del grado de alteración en los tiempos en el calendario, se puede hacer uso de las holguras para tratar de minimizar los efectos adversos de estos cambios o, en casos más drásticos, afrontar que el plazo de entrega no se podrá llevar a cabo en los tiempos pactados, para lo cual es necesario registrar y documentar los motivos por los que se ha llegado a tener un desfase en el proyecto.

Para prevenir o detectar desviaciones en la gestión del proyecto, el equipo que lo integra puede  hacer uso de las lecciones aprendidas, en caso de que tenga un conocimiento previo, o al haber desarrollado otra solución informática, con el objetivo de prevenir el impacto que tendrán estas alteraciones. 

A continuación conocerás cómo, de qué manera y para qué es importante tomar en cuenta las acciones correctivas y preventivas.

Ahora bien, los indicadores y sus métricas también deben ser catalogados de acuerdo con la naturaleza de lo que se quiera medir; entre mejor se puedan agrupar y clasificar será mucho más fácil poder trabajar tanto en su elaboración como en su uso.

A continuación se muestran un par de ejemplos de indicadores y métricas de desempeño.

Nota: las siglas “RFR” y “RFA” significan “Recurso financiero real” y “Recurso financiero asignado”, respectivamente; el símbolo ≡ significa “exactamente igual a”. Elaborado por MDTI Ricardo Ángel Aguilar Pérez, para el MOOC de AP de TI. 

Nota: las siglas “TD” significan “tiempo de desarrollo”; (m)  es “medida de tiempo” (horas, días, semanas, meses); el símbolo ∑ significa “sumatoria”; (t) es periodo de tiempo; (mp) es “medida de tiempo propuesto” (horas, días, semanas, meses). Elaborado por MDTI Ricardo Ángel Aguilar Pérez, para el MOOC de AP de TI.

El control de cambios

Ahora bien, el control de cambios se realiza mediante un análisis de las desviaciones que sufre el proyecto, llevado a cabo por equipo del proyecto, que afectan de forma directa o indirecta el desarrollo de la solución informática. Como se ha visto, es durante el ciclo de vida del proyecto cuando se presentan situaciones que dificultan alcanzar el objetivo del proyecto. 

Por lo anterior, el control de los cambios es una actividad rigurosa, definida y crítica que debe realizarse desde la planeación del proyecto, ya que de esta forma se podrá llevar un registro de las acciones preventivas o correctivas que se tengan que hacer, pero sobre todo, deben ser justificadas y  aprobadas tanto por el equipo del proyecto como por el cliente.

Entre los factores que llegan a afectar a un proyecto se encuentran los siguientes: cambios en la organización interna del proyecto o por parte del cliente, surgimiento de nuevas áreas y oportunidades tecnológicas, falta de solvencia económica por parte del cliente, nuevas necesidades no previstas y que afectan el desarrollo de la solución, cambios en el entorno del proyecto (sociales y de medio ambiente), normativas gubernamentales, políticas públicas, por citar algunos ejemplos. En el peor de los escenarios, todos estos factores podrían llegar a presentarse durante el desarrollo del proyecto, sin embargo, si son debidamente resueltos y se cuenta con un equipo sólido, se podrán superar para llevar a buen fin la solución informática.

Como se ha visto, el control de los cambios es una actividad que termina siendo interna para el equipo del proyecto; es decir, las peticiones de cambios tienen origen del lado del cliente y, cuando estas son aprobadas, es la parte de desarrollo la encargada de efectuarlas. Para que un cambio sea aprobado, es necesario realizar una evaluación sobre el motivo y la justificación del cambio de acuerdo con el plan original. 

Se pueden identificar dos tipos de peticiones dentro del control de cambios de un proyecto de TI:

Errores en la programación: cuando se identifica un fallo o defecto. Requerimiento de actualización: cuando se requiere modernizar un

componente de la solución informática.

Las peticiones generan dos tipos de respuestas por parte del equipo de desarrollo:

Documento de aprobación: los cambios deben verse reflejados en el sistema informático.

Documento de rechazo: se justifica el motivo por el cual no se considera necesario emprender la acción correctiva o solicitada.

Gestión de riesgos

Al igual que en la etapa de control, en la gestión de riesgos se debe elaborar un plan de respuesta a partir de la identificación y el análisis de los posibles sucesos que supongan un peligro para el correcto funcionamiento de las etapas de un proyecto. Es por ello que se requiere monitorear y dar seguimiento a las distintas fases que conlleva realizar una herramienta de Tecnologías de Información. Con lo anterior se busca minimizar los riesgos y el impacto que estos podrían tener en caso de que ocurrieran. Se considera que un riesgo es todo suceso o evento con un grado de incertidumbre que puede ocurrir en el futuro y que pone en peligro al menos un segmento importante de un proyecto. 

Todos los proyectos tienen algo en común desde su etapa de definición, tienen un grado de incertidumbre que permanecerá latente durante la vida de los mismos. La probabilidad de que ocurran eventos que pongan en peligro un proyecto es tal que se requiere de un plan de contingencia, el cual permita identificar posibles problemas, su grado de impacto, el potencial de sus efectos y consecuencias. 

Por lo anterior, es recomendable que un miembro del equipo con experiencia en proyectos sea la persona designada para realizar el análisis de los posibles riesgos y diseñar un plan de contingencia contra ellos.   

Existen dos tendencias claras que pueden asumir los miembros del equipo de un proyecto:

Del tipo reactivo: no se realiza ninguna planeación y se espera hasta que suceda un problema para solucionarlo; sin embargo, la desventaja de esta tendencia radica en que si una problemática es muy grande, se pone en peligro que el proyecto continúe. 

Del tipo proactivo: en esta tendencia se realiza proceso de análisis e identificación de problemas potenciales, en el que se evalúa la probabilidad de que ocurran y el impacto que podrían tener. A partir de ello se diseña un plan de contención. Su desventaja radica en que la búsqueda de dificultades potenciales y la elaboración de un plan de contingencia consumen tiempo.  

Ahora bien, los cuatro tipos de riesgos más comunes para un sistema informático son los siguientes:

Riesgos organizacionales del proyecto  Riesgos del tipo técnico o tecnológico Riesgos relacionados con las herramientas de diseño Riesgos del tipo financiero

La identificación de riesgos es una actividad sistemática que se relaciona con las amenazas que giran en torno a la planeación del proyecto, pero que incluyen factores externos que no pueden ser controlados pese a que se hagan esfuerzos, hacia el interior de la administración del proyecto, para minimizarlos.

Asimismo, es necesario evaluar tres aspectos para conocer el impacto de un riesgo: la naturaleza del problema, el ambiente por el cual se originó y el grado de afectación que tendrá el calendario (el tiempo).

Para lograr que las probabilidades de éxito de un proyecto se logren, no sólo basta con tener buena voluntad para llevarlo a cabo, se requiere de una constante vigilancia sobre las actividades y tareas que se han planificado, ya que teóricamente se pueden mostrar secuenciales o paralelas, pero en realidad se traslapan, retrasan o adelantan, sobre todo en aquellos proyectos de gran complejidad y que por su duración, como se ha mencionado, se recomienda fragmentar, para ser divididos en módulos, haciendo de la tarea de monitoreo una acción más compleja.

El plan de los riesgos en el proyecto

El plan de riesgos es un proceso en el que se elabora un documento donde se definen las acciones que se deben tomar en caso de que un riesgo aparezca en el horizonte del proyecto. Su función es determinar las acciones que debe realizar el equipo del proyecto frente a una situación y cómo debe ser solucionada, éstas deben quedar enmarcadas en un intervalo de tiempo muy pequeño y ser muy concretas, de lo contrario afectarán el correcto desempeño general de las actividades del proyecto. Este plan debe iniciarse siempre al terminar el análisis; en algunos casos, sobre todo aquellos en que el proyecto sea de gran prioridad y tenga gran rispidez, puede hacerse en paralelo con la identificación de los riesgos, para iniciar su mitigación en cuanto sea posible.   

Como se ha mencionado, el plan de riesgos debe contener acciones claras sobre cómo actuar ante una amenaza y cómo solucionarla. Al respecto, el equipo del proyecto espera que la acción de respuesta sea acorde a la magnitud del problema, al tipo de proyecto y su objetivo.

En definitiva, la persona o el equipo asignado para esta etapa debe estar consciente de que su responsabilidad radica en la correcta evaluación y formulación de las respuestas ante los riesgos que se puedan presentar en el proyecto; de otra forma, los costos serían mayores, lo cual provocaría un

peligro interno, quizá mucho mayor que los que puedan encontrarse en el entorno de la herramienta de TI.

Desarrollo  del proyecto

Una vez que se ha desarrollado la solución informática con base en la metodología seleccionada para desarrollar un software, es necesario iniciar con el cierre del proyecto. Si bien esta etapa se considera administrativa y complementaria a los trabajos de planeación, permite que los participantes del proyecto tengan plasmada la información fundamental sobre el proyecto y su gestión.

El presente bloque tiene como objetivo describir las características de la etapa de cierre de un proyecto, así como presentar los tipos de documentación que deberán acompañar al sistema informático cuando sea presentado y entregado a los usuarios finales de las empresas u organizaciones.

A continuación conocerás las características de la etapa de cierre de un proyecto de TI.

Etapa del Cierre

Esta etapa consiste en llevar a cabo las actividades de gestión concernientes a la conclusión formal del proyecto. Se pueden identificar dos tipos de cierre: el interno, que está relacionado con la conclusión de las actividades por parte del equipo de desarrollo; y el externo, relacionado con el cliente y la empresa u organización para la cual se elaboró el sistema informático.

El cierre toma en cuenta la planificación del proyecto y las etapas anteriores a ésta, es decir, las etapas del PMBOK y la planificación del proyecto, validando que se hayan concluido con los trabajos y las actividades calendarizadas en el cronograma. Además, permite verificar si los objetivos del proyecto han sido logrados y si se han cubierto las necesidades y los requerimientos para el desarrollo de una solución informática.

La documentación de la etapa del cierre se encuentra orientada hacia las acciones que garanticen el término o conclusión del proyecto para que, en caso de que el sistema sea aprobado,  se libere y se transfiera al cliente en las cláusulas y tiempos que se hayan acordado.

Es en esta etapa donde se elabora y genera el mayor número de entregables (documentos significativos) producidos en el ciclo de vida del proyecto. Estos documentos se deben integrar en el archivo interno del proyecto, mediante una carpeta que constituye el expediente de la herramienta de TI. También se deben incluir los escritos pertenecientes a la propia etapa de cierre y entrega, lo cual se abordará más adelante.

Con lo anterior, te habrás percatado que un proyecto cancelado no tiene por qué quedar en el olvido, simplemente puede quedar guardado en el archivo para futuros trabajos.

Cancelación de un proyecto

Un proyecto es cancelado cuando no llega a buen término y éste ha sido cerrado por razones ajenas a la planeación inicial y aún con un plan de riesgos elaborado. Las situaciones que dan origen a un cierre inesperado pueden ser tanto internas como externas y no son planificadas. Sin embargo, los responsables del proyecto tienen el compromiso de documentar en un formato especial los hechos y causas que desembocan en la decisión de finiquitar los trabajos.

Es importante recordar que la redacción del documento  es libre y queda a consideración de quien lo elabora, sin embargo se recomienda que se incluyan los siguientes puntos para justificar los motivos del cierre prematuro de proyecto:

Describir la situación que generó la cancelación definitiva del proyecto. Resaltar los hechos que originaron la situación. Estado de avance del proyecto y su grado de avance en porcentaje. Listado de las actividades y tareas realizadas hasta la fecha de la

cancelación. En caso de ser una decisión interna, presentar la  justificación y los

motivos. Las consideraciones para retomar el proyecto en trabajos futuros. Fondos del presupuesto aún por asignar, gastos del presupuesto y

costos del proyecto.

Aprobación y aceptación del proyecto

La aprobación y aceptación del proyecto es un documento emitido por el cliente (propietario final) del sistema informático, en el que se señala la aceptación de la solución de TI, reconociendo con ello que se ha cumplido con el objetivo y que se puede dar por concluido satisfactoriamente el proyecto.

Las lecciones aprendidas constituyen un documento interno que, si bien no es un requisito administrativo para el cierre, es de gran importancia hacia el interior del equipo, ya que es aquí donde se pueden intercambiar opiniones, experiencia ganada, resolución de conflictos e imprevistos y, sobre todo, generar conocimiento colectivo para el equipo, que puede ser empleado en proyectos futuros. Estos acontecimientos por lo general no son documentados, para ello se aprovecha este punto.

Cuando el producto se ha implementado se recomienda realizar una presentación para el equipo de desarrollo y otra para el cliente, mismas que se expondrán en reuniones posteriores. En estas reuniones se resumirá el proyecto partiendo de la idea, la definición y su objetivo general, hasta llegar a las grandes etapas de gestión, técnicas y metodologías empleadas para la administración y desarrollo del sistema informático, así como las principales aportaciones del proyecto, tanto como una solución de TI y como una fortaleza para el área donde se implementó

Una vez realizada la documentación sobre la cancelación o aprobación del proyecto, es necesario realizar un expediente del proyecto, el cual se presenta a continuación.

Otro documento que puedes utilizar para el llenado de información, en donde podrás documentar los éxitos alcanzados, problemas durante el desarrollo, entre otros, es el de lecciones aprendidas, el cual a continuación se te explica a fondo.

Lecciones aprendidas

Las lecciones aprendidas constituyen un documento en el que se recuperan las experiencias de trabajo a lo largo del proyecto. Su objetivo es recolectar en un archivo los éxitos parciales alcanzados, problemas de gestión y problemas técnicos  y frustraciones operativas en el desarrollo de las actividades y tareas del proyecto en general. Estas experiencias constituyen el conocimiento

colectivo del equipo del proyecto y permiten mejorar futuros desarrollos, mediante la prevención, minimización o evasión de posibles riesgos. También permiten conocer, con base en experiencias previas, escenarios que podrían llegar a presentarse, para poder prever riesgos y su impacto, por ejemplo, el tiempo y los costos para poder tomar decisiones en casos donde las situaciones sean similares.

Por otro lado, también se pueden evitar problemas futuros si se mantienen en regla todos los aspectos del proyecto. A continuación conocerás más a fondo la concertación del proyecto y los acuerdos de negocio.

La presentación del proyecto

Si bien los entregables conforman la parte física que acompaña a un proyecto, también es importante elaborar una serie de láminas a modo de presentación; una para el equipo de trabajo y otra para el cliente. 

El enfoque del contenido es distinto en ambas presentaciones, ya que, por un lado, para el equipo de trabajo lo más importante será verificar el cumplimiento de los objetivos en el desarrollo de la solución en TI, corroborar que la planeación fuera la acordada desde un inicio y, en caso de que lo hubiera, revisar el grado de desviación que se tuvo en relación con el cronograma, así como el nivel y grado de aprendizaje de la metodología y las propuestas que se hicieron hacia el interior del equipo para alcanzar la meta fijada.

Por otro lado, es recomendable que para el cliente la presentación se enfoque en resaltar los beneficios que conlleva el uso de la herramienta de TI y el cumplimiento del objetivo general, comparando los resultados tanto con la solución informática como sin ella; si la implementación se ha llevado en módulos, se tendrán mayores referencias. Es recomendable aplicar una pequeña encuesta de satisfacción a los usuarios para ser presentada gráficamente, que apoye el éxito del sistema informático implementado. Otras características importantes para este tipo de presentación son el tiempo invertido total, el presupuesto inicial contra los gastos y la curva de aprendizaje

del sistema por los propios usuarios.