Download - Portafolio de Gestion
UNIVERSIDAD GERARDO BARRIOS
PORTAFOLIO DEL ESTUDIANTE
JOSE PEDRO DIAZ ALUMNOS:
Ángela Patricia Pérez Hernández Xenia Patricia Hernández Sandoval
Edgar Ulises Quintanilla Amaya Glenda Maricela Pérez Ramos
San Migue 14/06/16
INTRODUCCION AL PORTAFOLIO
Enmarcándonos dentro de la catedra “Gestión de Proyectos Informáticos” se
solicitado que los estudiantes realicen un portafolio de evidencias.
Es por ello que nuestro portafolio presenta todas las actividades realizadas en
clases, laboratorios, parciales y con respecto a los documentos realizados para la
ejecución del sistema informático “Sistema de Inventario Bazar Karina” dentro del
cual solo se incluirá la carpeta técnica, que dentro del cual incluye, definición de
roles, presupuesto, registro de stakeholder y las respectivas estrategias de gestión
de stakeholder. También se incluirá diseño del sistema, que incluye bocetos para la
respectiva aprobación del catedrático y luego del Sponsor. Es necesario también
incluir las fórmulas de método PERT.
CARPETA TECNICA
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Sistema de Inventario y Gestión de
Mercadería Bazar Karina
SINGEMEBAK
INICIACIÓN DEL PROYECTO
CRÉDITOS: Angela Patricia Pérez Hernández
Licenciatura en Computación Trabajo: Estudiante Cargo: Tel: 7271-2097 Email: [email protected]
Xenia Patricia Hernández Sandoval Licenciatura en Computación Trabajo: Estudiante Cargo: Tel: 7224-7168 Email: [email protected]
Edgar Ulises Quintanilla Amaya Licenciatura en Computación Trabajo: Cyber Station Cargo: Tel: 7141-4922 Email: [email protected]
Glenda Maricela Pérez Ramos Licenciatura en Computación Trabajo: Variedades Beatriz Cargo: Tel: 7878-9937 Email: [email protected]
CONTROLES DE VERSIONES
CONTROL DE VERSIONES Versión Hecha por Revisada por Aprobada por Fecha Motivo
PROJECT
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
DESCRIPCIÓN DEL PROYECTO: QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE? El proyecto ‘’ Sistema de Inventario y Gestión de Mercadería Bazar Karina’’, consiste en un sistema de inventario de los diferentes tipos de calzado que se encuentran en existencia, consigo una página web que le permita al cliente poder realizar una compra desde cualquier tipo de dispositivo. Para el mayor control de entrada y salida de los productos, se deben de contemplar las actividades incluidas en la etapa definidas en todo el desarrollo, como son:
El inicio y el alcance del proyecto La planificación del proyecto (calendario, recursos necesarios, costo) Definición de las necesidades del negocio y el análisis en detalle dela solución La creación de la solución Prueba que la solución funciona. La entrega de la solución a su público objetivo Cierre del proyecto.
El desarrollo estará a cargo en las siguientes áreas:
Productos nuevos (recolector de información) Diseñadores Gráficos Programación Mantenimiento del equipo y sistema Analista de sistema Depurador de sistema Verificador de programación Verificador de diseño de interfaz
El proyecto será realizado a partir del mes de febrero hasta junio, en el establecimiento Bazar Karina, dicha empresa que está ubicada en la ciudad de San Francisco Gotera, Morazán, El Salvador.
DEFINICIÓN DEL PRODUCTO DEL PROYECTO : DESCRIPCIÓN DEL PRODUCTO, SERVICIO O CAPACIDAD
A GENERAR. La creación de inventarios de Bazar Karina tendrá las siguientes características: Términos Generales.
Ingresos de productos nuevos. Ingresos de precios por estilo Adecuado para el registro de producto saliente.
Términos de Presentación.
Amigable para el usuario que lo manipule. La plantilla debe ser adecuada para la empresa. Debe ser accesible para el usuario. Debe guardar todos los productos nuevos que ingresen a la empresa.
Términos de Contenido
Lenguaje de programación: PHP, java Base de datos: Manejador de datos phpMyadmin Gestor de datos: Servidor web usbwebserver
El administrador del inventario pide los siguientes elementos para ser aprobados durante el desarrollo del sistema de control de inventario.
Una prueba de inventario antes de ejecutar el sistema en la plataforma. Un control de registros de productos. Una lista detallada de las cantidades de cada producto. Un código único para cada registro de producto del mismo estilo.
Adicional el grupo de proyecto de la empresa necesita validar y aprobar los siguientes elementos durante la ejecución del proyecto.
Informe de accesibilidad. Datos claros que se va realizar con el sistema. Como funciona cada herramienta del sistema.
La creación del sistema de control de inventario permitirá a la empresa un mejor ordenamiento de productos facilitando el mejoramiento del servicio a los clientes.
DEFINICIÓN DE REQUERIMIENTOS DEL PROYECTO: DESCRIPCIÓN DE REQUERIMIENTOS FUNCIONALES,
NO FUNCIONALES, DE CALIDAD, ETC., DEL PROYECTO/PRODUCTO
Requerimientos Funcionales
El sistema deberá almacenar información de los proveedores en existencia.
El sistema deberá almacenar información de los proveedores
El sistema almacenara información del cliente
Requerimientos no Funcionales
Creación de inventario diario
Rechazar accesos al momento de ingresar al sistema
Obligatoriedad de datos (al momento de ingresar algún producto, cliente, proveedor
etc.)
OBJETIVOS DEL PROYECTO: METAS HACIA LAS CUALES SE DEBE DIRIGIR EL TRABAJO DEL PROYECTO EN TÉRMINOS DE
LA TRIPLE RESTRICCIÓN. CONCEPTO OBJETIVOS CRITERIO DE ÉXITO
Alcance Cumplir con la elaboración de los siguientes: Gestión de proyecto, prueba piloto, producto terminado, demo.
Aprobación de todos los requerimientos establecidos para la creación del proyecto
Tiempo -Concluir con el proyecto en los siguientes plazos: -El sistema podrá estar terminado a más tardar para finales de mayo. -Las pruebas del sistema se irán haciendo a partir del mes marzo. - Recolección de información se dará entre febrero y marzo. -La selección del lenguaje de programación está programada en el mes de marzo. - El diseño de la interfaz será seleccionado entre marzo y abril. - Creación del demo en el mes de mayo -Pruebas del demo a finales de mayo. - Implementación del demo y finalización del sistema la segunda semana de junio.
Cumplir con lo propuesto
Costo El costo será el que acuerde con el proyecto de $2,250°°.
No exceder el costo presupuestado del proyecto.
FINALIDAD DEL PROYECTO: FIN ÚLTIMO, PROPÓSITO GENERAL, U OBJETIVO DE NIVEL SUPERIOR POR EL CUAL SE
EJECUTA EL PROYECTO. ENLACE CON PROGRAMAS, PORTAFOLIOS, O ESTRATEGIAS DE LA ORGANIZACIÓN. Con la finalidad, que la dueña del bazar, pueda realizar todos los procesamientos de una
Manera rápida y fácil, en cuanto a realizar una venta u consultar su inventario etc.
JUSTIFICACIÓN DEL P R O Y E C T O : MOTIVOS, RAZONES, O A R G U M E N T O S QUE J UST I F I CA N LA
E J E C U C I Ó N DEL PROYECTO. JUSTIFICACIÓN CUALITATIVA JUSTIFICACIÓN CUANTITATIVA Generar ingresos Flujo de
Ingresos
Facilidad de trabajo Generar unas ventas, extras por medio del Internet, creando un sitio web de compras En línea.
Ganancias
DESIGNACIÓN DEL PROJECT MANAGER DEL PROYECTO
Nombre Ulises Quintanilla Reporta A Francis Elvira Cumplimiento de las tareas, asignadas en las
diferentes áreas del sistema. Supervisa A P.H
A.H
G.M
CRONOGRAMA DE HITOS DEL PROYECTO
HITO O EVENTO SIGNIFICATIVO FECHA PROGRAMADA Inicio de proyecto 8 de febrero de 2016 Gestión del proyecto Febrero
Visualización del proyecto Febrero Análisis Mitad de febrero con iniciación de marzo Pruebas técnicas del proyecto
Abril Demo Mayo Instalación del demo Finales de mayo Proyecto terminado 2da semana de junio Fin de proyecto Junio
ORGANIZACIONES O GRUPOS ORGANIZACIONALES QUE INTERVIENEN EN EL PROYECTO
ORGANIZACIÓN O GRUPO ORGANIZACIONAL ROL QUE DESEMPEÑA Roy Zapato para caballero Picasa Zapato escolar Brendaly Sandalia para damas Patito Botitas para niñas
PRINCIPALES AMENAZAS DEL PROYECTO (RIESGOS NEGATIVOS) No cumplir con las expectativas de la empresa Diseño de interfaz modificado a última hora por nuevos procedimientos. Desastres naturales (internas) Exceder de la fecha de entrega del proyecto Amenazas económicas PRINCIPALES OPORTUNIDADES DEL PROYECTO (RIESGOS POSITIVOS)
Efectividad y eficiencia en las operaciones. Confiabilidad en la información contable. Cumplimiento de la demanda de la empresa. Evita pérdidas considerables en las ventas. Disponibilidad de productos para hacer frente a las necesidades de la empresa.
PRINCIPALES OPORTUNIDADES DEL PROYECTO (RIESGOS POSITIV
PRESUPUESTO PRELIMINAR DEL PROYECTO
CONCEPTO MONTO(US$)
1. PERSONAL Planillas de sueldos y salarios 1,200
2. MATERIALES Energía Eléctrica para las PC 350
3. VIATICOS Transporte y comida 520
4. OTROS COSTOS Varios 140 TOTAL LÍNEA BASE 2,210
5. OTROS COSTOS 200 TOTAL PRESUPUESTO 2,410
SPONSOR QUE AUTORIZA EL PROYECTO
NOMBRE EMPRESA CARGO FECHA
Francis Hernández de Pérez
Bazar Karina Presidenta 8 de febrero de 2016
CONTROL DE VERSIONES
Versión Hecha por Revisada por Aprobada por Fecha Motivo
LISTA DE - POR ROL GENERAL EN EL PROYECTO
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Sistema de Inventario y Gestión de
Mercadería Bazar Karina
SINGEMEBAK
ROL GENERAL STAKEHOLDERS
SPONSOR DIRECTORA DE PRODUCTOS NUEVOS
Francis Hernández de Pérez
COMITÉ EJECUTIVO Presidente
Francis Hernández de Pérez
Vicepresidente
Oswaldo Arquímedes Pérez
EQUIPO DE PROYECTO PROJECT MANAGER
Edgar Quintanilla
Xenia Sandoval
Angela Pérez
Maricela Pérez
GERENTES FUNCIONALES Director Legal Corporativa
Francis Hernández de Pérez
USUARIOS/CLIENTES Gerente Corporativo de Cadena de
Abastecimiento
Ángela Pérez
PROVEEDORES/ SOCIOS DE
NEGOCIOS
Proveedores de Zapatos
Roy
Brendaly
Ricarfeli
Golden
ADOC
Picasa
CONTROL DE VERSIONES
Versión Hecha por Revisada por Aprobada por Fecha Motivo
REGISTRO DE
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
IDENTIFICACIÓN EVALUACIÓN CLASIFICACIÓN
NOMBRE EMPRESA Y
PUESTO LOCALI ZACION
ROL EN EL PROYECTO
INFORMACIÓN DE CONTACTO
REQUERMIENTOS PRIMORDIALES
EXPECTATIVAS PRINCIPALES
INFLUENCIA POTENCIAL
FASE DE MAYOR INTERES
INTERNO / EXTERNO
APOYO / NEUTRAL / OPOSITOR
F.Hernandez Gerente Morazán Persona que solicita
el sistema
2654-0953 Que el sistema sea exitoso
Que el proyecto funcione correctamente.
Fuerte Todo el proyecto
Interno Apoyo
O.Perez Sub-Gerente Morazán 2da persona interesada
7896-7820 Que el sistema sea exitoso
Que el sistema cumpla con los requisitos
Fuerte Todo el proyecto
Interno Apoyo
A.Hernandez Project Manager
Morazán *Productos Nuevos *Diseño grafico
Encargada de recoger la información necesaria para el software.
Que el proyecto cumpla con las necesidades de la empresa
Fuerte Todo el proyecto
Interno Apoyo
U.Quintanilla Project Manager Chinameca
* Líder y programador *Mantenimiento de sistema y equipos
Cumplir con la finalidad del sistema
Mantener actualizado el sistema
Fuerte Todo el proyecto
Interno Apoyo
X.Sandoval Project Manager
Lolotique
*Analista *Verificador de diseño
Que el sistema
deberá almacenar
información de los
proveedores
Que el proyecto funcione correctamente.
Fuerte Todo el proyecto
Interno Apoyo
G.Perez Project Manager
Morazán *Verificador de programación *Depurador de sistema
Cumplir con mantener al día la demanda de productos
Que el sistema cumpla con los requisitos
Fuerte
Todo el proyecto
Interno Apoyo
7
Versión Hecha por Revisada por Aprobada por Fecha Motivo
ESTRATEGIA DE GESTION DE STAKEHOLDERS
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Sistema de Inventario y Gestión de
Mercadería Bazar Karina
SINGEMEBAK
STAKEHOLDER (PERSONAS O GRUPOS)
INTERES EN EL PROYECTO
EVALUACION DEL IMPACTO
ESTRATEGIA POTENCIAL PARA GANAR SOPORTE O REDUCIR OBSTÁCULOS
OBSERVACIONES Y COMENTARIOS
Comité ejecutivo: Francis de Pérez
Oswaldo Arquímedes
Que el proyecto se ejecute con éxito, agilizando los procesos de compra y venta de insumos, así como también un mejor control de inventario sobre los mismos.
Alto
Involucrar al comité ejecutivo mediante la información continua sobre la performance del proyecto.
Sponsor: Francis de Pérez
Que el proyecto se ejecute en el tiempo, costo y calidad pactados.
Muy Alto
Informar continuamente sobre la performance del proyecto, de posibles problemas que se presenten y solicitar el apoyo necesario.
Gerente funcionales: Francis de Pérez
Obtener los resultados en menor tiempo, transacciones y peticiones a fin de visualizar informes concisos y preciosos para la toma de decisiones.
Alto
Incluirlo en la planificación del proyecto y realizar reportes oportunos de la información necesaria del inventario y pedidos.
Usuarios y clientes:
Karina de Ramos
Que los elementos del proyecto sean entendibles y accesibles sin mayor inconveniente por usuarios con el fin de brindar una mejor atención a los clientes.
Medio
Informar continuamente sobre la performance del proyecto.
Angela Hernández
(Diseño gráfico,
productos nuevos)
Que el proyecto tenga un diseño gráfico e interfaz adecuado, para que el usuario pueda hacerle un uso adecuado y no le complique, y que este toda la información necesaria para la creación del sistema.
Alto Organizar reuniones con el gerente de la empresa, para recolectar información por medio de alguna entrevista, y sobre la interfaz que hayan imágenes adecuadas al tipo de sistema que estamos realizando.
Xenia Hernández
(verificador de diseño
gráfico, analista)
Que el diseño sea agradable para el sistema, observando el trabajo del diseñador y calificarlo si esta bueno o malo, y que el sistema sea terminado, con el mínimo de errores.
Alto *Informar al programador de las posibles mejores para el sistema, para así mostrar un proyecto que satisfaga las necesidades y cumpla con los requerimientos establecidos. *Verificar continuamente el diseño de sistema, para ver si el color está correcto, imágenes usadas, iconos, etc. para una interfaz satisfactoria.
Glenda Pérez
(Verificador de
programación,
depurador de sistema).
*Verificar, leer, analizar y buscar los errores que pueda tener el programa al momento de ejecutarlo así como puede detectar si hay variables que se usan sin ser definidas. *Siendo depurador tendré que captar cuales son los errores y eliminarlos examinando el código del programa y dar solución paso a paso.
Medio Tener el informe detallado de los errores y buscar una estrategia para darle solución lo más antes posible, para no extenderse con el tiempo que se ha establecido que acabaremos con el sistema,
Edgar Amaya
(programador,
mantenimiento de
sistemas y equipo)
Establecer los comandos de cómo tendrá que funcionar el sistema, de que es lo que realizara este; a fin de implantar las acciones al mismo y mantener un constante monitoreo del mismo para la verificación del buen funcionamiento y la corrección de código y revisión de equipos informáticos.
Alto Desarrollar el informe detallado de procesos acorde al reporte de requerimientos del sistema y al diseño de interfaz del sistema. Además realizar un informe detallado de los problemas y soluciones brindadas al momento de realizar el mantenimiento al equipo informático.
Proveedores: Roy
Brendaly
Ricarfeli
Golden
Adoc
Picasa
Agilizar los procesos de adquisición de materia prima (insumos) y registros de los mismos en el sistema, para un mejor control y manejo de la información de los mismos.
Medio
Que los elementos del proyecto sean claros y precisos a efecto de realizar mejores transacciones y peticiones de pedidos en la ágil transmisión de información para negociar la mejor alternativa en adquisición de bienes en tiempo y calidad.
APUNTES DE CLASE
36 errores clásicos en los proyectos de Software.
Algunas prácticas de desarrollo ineficaces han sido elegidas con tanta frecuencia, por tantas
personas, con resultados tan predecibles, mal que merecen ser llamados “Errores clásicos”. La
mayoría de los errores tienen un atractivo seductor.
Personas
Éstos son algunos de los errores clásicos relacionados con las personas.
1. Motivación débil.
Estudio tras estudio se ha mostrado que la motivación probablemente tiene mayor efecto sobre la
productividad y la calidad que ningún otro factor (Boehm, 1981).
2. Personal Mediocre
Después de la motivación la capacidad individual de los miembros del equipo, así como sus
relaciones como equipo, probablemente tienen la mayor influencia en la productividad (Boehm,
1981; Lakhanpal, 1993).
3. Empleados problemáticos incontrolados.
Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo.
Es un problema habitual, y se ha comprendido bien, al menos desde que Gerald Weinber publicó
Psychology of Computer Programming en 1971. Un fallo al tomar una decisión cuando se trata
con un empleado problemático es una de las quejas más comunes que tienen los miembros del
equipo respecto de sus responsables (Larson y LaFasto, 1989)
4. Hazañas.
Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los
proyectos (Bach, 1995). Pero lo que hacen tiene más de malo que de bueno.
5. Añadir más personal a un proyecto retrasado.
Esta es quizás el más clásico de los errores clásicos. Cuando un proyecto se alarga, añadir más
gente puede quitar más productividad a los miembros del equipo existente de la que añaden los
nuevos miembros. Fred Brooks compara añadir gente a un proyecto retrasado con echar gasolina
en un fuego (Brooks, 1975)
6. Oficinas repletas y ruidosas.
La mayoría de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias.
Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad (De-Marco y Liste,
1987).
7. Fricciones entre los clientes y los desarrolladores.
Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los
clientes puede parecerles que los desarrolladores no cooperan cuando rehúsan comprometerse
con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los
desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes
irreales o cambios en los requerimientos después de que estos hayan sido fijados.
En el caso medio, las fricciones entre clientes y desarrolladores de software llegan a ser tan
severas que ambas partes consideran la cancelación del proyecto (Jones, 1994)
8. Expectativas poco realistas.
Una de las causas más comunes de fricciones entre los desarrolladores y sus clientes o los
directivos son las expectativas poco realistas.
Una inspección de Standish Group marcó las expectativas realistas como uno de los cinco factores
principales necesarios para asegurar el éxito de los proyectos internos de software de gestión
(Standish Group, 1994)
9. Falta de un promotor efectivo del proyecto.
Para soportar muchos de los aspectos del desarrollo rápido es necesario un promotor del proyecto
de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de
nuevos métodos de desarrollo.
El consultor Australiano Rob Thomsett afirma que la falta de un promotor efectivo garantiza
virtualmente el fracaso del proyecto (Thomsett, 1995).
10. Falta de participación de los implicados.
Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el
proyecto. Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo,
personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto.
11. Falta de participación del usuario.
La inspección de Standish Group descubrió que la razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la implicación del usuario. (Standish Group, 1994)
12. Política antes que desarrollo.
Larry Constantine indico que si hay cuatro equipos hay cuatro tipos diferentes de orientaciones
políticas (Constantine, 1995).
Los políticos están especializados en la gestión, centrándose en las relaciones con sus directivos.
Los investigadores se centran en explorar y reunir información.
13. Ilusiones.
Estoy impresionado de ver cuantos problemas del desarrollo del software se deben a la ilusión. Cuántas veces hemos escuchado cosas como estas a distintas personas: “Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de acuerdo con el plan que tiene, pero piensan que quizás se trabajan duro, y nada va mal, y tienen un poco de suerte, serán capaces de concluir con éxito.”. Las Ilusiones no son solo optimismo. Realmente consisten en cerrar los ojos y esperara que todo
funciones cuando no se tienen las bases razonables para pensar que será así. Las Ilusiones al
comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una
planificación coherente y pueden ser la raíz de más problemas en el software que todas las otras
causas combinadas.
Proceso
Los errores relacionados con el proceso ralentizan a los proyectos por que malgastan el talento y el esfuerzo del personal. A continuación se muestran de los peores errores relacionados con el proceso.
14. Planificación excesivamente optimista.
Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el
alcance del proyecto, minando la planificación efectiva y reduciendo las actividades críticas para el
desarrollo, como análisis de requerimientos o el diseño.
También supone una excesiva presión para los desarrolladores, quienes a largo plazo se ven
afectados en su moral y su productividad.
15. Gestión de riesgos insuficientes.
Si no ejercemos una gestión activa de los riesgos, con que solo vaya mal una cosa se pasara de
tener un proyecto con un desarrollo rápido a uno con un desarrollo lento. El fallo de no gestionar
uno solo de estos riesgos es un error clásico.
16. Fallos de los contratados
Las empresas a veces contratan la realización de partes de un proyecto cuando tienen demasiada
prisa para hacer el trabajo en casa. Pero los contratados frecuentemente entregan su trabajo
tarde, con una calidad inaceptable o que falla al no coincidir con la especificación (Bohem, 1989).
El problema no está en el abandono del plan, sino más bien en fallar al no crear un plan
alternativo, y caer entonces en el modo de trabajo de codificar y corregir.
17. Planificación insuficiente.
Si no planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo.
18. Abandono de la planificación bajo presión.
Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con
un problema en la planificación (Humphrey, 1989).
El problema no está en el abandono del plan, sino más bien en fallar al no crear un plan
alternativo, y caer entonces en el modo de trabajo de codificar y corregir.
19. Pérdida de tiempo en el inicio difuso.
El inicio difuso es el tiempo que trascurre antes de que comience el proyecto; este tiempo
normalmente se pierde en el proceso de aprobar y hacer el presupuesto.
20. Escatimar en las actividades iniciales
Los proyectos que se aceleran intentando acortar las actividades no esenciales, y puesto que el
análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los
candidatos fáciles.
21. Diseño inadecuado.
Un caso especial de escatimar en las actividades iniciales es el diseño inadecuado. Proyectos
acelerados generan un diseño indeterminado, no asignando suficiente tiempo para él y originando
un entorno de alta presión que hace difícil la posibilidad de considerar alternativas en el diseño.
22. Escatimar en el control de calidad.
En los proyectos que se hacen con prisa se suele cortar por lo sano, eliminando las revisiones del diseño y del código, eliminando la planificación de las pruebas y realizando solo pruebas superficiales. Acortar en un día las actividades de control de calidad al comienzo del proyecto probablemente
supondrá de 3 a 10 días de actividades finales (Jones, 1994). Esta reducción va contra la velocidad
de desarrollo.
23. Control insuficiente de la directiva
Poco control de la directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los
pocos controles definidos al comienzo se abandonan cuando el proyecto comenzó a tener
problemas. Antes de encarrilar un proyecto, en primer lugar debemos ser capaces de decir si va
por buen camino.
24. convergencia prematura o excesivamente frecuente.
Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el
producto para la entrega, mejorar el rendimiento del producto, imprimir la documentación final,
incorporar entradas en el sistemas final de ayuda, pulir el programa de instalación, eliminar las
funciones que no van a estar listas a tiempo y demás.
25. Omitir tareas necesarias en la estimación.
Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos
visibles, pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de
desarrollo en un %20 o %30 (Van Genuchten, 1991).
26. Planificar ponerse al día más adelante.
Un tipo de estimación es responder inapropiadamente al retraso del plan. Si hemos trabajado en
un proyecto durante 6 meses, y hemos empleado tres meses en llegar al hito correspondiente a
los dos meses, ¿Qué hacer? En muchos proyectos simplemente se plantea recupera el retraso más
tarde, pero nunca se hace.
Otro tipo de error en la reestimación se debe a cambios en el producto. Si el producto que
estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiara
también.
27. Programación a destajo.
Algunas organizaciones creen que la codificación rápida, libre, tal como salga, es el camino hacia el
desarrollo rápido. Piensan que si los desarrolladores están lo suficientemente motivados, pueden
solventar cualquier obstáculo.
Producto
A continuación se muestran los errores clásicos relacionados con la forma en la que se define el producto.
28. Exceso de Requerimientos.
Algunos proyectos tienen más requerimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo que es necesario, y puede generar una planificación del software innecesariamente larga.
29. Cambio de las prestaciones.
Incluso si hemos evitado con éxito los requerimientos excesivos, los proyectos sufren como media
sobre un %25 de cambios en los requerimientos a lo largo de su vida (Jones, 1994).
Un cambio de este calibre puede producir un aumento en el plan de al menos %25, lo que puede
ser fatal para los proyectos de desarrollo rápido.
30. Desarrolladores meticulosos.
Los desarrolladores encuentran fascinante la nueva tecnología, y a veces están ansiosos por
probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementación de
una utilidad bonita que han visto en otro producto, la necesite o no su producto. El esfuerzo
requerido para diseñar, implementar, probar, documentar o mantener estas prestaciones
innecesarias alarga el plan.
31. Tiras y aflojas en la negociación.
Cuando un directivo aprueba un retraso en el plan e un proyecto que progresa más lento de lo
esperado, y entonces añade tareas completamente nuevas después de un cambio en el plan, se
produce una situación curiosa. La razón subyacente de esto es difícil de localizar, puesto que el
directivo que aprueba el retraso en el plan lo hace sabiendo implícitamente que el plan estaba
equivocado. Pero una vez que se corrige, la misma persona realiza acciones explicitas para volver a
equivocarse. Esto solo puede ir en contra del plan.
32. Desarrollo orientado a la investigación.
Seymour Cray, el diseñador de los supercomputadores Cray, dijo que no intentaba sobrepasar los límites de la ingeniería en más de dos áreas a la vez, porque el riesgo de fallo es demasiado alto (Gilb, 1988). Si el proyecto fuerza los límites de la informática por que necesita la creación de nuevos
algoritmos o de nuevas técnicas de computación, no estamos desarrollando software; estamos
investigando en software. Los planes de desarrollo de software son razonablemente predecibles;
los planes en la investigación sobre software ni siquiera son predecibles teóricamente.
Tecnología
El resto de los errores clásicos están relacionados con el uso correcto o incorrecto de la tecnología moderna.
33. Síndrome de la panacea.
Cuando un equipo de proyecto se aferra solo a una nueva técnica, una nueva tecnología o un proceso rígido, y espera resolver con ello sus problemas de planificación, esta inevitablemente equivocado (Jones, 1994)
34. Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos.
Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuantas
nuevas herramientas o métodos empleen o lo buenos que sean. Los beneficios de las nuevas
técnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y
aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su tiempo.
Un caso especial de sobreestimaciones de las mejoras se produce cuando se reutiliza código de
proyectos anteriores. Este tipo de reutilización puede ser una técnica muy efectiva, pero el tiempo
que se gana no es tan grande como se espera.
35. Cambiar de herramientas a mitad del proyecto.
Es un viejo recurso que funciona raramente. A veces puede tener sentido actualizar
incrementalmente dentro de la misma línea de productos, de la versión 3 a la 3.1 o incluso a la 4.
Pero cuando estamos a la mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los
inevitables errores cometidos con una herramienta totalmente nueva, normalmente anulan
cualquier posible beneficio.
36. Falta de control automático del código fuente.
Un fallo en la utilización del control automático del código fuente expone a los proyectos a riesgos
innecesarios. Sin él, si dos desarrolladores están trabajando en la misma parte del programa,
deben coordinar su trabajo manualmente. Deberían ponerse de acuerdo para poner la última
versión de cada archivo en el directorio maestro y verificarlos con los demás antes de copiarlas en
este directorio. Pero invariablemente alguno sobrescribirá el trabajo del otro.
Se desarrolla nuevo código con interfaces desfasadas, y después se tiene que re-diseñar el código
al descubrir que se ha utilizado una versión equivocada de la interfaz. Como media, los cambios en
el código fuente suelen ser de un %10 al mes y con un control manual del código fuente no
deberían crecer.
Fuentes | Fragment of “Rapid development”. Author: Steve McConn
Cómo gestionar proyectos exitosos
Con las herramientas que provee la administración de proyectos, se puede proporcionar la
estructura, la flexibilidad y el control necesario para que los miembros de un equipo puedan
alcanzar resultados extraordinarios a tiempo y dentro del presupuesto.
as empresas necesitan a menudo desarrollar proyectos que requieren estructuras y
tratamientos distintos a los tradicionales. Estos proyectos, con sus limitaciones de
recursos y tiempos, requieren de la participación de ejecutivos con diversas
competencias, procedentes de distintas áreas de la
Organización, lo cual genera situaciones y conflictos no habituales.
En este artículo se tratarán algunos temas de administración de proyectos, a los fines de
identificar las causas del éxito y el fracaso de los mismos.
La administración de proyectos
La administración de proyectos es la aplicación de conocimiento, habilidades, herramientas y
técnicas a las actividades necesarias para alcanzar los objetivos del proyecto.
Las herramientas de administración de proyectos sirven para proporcionar la estructura, la
flexibilidad y el control necesario a los miembros del equipo de trabajo para alcanzar resultados
extraordinarios a tiempo y dentro del presupuesto.
Además, debemos mencionar que la administración eficiente de un proyecto implica la utilización
de procesos de gestión específicos para cada una de las etapas del mismo: inicio, planificación,
ejecución, control y cierre.
Iniciación
Planeamiento
Control
Ejecución
Cierre
L
Una buena administración de
proyectos ahorra recursos y
Facilita la entrega del producto
final en tiempo y forma.
¿Qué se entiende por proyecto ‘exitoso’?
Si bien las técnicas de administración de proyectos se utilizan desde hace varios siglos, el auge y
desarrollo de herramientas específicas comenzó a profundizarse a partir de 1960.
Entre 1960 y 1985 se definía al éxito de un proyecto sólo en base a su calidad. O sea, un proyecto
que cumpliera con los objetivos de calidad preestablecidos se lo definía como exitoso.
Luego, entre 1985 y 1993, se define un proyecto como exitoso cuando, además de cumplir con la calidad, cumplía con los plazos y presupuesto definidos en el plan del proyecto.
Como si esto fuera poco, en la actualidad, no alcanza con cumplir la calidad, plazos y presupuesto
para el éxito de un proyecto. Sino, que además de estos objetivos mínimos, es necesario que el
proyecto cumpla con la ‘satisfacción del cliente’. ¿De qué serviría un proyecto de una calidad
excepcional, que se finalizó en el plazo previsto utilizando los recursos preestablecidos, si luego,
nadie compra los productos de ese emprendimiento?
Por ende, hasta nuestros días, para que un proyecto sea exitoso debe cumplir con todos estos
requisitos:
a) Calidad
b) Plazos
c) Presupuesto
d) Aceptación del cliente
Contexto del proyecto
Las herramientas de administración de proyectos no han sido desarrolladas sólo para países
desarrollados, sino que por el contrario éstas técnicas son aplicables en todo contexto y para todo
tipo de empresa o emprendimiento.
Entre algunas de las características básicas en que hoy se encuentran enmarcados casi todos los
proyectos, se pueden mencionar:
a) Cambios constantes de las condiciones económico-sociales
b) Cambios consecuentes en el mercado
c) Creciente avance tecnológico y costos decrecientes
d) Información amplia y accesible
e) Globalización
f) Intensa competencia en todos los ámbitos.
g) Cada vez es más difícil posicionar nuestros proyectos.
Resumiendo, en la actualidad todos los proyectos actuales se encuentran inmersos en un mundo
de permanentes cambios, cambios y más cambios.
Los proyectos y las crisis
Generalmente, la hipótesis que se plantea es que en un mercado en crisis y de cambios profundos
no se puede ser exitoso. Para evaluar este planteo es válido recurrir a un buen ejemplo de crisis
económica: el caso argentino.
Las grandes escuelas de negocio internacionales están debatiendo si el caso argentino fue o no la
peor crisis del mundo. Como buen argentino, que siempre quiere ser el mejor de todos,
supongamos por un momento que la Argentina sí ganó el campeonato mundial de crisis.
Pero, ¿qué pasó? ¿Cómo un país ‘estrella’ pasó a la peor crisis del mundo de manera vertiginosa?
220.000
230.000
240.000
250.000
260.000
270.000
280.000
290.000
300.000
I 98 II III IV I 99 II III IV I 00 II III IV I 01 II III IV I 02 II III IV I 03 (e)
La súper Economía de
1998 La economía De la Rua
La caída del 2° Sem. 01
La hecatombe
Hoy
NIVEL DE PBI (Trimestral desestacionalizado)
1998 Caída del 18% 2002 => Vs
Hay varios motivos que llevaron a la Argentina a ese colapso, pero dado que ese análisis no es el
motivo de este artículo, sólo se mencionarán las causas económicas que se consideran más
importantes:
a) El régimen de convertibilidad fue útil para enfrentar shocks financieros (crisis del tequila, asiática y rusa), pero nunca pudo adaptarse a la devaluación del real brasileño y a la caída de los precios agrícolas.
b) La deflación interna no fue suficiente para solventar la caída de competitividad.
c) La rigidez monetaria y cambiaria requería una fortaleza fiscal que no se logró y el endeudamiento del sector público abrió riesgos de default.
d) La situación política post diciembre de 1999 abrió un nuevo frente de crisis.
e) La crisis bancaria y la fuga de capitales de 2001 precipitaron la crisis.
Estos problemas terminaron en un triple final caótico a fines del año 2001:
a) Default de la deuda pública
b) Colapso del sistema financiero (corralito)
c) Devaluación y pesificación asimétrica de contratos en dólares
Como resultado de esta hecatombe se puede mencionar que:
a) Entre 1998 y 2002 la caída del producto bruto interno (PBI) fue del 18%
b) El PBI retrocedió 9 años
c) El consumo y las importaciones retrocedieron 10 años
d) La inversión retrocedió 12 años
e) El poder adquisitivo, en base a la canasta de alimentos, empeoró un 42%
f) La pobreza aumentó de un 35% a un 54%
Hecha esta explicación de una de las peores crisis de la historia, volvamos a la pregunta inicial:
¿Hubo algún proyecto exitoso en Argentina en medio de tanta crisis?
Durante este período obviamente existieron muchos fracasos de proyectos, ya que hay una
correlación directa entre crisis y fracaso. Sin embargo, algunos proyectos sobrevivieron. Más aun;
varios proyectos nacieron y se desarrollaron exitosamente en medio de la crisis.
Entre algunos casos de proyectos exitosos en plena crisis se pueden mencionar:
a) Exportadores
b) Sustitución de importaciones
c) Turismo
d) Negocios de intermediación financieras con las cuasi-monedas
e) Recursos de amparo judicial para rescatar el dinero del corralito
f) Nacimiento de otras pymes: educación, automatización, etc.
En concreto, se puede afirmar que si tantos proyectos fueron exitosos en la peor crisis de la
historia, seguramente sus proyectos también podrán ser exitosos. ¡Manos a la obra!
Algunas coincidencias
Si bien cada proyecto se caracteriza por ser único y temporal, hay algunas coincidencias en los que
fueron exitosos:
a) Definieron una visión-misión
b) Fijaron objetivos (claros, medibles, transferibles)
c) Implementaron una estrategia
d) Se supieron adaptar al cambio permanente
e) Tuvieron una administración eficiente
Definir el problema
Plan Estratégico
Misión Objetivos
Metas
Fracasos de proyectos
Se puede lograr el éxito del proyecto estudiando e implementando herramientas de
administración eficiente o estudiando las causas de fracasos, para evitarlas.
Se estima que en Estados Unidos aproximadamente existe un 17% de proyectos exitosos. El otro
83% está formado por proyectos que no cumplieron sus objetivos iniciales (plazo, costo, calidad,
satisfacción del cliente) o por proyectos que nunca se implementaron y fueron cancelados. Estos
proyectos que fracasan originan pérdidas superiores a los 80.000 millones de dólares anuales.
Una de las principales razones del fracaso de proyectos se debe a una mala planificación. Algunos
de los problemas típicos que se cometen al planificar son:
a) No incluir todos los recursos necesarios para cumplir con los objetivos del proyecto
b) No dar participación en la elaboración del plan a las personas responsables de implementar esas tareas
c) Objetivos o agendas irreales al no comprender la ‘restricción triple’
La restricción triple
Las tareas definidas dentro del alcance del proyecto tienen tres restricciones básicas: tiempo,
recursos y calidad. Estas restricciones en su conjunto es lo que se denomina la restricción triple del
proyecto.
El administrador de proyectos se enfrenta al conflicto de manejar los intereses contrapuestos de
cuatro variables: alcance, tiempo, recursos y calidad. Sólo tres de éstas variables podrán fijarse a la
vez.
Si el cliente solicita cierto alcance de las tareas a cubrir con el proyecto, bajo una calidad
predeterminada y en cierto plazo, la variable de ajuste será la cantidad de recursos necesarios
para hacer el proyecto, incluyendo no sólo los recursos monetarios, sino también los recursos
materiales y humanos.
El proyecto estará destinado al fracaso
si alguien fija arbitrariamente el
alcance, tiempo, recursos y calidad.
CALIDAD
T I E M P O S
C O S T O S
ALCANCE
Si las restricciones están dadas en cuanto a tiempo, recursos disponibles y estándares de calidad,
el administrador del proyecto sólo podrá negociar con los stakeholders la magnitud del alcance
para poder cumplir con los objetivos en tiempo, forma y dentro del presupuesto. Por ejemplo, un
proyecto de construcción de un edificio cuyo alcance inicial era de 20 pisos, podrá verse reducido
a sólo 10 pisos para poder cumplir con la restricción triple.
Si a un miembro del equipo le fijan las horas de trabajo, el alcance de las tareas y la fecha de
entrega, la variable de ajuste automática de esta persona será la calidad del trabajo.
Por último, si el alcance, calidad y recursos disponibles están predeterminados para un proyecto,
el factor tiempo será la variable de ajuste.
Más rápido, más barato y mejor
Teniendo en cuenta las cuatro variables mencionadas, sólo tres de ellas podrán ser fijadas en
forma exógena y la cuarta variable será determinada en forma endógena en función de la
magnitud de las otras tres.
Un caso típico es que el inversor exija que cierto alcance del proyecto sea finalizado “ayer”, con el
presupuesto más barato y con altos estándares de calidad. En estos casos, el contratista del
proyecto generalmente deberá negociar el alcance de las tareas a realizar.
Si el inversor insiste en que el proyecto debe realizarse bajo las pautas que él exige, seguramente
estamos frente a un potencial caso de fracaso de proyecto.
Dada la escala del proyecto, uno de los grandes desafíos del administrador de proyectos es buscar
permanentemente la eficiencia en el manejo de la restricción triple. Dictar en forma arbitraria
todas las variables, seguramente será la receta perfecta para el fracaso del proyecto. Sin embargo,
las técnicas de administración de proyectos apuntan a que los administradores puedan lograr el
paradigma “más rápido, más barato y mejor”.
Otras causas de fracaso
Además de comenzar con el pie izquierdo con una mala planificación del proyecto, otras causas
típicas de fracaso son:
a) El rol del administrador del proyecto no está bien definido
b) Falta de comunicación y coordinación para trabajar en equipo
c) Rotación excesiva de personas en las actividades de trabajo. Menor especialización d) Controles inapropiados
e) No realizar informes de avance periódico
f) El administrador del proyecto pierde la visión de conjunto controlando detalles minuciosos
g) No comparar el estado del proyecto con el plan original
h) No planificar la administración de los riesgos potenciales
Áreas del conocimiento
Para poder implementar una adecuada administración del proyecto es necesario trabajar sobre
nueve áreas básicas: alcance, tiempos, costos, calidad, recursos humanos, comunicación, riesgos,
abastecimiento e integración total.
Las técnicas modernas de administración de proyectos han desarrollado procesos específicos para
cada una de estas áreas. Cada una requiere insumos específicos; luego se aplican herramientas
estandarizadas para cada caso en particular, y con ello aumentan las chances de obtener
resultados exitosos en el proyecto.
Algunas herramientas
Una de las herramientas básicas de todo proyecto es comenzar con lo que se denomina la
estructura de división del trabajo. Esto es descomprimir el proyecto en sub-proyectos a los fines
de mejorar el proceso de planificación, presupuestario y control. Existe software muy simple de
utilizar que hoy en día nos facilitan este proceso.
En el gráfico a continuación se muestra la estructura de división del trabajo de un proyecto
agrícola.
Recursos Humanos
Comunicación Abastecimiento Riesgos
Alcance Visión Integral
Calidad Costos Tiempos
ADMINISTRACION DE PROYECTOS
Por otro lado, una vez que se tiene el plan del proyecto, es fundamental distinguir cuáles son las
actividades críticas. O sea, cuáles son aquellas actividades que en caso de retrasarse o adelantarse
pueden retrasar o adelantar todo el proyecto.
Generalmente, los proyectos tienen cientos de actividades para llevar a cabo y sólo algunas de
ellas son críticas. El software de administración de proyectos también nos simplifica la vida con un
simple clic en el mouse para identificar las actividades críticas.
Si quiere asegurar los plazos de
ejecución, concéntrese en las
actividades críticas.
Una herramienta adicional que nos ayuda a lograr proyectos exitosos es realizar una
Un error típico de mala asignación es suponer que algunos miembros del equipo de trabajo tienen
cuatro brazos y dos cabezas, que el día tiene 48 horas o que una máquina podrá utilizarse en cinco
proyectos simultáneamente.
Para evitar estas utopías, también podemos pedir ayuda a los software, los que nos van a recordar
permanentemente que todo proyecto tiene una restricción triple. Por ejemplo, en el gráfico a
continuación, el software nos indica qué miembros del equipo de trabajo están sobre-asignados.
En caso de no modificar el plan para evitar sobreasignaciones, el proyecto va camino al fracaso.
Eficiente asignación de recursos.
Gestión tradicional vs. Gestión eficiente
Para finalizar, se exhibe una tabla para evaluar si sus proyectos están más cercanos del esquema
tradicional de gestión o se aproximan a los procesos de administración de proyectos eficientes.
GESTION TRADICIONAL GESTION EFICIENTE
Improvisación e intuición Prevención, orden, estrategias y procedimientos
Proyecto unipersonal Integración del equipo de trabajo creando compromiso de los
involucrados
Duplicación u omisión de recursos y
funciones
Distribución eficiente de recursos, roles y funciones
Alto nivel de desgaste Calidad de vida
Los cierres del proyecto se llevan a la
memoria
Los cierres del proyecto se documentan para capitalizar sobre
las lecciones aprendidas
Los cambios no se documentan, son
verbales y sin control
Se implementa un sistema de control de cambios global
No se identifican los riesgos Se identifican los riesgos y se planifican las planes de
respuesta
Calidad deficiente Mejoras en los procesos de calidad
Proyecto fuera de plazos Cambios de plazos predecibles
Proyecto fuera de presupuesto Proyecto dentro del presupuesto. Ahorro de costos debido al
control de gestión.
Por último, si usted cree que las herramientas de administración eficiente de proyectos son sólo
aplicables para grandes empresas multinacionales, se equivoca... “Todas las grandes firmas
en sus comienzos fueron pequeñas”
Por Pablo Lledó
Master of Science in Project Analysis, Finance and Investment (University of York, Inglaterra)
Project Management Professional (PMP certified by the PMI) Profesor de Evaluación de Proyectos y Project Management de ADEN Profesor de la Universidad de California, Irvine Extension.
Licenciado en Economía (Universidad Nacional de Cuyo)
Socio fundador de MasConsulting
GUIAS DE LABORATORIO RESUELTAS
Carpeta técnica, y existen otros tipos de plantillas que utilizamos, entre otras
están:
Ejemplo de Fase de Planificación Parte 1
Formato de Actas para Reuniones del Proyecto
Formato de Actas para Reuniones del Proyecto
Ejemplo de Fase 2 de Planificación Parte 3
Formato de Fase 3 del Proyecto Ejecución
Fase 4 Formato de Control de Gestión de Proyectos Informáticos
Fase 5 de Cierre del Proyecto Formato