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.

MAPAS MENTALES

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]

mailto:[email protected]




CONTROLES DE VERSIONES

CONTROL DE VERSIONES Versión Hecha por Revisada por Aprobada por Fecha Motivo

PROJECT


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




SINGEMEBAK

ROL GENERAL STAKEHOLDERS

SPONSOR DIRECTORA DE PRODUCTOS NUEVOS


COMITÉ EJECUTIVO Presidente


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


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


REGISTRO DE


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


Interno Apoyo

A.Hernandez Project Manager

Morazán *Productos Nuevos *Diseño grafico

[email protected]

Encargada de recoger la información necesaria para el software.

Que el proyecto cumpla con las necesidades de la empresa


Interno Apoyo

U.Quintanilla Project Manager Chinameca

* Líder y programador *Mantenimiento de sistema y equipos

[email protected]

Cumplir con la finalidad del sistema

Mantener actualizado el sistema


Interno Apoyo

X.Sandoval Project Manager

Lolotique

*Analista *Verificador de diseño

[email protected]

Que el sistema

deberá almacenar

información de los

proveedores

Que el proyecto funcione correctamente.


Interno Apoyo











G.Perez Project Manager

Morazán *Verificador de programación *Depurador de sistema

[email protected]

Cumplir con mantener al día la demanda de productos

Que el sistema cumpla con los requisitos

Fuerte

Todo el proyecto

Interno Apoyo

7





ESTRATEGIA DE GESTION DE STAKEHOLDERS




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.

COMPROBACION DE RESPUESTAS SEGÚN LA FORMULA

BOSETOS

CALENDARIZACION

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

Evidencia de parcial de errores clásicos.

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

Portafolio de Gestion

Documents

Transcript of Portafolio de Gestion