República Bolivariana de Venezuela

Ministerio para el poder popular para educación ciencia y tecnología

Universidad Experimental de la Gran Caracas

Gestión de Proyectos Tecnológicos

Control y Seguimiento en la Gestión de Proyectos Tecnológicos

Integrantes del equipo:

Cédula de Apellidos y Nombres Correo electrónico Sección

Identidad

20.793.964 Cabezas Fernando linuxionist@gmail.com A

 Profesora: Diego Maestre

Especialización: Auditoria de Tecnología de Información Financiera y Seguridad

de Datos

Introducción

En el presente trabajo de investigación se describen los conceptos básicos sobre

las herramientas y técnicas necesarias para realizar los procesos de seguimiento y
control de proyectos tecnológicos. A lo largo del presente material se expone
como el seguimiento se entrelaza con el control. Las dos representan funciones
opuestas: Seguimiento es recolectar y reportar información sobre los elementos de
desempeño del proyecto previamente definidos, y el control utiliza la información
proporcionada por las técnicas de seguimiento para alinear los resultados reales
del proyecto con los estándares de desempeño del proyecto establecidos.
A medida que lea esta investigación, podrá:

 Comprender qué se entiende por seguimiento y control.

 Comprender los procesos generalmente aceptados de seguimiento y

control.

 Comprender cómo llevar a cabo el proceso de seguimiento y control.

Planificación de un proyecto y como evitar fallas

El primer paso que puede representar un factor determinante en todas las

metodologías y marcos de trabajo existentes para el desarrollo de proyectos en
general es la planificación. Esto ayuda de manera individual y equipo a tener un
mejor conocimiento en términos de necesidades y expectativas que justifican su
implementación, soporte e interés requerido de los gerentes de negocio y a
naturaleza del trabajo a realizar.

El propósito de esta fase en un ciclo de vida es establecer la estrategia que el

proyecto tomara con la finalidad de cumplir las necesidades e intereses de
negocio.

Cada proyecto de desarrollo de sistemas debe tener un plan claro, el cual debe
ser definido con suficiente precisión para guiar las acciones tomadas para guiar el
desarrollo del proyecto y que estas tengan un alto nivel de certeza de lo que se
realizara. De hecho, este paso ayuda a identificar las dependencias y relaciones
en el proyecto donde se desea alcanzar una sinergia del equipo y las acciones
prescritas por la gerencia.

En esta etapa la información es escasa y puede que se conozca muy poco del
proyecto. Algunos de los requerimientos a nivel general pueden estar establecidos
o en desarrollo, de igual forma se puede tener lo que el sistema quiere comunicar
para permitir la identificación de interfaces por dar un ejemplo y los procesos
genéricos de negocio deben estar claros. De otra forma solo se contara con
información circunstancial y anecdótica y otras cosas que pueden ser útiles de
proyectos anteriores.
Para evitar fallas un proyecto debe contar con al menos un plan de contingencia.
Se pueden denominar estos planes como rollback, peor escenario o panes de
recuperación de desastres. Un plan de contingencia es una medida
predeterminada que debe ser ejecutada si el proyecto no se desarrolla como se
planifico. Si se ignora la creación de un plan de contingencia se estará apelando
básicamente a la fe de que “todo saldrá bien” ademas de no contar con una
correcta mitigación de riesgos. Este tipo de proyectos siempre son forzados a una
entrega tardía y siempre con el consumo de mas presupuesto y recursos.

Cuando se esta completando la investigación preliminar y se establece que se

quiere alcanzar con el proyecto, se debe pensar en como se va a reaccionar si
alguna de las fases no van de acorde a lo planificado. Muchos de los proyectos de
tecnología tienen múltiples pasos para completarse, por lo que hay muchas
oportunidades de que las cosas salgan mal. De hecho así es siempre sin importar
el proyecto.

Como parte del proceso de planificación se deben registrar los problemas,

documentar conflictos con cualquiera de las tecnologías usadas preferiblemente
en una bitácora y tener a la mano una base de conocimientos de artículos y libros
que ofrezcan soluciones con las tecnologías que se están implementando.

Una de las principales razones para crear planes de contingencia durante la

planificación es la preparación a las siguientes fases

Teniendo un plan de contingencia bien estructurado por cada fase, permite tener
adelantadas respuestas a nivel gerencial en las reuniones con cualquiera de los
involucrados. Esto permitirá subir el nivel de confianza y soporte del proyecto
inclusive antes de escuchar la palabra “Ejecútenlo”.

Indicadores de desempeño en gestión de proyectos

Un esquema detallado de indicadores de desempeño es necesario para permitir la

evaluación individual y de equipo en el logro de los objetivos para identificar
desviaciones y problemas a tiempo. Esto permite tomar medidas correctivas a los
procesos que lo requieran con el fin de restablecer los parámetros esperados de
desarrollo. Este esquema generalmente incluye una colección de indicadores de
procesos, orientados a verificar si las circunstancias permitieron al proceso iniciar,
como es el desempeño en este y la calidad de los resultados obtenidos.

Cada uno de estos indicadores debe obtener objetivos específicos de control que
permitirán a los propietarios de los procesos validar la relevancia y utilidad de los
procesos y así eliminar mecanismos que contribuyen poco o nada para controlar y
mejorar el proceso.

Los esquemas de monitoreo deben identificar métodos a ser usados para la

medición de procesos y la frecuencia de controles e inspecciones aplicadas. Todo
esto varia según la metodología o marco de trabajo aplicado, ejemplos:

 Scrum: por ser una metodología ágil da parámetros para tener de forma
diaria una medición de la salud de el proyecto en los Daily Meetings. Se
sugiere el uso de un burndown chart en el cual se puede constatar como en
un escenario optimo se puede desarrolla el proyecto y como actualmente se
desarrolla.

 Metodologías tradicionales de cascada: En su mayoría se guían mediante

un Diagrama de Gantt que establece las actividades y su desarrollo así en
que porcentaje se desarrolla cada una.

Conceptos de control y seguimiento en gestión de proyectos

Control: Incluye el determinar acciones correctivas y preventivas, replanificación y

el seguimiento de los planes de acción para determinar cuales acciones deben ser
tomadas para resolver problemas de rendimiento.

Seguimiento: Es un aspecto de la gerencia de proyectos ejecutado durante todo el

desarrollo del mismo. El seguimiento incluye recolectar, medir y evaluar medidas
de tendencias para mejorar procesos. El seguimiento continuo le da a la gestión
de proyecto el conocimiento interno de la gestión de proyectos e identifica las
áreas que requieren atención especial

El control en proyectos tecnológicos

El control permitirá (como fue previamente expuesto) controlar los procesos

principalmente relacionados el alcance, tiempo y cambios de costo. También en
este proceso se trabajara con los interesados en el proyecto para verificar que se
cumple con sus necesidades de forma tal que acepten los entregables que ha
creado el equipo de desarrollo para ellos. La revisión del alcance en un proceso
que lleva a aceptar las decisiones para el proyecto. Otra inspección que es hecha
sin los interesados es el control de calidad. En el control de calidad se inspecciona
el proyecto (preferiblemente por un equipo especialista en pruebas) para confirmar
que este hace las tareas para las que fue creado antes de la revisión por parte de
los interesados funcionales.

El control de calidad va relacionado a mantener los errores tecnicos lejos de las

manos de los clientes. Este es un buen ejemplo de como el control de proyectos
tecnologicos y su ejecucion traajan juntos. El control de calidad debe confirmar
que el trabajo fue hecho correctamente y si no el equipo debe realizar acciones
correctivas para corregir los errores.

Tipos de control en proyectos tecnológicos

Aunque obedeciendo siempre al esquema conceptual general, los mecanismos de

control pueden clasificarse, dependiendo del momento en que se realice la acción
de control, en la forma que se indica a continuación:
Control direccional

El mecanismo de control actúa antes de que la actividad este totalmente

concluida. En este caso el control se realiza de modo continuo y no en puntos
determinados, de modo que cada elemento de la acción sea el resultado de la
rectificación casi instantánea de la acción anterior.

Es lo que ocurre, por ejemplo, con un conductor de carro, al orientar su trayectoria

de acuerdo con los obstáculos que se encuentran en el camino. El espacio de
tiempo entre la percepción de la nueva situación, la evaluación de la rectificación
a efectuar, la decisión y la acción correctiva debe ser mínimo, so pena de
ocasionar un accidente.

En proyectos, este tipo de control se puede realizar cuando se tiene estructurado

un sistema, que permita controlar los diferentes factores de manera continua.

Control aprobado – reprobado

En este caso, el receptor del control se somete a un examen después de

concluidas determinadas actividades. En caso de aprobación se permite la
realización de la actividad siguiente. Si hubiera una rectificación, el proceso se
interrumpe definitivamente o hasta que se subsanen las irregularidades.

Este es el caso típico del control de calidad. Una pieza de la línea de producción
se somete periódicamente a inspección, la que se realiza de acuerdo con
especificaciones preestablecidas por el órgano encargado del diseño técnico del
producto. Al pasar la inspección, la pieza se libera para someterse a la próxima
operación. Al ser reprobada, se la encamina hacia un campo de recuperación, si
esto fuera posible. Al no ocurrir esto último, la pieza se desecha.

En proyectos ocurre algo similar, si se realiza este control y, se detectan fallas en

alguna de las actividades, lo más recomendable es encaminarla(s) correctamente,
para que no se presenten problemas posteriores.
Control postoperacional

El mecanismo de control sólo se pone en funcionamiento después de concluida

toda la operación. La información para la acción correctiva en este tipo de control,
solo se utilizara en un periodo (proyecto) futuro cuando se inicie la planificación
para un nuevo ciclo de actividades.

Ocurre, por ejemplo, en la evaluación final de un curso de capacitación, o cuando

el entrenador de un equipo de fútbol evalúa el desempeño de sus jugadores
después del juego. Este tipo de control se utiliza también con la finalidad de dar
premios e incentivos a los agentes que participaron en la actividad.

Estos controles se pueden hacer al interior del proyecto (control por dentro) o por
intermedio de firmas, externas al proyecto, especializadas en control (control por
fuera).

Vale la pena mencionar que estos tres tipos de control no son mutuamente
excluyentes, sino que más bien, deben ser complementarios. La decisión de
emplear un tipo aislado de control o una combinación de los tipos antes
mencionados, esta en función del carácter del sistema que se desea controlar y
del nivel de complejidad que se intenta introducir en los mecanismos de control.
En algunos casos, los contratistas exigen que se haga un control externo al
proyecto, para asegurarse de la buena marcha del mismo.

El proceso de control en la gestión de proyectos tecnológicos

El proceso utilizado para monitorear y controlar el trabajo del proyecto varía,

dependiendo del tamaño, flexibilidad y ubicación de los recursos y otros factores.
A continuación se enumeran las pautas generales que debe seguirse durante el
proceso de control:
  Educar a las partes interesadas y a los miembros del equipo sobre la
necesidad y el uso de la información de progreso para fomentar un entorno
de informes honestos y precisos.

 Automatice la recopilación de información de estado tanto como sea

posible.

 La frecuencia de recolección depende del tamaño del proyecto y la

ubicación de los participantes. Independientemente de las características
del proyecto, recopilación del estado del proyecto esta información nunca
debe exceder de una semana y, si es posible, debe hacerse diariamente.

 La frecuencia y el formato de los informes se describen en el análisis de las

partes interesadas.

 Se debe tener un proceso de control de cambios como el que ofrece la

metodología ITIL para tener un proceso formal de controles de cambio.

 La aprobación final del entregable debe obtenerse formalmente de las

partes interesadas antes de que cualquier tarea se pueda declarar
completa.

Metodologías de control en la gestión de proyectos tecnológicos

Muchas organizaciones tienen un proceso de desarrollo de sistemas de

información formal que consiste en un conjunto estándar (repetible) de procesos o
actividades que se siguen para construir un sistema o producto. El ciclo de vida de
desarrollo de sistemas es un enfoque sistematizado para la resolución de
problemas que organiza estos procesos en fases y tareas con el propósito de
construir un producto de sistema de información, comenzando con los procesos de
planificación inicial, continuando hasta la implementación y el soporte.

Muchas metodologías se han desarrollado a lo largo de los años para guiar el

esfuerzo de desarrollo. Uno de los primeros y más comunes es el modelo de
cascada, que fue heredado de la comunidad de ingenieros. Debido a que muchos
aspectos de los sistemas de información son únicos (por ejemplo, infraestructuras
de red, hardware, lenguaje de programacion, dominio de aplicaciones, uso de
Internet, cultura organizacional), los expertos en la industria han desarrollado
diferentes metodologias y marcos de trabajo para diferentes tipos de proyectos.
Ejemplos de estos son el Proceso Racional Unificado (o RUP por sus siglas en
ingles de Rational Unified Process ) de IBM, Scrum y Extreme Programming (XP).
Existen muchos ciclos de vida con los que se puede tener un control adecuado ,
depende del gerente de proyecto y del equipo seleccionar el que sea más
apropiado para el proyecto que les dará la mejor oportunidad de éxito

Modelo en cascada

El modelo en cascada se considera el enfoque tradicional para el desarrollo de

sistemas. Describe un enfoque de desarrollo que es lineal y secuencial, tiene
objetivos distintos para cada fase y en el que el resultado de una fase es la
entrada para la siguiente. Boehm y Turner se refieren a esto como plan impulsado:
paradigma de requisitos / diseño / construcción con procesos estándar bien
definidos que las organizaciones mejoran continuamente (2004). El modelo de
cascada se llamó así porque una vez que el agua pasa por encima de las
cataratas, no puede dar marcha atrás ni volver a subir. De manera similar, en el
desarrollo de sistemas, una vez que se ha completado una fase, no se puede
volver a una fase anterior. La ventaja del desarrollo en cascada es que permite un
control administrativo estricto. El cronograma del proyecto se puede desarrollar
con plazos firmes para cada fase del proyecto.

El modelo espiral

El modelo de ciclo de vida en espiral se basa en el modelo de cascada clásico con

la adición de análisis de riesgo e iteraciones. El modelo en espiral enfatiza la
necesidad de retroceder y reiterar etapas anteriores varias veces a medida que
avanza el proyecto. En realidad, es una serie de ciclos cortos en cascada, cada
uno de los cuales produce un prototipo inicial que representa una parte de todo el
proyecto. Este enfoque ayuda a demostrar una prueba de concepto al principio del
proyecto y ayuda a reflejar con precisión la complejidad de la tecnología en
constante cambio. El modelo consta de cuatro partes principales, o bloques, y el
proceso se muestra mediante un bucle continuo que va desde el interior hacia el
exterior. El tamaño de la espiral representa el tamaño creciente de la aplicación
que se completa.

El modelo Scrum

El enfoque Scrum, desarrollado por Ken Schwaber y Jeff Sutherland, fue

desarrollado para gestionar el proceso de desarrollo de sistemas. Scrum se basa
en el concepto de que el desarrollo de software no es un proceso definido, sino un
proceso empírico con transformaciones complejas de entrada a salida que pueden
repetirse o no en diferentes circunstancias.

El nombre Scrum se deriva esencialmente del juego de rugby. En rugby, una

jugada en la que dos equipos rivales intentan moverse entre sí en grupos grandes
de fuerza bruta se llama Scrum. Cada grupo debe ser rápido para contrarrestar el
impulso del otro y ajustar y explotar cualquier debilidad percibida, sin el lujo de
planificar.

La idea principal de Scrum es que el desarrollo de sistemas involucra varias

variables ambientales y técnicas que es probable que cambien durante el proceso
(por ejemplo, requisitos, marco de tiempo, recursos, tecnología). Esto hace que el
proceso de desarrollo sea impredecible y complejo, lo que requiere flexibilidad del
proceso de desarrollo de sistemas para responder a estos cambios. Como
resultado del proceso de desarrollo, se desarrolla un sistema útil.

El Proceso Racional Unificado

RUP proporciona un enfoque disciplinado para asignar tareas y responsabilidades
dentro de una organización de desarrollo. Su objetivo es garantizar la producción
de software de alta calidad que satisfaga las necesidades de los usuarios finales,
dentro de un calendario y presupuesto predecibles. RUP es un proceso iterativo
que identifica cuatro fases de un proyecto de desarrollo de software: inicio,
elaboración, construcción y transición. Cada fase implica una o más iteraciones
donde se produce un ejecutable, pero puede ser un sistema incompleto (excepto
posiblemente en la fase inicial). Durante cada iteración, el equipo realiza
actividades de varias disciplinas (flujos de trabajo), en diferentes niveles de
detalle.

El modelo XP

Extreme Programming (XP) es posiblemente la más conocida de las metodologías

ágiles. El enfoque básico de XP implica ciclos de desarrollo cortos, actualizaciones
frecuentes, división de prioridades técnicas y comerciales y asignación de historias
de usuario. XP tiene cuatro valores clave: comunicación, retroalimentación,
simplicidad y coraje, además de una docena de prácticas que se siguen durante
los proyectos de XP: planificación, versiones pequeñas, metáfora, diseño simple,
refactorización, pruebas, programación de pares, propiedad colectiva, integración
continua, 40 horas semanales, cliente in situ y estándares de codificación. XP
pone gran énfasis en las pruebas. De hecho, los programadores de XP deben
escribir pruebas mientras escriben código de producción. Debido a que las
pruebas están integradas en el proceso de construcción, se obtiene un producto
altamente estable y expandible.
Conclusión

No importa cuánta planificación, preparación y estrategia invierta en un proyecto,

el cambio puede ocurrir. Un cambio en los entregables puede ocurrir por parte de
la gerencia o del cliente que recibe los entregables. Los ciclos económicos, los
nuevos requisitos de los clientes o la nueva gestión pueden llevar a cambios en el
plan de un proyecto.

La gerencia de proyectos tecnológicos debe implementar un esquema de

seguimiento y control de cambios para formalizar una solicitud de cambio y luego
reaccionar al cambio en una declaración formal también. Una solicitud para
cambiar los entregables del proyecto, sin importar cuán aparentemente pequeña
sea, es una solicitud importante que requiere una justificación comercial para
comenzar a ejecutar la corrección.

Un cambio en los entregables del proyecto puede requerir recursos adicionales,

financiamiento adicional, tiempo adicional o los tres para completar el proyecto. La
gerencia o los clientes deben estar dispuestos a cumplir con sus solicitudes para
completar el proyecto.

Si el cambio se produce debido a fuerzas internas, como la falta de enfoque, el

cambio en los recursos, las unidades de trabajo que no se completan o la
financiación inadecuada, debe tomar la iniciativa para corregir el problema. Hay
que enfrentarse a la dirección y explicar el problema y ofrecer una solución para
corregir el problema y volver a encarrilar el proyecto.

Una vez que se ha modificado el alcance del proyecto, el gerente de proyectos y

su equipo deben renovar su dedicación a la visión del proyecto. Un nuevo sentido
de responsabilidad y dedicación deben surgir canales de comunicación para que
el proyecto avance hasta su finalización.

Bibliografía

Brewer, J. y Dittman K. (2013). Methods of IT Project Management [Libro].

Control y seguimiento en gestión de proyectos [Articulo en línea]. Disponible:

https://www.gestiopolis.com/control-y-seguimiento-en-gestion-de-proyectos/

Lopez, J. (2012). Maximizing Benefits from IT Project Management [Libro].

Phillips, J. IT Project Management [Libro].

Project Management Institute (2017). A guide to the project management body of

knowledge (PMBOK guide) [Libro].