Pueden existir algunas limitaciones al planear un proyecto ya sean internas, por ejemplo: computadoras disponibles, capacidad del personal, disposiciones presupuestarias, o bien externas, como ser: fechas de entrega de cualquier tipo de recursos, factores climáticos, aprobaciones de organismos oficiales. Es lo que estábamos diciendo la anterior vez al momento de crear un proyecto, pero ahora exploraremos algo más que crear un proyecto, ahora veremos con es que se debe de gestionar un proyecto. Bienvenido nuevamente a los estudios de investigación que he preparado para que te puedan ser de utlidad a la hora de gestionar tu proyecto.

Algunas consideraciones que debe de saber

1. Defina el alcance y los objetivos del proyecto.

El alcance o área de competencia define los límites del proyecto. Decidir que es lo que está dentro o fuera de los límites del proyecto determinará la cantidad de trabajo que se necesitará realizar.

2. Defina las tareas

Debe definir que tareas se esperan del proyecto. Si por ejemplo su proyecto es una campaña publicitaria para una nueva barra de chocolate, entonces una tarea sería producir el trabajo de arte para la publicidad. Por eso defina que cosas tangibles deben ser producidas y documéntelas con suficiente detalle para que cualquiera de los involucrados pueda llevarla a cabo correcta y eficientemente.

3. Planifique el proyecto

Planificar requiere que el gerente de proyecto decida qué gente, recursos y presupuestos se requieren para completar el mismo. Debe definir que actividades se requieren para producir los productos, utilizando técnicas tales como Estructura Analítica de Proyectos (Work Breakdown Structures -WBS; en el gerenciamiento de proyectos el WBS es una técnica que consiste en la descomposición del proyecto en partes manejables). Además debe estimar los tiempos y los esfuerzos requeridos para cada actividad, las dependencias entre actividades y luego decidir un programa realista para completarlas. Involucre al equipo de proyecto en la estimación de la duración de las actividades. Establezca hitos que indiquen fechas críticas durante el desarrollo del proyecto. Escríbalas en su planificación.

4. Comunicación

La planificación del proyecto resulta inútil si no es comunicada efectivamente al equipo del proyecto. Cada miembro del equipo necesita conocer sus responsabilidades. Lee esta historia:

“Una vez trabajé en un proyecto en donde el project manager (director del proyecto) se quedó sentado en su escritorio rodeado de un enorme cronograma. El problema fue que nadie en ese equipo sabía cuales eran las tareas y las fechas tope, pues nadie había compartido la planificación. El proyecto sufrió todo tipo de problemas porque la gente hacía actividades que pensaban que eran importantes en vez de hacer las que el director de proyecto les había asignado.”

5. Seguimiento y reporte de avance del proyecto

Una vez que el proyecto esté en ejecución debe ser monitoreado y comparado el progreso actual con el proyectado. Necesitará reportes de avance de proyecto que deberán producir los miembros del equipo. Deberá registrar las variaciones entre lo real y lo proyectado, tanto en lo referente a costos como a cronograma y al alcance. Deberá reportar las variaciones a su superior y a los accionistas claves para poder tomar acciones correctivas antes de que esos desfasajes sean demasiado grandes.

Puede ajustar el plan de muchas maneras para volver a poner la planificación en el camino trazado pero siempre terminará equilibrando costos, cronograma de tareas y alcances. Si el director de proyecto cambia una de estas, entonces uno o los dos elementos restantes deberán inevitablemente ajustarse de forma acorde. Es justamente el balance de estos tres elementos -conocidos como el triángulo del proyecto- lo que típicamente causa los mayores dolores de cabeza al director de proyecto.

6. Gestión del cambio

Los accionistas o clientes a menudo cambian de parecer en lo que respecta a las áreas de cada proyecto. A veces cambia el entorno de negocio en medio del desarrollo, y los supuestos que se hicieron al comenzar no siempre siguen siendo válidos. Esto a veces implica que el cronograma o las tareas deban ser cambiados. Si el director del proyecto acepta todos los cambios, muy probablemente el proyecto se saldrá de presupuesto, se atrasará y hasta podría no terminarse.

Administrando los cambios, el líder de proyecto puede tomar decisiones sobre si incorporar o no los cambios inmediatamente o en el futuro, o directamente rechazarlos. Esto aumenta las posibilidades de que el proyecto sea exitoso porque el director del proyecto controla la forma en que esos cambios son incorporados, puede disponer nuevos recursos acordes al cambio y puede planificar cuando y como se harán los mismos. Una de las razones por lo que a veces fracasan los proyectos es por la imposibilidad de gestionar los cambios eficientemente.

7. Gestión del riesgo

Los riesgos son eventos que pueden afectar negativamente su proyecto. Alguno dijo por ahi:

“He trabajado en proyectos en lo que los riegos incluyeron: un plantel laboral que no tenía las habilidades técnicas requeridas para realizar el trabajo, la falta de entrega a tiempo de hardware u otros equipos, una sala de control con riesgo de inundación y muchos otros.”

Los riesgos varían con cada proyecto pero se debe identificar lo antes posible los riesgos del proyecto en particular. Se debe planificar para evitar los riesgos o, si los riesgos no pueden ser evitados, para mitigar su impacto en el proyecto en caso de que efectivamente ocurra. Esto se conoce como gestión del riego (risk management).  No controlas todos los riesgos, lo sé, porque estos pueden ser muchos y no todos tienen el mismo impacto. Entonces, identifique todos los riesgos, estime las probabilidades de que ocurran cada uno de la siguiente manera:

• 1= no probable;
• 2= posible;
• 3= muy probable.

Luego estime su impacto en el proyecto

• 1= bajo;
• 2= medio;
• 3= alto.

Luego multiplique ambos números para tener un factor de riesgo. Los factores de riego alto indican los riesgos más severos y, por lo tanto, las situaciones más problemáticas. Gestione las 10 estimaciones con los mayores factores de riesgo. Revise constantemente los riesgos y esté alerta por nuevos que pudieran surgir pues tienen la manía de aparecer cuando menos los esperamos.

No gestionar los riesgos eficientemente es otra de las causas frecuentes de fracaso en los proyectos.

Gerencia de Proyectos

Podemos definir la gerencia de proyectos como el arte de dirigir y coordinar recursos humanos y materiales durante la vida de un proyecto mediante el uso de técnicas modernas de administración y para alcanzar objetivos predeterminados de cubrimiento, costo, tiempo,  calidad y satisfacción de todos los participantes (PMI). Es, por tanto, la aplicación del conocimiento, herramientas y técnicas a las actividades del proyecto para satisfacer o exceder las necesidades y expectativas de los participantes.

La gerencia de proyectos es un conjunto de actividades pertenecientes a un proceso administrativo, cuyos componentes principales son los siguientes.

Planeación: Qué vamos a hacer y por qué?

En el hecho de respondernos esta pregunta ya estaremos dándo solución a la misión, los objetivos, las metas y estrategias del proyecto.

Organización: Qué elementos están involucrados y por qué?

Debemos de definir:

• Estructura organizacional del equipo del proyecto
• Identificar y asignar las funciones a cada miembro del equipo
• Definir políticas, procedimientos y técnicas de la gerencia
• Establecer normas de autoridad, responsabilidad y auditoría del proyecto

Motivación: Qué motiva a las persona para ejecutar su trabajo lo mejor posible?.

Un aspecto importante a tomar en cuenta en el desenvolvimiento y desarrollo de un proyecto es la motivación de las personas, para esto es importante tomar los siguientes aspectos:

• Determinar necesidades del equipo del proyecto
• Adquirir elementos de motivación
• Proveer de asesoramiento a los miembros del equipo según se requiera
• Establecer los programas de incentivos a los miembros
• Hacer estudio inicial del impacto y la motivación en la productividad

Dirección: Quién decide qué y cuándo?.

Un barco sin timón navega a la deriva en el mar y es llevado por las olas a su gusto y gana; en un proyecto siempre es vital que haya un director, algún encargado de coordinar actividades y controlar el progreso de las mismas, debe ser una persona con cualidades idóneas no necesariamente con grandes conocimientos, sino apta para expresarse y dar a entender en dialecto humano lo que se quiere hacer y cuándo se lo debe de hacer. Algunas de las tareas de un director son:

• Establecer límites de autoridad en la toma de decisiones sobre asignación de recursos
• Desarrollar estilos de liderazgo
• Mejorar habilidades interpersonales
• Planear técnicas de participación administrativa
• Implantar técnicas de toma de decisiones mediante consenso.

Control: Quién juzga los resultados y mediante cuáles estándares?.

Algunas veces poner juicio a tareas que se vienen desenvolviendo suele ser dificil de decirlas por temor a hacer sentir menospreciado a quién lo hizo; pero sucede que esto suele ser fácil de controlarlo si se cumple con lo siguiente:

• Establecer estándares de costo, programación y técnicos
• Planear los medios para evaluar el progreso del proyecto
• Definir un sistema de información para el proyecto
• Preparar las estrategias para revisión del proyecto
• Evaluar el progreso del proyecto

El ciclo de vida del proyecto se define por una serie de fases que componen la conceptualización, diseño, desarrollo y puesta en funcionamiento de los resultados del proyecto. Los pasos a seguir en la organización y planeación que lleven a tener un primer plan definido se describen enseguida (sigue leendo).

Definir las metas del proyecto.

Para definir las metas, respóndase: qué planea ejecutar?. Tenga en cuenta el tamaño y tipo del proyecto y establezca metas globales reales. Investigue presupuestos y requisitos de tiempo y dinero y determine claramente el nivel de calidad requerido. Es necesario determinar la prioridad entre dinero y calidad como concepto “manejador” del proyecto.

Establezca metas que puedan ser cuantificadas. Es muy difícil asegurar el rendimiento de un proyecto cuyas metas son vagas o no medibles. Y cuando estén definidas sus metas y prioridades, obtenga la aprobación del staff administrativo, si es necesario, e involúcrelo con el proyecto lo más temprano posible para que pueda proceder con seguridad, sabiendo que su trabajo está soportando objetivos ya acordados.

Desarrollar la estrategia de administración.

Defina qué tipo de estrategia es la aplicable; por ejemplo, un pequeño proyecto puede ser manejado por una sola persona o un proyecto grande puede involucrar numerosos administradores, cada uno con una responsabilidad diferente definida para cada área o departamento.

Como administrador general de un proyecto grande, su estrategia debe garantizar que los administradores individuales entienden y aceptan sus propias responsabilidades.

Crear el plan del proyecto.

Con metas definidas y estrategia creada, está listo para definir el plan del proyecto. Prepare un esbozo general como primer paso en la organización del proyecto. Rompa el proyecto en varios niveles de detalle para proveer una buena estructura de desagregación del trabajo, con información detallada y resumida.

Existen  varias formas de ejecutar un esbozo. Generalmente el tamaño y tipo del proyecto definirán el método apropiado. Si el proyecto es grande o único, puede usar el método “top-down” que comienza en tópicos generales y pasa paulatinamente a niveles de detalle. Si el proyecto es pequeño o parecido a alguno ya ejecutado con anterioridad, posiblemente se sienta más cómodo con el método detallado, que comienza con tareas a nivel de detalle y luego las une en conjuntos más grandes.

Establecer la secuencia de tareas.

Tenga en cuenta la duración planeada para cada tarea y la secuencia en que debe realizarse, pues existen tareas que no pueden comenzar antes de que otras terminen. La especificación correcta de las duraciones y dependencias conforma la programación inicial del plan.

Definir hitos o “milestones”.

Los “hitos”  -en inglés milestones-  son puntos de verificación del proyecto, fechas que no pueden ser movidas o puntos que deben cumplirse antes de continuar. Llegar a uno de ellos significa que todas las actividades anteriores a él se han cumplido y estamos listos para comenzar una nueva serie de actividades. Coloque “hitos” reales y con intervalos cortos, que son mas fáciles de alcanzar y motivan a los participantes en el proyecto.

Asignar recursos.

Son recursos las personas, el equipo y, en general, cualquier elemento necesario para terminar el trabajo y cuya disponibilidad es limitada. Los elementos que no son limitados y que el proyecto consume se denominan insumos y hacen parte de su costo pero no tienen influencia en la duración del mismo.

LOS RECURSOS son los elementos utilizados para poder realizar la ejecución de cada una de las tareas; como por ejemplo: hardware, programas de base (sistemas operativos), programas de aplicación, discos de almacenamiento, energía, servicios, inversiones de capital, personal, información, dinero y tiempo.

Asigne recursos a las tareas individualmente. Determine la disponibilidad actual de personal y el tiempo que cada uno puede dedicar a su proyecto. Evite en lo posible asignar actividades a personas que deben ejecutar otras simultáneamente; trate de asignar el tiempo de cada persona a una actividad específica.

Haga los ajustes necesarios si encuentra que ha sobreasignado a personas o equipos.

Estimar Costos.

El siguiente paso consiste en el cálculo de costos del proyecto, a partir de los costos de cada actividad. Cuando se planifica un proyecto se tienen que obtener estimaciones del esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Algunos métodos que pueden ayudarte en este punto son:

Líneas de Código y Puntos de Función.

Los datos de líneas de código (LDC) y los puntos de función (PF) se emplean de dos formas durante la estimación del proyecto de software:

• Variables de estimación, utilizadas para calibrar cada elemento del software.
• Métricas de base, recogidas de anteriores proyectos utilizadas junto con las variables de estimación para desarrollar proyecciones de costo y esfuerzo.

Estas técnicas son diferentes pero tienen características comunes. El planificador del proyecto comienza con una declaración restringida del ámbito del software y, a partir de esa declaración, intenta descomponer el software en pequeñas subfunciones que pueden ser estimadas individualmente. Entonces, estima las LDC o PF (la variable de estimación) para cada subfunción. Luego, aplica las métricas básicas de productividad a la variable de estimación apropiada y deriva el costo y el esfuerzo para la subfunción. Combinando las estimaciones de las subfunciones se produce la estimación total para el proyecto entero. Difieren en el nivel de detalle que requiere la descomposición.

Técnicas Delfi.

Las técnicas delfi fueron desarrolladas en la corporación Rand en el año de 1948, con el fin de obtener el consenso de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica puede adaptarse a la estimación de costos de la siguiente manera:

• Un coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.
• Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar con el coordinador, pero no entre ellos.
• El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.
• Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.
• El proceso se repite varias veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso. El siguiente enfoque es una variación de la técnica Delfi tradicional que aumenta la comunicación conservando el anonimato.
• El coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.
• Cada experto estudia su definición, y el coordinador llama a una reunión del grupo con el fin de que los expertos puedan analizar los aspectos de la estimación con él y entre ellos.
• Los expertos terminan su estimación en forma anónima.
• El coordinador prepara un resumen de las estimaciones efectuadas sin incluir los razonamientos realizados por algunos de los expertos.
• El coordinador solicita una reunión del grupo para discutir los puntos donde las estimaciones varíen más.
• Los expertos efectúan una segunda ronda de estimaciones, otra vez en forma anónima. El proceso se repite tantas veces como se juzgue necesario.

COCOMO.

El Modelo Constructivo de Costos (COnstructive COst MOdel) es una jerarquía de modelos de estimación para el software. Esta jerarquía está constituida por los siguientes modelos:

• El modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.
• El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
• El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.

Los modelos COCOMO están definidos para tres tipos de proyecto de software. Modelo Orgánico: Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico). Modelo Semiacoplado: Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos). Modelo Empotrado: Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).

Las ecuaciones del modelo COCOMO básico tienen la siguiente forma: E = ab (KLDC) exp (bb) D = cb (E) exp (db) donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de desarrollo en meses cronológicos y KLDC es el número estimado de Líneas de Código distribuídas (en miles) para el proyecto.

Las ecuaciones del modelo COCOMO intermedio toma la forma: E = ai (KLDC) exp (bi) x FAE donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuídas para el proyecto.

Se han desarrollado varias técnicas de estimación para el desarrollo de software como establecer de antemano el ámbito del proyecto, usar las métricas del software (mediciones del pasado) como base para la realización de estimaciones y desglosar el proyecto en partes mas pequeñas que se estiman individualmente. Esto ayuda al programador, ya que le permite dedicar más tiempo a otras partes del proyecto.  En resumen el director del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el director debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación.

Revisar el plan

El paso final consiste en revisar el plan, buscando puntos débiles y áreas con posibles problemas y determinando las actividades críticas, que al final son las que controlarán el desarrollo del proyecto.

Para estos procesos vamos a utilizar herramientas de software que se encargarán del trabajo manual y dejarán al gerente su valioso tiempo disponible para la toma de decisiones soportadas en información confiable.

En conclusión

El seguimiento de estas mejores prácticas no puede garantizarle el éxito de su proyecto pero le dará una mejor chance de éxito. En cambio, el descuido de estas prácticas muy probablemente llevará su proyecto al fracaso.

Creo importante traer el pensamiento de Deming, quien señala y remarca muy claramente, al presentar su teoría de Calidad Total,

que el administrador de un proyecto al planificar las actividades, debe tener presente que los mejores esfuerzos constituyen un elemento esencial; pero desgraciadamente, si estos esfuerzos se toman aisladamente sin una debida orientación basada en principios administrativos, éstos esfuerzos pueden causar profundos daños.

La necesidad de la consistencia en los esfuerzos supone que si cada uno sabe lo que tiene que hacer y, que si cada uno hiciese lo mejor que puede, el resultado sería la dispersión del conocimiento y de los esfuerzos; por lo tanto, no hay nada que substituya al trabajo en equipo y a los buenos líderes, para alcanzar una consistencia entre los esfuerzos y el conocimiento necesario.

Algo importante a tener siempre presente es que: si el administrador realiza un buen trabajo en la gestión del proyecto, su éxito podrá ser visto y verificado por los demás; en caso contrario, naturalmente, el fracaso también estará a la vista de todo el mundo. La responsabilidad es muy alta: alcanzar el objetivo o no pero la oportunidad de “demostrar la capacidad profesional”, es de las que no pueden dejarse pasar por alto.

Los administradores eficaces de proyectos, son los que logran que el trabajo se ejecute a tiempo, dentro del presupuesto, y conforme a las normas de calidad especificadas.

Bibliografía Consultada

Manual de Administración de Proyectos
Gestión de Proyectos: las 7 mejores prácticas
Monografía: Técnicas de estimación de costos y esfuerzos
Escuela Superior de Informática Universidad de Castilla-La Mancha
Planificación de Proyectos de Software Autor: Pedro Concepción
Estimación del Esfuerzo de Desarrollo Autor: Marcela P. Varas C. (Depto. Ing. Informática y Cs. de la Computación Universidad de Concepción)

]]> http://www.gameplayart.com/?feed=rss2&p=36 0