Ficha del libro
Título: Gestión de proyectos de Tecnologías de Información
Título original: Information Technology Project Management
Autor: Jack Marchewka
Editorial: Wiley
Jack T. Marchewka es profesor de Administración de Sistemas de Información en la Northern Illinois University. También ha dado clases en la Rotterdam School of Management en los Países Bajos. Sus artículos se han publicado en varias revistas de la industria.
Conceptos clave
- Los proyectos de tecnologías de información (TI) requieren una gestión especial debido a su complicada combinación de factores técnicos, financieros y personales.
- Contar con el apoyo de todos los involucrados mejora el nivel de éxito de los proyectos de TI.
- El documento denominado “alcance del proyecto” es un contrato con la gerencia en donde se resume el proyecto.
- Debemos considerar que los factores personales son parte del proyecto.
- Si los líderes del proyecto se comportan de manera ética, los miembros de su equipo harán lo mismo.
- Los equipos que asumen grandes proyectos de TI, deberán desarrollar sus correspondientes planes de comunicación.
- Los administradores de proyectos utilizan software especializado para coordinar los calendarios, aprobar los presupuestos y para compartir información.
- Debemos establecer procedimientos formales para ampliar el alcance de los proyectos o se generará una ampliación constante con “alcances ilimitados”.
- Definir un procedimiento formal de cierre para concluir los proyectos de TI y analizar los resultados.
Por qué los proyectos de TI requieren una gestión especial
Aunque los proyectos que involucran tecnologías de información (TI) son muy parecidos a cualquier otro proyecto, existen algunas diferencias cruciales. Las TI proporcionan un servicio de soporte técnico. Por lo tanto, las personas que promueven la actualización de TI tienen que justificar sus horas imputadas a esos proyectos, mostrando a la organización el valor adicional que obtendrán.
La gestión de perfiles técnicos y usuarios finales
Los proyectos de TI combinan sistemas altamente técnicos y un número muchas veces amplio de personas, algunas con perfil técnico y otras que son simplemente usuarios del producto final. Los administradores de proyectos de TI deben de mantener el enfoque en las personas y no dejarse llevar por la excelente tecnología que están instalando. Tampoco es conveniente ignorar las formalidades de la administración de proyectos. Debemos activar un sistema nuevo sólo después de que hayamos considerado de qué manera afectará a cada uno de los usuarios implicados. Para ello, es crítico documentar los detalles de todos los sistemas de TI implementados, diseñar guías de usuario, definir quién se supone que los usará y cuáles son los procesos de negocio que dependen de estos sistemas.
Cómo empezar a pensar en proyectos de TI
Aunque cada proyecto será diferente, debemos documentarlo con una plantilla probada que pueda ajustarse a las particularidades de cada proyecto para evitar reinventar la práctica de la administración de proyectos de TI cada vez que comencemos uno nuevo.
El Valor Organizacional Medible (MOV)
Empezaremos por definir el Valor Organizacional Medible (MOV en inglés) del proyecto, un indicador independiente que permite verificar el éxito en la implantación del proyecto. El documento formal deberá incluir su MOV y una evaluación del grado de fiabilidad, costos estimados y duración, así como cualquier otro planteamiento adicional que afecte a la ejecución del proyecto. Debe incluir la previsión de cobro en función a las fases del proyecto entregadas o ejecutadas, definir a quién va a afectar, cómo se va asegurar su cumplimiento y cómo va a apoyar la estrategia de su compañía.
Documento de alcance del proyecto y plan de referencia
El documento de alcance del proyecto contiene el MOV y todos los recursos que se van a necesitar. Proporciona un resumen del plan del proyecto y debe aportar la mayor claridad posible. Este documento funciona como un contrato que pueden usar los miembros del equipo y los grupos de interés para resolver dudas o malentendidos.
Preguntas clave del plan de referencia
Al describir el plan de referencia del proyecto tenemos que responder algunas preguntas claves: ¿Cuáles son los objetivos del proyecto? ¿Cuáles son las tareas que tiene que realizar el equipo para alcanzar los objetivos establecidos? ¿Quién llevará a cabo dichas tareas? ¿Cuándo se realizarán las tareas y cuánto tiempo les tomará? ¿Cuál será el coste de cada tarea? El plan de referencia del proyecto es táctico por naturaleza y sus estimaciones deberán ajustarse a la descripción general del alcance del proyecto.
Recursos humanos en los proyectos
Como administrador de proyectos de TI, tenemos que entender de qué manera el proyecto afectará a la compañía y al personal. Una característica tecnológica que cause emoción a un gerente de TI, puede dejar a gerentes de otras áreas completamente impasibles. Es importante orientar al equipo del proyecto no sólo para realizar los aspectos técnicos de una instalación de TI, sino también mostrar interés en comprender las necesidades y responsabilidades de cada uno de los implicados.
Control del alcance de tu proyecto
Definamos con precisión lo que el equipo tiene que entregar y en cuánto tiempo, y qué recursos se necesitan para la entrega completa. Esta es una ciencia imperfecta. Las desviaciones forman parte del juego. Por esta razón, las especificaciones del proyecto tienen que incluir una explicación detallada de cómo se puede cambiar el alcance del proyecto, quién deberá asumir los costos adicionales y cómo se gestionar a la gente afectada por los cambios. Sin estos protocolos, lo que puede seguir es un “alcance desmedido”, que aumentará los costos del proyecto y eliminará su MOV.
Estructura del proyecto y estimados
La técnica denominada estructura de descomposición del trabajo (work breakdown structure, o WBS por sus siglas en inglés) permite conectar el alcance del proyecto con un plan detallado dentro de una jerarquía lógica y tareas compartimentadas. La mayoría de las empresas utilizan métodos estándar para generar los estimados del proyecto, entre ellos:
- La técnica Delphi– Técnica de comunicación estructurada basada en contar con un panel de expertos informados para que lleguen a un consenso respecto a los tiempos de entrega.
- Tiempo fijo– Definimos que el trabajo esté terminado dentro de un límite de tiempo específico.
- Estimado de arriba hacia abajo– Determina la duración de un proyecto después de decidir cuánto tiempo debe tomar, no cuánto puede tomar en caso de retrasos. Debemos ser extremadamente realistas.
- Estimado de abajo hacia arriba– Establecemos que la duración de un proyecto sea igual a la suma de la duración estimada de cada tarea basada en experiencias del mundo real.
Calendario y presupuesto del proyecto
Una vez que conozcamos todas las tareas del proyecto, su duración y los recursos requeridos, establecemos una secuencia de estas tareas dentro del calendario del proyecto.
El software para gestión de proyectos aporta varios beneficios: permite
- crear calendarios
- vistas tipo Gantt
- señalar dependencias entre las tareas (cuáles deben comenzarse cuando se termine una tarea anterior)
- identificar las rutas críticas para que el proyecto sea un éxito
- el trabajo colaborativo entre los miembros del equipo que comparten la misma información
- monitorizar los gastos del proyecto, comparando los costes reales con los presupuestados
La combinación del calendario del proyecto de TI y el presupuesto, forman un plan de referencia del proyecto que podemos poner a disposición de la alta gerencia. Este plan de referencia es el “criterio” para medir la actividad y el progreso del proyecto.
Riesgos en la administración del proyecto
Las empresas innovadoras aceptan y explotan ciertos riesgos de negocio convirtiéndolos en oportunidades rentables. Probablemente merezca la pena aceptar proyectos que representan algunos riesgos. La incertidumbre puede generar mucha presión sobre el plan del proyecto y los supuestos erróneos acerca de los elementos externos, pueden requerir su modificación. Diseñar planes de contingencia para responder a los malos resultados es clave.
Comunicar, monitorizar y reportar información del proyecto
La base de conocimiento, toda la información relevante, del proyecto tiene que estar disponible y ser confiable. Facilitemos que la gente pueda hacer cambios autorizados y actualizar tareas en cuanto tengan información nueva. Si el proyecto es grande, debemos desarrollar un plan de comunicación formal. Las comunicaciones informales sólo son suficientes para proyectos pequeños. Desarrollemos un calendario para la difusión de información, incluidos los reportes de avance.
Controlar la calidad de un proyecto de TI
El plan de calidad del proyecto tiene que destacar los estándares con los que tiene que cumplir cada tarea para considerarse terminada. Contamos con muchos métodos de administración científica. Algunos ofrecen beneficios reales cuando se usan de manera adecuada, pero mal implementados puede generar resultados decepcionantes. La Organización Internacional de Estándares (ISO, por sus siglas en inglés) emite un conjunto de estándares de operaciones mundialmente aceptado y conocido, que utilizan los gerentes en todo el mundo para asegurar el máximo rendimiento. Carnegie Mellon University promueve el modelo Capability Maturity Model Integration (CMMI), un sistema que recomienda prácticas para administrar el desarrollo de software. Independientemente del modelo que utilice la empresa, deberemos implementar definiciones claras de estándares y medidas y describa sus mecanismos de verificación.
Cultura y cambio organizacional
Si contamos con el apoyo de todas las personas a las que afectará un proyecto de TI tendremos muchas más oportunidades de éxito. Respondamos a la tendencia natural humana de adoptar temporalmente un nuevo comportamiento para luego regresar al antiguo cuando creen que nadie les observa. Cuando pidamos a los empleados que cambien su comportamiento, es mucho más probable que lo hagan si creen que tomaron la decisión de cambiar por sí solos y que además están ayudando al progreso de la organización. Utilicemos un procedimiento formal y definido para discutir y resolver los conflictos que surjan durante el proyecto.
Compras y subcontratación (outsourcing)
Casi todos los proyectos de TI necesitan aprovisionamiento externo en forma de compras. Existen tres tipos de contratos de compras que son los más comunes:
- precio fijo determinado inicialmente
- precio inicial con un descuento final en función de los recursos que no fueron utilizados
- pago por tiempo trabajado y materiales usados, facturados según se van necesitando
6 procesos del aprovisionamiento efectivo
- diseño de presupuesto que contemple todas las necesidades de material
- formalización del contrato con la empresa para la que desarrollaremos el proyecto
- solicitud de presupuestos a los diferentes proveedores de cada tipo de material
- selección de proveedores
- definición de condiciones de los contratos
- firma con los diferentes proveedores
Es probable que necesitemos subcontratar algunas partes del proyecto por diversas razones. Mantengamos todo el trabajo subcontratado integrado con el resto del proyecto y contabilicemos todos los gastos de la subcontratación para conocer su impacto en las métricas del proyecto.
Cómo empezar, terminar y evaluar un proyecto
A menos que sea un sistema completamente nuevo y un nuevo proceso de negocio para la empresa, implementar rápidamente una metodología es arriesgado. Un error grave en el sistema podría interrumpir los procesos del negocio y afectar la confianza de los empleados y la aceptación del nuevo sistema. Muchas empresas eligen instalar un nuevo sistema en paralelo al viejo, hasta que el nuevo demuestre su viabilidad.
Los proyectos se pueden concluir por varias razones, pero un proyecto se tiene que cerrar de manera adecuada, independientemente de si termina de manera exitosa o no.
El aspecto más importante del cierre del proyecto es asegurar que el nuevo sistema está totalmente documentado y que hemos captado toda la información útil acerca del sistema y su funcionamiento. La evaluación final del proyecto debería demostrar exactamente lo que ha logrado, el valor entregado lo que se ha aprendido sobre el negocio. Entreguemos un informe realista y constructivo al cerrar el proyecto. Para que la evaluación sea independiente, incluyamos los comentarios de la alta gerencia y de todos los involucrados.