Unidad I - PROYECTOS

Introducción.

En ASI I hemos visto algunos aspectos "teóricos" de la planificación de proyectoss. En este caso vamos a efectuar algunas puntualizaciones sobre la utilización de dicha teoría junto con otras consideraciones prácticas sobre el seguimiento. control y cierre de los proyectos en sistemas informáticos, teniendo en cuenta que la planificación y el seguimiento de los proyectos con diferentes tecnicas.

2.- Origen de los datos.

Sin datos (técnicos, históricos, estimaciones, etc) no es posible realizar ninguna planificación y menos su seguimiento. Aunque en los ejemplos desarrollados hasta el momento, hemos supuesto que todos los datos necesarios estaban disponibles, raramente es así en la práctica. 

 

Los datos, si existen, están dispersos y celosamente guardados por quienes se creen sus propietarios, cuyo deseo más claro es no compartirlos, a pesar de que se trata de un bien que puede cederse sin dejar de poseerlo.

 

Por dicha circunstancia empezaremos tratando de cómo puede obtener los datos, para el  equipo de planificación y seguimiento, a las ordenes del jefe de proyecto

3.-  ¿De donde obtenemos los datos para la planificación?

Los datos de partida para la realización de la planificación tienen su origen, fundamentalmente, en los elementos técnicos implicados en el desarrollo del proyecto, aunque la palabra "técnicos" debe entenderse en una aceptación muy amplia. Para la obtención de los datos es conveniente proceder de la siguiente forma:

3.1.- Procedimiento para la obtención de los datos iníciales.

 

1. Difundir información lo más completa y extensa posible sobre los objetivos, métodos, procedimientos y herramientas del equipo de planificación a todos los niveles de los entes implicados, comenzando preferentemente por los más elevados.

 

Se recurrirá a reuniones, conferencias, cursillos, folletos, manuales, demostraciones, etc. El objetivo es sensibilizar a todos los participantes y hacerles comprender los fines perseguidos.

 

2. Descomponer el proyecto en partes o subproyectos coherentes. Los criterios de descomposición más utilizables son: la funcionalidad, el tipo de tecnología involucrada en el diseño o en la construcción y la situación geográfica en la realización.

 

El organigrama técnico puede servir de guía en la descomposición. Cada parte se estudia aisladamente en detalle antes de proceder a las consideraciones finales de conjunto.

 

3. Obtener datos sobre cada una de las partes, relativos a descripción del subproyecto, su funcionalidad, actividades principales que comprende su realización, plazos de realización, problemas principales probables o posibles, etc.

 

La forma de obtener esta información es a través de la información y documentación existente relativa a otros proyectos semejantes y que sin duda habrá sido recogida en la fase de definición.

 

El objetivo es tener un nivel de conocimiento suficiente sobre el proyecto, para que las entrevistas que se celebren a continuación con los responsables de los distintos departamentos sean fructíferas, gracias al empleo de un mismo lenguaje.

 

4. Elegir una nomenclatura para la codificación de la información que va a obtenerse; en especial para decidir la codificación de las actividades. Siendo habitual el empleo de un ordenador en forma interactiva, las características del programa disponible en el mismo influirán grandemente en dicha codificación.

 

5. Celebrar entrevistas con los diferentes responsables de la construcción para recabar la información correspondiente a la descomposición en actividades, precedencias y duración.

 

En las primeras entrevistas puede centrarse el interés en las dos primeras cuestiones, a fin de evitar el efecto pernicioso que puede tener la superposición de los conceptos duración y plazo.

 

6. Establecer actas de las entrevistas, en forma muy somera, en las que se indiquen las conclusiones a que se ha llegado. De hecho estas conclusiones se pueden reflejar de dos formas:

a) Fichas de actividad. Estas fichas están destinadas a contener no sólo los datos necesarios para la planificación, sino otros auxiliares. 

b) Grafos PERT o ROY (en principio, uno por subproyecto) con indicación de las precedencias. Tampoco aquí debe tenerse la pretensión de alcanzar nunca un nivel definitivo, por lo que debe utilizarse procedimientos rápidos de elaboración y modificación de los gráficos, incluso una vía manual

Diagrama Gantt de seguimiento o simulación:

7. Difundir las actas y recoger las reacciones si no se producen espontáneamente, provocarlas.

 

8. Cuando se disponga de suficiente información realizar algunos supuestos de planificación, discutiendo los resultados con los entes implicados, con el fin de llegar a un primer conjunto de datos depurados.

4.- ¿Por que es necesario el seguimiento del proyecto?

A medida que transcurre el tiempo y va avanzando la realización del mismo van variando las estimaciones sobre las realizaciones futuras:

 

1. El conocimiento que se posee sobre estas tareas ha mejorado debido a la experiencia o al incremento de atención que les proporciona la inmediatez (que las ha transformado de un asunto importante en un asunto urgente).

 

2. Han podido variar las condiciones existentes y por consiguiente haberse decidido el empleo de un metodo diferente del inicialmente previsto, lo que repercute en definiciones y duraciones.

 

3. La marcha del proyecto obliga a secuenciar las actividades en una forma diferente a la establecida inicialmente.

 

4. Se han producido o se prevee que se producirán incidentes que han repercutido en variaciones de la duración de algunas actividades respecto a lo previsto.

Todo esto provoca que el programa base no refleje la situación real del proyecto.

4.1.-¿ Dónde obtenemos los datos para la actualización?

Los datos para la actualización se encuentran en:

1. La propia realización del proyecto.

2. Los equipos técnicos de los departamentos que intervienen en la realización.

3. En los trabajadores directos que realizan una determinada tarea

4.2.- ¿Cómo los conseguimos?

Las formas de conseguirlos son:

1. La observación directa de la realización, siempre interesante por dar un contenido físico a algo que de otra forma se quedaría en unas inscripciones en unos papeles. La información obtenida sobre el terreno puede registrarse en un estadillo ficha de obra.

 

2. Entrevistas con los responsables.

 

3. Las reuniones de seguimiento del proyecto.

5.- Comunicación del programa

Tiene mucha menos importancia confeccionar la programación, que la labor y el esfuerzo de seguimiento durante el cual se detectan los problemas, se analizan las soluciones y se toman decisiones.

 

5.1.- Documentos

 

Es conveniente que después de cada actualización y en el plazo más breve posible el equipo de planificación difunda ampliamente un documento que podemos denominar estado de la planificación.

 

5.2.- Frecuencia de la actualización

 

Es útil hacer coincidir la revisión de la programación con la emisión del documento: estado de la planificación, con las reuniones de seguimiento del proyecto.

ESTADO DE LA PLANIFICACIÓN

0.- Numero de documento y fechas de emisión y datos

1.- Situación actual

   1.1.- Actividades (importantes) terminadas desde el documento anterior

   1.2.- Actividades iniciadas

   1.3.- Actividades que continúan

   1.4.- Problemas (relevantes) encontrados

   1.5.- Desviaciones (relevantes) producidas, sus causas y líneas de solución adoptadas

2.- Previsiones para el plazo inmediato

   2.1.- Etapas a alcanzar dentro de un horizonte cercano (antes de la próxima revisión)

   2.2.- Posibles problemas y soluciones. Actividades criticas y subcriticas

   2.3.- Modificaciones de la planificación

3.- Previsiones a largo plazo

   3.1.- Estimación de la fecha de realización de las etapas características

   3.2.- Desviaciones respecto a la planificación anterior

4.- Estimación cualitativa del responsable de la planificación (si no es posible obtener la del jefe del proyecto) fundada en los aspectos cuantitativos anteriores y otra información de que pudiera disponerse.

Para mejor comunicar dicha información debe recurrirse a diversos procedimientos tabulares, gráficos, etc.

6.- Documentos necesarios para la información y toma de decisión del jefe de proyecto

Los documentos indispensables para la actuación del jefe de proyecto en su labor de seguimiento y control son de cuatro tipos:

1. Documentos sobre los costes, gastos y presupuestos. Compromisos y pagos realizados desde el inicio del proyecto y desde inicio del año en curso, presentado por bloques de actividades y conceptos; previsiones hasta fin de años y hasta fin del proyecto.

2. Documentos que muestran el estado de avance. Documento estado de la planificación vigente

3. Documentos sobre personal y plantilla. Personal existente, seleccionado por especialidades y afiliación; previsiones periodificadas hasta final de año y hasta final de proyecto.

4. Documentos sobre características técnicas. Especificaciones y su evolución

Estos documentos deben permitir comparar las especificaciones exigidas y previstas con las realizaciones concretas. Tanto en los que se refiere a las características técnicas, como a los datos fácilmente mesurables de costes y plazos, es preciso cuantificar o por lo menos normalizar la información, dándole la forma de tablas o gráficos.

Estas tablas o gráficos, además de describir la situación en el momento de su emisión, deben permitir comparaciones y deben mostrar tendencias de forma clara.

Podemos por tanto distinguir tres tipos de documentos  (tablas y/o gráficos):

1. Documentos  de base en el que se recoge la estimación más fiable en la fecha de emisión.

2. Documentos  de actualización en el que se recoge la nueva versión del anterior, o la información que ha sufrido modificación.

3. Documentos  de comparación que permite seguir y analizar la evolución de las estimaciones.

6.1.- Visualización de las desviaciones en plazos

 

Periódicamente se realizan actualizaciones de la planificación, y como resultado se obtienen estimaciones, algunas veces iguales a las precedentes, otras distintas, de las fechas en las que se alcanzarán ciertas etapas, hitos importantes del proyecto.

 

Estas estimaciones se difunden a los diversos responsables, no sólo para su información, sino para que actúen en consecuencia. Por ello es extremadamente útil que aparezcan en forma clara las desviaciones, si existen, en los plazos.

 

Recordando que cada estimación de una fecha tiene asociada además otra fecha, que es la de la realización de la estimación, una forma posible es la utilización de un diagrama en el que en abscisas figure la fecha de realización de la estimación, y en ordenadas el valor estimado (fecha mínima, máxima o ambas).

6.2.- Diagrama para la comparación de sucesivas estimaciones de la fecha de realización de una etapa

La bisectriz del primer cuadrante constituye el lugar de los puntos ciertos cuando se confunden estimación y realización.

1. Estabilidad completa

La etapa x presenta una estabilidad completa en cuanto a las estimaciones. Prolongando la línea de tendencia de las mismas obtendremos el punto x´

2. Inestabilidad imprevisible

No se aprecia una tendencia clara en el desarrollo de esta actividad, que ha estado sujeta a continuas medidas correctivas. Se hace imprescindible tener un especial cuidado con las actividades de este tipo. Sólo podremos bajar la guardia cuando la proximidad del final de la actividad haga casi imposible la desviación con respecto a la estimación.

3. Deslizamiento con tendencia

La etapa Z sufre un progresivo deslizamiento en su fecha de realización estimada. Prolongando la tendencia alcanzaremos el punto Z´, que presenta un retraso con respecto a la estimación inicial por lo que se hace necesario adoptar medidas.

4. Deslizamiento uniforme

La etapa U se retrasa con el tiempo de forma uniforme, de seguir las cosas como están nunca se realizara. Aunque la situación parece incoherente, se han vivido situaciones de este tipo. Este deslizamiento de las estimaciones oculta algún problema crónico que conviene hacer aflorar y resolver.

No es necesario indicar que aquí la actuación es absolutamente necesaria y urgente, aunque no es fácil de encontrar.

6.3.- Visualización de las desviaciones en gasto

Más difícil es presentar la evolución de los gastos ocasionados por el proyecto de forma que puedan adoptarse medidas correctoras rápidamente.

• La línea escalonada P corresponde al presupuesto acumulado.

•  La C al calendario de gastos acumulados estimados.

• La R a los gastos acumulados contabilizados

Dada la desviación de R respecto de C, su prolongación E constituye el nuevo calendario de gastos estimados

Suele resultar conveniente representar también la evolución del gasto comprometido para tener una mejor referencia de la evolución del proyecto.

La situación se complica si tenemos en cuenta dos hechos que influyen en lo anterior:

El valor añadido al proyecto no es proporcional al tiempo, y es respecto a dicho valor que debemos evaluar la desviación en el gasto.

El calendario inicial de gastos acumulados se hizo de acuerdo con un calendario de realización de actividades. En el momento actual pueden haberse producido desviaciones en estas realizaciones (y tal vez un aumento de la duración estimada del proyecto). Los retrasos influyen en el valor realizado del proyecto y en el calendario de gastos, que se extienden sobre una duración mayor.

Definición Valor ganado ( ver ampliación)

1. La definición Valor Ganado como sistema de control, básicamente requiere de la instrumentación de tres indicadores;

• Costo Actual del Trabajo Realizado CATR (ACWP Actual Cost for Work Performed).

• Costo Presupuestado del Trabajo Realizado CPTR (BCWP Budgeted Cost for Work Performed).

• Costo Presupuestado del Trabajo Planificado CPTP (BCWS Budgeted Cost for Work Scheduled).

Proyección del calendario de gastos acumulados teniendo en cuenta las desviaciones de duración y de presupuesto.

Monitorización estado del proyecto

7.- Cierre del proyecto

El cierre del proyecto incluye la aceptación oficial del proyecto y la finalización del mismo. Las actividades administrativas de incluir el archivo de los expedientes y la documentación de todo lo aprendido a lo largo de la ejecución del proyecto. 

Se realiza través de reuniones (videoconferencias) con el cliente, donde se levanta acta de recepción del proyecto y condiciones de garantías. 

En el transcurso de cualquier proyecto se realizan cambio, que deben de valorarse y adjuntase en el cierre del proyecto. El cambio es una parte normal y prevista del proceso de ejecución del proyecto.

 

Los cambios pueden ser el resultado de las necesarias modificaciones de diseño, las diferentes condiciones del lugar, la disponibilidad de material, contratista de cambios solicitados, el valor de ingeniería y de impacto por parte de terceros, por citar algunos. Más allá de la ejecución de los cambios en el terreno, el cambio normalmente es necesario documentar para mostrar lo que de hecho se construye.

 

Por lo tanto, el propietario por lo general requiere de un acta final para mostrar todos los cambios o, más concretamente, cualquier cambio que modifica la parte tangible de la obra terminada.

 

El registro se hace en el pliego de cláusulas administrativas , por lo general, pero no necesariamente se limita a ello, también se debe de reflejar en el diseño de los dibujos.

 

El producto final de este esfuerzo es lo que el cliente debe ver en el apartado de, "asbuilts.". Este es un requisito que se debe de proporcionarse  en los contratos de construcción.

¿Qué es un proyecto informático?

Un proyecto informático es cualquier proyecto de tecnología de la información que tiene una fecha de inicio y final asignada, a menudo con hitos y objetivos específicos que deben cumplirse durante el ciclo de desarrollo. Pueden ser cosas como cambiar unos servidores antiguos, desarrollar un sitio web de comercio electrónico o fusionar bases de datos.

.La gestión de proyectos informáticos se ve limitada por tres factores: tiempo, coste y alcance. Para que un proyecto tenga éxito, estas tres restricciones deben estar en equilibrio.

Necesidad de estandarizar la gestión de proyectos informáticos

Para tener éxito, las organizaciones deben crear o adaptar un enfoque estándar para la gestión de proyectos informáticos. Un enfoque estándar proporciona las siguientes ventajas:

Establece reglas y expectativas para el equipo del proyecto.

Proporciona a los gestores de proyectos, gerentes funcionales y el personal operativo, un lenguaje común que facilita la comunicación y ayuda a asegurar que todos están alineados

Los administradores pueden determinar rápidamente qué proyectos preceden a otros y cuáles no ya que todos siguen los mismos procesos y enfoques, y utilizan las mismas métricas para medir el rendimiento del proyecto.

La no utilización de un enfoque estándar es el error más grande en gestión de proyectos informáticos que una empresa puede cometer. Utilizarlo hace que sea posible que una empresa pueda medir el éxito de sus proyectos para determinar qué procesos y metodologías están funcionando y cuáles deben ser mejoradas.

¿Por qué fracasan algunos proyectos informáticos?

Cierta gestión de proyectos informáticos termina en fracaso, simplemente, porque se trata proyectos muy complicados. Además de los retos habituales de recursos, también se enfrentan a desafíos tecnológicos únicos: desde el hardware, sistema operativo, problemas de base de datos o de red, riesgos de seguridad, problemas de interoperabilidad y además, los fabricantes hacen cambios a sus configuraciones de hardware y software

Pero las tres razones más comunes por las que los proyectos fracasan son:

1. Una falta de planificación

2. Porque los proyectos se precipitaron

3. Porque el alcance era demasiado difícil de manejar

Durante el inicio de un proyecto, se deben establecer los criterios para decidir el éxito o el fracaso del proyecto. Por ejemplo, para ser considerado exitoso, un proyecto puede tener que cumplir con ciertas normas de calidad (por ejemplo, un programa de Six Sigma o uno ISO), estar dentro de un determinado presupuesto, cumplir con un plazo determinado o ofrecer una funcionalidad específica.

Otro enfoque es el uso de un indicador como la “Regla 15-15”. La Regla 15-15 establece que si un proyecto está más de un 15 por ciento por encima del presupuesto o un 15 por ciento por encima en tiempo, es probable que nunca se recupere el tiempo o el coste necesario para ser considerado exitoso.

¿Qué estrategias consiguen que los proyectos informáticos aumenten su velocidad?

Lento y rápido son términos subjetivos. Lo que puede parecer lento para tu organización puede ser muy rápido en otro lugar. Es importante determinar un marco de tiempo razonable para completar un proyecto informático basado en el alcance, los resultados esperados y las condiciones del proyecto.

Dicho esto, si que es posible determinar si tus proyectos están yendo demasiado lentos. Sobre todo si tienes información histórica con la que comparar la velocidad de los proyectos en curso.

Y por otro lado, pregúntate si tu gestión de proyectos informáticos está condicionada por el esfuerzo o por un duración determinada. Los proyectos condicionados por el esfuerzo pueden ser mejorados añadiendo más recursos para reducir el tiempo total del proyecto. Lo que ocurre es que hacer esto añade costes. Por otro lado, si el proyecto tiene una duración fija, como por ejemplo un proyecto que sea “hacer pruebas de software durante dos meses antes de ponerlo en producción”, no hay mucho que se pueda hacer para reducir el tiempo del proyecto sin incrementar el riesgo.

https://www.youtube.com/watch?v=HxuAcrj8JJk

https://www.youtube.com/watch?v=0KIV66volCI

https://prezi.com/qc8um87d4mn2/gestion-de-proyectos-informaticos/