Comentarios para Gerencia de Proyectos T.I. http://www.icesi.edu.co/blogs/gerenciaproyectosti Blog de Gerencia de Proyectos T.I. - Universidad Icesi Thu, 08 Jan 2009 18:29:09 +0000 http://wordpress.org/?v=2.3.3 Comentario de Daniel Augusto Amariles Garcia en Control del conjunto de prestaciones - Gerencia de Proyectos T.I. http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-24 Daniel Augusto Amariles Garcia Tue, 14 Oct 2008 23:10:40 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-24 En la vida todo cambia y el software no es la excepción, bien desde que pensamos un proyecto personal y a mitad de camino queremos añadirle nuevas funcionalidades o mejorar las actuales, o cuando un cliente descubre una nueva necesidad y quiere agregarla, el cambio existe y debemos convivir con él. Tal vez existan proyectos donde no necesitamos cambiar nada, pero son contadas las excepciones y al menos que hayamos hecho un buen análisis, seguramente la falta de cambios indica que estamos dejando de lado algo. El primer paso para evitar traumas con los cambios de requerimientos, es realizar un análisis de requerimientos global, para ello debemos tener muy claro cuál es el objetivo del software y sobretodo que problema planta solucionar el cliente. A primera vista parece fácil, “un software para manejo de inventario”, pero esta definición tan simple tiene implicaciones muy diferentes en cada negocio e incluso dentro de una misma empresa las personas lo pueden interpretar diferente, ¿acaso el software debe hacer seguimiento vía RFID?, o debe tener soporte para múltiples bodegas, ¿es importante enviar notificaciones vía SMS? Todas estas características y cientos más pueden ajustarse al negocio o pueden que no, y es parte de la labor identificarlas y poder estar preparado para desarrollarlas si así se requiere. Es importante hacer control de cambios al inicio, durante y al finalizar. La especificación mínima nos acerca a no dejar errar en los detalles, ya sea por acción o por omisión, y conocer el por qué se dan los cambios nos prepara para las situaciones indeseables. Muchas veces la experiencia permite identificar una necesidad que el cliente no tiene clara, pero que seguramente necesitara en el futuro, es ahí donde la detección temprana puede ser vital a la hora de realizar o no el cambio. Un ejemplo claro, se puede observara a la hora de diseñar una base de datos, en una ocasión fuimos contratados para realizar un sencillo programa de facturación, al preguntar sobre la manera de hacer los descuentos, la respuesta fue “Aquí casi no damos descuentos y si mucho damos un 10% descuento por pago de contado”, de esta manera cuando diseñamos la base de datos incluimos en una tabla factura una columna llamada descuento con un valor entre 0 y 100, de esta manera el programa permitía agregar un solo descuento al precio final de la factura. Tiempo después la junta directiva creyó que una buena estrategia podía ser agregar descuentos en cascada (descuentos sobre descuentos ya aplicados a la factura) para motivar los pagos antes de 30 días y las ventas por volumen, cuando nos llamaron, explicamos todos los inconvenientes que este cambio podía ocasionar, no solo teníamos que modificar la forma de facturar, si no que debíamos cambiar la base de datos y con ello, la información que ya se había guardado durante el tiempo de operación. Si en esa ocasión hubiéramos previsto ese tipo de cosas, por encima de la necesidad inmediata del cliente, tal vez, desde el diseño abríamos pensado en múltiples descuentos y el cambio no hubiera sido tan traumático, es cierto que cumplimos con un requerimiento inicial pero no fuimos capaces de adaptarnos a las necesidades de nuestro cliente. <em> Francisco Martinez Daniel Amariles</em> En la vida todo cambia y el software no es la excepción, bien desde que pensamos un proyecto personal y a mitad de camino queremos añadirle nuevas funcionalidades o mejorar las actuales, o cuando un cliente descubre una nueva necesidad y quiere agregarla, el cambio existe y debemos convivir con él. Tal vez existan proyectos donde no necesitamos cambiar nada, pero son contadas las excepciones y al menos que hayamos hecho un buen análisis, seguramente la falta de cambios indica que estamos dejando de lado algo.
El primer paso para evitar traumas con los cambios de requerimientos, es realizar un análisis de requerimientos global, para ello debemos tener muy claro cuál es el objetivo del software y sobretodo que problema planta solucionar el cliente. A primera vista parece fácil, “un software para manejo de inventario”, pero esta definición tan simple tiene implicaciones muy diferentes en cada negocio e incluso dentro de una misma empresa las personas lo pueden interpretar diferente, ¿acaso el software debe hacer seguimiento vía RFID?, o debe tener soporte para múltiples bodegas, ¿es importante enviar notificaciones vía SMS? Todas estas características y cientos más pueden ajustarse al negocio o pueden que no, y es parte de la labor identificarlas y poder estar preparado para desarrollarlas si así se requiere.
Es importante hacer control de cambios al inicio, durante y al finalizar. La especificación mínima nos acerca a no dejar errar en los detalles, ya sea por acción o por omisión, y conocer el por qué se dan los cambios nos prepara para las situaciones indeseables.
Muchas veces la experiencia permite identificar una necesidad que el cliente no tiene clara, pero que seguramente necesitara en el futuro, es ahí donde la detección temprana puede ser vital a la hora de realizar o no el cambio.
Un ejemplo claro, se puede observara a la hora de diseñar una base de datos, en una ocasión fuimos contratados para realizar un sencillo programa de facturación, al preguntar sobre la manera de hacer los descuentos, la respuesta fue “Aquí casi no damos descuentos y si mucho damos un 10% descuento por pago de contado”, de esta manera cuando diseñamos la base de datos incluimos en una tabla factura una columna llamada descuento con un valor entre 0 y 100, de esta manera el programa permitía agregar un solo descuento al precio final de la factura. Tiempo después la junta directiva creyó que una buena estrategia podía ser agregar descuentos en cascada (descuentos sobre descuentos ya aplicados a la factura) para motivar los pagos antes de 30 días y las ventas por volumen, cuando nos llamaron, explicamos todos los inconvenientes que este cambio podía ocasionar, no solo teníamos que modificar la forma de facturar, si no que debíamos cambiar la base de datos y con ello, la información que ya se había guardado durante el tiempo de operación. Si en esa ocasión hubiéramos previsto ese tipo de cosas, por encima de la necesidad inmediata del cliente, tal vez, desde el diseño abríamos pensado en múltiples descuentos y el cambio no hubiera sido tan traumático, es cierto que cumplimos con un requerimiento inicial pero no fuimos capaces de adaptarnos a las necesidades de nuestro cliente.

Francisco Martinez
Daniel Amariles

]]> Comentario de Jaime Humberto Arismendi Munoz en Control del conjunto de prestaciones - Gerencia de Proyectos T.I. http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-23 Jaime Humberto Arismendi Munoz Tue, 14 Oct 2008 22:55:45 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-23 <strong>Control del Conjunto de Prestaciones</strong> Por: Andres Felipe Montoya Jaime H Arismendi Todo desarrollo de software es susceptible a cambios durante su proceso de desarrollo, esto se puede dar por varios factores entre los cuales podemos destacar: *Los cambios generados por el avance del proyecto, a medida que se avanza con el desarrollo del software se van teniendo más claros los requerimientos dando lugar a posibles cambios. *Por otra parte están los cambios impulsados por los clientes finales, ya que hay ocasiones en que ellos desean realizar variaciones o adiciones inesperadas en los requerimientos para mejorar la funcionalidad del software en desarrollo, para ello se deben de hacer cambios en la marcha del proyecto lo que genera un impacto sobre los diferentes grupos del proyecto. *Otro cambio encontrado regularmente en los desarrollos de software está arraigado en las innovaciones, cambios y nuevos productos lanzados por las competencias, pues no estar a la vanguardia del mercado puede dar pie al fracaso del software. Este último factor citado es el caso presentado en el Ejemplo 14.1 del libro “<em>Desarrollo y Gestión de Proyectos Informáticos</em>”, en donde a pocas semanas de la entrega del desarrollo hecho por Square-Calc 4.0, se enteran que la competencia lanzo una nueva versión con mejoras que ellos no tenían previsto para la entrega de su producto final. De allí surge la necesidad de gestionar cambios en el desarrollo, teniendo en cuenta que “<em>los productos con un mayor éxito son a menudo aquellos que han incorporado la mayoría de sus cambios al final del ciclo de desarrollo</em>”, seguramente no tendrían ninguna oportunidad de éxito si no se implementaran algunos cambios que permitieran estar a un nivel igual o superior que el producto entregado por la competencia. De esta manera podemos afirmar que los cambios no son del todo malos e intentar detenerlos puede ser un error, los cambios se deben ver como una oportunidad de éxito y su correcta gestión es la clave para lograr que el impacto de estos en lugar de ser perjudicial sea beneficioso. Para ello hay una serie de objetivos comunes que se deben buscar con la implementación de un plan de gestión de cambios y estos son: “<em>Permitir cambios que ayuden a obtener el mejor producto posible en el tiempo disponible. Permitir que todas las partes afectadas por un cambio estimen los impactos del cambio en la planificación, los recursos y el producto. Notificar cada cambio propuesto a los miembros del entorno del proyecto, indicando su impacto estimado y si ha sido aceptado o rechazado. Mantener un registro de las decisiones relacionadas con el contenido del producto.</em>” Ahora bien, volviendo al Ejemplo 14.1, podemos apreciar como allí se hace una correcta gestión de los cambios, se realiza un estudio detallado de las implicaciones que tienen los cambios en el costo, tiempo y el producto, para así poder tomar las decisiones correctas que representan un mayor beneficio para todos los implicados en el proyecto y para la compañía. Los proyectos de software que hemos desarrollado han tenido cambios en el conjunto de prestaciones que, de forma inconsciente, hemos tratado de sobrellevar sin tener un método claro o conocimientos sobre cómo realizar este control. En varias ocasiones al final del proyecto cuando no tenemos tiempo para terminar de implementar todas las prestaciones debemos recurrir a recortarlas. Fallos en la planificación, desarrollo de prestaciones innecesarias, introducción de nuevas prestaciones, falta de experiencia en la negociación y no tener clara la magnitud del proyecto entre otras cosas; son algunas de las causas que nos han impedido entregar un producto terminado y de calidad. Control del Conjunto de Prestaciones
Por: Andres Felipe Montoya
Jaime H Arismendi

Todo desarrollo de software es susceptible a cambios durante su proceso de desarrollo, esto se puede dar por varios factores entre los cuales podemos destacar:
*Los cambios generados por el avance del proyecto, a medida que se avanza con el desarrollo del software se van teniendo más claros los requerimientos dando lugar a posibles cambios.
*Por otra parte están los cambios impulsados por los clientes finales, ya que hay ocasiones en que ellos desean realizar variaciones o adiciones inesperadas en los requerimientos para mejorar la funcionalidad del software en desarrollo, para ello se deben de hacer cambios en la marcha del proyecto lo que genera un impacto sobre los diferentes grupos del proyecto.
*Otro cambio encontrado regularmente en los desarrollos de software está arraigado en las innovaciones, cambios y nuevos productos lanzados por las competencias, pues no estar a la vanguardia del mercado puede dar pie al fracaso del software.
Este último factor citado es el caso presentado en el Ejemplo 14.1 del libro “Desarrollo y Gestión de Proyectos Informáticos”, en donde a pocas semanas de la entrega del desarrollo hecho por Square-Calc 4.0, se enteran que la competencia lanzo una nueva versión con mejoras que ellos no tenían previsto para la entrega de su producto final. De allí surge la necesidad de gestionar cambios en el desarrollo, teniendo en cuenta que “los productos con un mayor éxito son a menudo aquellos que han incorporado la mayoría de sus cambios al final del ciclo de desarrollo”, seguramente no tendrían ninguna oportunidad de éxito si no se implementaran algunos cambios que permitieran estar a un nivel igual o superior que el producto entregado por la competencia.
De esta manera podemos afirmar que los cambios no son del todo malos e intentar detenerlos puede ser un error, los cambios se deben ver como una oportunidad de éxito y su correcta gestión es la clave para lograr que el impacto de estos en lugar de ser perjudicial sea beneficioso. Para ello hay una serie de objetivos comunes que se deben buscar con la implementación de un plan de gestión de cambios y estos son: “Permitir cambios que ayuden a obtener el mejor producto posible en el tiempo disponible. Permitir que todas las partes afectadas por un cambio estimen los impactos del cambio en la planificación, los recursos y el producto. Notificar cada cambio propuesto a los miembros del entorno del proyecto, indicando su impacto estimado y si ha sido aceptado o rechazado. Mantener un registro de las decisiones relacionadas con el contenido del producto.”
Ahora bien, volviendo al Ejemplo 14.1, podemos apreciar como allí se hace una correcta gestión de los cambios, se realiza un estudio detallado de las implicaciones que tienen los cambios en el costo, tiempo y el producto, para así poder tomar las decisiones correctas que representan un mayor beneficio para todos los implicados en el proyecto y para la compañía.
Los proyectos de software que hemos desarrollado han tenido cambios en el conjunto de prestaciones que, de forma inconsciente, hemos tratado de sobrellevar sin tener un método claro o conocimientos sobre cómo realizar este control. En varias ocasiones al final del proyecto cuando no tenemos tiempo para terminar de implementar todas las prestaciones debemos recurrir a recortarlas. Fallos en la planificación, desarrollo de prestaciones innecesarias, introducción de nuevas prestaciones, falta de experiencia en la negociación y no tener clara la magnitud del proyecto entre otras cosas; son algunas de las causas que nos han impedido entregar un producto terminado y de calidad.

]]> Comentario de Alvaro Jose Guerrero Torres en Control del conjunto de prestaciones - Gerencia de Proyectos T.I. http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-19 Alvaro Jose Guerrero Torres Tue, 14 Oct 2008 15:48:51 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-19 <strong>GPTI - Capítulo 14</strong> El control de cambios es un factor muy importante en cualquier desarrollo de software. Es común ver en casos donde clientes adicionan requerimientos al sistema de forma acelerada, sin pensar en el retraso y en los cambios en el resto del sistema que pueden generar. Otro caso es el que se presenta en Square-Calc 4.0, donde es la competencia de un producto de similares características quien define esos nuevos requerimientos adicionados. La adición y posterior redefinición debe ser tratada con cautela. El trabajo en equipo es esencial en este caso. Todas las partes involucradas en el desarrollo deben dar un informe de retrasos y posibles inconvenientes y riesgos que pueden traer los cambios. Es importante darle prioridad a este proceso, dado que está en juego recursos y tiempo futuro que no estarán disponibles; además, en casos donde se esté haciendo un desarrollo a la medida, es clave darle a entender al cliente que estos cambios traerán un retraso y aún más importante es decirles de cuánto será el retraso. Dependiendo del tamaño y la complejidad del proyecto, hay diferentes formas de llevarlo a cabo con el fin de tener un desarrollo rápido y ordenado: • En proyectos de pequeña escala, es muy importante tener en cuenta que se deben hacer con un mínimo de tiempo. No es necesaria una especificación detallada de requerimientos y para facilitar futuros cambios; es conveniente trabajar un desarrollo evolutivo. • En proyectos a mediana escala, es importante documentar muy bien todo lo que se desarrolle, se cambie y se sugiera; en estos desarrollos muchas personas intervienen en los diferentes procesos y es necesario llevar un control minucioso de los cambios que se van a realizar y se han realizado. • En proyectos a gran escala, es importante controlar los tiempos. Un pequeño cambio puede hacer repercusión en un gran número de puntos funcionales o requerimientos. En más conveniente socializar en el equipo de desarrollo el cambio y en un tiempo prudente pensarlo, que tratar de hacer las estimaciones de forma acelerada sin tener en cuenta el efecto de los cambios en las entregas y en el sistema total. GPTI - Capítulo 14

El control de cambios es un factor muy importante en cualquier desarrollo de software. Es común ver en casos donde clientes adicionan requerimientos al sistema de forma acelerada, sin pensar en el retraso y en los cambios en el resto del sistema que pueden generar. Otro caso es el que se presenta en Square-Calc 4.0, donde es la competencia de un producto de similares características quien define esos nuevos requerimientos adicionados.
La adición y posterior redefinición debe ser tratada con cautela. El trabajo en equipo es esencial en este caso. Todas las partes involucradas en el desarrollo deben dar un informe de retrasos y posibles inconvenientes y riesgos que pueden traer los cambios. Es importante darle prioridad a este proceso, dado que está en juego recursos y tiempo futuro que no estarán disponibles; además, en casos donde se esté haciendo un desarrollo a la medida, es clave darle a entender al cliente que estos cambios traerán un retraso y aún más importante es decirles de cuánto será el retraso.
Dependiendo del tamaño y la complejidad del proyecto, hay diferentes formas de llevarlo a cabo con el fin de tener un desarrollo rápido y ordenado:

• En proyectos de pequeña escala, es muy importante tener en cuenta que se deben hacer con un mínimo de tiempo. No es necesaria una especificación detallada de requerimientos y para facilitar futuros cambios; es conveniente trabajar un desarrollo evolutivo.

• En proyectos a mediana escala, es importante documentar muy bien todo lo que se desarrolle, se cambie y se sugiera; en estos desarrollos muchas personas intervienen en los diferentes procesos y es necesario llevar un control minucioso de los cambios que se van a realizar y se han realizado.

• En proyectos a gran escala, es importante controlar los tiempos. Un pequeño cambio puede hacer repercusión en un gran número de puntos funcionales o requerimientos. En más conveniente socializar en el equipo de desarrollo el cambio y en un tiempo prudente pensarlo, que tratar de hacer las estimaciones de forma acelerada sin tener en cuenta el efecto de los cambios en las entregas y en el sistema total.

]]> Comentario de Carlos Serna Jorge Saucedo en Control del conjunto de prestaciones - Gerencia de Proyectos T.I. http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-18 Carlos Serna Jorge Saucedo Mon, 13 Oct 2008 20:48:04 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/10/06/control-del-conjunto-de-prestaciones-gerencia-de-proyectos-ti/#comment-18 Los proyectos de software son realizados según las especificaciones y deseos de los clientes. Sin embargo, lograr plasmar en código lo que el cliente está pensando y quiere obtener al contratar a un grupo de desarrolladores es una tarea difícil. Para esto, existen varios métodos para obtener los requerimientos del software que el cliente desea. Una vez se tengan todos los requerimientos, y que el cliente los haya aprobado, se procede a la codificación. Sin embargo, es común que los requerimientos cambien, ya sea porque al cliente se le ocurrió añadir una nueva funcionalidad al software en mitad de camino, o porque salió a la venta un nuevo software de la competencia que tiene aspectos que no se habían tenido en cuenta. Esto ultimo fue lo que ocurrió con Square-Calc 4.0, en el cual la competencia sacó a la venta un software superior a éste en varios aspectos, por lo que se debieron replantear las prestaciones del software y por lo tanto los requerimientos. Cuando se modifican los requerimientos de un producto de software, la consecuencia más común es un atraso en varios meses de la entrega final del producto y un sobre costo en la producción. Esto se debe a que al ingresar nuevos requerimientos y modificaciones al producto, la probabilidad de que sea necesario modificar las partes ya codificadas del software aumente considerablemente y haya necesidad casi de reescribirlo. De acuerdo a lo anterior, al momento de realizar cambios en los requerimientos, es necesario hacer un estudio del impacto que éstos generan en el costo y tiempos de entrega del producto final. Tal como se aprecia en la lectura, primero se realizó una lista de prestaciones que deben ser modificadas, luego se estudió cuanto tiempo tardarían, y al final solo se escogieron las que eran mas relevantes y no tomaran mucho tiempo en ser establecidas. Los cambios en los requerimientos son el común denominador en el desarrollo de software. Sin embargo, no se debe tener una actitud negativa frente a los cambios. Existen métodos para estimar los costos en tiempo y dinero de los cambios, y dependiendo de esto se pueden implementar o no. Los proyectos de software son realizados según las especificaciones y deseos de los clientes. Sin embargo, lograr plasmar en código lo que el cliente está pensando y quiere obtener al contratar a un grupo de desarrolladores es una tarea difícil. Para esto, existen varios métodos para obtener los requerimientos del software que el cliente desea. Una vez se tengan todos los requerimientos, y que el cliente los haya aprobado, se procede a la codificación.

Sin embargo, es común que los requerimientos cambien, ya sea porque al cliente se le ocurrió añadir una nueva funcionalidad al software en mitad de camino, o porque salió a la venta un nuevo software de la competencia que tiene aspectos que no se habían tenido en cuenta.

Esto ultimo fue lo que ocurrió con Square-Calc 4.0, en el cual la competencia sacó a la venta un software superior a éste en varios aspectos, por lo que se debieron replantear las prestaciones del software y por lo tanto los requerimientos.

Cuando se modifican los requerimientos de un producto de software, la consecuencia más común es un atraso en varios meses de la entrega final del producto y un sobre costo en la producción. Esto se debe a que al ingresar nuevos requerimientos y modificaciones al producto, la probabilidad de que sea necesario modificar las partes ya codificadas del software aumente considerablemente y haya necesidad casi de reescribirlo.

De acuerdo a lo anterior, al momento de realizar cambios en los requerimientos, es necesario hacer un estudio del impacto que éstos generan en el costo y tiempos de entrega del producto final. Tal como se aprecia en la lectura, primero se realizó una lista de prestaciones que deben ser modificadas, luego se estudió cuanto tiempo tardarían, y al final solo se escogieron las que eran mas relevantes y no tomaran mucho tiempo en ser establecidas.

Los cambios en los requerimientos son el común denominador en el desarrollo de software. Sin embargo, no se debe tener una actitud negativa frente a los cambios. Existen métodos para estimar los costos en tiempo y dinero de los cambios, y dependiendo de esto se pueden implementar o no.

]]> Comentario de carlos lozano, andres camacho en Gestión de la Calidad http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-17 carlos lozano, andres camacho Thu, 25 Sep 2008 22:07:46 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-17 El mejoramiento de la calidad debe estar en cada una de los procesos que conforman la administración de calidad del proyecto. Las entradas en la planeación (gestión) de calidad son la política, los procedimientos y los procesos de planificación de calidad. Las entradas en el aseguramiento de la calidad son muchas más y no solo los resultados de las mediciones del control de la calidad, según la grafica 8.1 del texto son 10. Las líneas de interacción entre procesos deberían ser en ambos sentidos y no solo de izquierda a derecha. Las herramientas y técnicas para monitorear la calidad son mas según el diagrama 8.1. Una entrada muy importante en la realización del aseguramiento de la calidad es dirigir y gestionar la ejecución del proyecto. El mejoramiento de la calidad debe estar en cada una de los procesos que conforman la administración de calidad del proyecto.

Las entradas en la planeación (gestión) de calidad son la política, los procedimientos y los procesos de planificación de calidad.
Las entradas en el aseguramiento de la calidad son muchas más y no solo los resultados de las mediciones del control de la calidad, según la grafica 8.1 del texto son 10.

Las líneas de interacción entre procesos deberían ser en ambos sentidos y no solo de izquierda a derecha.

Las herramientas y técnicas para monitorear la calidad son mas según el diagrama 8.1.

Una entrada muy importante en la realización del aseguramiento de la calidad es dirigir y gestionar la ejecución del proyecto.

]]> Comentario de Daniel Augusto Amariles Garcia en Gestión de la Calidad http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-16 Daniel Augusto Amariles Garcia Thu, 25 Sep 2008 03:58:21 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-16 @Carlos Serna Jorge Saucedo: Identificar los componentes de la gestión de la calidad es un parte importante para poder estudiarla, pero es más importante conocer el papel que juegan estos en proyecto y como estos componentes colaboran entre sí. Por lo que para términos prácticos es mejor poder representar este funcionamiento con un método que pueda dar más determinación y significado a los proceso, por lo que estamos de acuerdo con que un mapa conceptual tal vez no sea la mejor manera para hacer esta representación, y qué además no deje que falten piezas claves del esquema como describe el PMBOK en el capitulo 8: Entradas, Herramientas y técnicas, y Salidas. Lo que genera cada proceso, pensamos que es necesario dividir en aspectos positivos y negativos, ya que es importante identificar lo que es deseable y lo que no. @Carlos Serna Jorge Saucedo: Identificar los componentes de la gestión de la calidad es un parte importante para poder estudiarla, pero es más importante conocer el papel que juegan estos en proyecto y como estos componentes colaboran entre sí. Por lo que para términos prácticos es mejor poder representar este funcionamiento con un método que pueda dar más determinación y significado a los proceso, por lo que estamos de acuerdo con que un mapa conceptual tal vez no sea la mejor manera para hacer esta representación, y qué además no deje que falten piezas claves del esquema como describe el PMBOK en el capitulo 8: Entradas, Herramientas y técnicas, y Salidas.

Lo que genera cada proceso, pensamos que es necesario dividir en aspectos positivos y negativos, ya que es importante identificar lo que es deseable y lo que no.

]]> Comentario de Carlos Lozano Jorge Camacho en Gestión de Riesgos http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/15/gestion-de-riesgos/#comment-15 Carlos Lozano Jorge Camacho Tue, 23 Sep 2008 23:25:33 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/15/gestion-de-riesgos/#comment-15 Gestion de riesgos: La gestión de riesgos es el proceso mediante el cual se identifican, se estudian y se eliminan las fuentes de riesgo que podrían amenazar la finalización oportuna de el proyecto, hay 5 formas distintas para hacer una gestión de riesgos: • Control de crisis. • Arreglar cada error. • Mitigación de riesgos. • Prevención. • Eliminación de causas principales. Dentro de estas formas podemos observar que las primeras tres son situaciones en las cuales ya se ha cometido el error y ya se esta haciendo un intento de corrección cuando ya se cometió un error muy grave mientras que en las ultimas dos que son las indicadas trata es de hacer corrección a tiempo del problema lo que es lo realmente correcto en la gerencia de proyectos de T.I. La gestión de riesgos se lleva a cabo en dos partes claves que son: la estimación y el control de riesgos. La estimación de riesgos se compone a su vez de identificación análisis y priorización, El proceso de identificación es la parte en la cual se deben analizar la lista de errores posibles que salió en la planificación, después debe pasarse a hacer el análisis en donde debe verse cuales de los errores se pueden dar en el proyecto en cuestión y después observar en que medida afectara cada uno de ellos al proyecto en cuestión esta estimación puede hacerse mediante: exposición a riesgos, estimación de la magnitud de la perdida y/o estimación de la probabilidad de perdida. Finalmente se debe hacer una priorización de riesgos para con una buena estimación saber cuales de los errores deben arreglarse primero y en que orden deben arreglarse los otros. Después debe pasarse a la parte de control de riesgos, parte que a su vez se divide en planificación, resolución y monitoreo. En la planificación se desarrolla un plan estructurado según la priorización que se haya echo de los riesgos que deben ser atendidos(por lo menos en teoría) antes de comenzar el proyecto después se da la resolución que es donde se desarrolla(se ejecuta) la planificación que se a dado en el punto anterior, finalmente debe hablarse de el monitoreo que donde se lleva a cabo la vigilancia requerida por el proceso descrito anteriormente. En conclusión aquí observamos el proceso que debe llevarse a cabo para estar lo mas protegido posible en contra de fallos en un proyecto para no perder el tiempo y el dinero invertido en la solución en la cual se esta trabajando. El cumplimiento de todas estos puntos no garantiza la calidad del trabajo pero si garantiza que por lo menos se esta haciendo el mejor esfuerzo. Gestion de riesgos:
La gestión de riesgos es el proceso mediante el cual se identifican, se estudian y se eliminan las fuentes de riesgo que podrían amenazar la finalización oportuna de el proyecto, hay 5 formas distintas para hacer una gestión de riesgos:
• Control de crisis.
• Arreglar cada error.
• Mitigación de riesgos.
• Prevención.
• Eliminación de causas principales.
Dentro de estas formas podemos observar que las primeras tres son situaciones en las cuales ya se ha cometido el error y ya se esta haciendo un intento de corrección cuando ya se cometió un error muy grave mientras que en las ultimas dos que son las indicadas trata es de hacer corrección a tiempo del problema lo que es lo realmente correcto en la gerencia de proyectos de T.I.
La gestión de riesgos se lleva a cabo en dos partes claves que son: la estimación y el control de riesgos. La estimación de riesgos se compone a su vez de identificación análisis y priorización, El proceso de identificación es la parte en la cual se deben analizar la lista de errores posibles que salió en la planificación, después debe pasarse a hacer el análisis en donde debe verse cuales de los errores se pueden dar en el proyecto en cuestión y después observar en que medida afectara cada uno de ellos al proyecto en cuestión esta estimación puede hacerse mediante: exposición a riesgos, estimación de la magnitud de la perdida y/o estimación de la probabilidad de perdida. Finalmente se debe hacer una priorización de riesgos para con una buena estimación saber cuales de los errores deben arreglarse primero y en que orden deben arreglarse los otros.
Después debe pasarse a la parte de control de riesgos, parte que a su vez se divide en planificación, resolución y monitoreo. En la planificación se desarrolla un plan estructurado según la priorización que se haya echo de los riesgos que deben ser atendidos(por lo menos en teoría) antes de comenzar el proyecto después se da la resolución que es donde se desarrolla(se ejecuta) la planificación que se a dado en el punto anterior, finalmente debe hablarse de el monitoreo que donde se lleva a cabo la vigilancia requerida por el proceso descrito anteriormente.
En conclusión aquí observamos el proceso que debe llevarse a cabo para estar lo mas protegido posible en contra de fallos en un proyecto para no perder el tiempo y el dinero invertido en la solución en la cual se esta trabajando. El cumplimiento de todas estos puntos no garantiza la calidad del trabajo pero si garantiza que por lo menos se esta haciendo el mejor esfuerzo.

]]> Comentario de Andres Montoya - Jaime Arismendi en Gestión de la Calidad http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-14 Andres Montoya - Jaime Arismendi Tue, 23 Sep 2008 15:26:24 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-14 La gestión de la calidad no solo implica gestionar la calidad del producto del proyecto sino también administrar la calidad de la gestión del proyecto como tal. Esto quiere decir que dentro de la gestión de calidad debemos ir mejorando continuamente el proceso de gestión del los proyectos en la organización reduciendo las actividades inútiles y que no agregan valor, permitiendo así un proceso más eficiente y efectivo. El aseguramiento de la calidad proporciona herramientas claves para la mejora continua del proceso. La mejora continua del proceso proporciona un medio iterativo para mejorar la calidad de todos los procesos de la organización. Respecto al mapa conceptual, allí se especifica que el aseguramiento de calidad al final conlleva a un mejoramiento de calidad, sin embargo no estamos totalmente de acuerdo con esto, pues es claro que un aseguramiento de calidad consiste en “la aplicación de actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto emplee todos los procesos necesarios para cumplir con los requisitos”1 lo cual hace parte del proceso de gestión para buscar el aseguramiento de calidad, pues de igual manera se requiere realizar un control de calidad. De tal manera sería inapropiado afirmar que con el aseguramiento de calidad se lograría un mejoramiento de la calidad. Otro aspecto que hace falta tratar y que explicamos al comienzo es la gestión de calidad de los procesos de la organización. “El incumplimiento de los requisitos de calidad en cualquiera de las dos dimensiones (Gestión de calidad del producto y Gestión de calidad del proyecto) puede tener consecuencias negativas graves para los interesados en el proyecto”2. En el desarrollo de todos los proyectos y productos de la organización se debe hacer gestión a la calidad de los procesos para irlos validando, corrigiendo y mejorando según sea el caso. ______________________________________ 1 PMBOK 2004 Versión en Español. Capítulo 8: Gestión de la Calidad del Proyecto. Pág. 187 2 PMBOK 2004 Versión en Español. Capítulo 8: Gestión de la Calidad del Proyecto. Pág. 180 La gestión de la calidad no solo implica gestionar la calidad del producto del proyecto sino también administrar la calidad de la gestión del proyecto como tal. Esto quiere decir que dentro de la gestión de calidad debemos ir mejorando continuamente el proceso de gestión del los proyectos en la organización reduciendo las actividades inútiles y que no agregan valor, permitiendo así un proceso más eficiente y efectivo.

El aseguramiento de la calidad proporciona herramientas claves para la mejora continua del proceso. La mejora continua del proceso proporciona un medio iterativo para mejorar la calidad de todos los procesos de la organización.

Respecto al mapa conceptual, allí se especifica que el aseguramiento de calidad al final conlleva a un mejoramiento de calidad, sin embargo no estamos totalmente de acuerdo con esto, pues es claro que un aseguramiento de calidad consiste en “la aplicación de actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto emplee todos los procesos necesarios para cumplir con los requisitos”1 lo cual hace parte del proceso de gestión para buscar el aseguramiento de calidad, pues de igual manera se requiere realizar un control de calidad. De tal manera sería inapropiado afirmar que con el aseguramiento de calidad se lograría un mejoramiento de la calidad.

Otro aspecto que hace falta tratar y que explicamos al comienzo es la gestión de calidad de los procesos de la organización. “El incumplimiento de los requisitos de calidad en cualquiera de las dos dimensiones (Gestión de calidad del producto y Gestión de calidad del proyecto) puede tener consecuencias negativas graves para los interesados en el proyecto”2. En el desarrollo de todos los proyectos y productos de la organización se debe hacer gestión a la calidad de los procesos para irlos validando, corrigiendo y mejorando según sea el caso.

______________________________________
1 PMBOK 2004 Versión en Español. Capítulo 8: Gestión de la Calidad del Proyecto. Pág. 187
2 PMBOK 2004 Versión en Español. Capítulo 8: Gestión de la Calidad del Proyecto. Pág. 180

]]> Comentario de Carlos Serna Jorge Saucedo en Gestión de la Calidad http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-13 Carlos Serna Jorge Saucedo Sun, 21 Sep 2008 23:52:47 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/19/gestion-de-la-calidad/#comment-13 La Gestión de Calidad de un proyecto, esta formada por tres procesos que se encargan de definir todas las actividades para determinar las políticas, los objetivos y las responsabilidades relativos a la calidad, de modo que el proyecto satisfaga las necesidades por las cuales se realizará. Los 3 procesos que abarca la Gestión de Calidad son: • La planificación de Calidad • Realizar Aseguramiento de Calidad • Realizar Control de Calidad. Cada uno de los procesos anteriormente expuestos, están formados principalmente por entradas, herramientas y técnicas y salidas. Sin embargo es importante especificar que estos 3 proceso se relacionan entre si. Básicamente, las salidas del proceso de Planificación de Calidad, sirven de entrada para los otros dos procesos. De igual modo, las salidas del proceso de Aseguramiento de Calidad sirven como entradas del último proceso. El primer proceso de la gestión de calidad, la planificación, permite identificar que normas de calidad pueden ser aplicadas en el proyecto y determina como satisfacerlas. El segundo proceso, el aseguramiento de Calidad, es la aplicación de actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto emplee todos los procesos necesarios para cumplir con los requisitos. En otras palabras, aplica todo lo aprendido en el primero proceso. El tercer y último proceso, el control de Calidad, implica supervisar los resultados específicos del proyecto, para determinar si cumplen con las normas de calidad relevantes e identificar los modos de eliminar las causas de resultados insatisfactorios. En otras palabras, es la revisión de todas las técnicas aplicadas en el segundo proceso, para asegurar de que fueron bien implementadas. De acuerdo con el mapa conceptual, es posible apreciar como se relacionan los procesos entre sí. Sin embargo, las herramientas y técnicas para “procesar” las entradas, están incompletas y no están claramente explicadas. Por otro lado, el esquema de proceso de ENTRADA >> HERRAMIENTAS Y TECNICAS >> SALIDAS, no es muy claro y puede llevar a confusiones. Si se hubiera realizado una cadena entre los procesos, el proceso de la gestión de calidad hubiera sido mucho más claro y hubiera sido mucho más fácil la identificación de las relaciones entre procesos. Como podemos apreciar, la gestión de calidad de un proyecto es un proceso encadenado, el cual empieza por la planeación o investigación de cuales son las técnicas que se van a emplear para producir un producto de calidad. Luego, viene la implementación de estas técnicas anteriormente definidas. Por ultimo, se deben revisar los resultados del proyecto, para saber si cumplen o no con las normas de calidad planteadas desde el principio. La ausencia u omisión de alguno de estos pasos, podría llevar al fracaso del proyecto. Si se omite la planificación, no se tendría una base para realizar la segunda. Si se omite la realización del aseguramiento de calidad, no se tiene proceso de implementación del proceso de calidad. Y si se ignora el control, no se pueden evaluar los resultados, no se tendría un punto de comparación, no se podría realizar una retroalimentación y lo mas importante, no se sabría con certeza si el producto es de calidad o no. La Gestión de Calidad de un proyecto, esta formada por tres procesos que se encargan de definir todas las actividades para determinar las políticas, los objetivos y las responsabilidades relativos a la calidad, de modo que el proyecto satisfaga las necesidades por las cuales se realizará.
Los 3 procesos que abarca la Gestión de Calidad son:
• La planificación de Calidad
• Realizar Aseguramiento de Calidad
• Realizar Control de Calidad.
Cada uno de los procesos anteriormente expuestos, están formados principalmente por entradas, herramientas y técnicas y salidas. Sin embargo es importante especificar que estos 3 proceso se relacionan entre si. Básicamente, las salidas del proceso de Planificación de Calidad, sirven de entrada para los otros dos procesos. De igual modo, las salidas del proceso de Aseguramiento de Calidad sirven como entradas del último proceso.
El primer proceso de la gestión de calidad, la planificación, permite identificar que normas de calidad pueden ser aplicadas en el proyecto y determina como satisfacerlas.
El segundo proceso, el aseguramiento de Calidad, es la aplicación de actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto emplee todos los procesos necesarios para cumplir con los requisitos. En otras palabras, aplica todo lo aprendido en el primero proceso.
El tercer y último proceso, el control de Calidad, implica supervisar los resultados específicos del proyecto, para determinar si cumplen con las normas de calidad relevantes e identificar los modos de eliminar las causas de resultados insatisfactorios. En otras palabras, es la revisión de todas las técnicas aplicadas en el segundo proceso, para asegurar de que fueron bien implementadas.
De acuerdo con el mapa conceptual, es posible apreciar como se relacionan los procesos entre sí. Sin embargo, las herramientas y técnicas para “procesar” las entradas, están incompletas y no están claramente explicadas. Por otro lado, el esquema de proceso de ENTRADA >> HERRAMIENTAS Y TECNICAS >> SALIDAS, no es muy claro y puede llevar a confusiones. Si se hubiera realizado una cadena entre los procesos, el proceso de la gestión de calidad hubiera sido mucho más claro y hubiera sido mucho más fácil la identificación de las relaciones entre procesos.
Como podemos apreciar, la gestión de calidad de un proyecto es un proceso encadenado, el cual empieza por la planeación o investigación de cuales son las técnicas que se van a emplear para producir un producto de calidad. Luego, viene la implementación de estas técnicas anteriormente definidas. Por ultimo, se deben revisar los resultados del proyecto, para saber si cumplen o no con las normas de calidad planteadas desde el principio. La ausencia u omisión de alguno de estos pasos, podría llevar al fracaso del proyecto. Si se omite la planificación, no se tendría una base para realizar la segunda. Si se omite la realización del aseguramiento de calidad, no se tiene proceso de implementación del proceso de calidad. Y si se ignora el control, no se pueden evaluar los resultados, no se tendría un punto de comparación, no se podría realizar una retroalimentación y lo mas importante, no se sabría con certeza si el producto es de calidad o no.

]]> Comentario de Geovany Trejos Salas en Gestión de Riesgos http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/15/gestion-de-riesgos/#comment-9 Geovany Trejos Salas Wed, 17 Sep 2008 00:50:17 +0000 http://www.icesi.edu.co/blogs/gerenciaproyectosti/2008/09/15/gestion-de-riesgos/#comment-9 La gestión del Riesgo en los proyectos Es importante garantizar la Calidad de un producto en el momento de su fabricación, ya que así garantizamos que el cliente tendrá un mayor nivel de satisfacción con el producto que recibirá; así que diremos que el Control de la Calidad y el Aseguramiento de la Calidad es de vital importancia en la producción para productos tangibles e intangibles. En la gestión de Proyectos, el Aseguramiento de la Calidad es dado por la determinación de los riesgos a los que pueda tender el proyecto y el Control de Calidad serán entonces las mediciones que se hacen alrededor de este riesgo en el transcurso del proyecto, cuantificando las posibilidades en su avance conforme el programa y su formación conforme su crecimiento. Las posibilidades de éxito de un proyecto se incrementa en la media que se tienen en cuenta los riesgos posibles, la gestión del riesgo en los proyectos es importante en términos de tiempo y costo. Prever y maniobrar los posibles riesgos puede llevar a que el proyecto sea más que un éxito. Es importante tener en cuenta: Planificación de la gestión de riesgos: en este paso se decide como enfocar, planificar y ejecutar las actividades de gestión de riesgo para el proyecto. Identificación de riesgos: Aquí se determina a qué riesgos es más propenso el proyecto y se documentan sus características. Análisis cualitativo de riesgos: Los riesgos son clasificados según su probabilidad de ocurrencia e impacto, para realizar otros análisis o acciones posteriores. En estos casos es útil utilizar una herramienta como el diagrama causa efecto. Análisis cuantitativo de riesgos: Los riesgos se identifican en los objetivos generales del proyecto y son analizados según su efecto. Para este caso una herramienta como el AMEF (análisis de modo y efecto de falla) Planificación de la respuesta a los riesgos: El equipo encargado desarrolla opciones y acciones para mejorar las oportunidades y reducir las amenazas según los análisis anteriores. Es algo así como saltar los huecos que resultan en el camino Seguimiento y control de riesgos: Cuando ya se han identificado los riesgos a los cuales es propenso el proyecto, se realizar un seguimiento cada uno de ellos, se debe también identificar nuevos riesgos (las posibilidades son latentes en cada momento), ejecutar planes de respuesta a los riesgos y evaluar su efectividad. Los seis procesos anteriores son descritos en la Guía PMBOK, Geovany Trejos Universidad Universidad Icesi La gestión del Riesgo en los proyectos

Es importante garantizar la Calidad de un producto en el momento de su fabricación, ya que así garantizamos que el cliente tendrá un mayor nivel de satisfacción con el producto que recibirá; así que diremos que el Control de la Calidad y el Aseguramiento de la Calidad es de vital importancia en la producción para productos tangibles e intangibles. En la gestión de Proyectos, el Aseguramiento de la Calidad es dado por la determinación de los riesgos a los que pueda tender el proyecto y el Control de Calidad serán entonces las mediciones que se hacen alrededor de este riesgo en el transcurso del proyecto, cuantificando las posibilidades en su avance conforme el programa y su formación conforme su crecimiento. Las posibilidades de éxito de un proyecto se incrementa en la media que se tienen en cuenta los riesgos posibles, la gestión del riesgo en los proyectos es importante en términos de tiempo y costo. Prever y maniobrar los posibles riesgos puede llevar a que el proyecto sea más que un éxito.

Es importante tener en cuenta:

Planificación de la gestión de riesgos: en este paso se decide como enfocar, planificar y ejecutar las actividades de gestión de riesgo para el proyecto.

Identificación de riesgos: Aquí se determina a qué riesgos es más propenso el proyecto y se documentan sus características.

Análisis cualitativo de riesgos: Los riesgos son clasificados según su probabilidad de ocurrencia e impacto, para realizar otros análisis o acciones posteriores. En estos casos es útil utilizar una herramienta como el diagrama causa efecto.

Análisis cuantitativo de riesgos: Los riesgos se identifican en los objetivos generales del proyecto y son analizados según su efecto. Para este caso una herramienta como el AMEF (análisis de modo y efecto de falla)

Planificación de la respuesta a los riesgos: El equipo encargado desarrolla opciones y acciones para mejorar las oportunidades y reducir las amenazas según los análisis anteriores. Es algo así como saltar los huecos que resultan en el camino

Seguimiento y control de riesgos: Cuando ya se han identificado los riesgos a los cuales es propenso el proyecto, se realizar un seguimiento cada uno de ellos, se debe también identificar nuevos riesgos (las posibilidades son latentes en cada momento), ejecutar planes de respuesta a los riesgos y evaluar su efectividad.

Los seis procesos anteriores son descritos en la Guía PMBOK,

Geovany Trejos

Universidad Universidad Icesi

]]>