Gestión y Gobierno de Proyectos - parte II

Una de las actividades importantes del Gobierno de Proyectos es definir las prácticas y metodologías cuales deberían ser usadas uniformemente en la gestión y ejecución de los proyectos, con el objetivo de garantizar la calidad y resultado de los proyectos.

Actualmente en el mercado existen diferentes metodologías o mejores prácticas para Gestión de Proyectos (PMI, Prince2, etc.), pero estos no incluyen actividades de Desarrollo / Implementación de Sistemas de Información o Gestión de Cambios organizativos. Por otro lado existen una multitud de metodologías para desarrollo / implementación de Sistemas TI, pero excluyen las tareas de gestión de proyectos. Ambos no incluyen las actividades relacionadas con cambios organizativos. Realmente una dilema para los departamentos de TI, habitualmente responsables de coordinar estos tres áreas de actividad.



En los proyectos llevados a cabo por las empresas consultoras del sector TI, cada uno suele traer consigo una diferente metodología de gestión de proyectos TI - Negocio, con el consiguiente impacto de tener heterogeneos métodos en la compañía, cuales no incluyen los procedimientos, normas y practicas de la propia compañía, ni tomando en cuenta las especialidades del negocio de la compañía. A final esto causa confusión y desorganización en la implementación e intergración de los proyectos en la empresa.

Para apoyar las organizaciones en la gestión de los Proyectos TI para el Negocio, he desarrollado una fusión de las siguientes metodologías:

• Gestión de Proyectos basado a PMI (Project Management Institute) y
• Desarrollo/Implementación de Sistemas TI basado a la métodos tipo cascada como p.ej. SDLC (System Development Lifecycle),
• Gestión de Cambio basado a modelos y mejores prácticas del mercado (7S de McKinsey, Kotter 8 pasos, Lewin).

El objetivo de esta fusión es facilitar una ejecución y control simultáneo y sincronizado de ambos por un único Jefe de Proyecto, evitando organizaciones complejas y costosas de los proyectos.  La metodología ya está muy probada en diferentes entornes de negocios y empresas y permite en una manera eficiente y simple controlar hasta proyectos muy complejas.

Adicionalmente esta metodología añade actividades de preparación del proyecto hasta su aprobación interna, como en las actividades de Gestión de Cambios organizativos y su puesta en marcha en las organizaciones sincronizándolo con las actividades puramente ligados a sistemas informáticos.

En el siguiente diagrama podrá ver el proceso completo, incluyendo los hitos principales y los auditorías de calidad.  Este proceso se compone de 5 ases consecutivas, aunque podrán solaparse también en tiempo, siempre dependiendo del tipo de proyecto.

Esta metodología de Gestión de Proyectos se adapta a todo tipo de proyectos para implementar nuevos sistemas de información o infraestructuras informáticos en las organizaciones. Para despliegues repetitivos de la solución solamente hace falta de repetir algunos de los fases y actividades, sin tener que asumir otra metodología específica para ello.  Esta metodología permite controlar en los despliegues repetitivos las actividades de gestión de cambio organizativo y las de TI.

Esta metodología de Gestión de Proyectos debe ofrecer una ayuda a los Jefes de proyecto de las divisiones o departamentos de negocio para controlar toda la envergadura del proyecto, ayudarles a recolectar todos los datos necesarios y coordinar todos los procesos necesarios en diferentes unidades y/o proveedores para cumplir el objetivo final del proyecto. Más que una lista de actividades a acometer, representa un método controlado y secuencial para gestionar el proyecto – Guía rápida del proyecto. En la guía rápida de gestión de proyectos se puede distinguir entre proyectos importantes y complejas y en proyectos más pequeños con menos riesgos. Según la clasificación las tareas son más o menos completas. La guía rápida incluye también el primer control de seguimiento y calidad con controles de estado de las actividades y cumplimiento de fases, facilitando así el labor de control.

En este documento se escriben las fases, sub-fases y actividades cuales serán el base para la “Guía rápida” , cual se podrá utilizar diariamente en controlar los proyectos. Se especifican las tareas concretas a llevar a cabo, indicando la información necesaria para llevar a cabo la tarea, y el resultado (Resultado) de la tarea, así como los formularios estándares cuales pueden ser utilizados como documentación del proyecto. Se recomiendo crear un repositorio por cada proyecto en los sistemas existentes de de la organización. Todos los formularios y herramientas están creados en el entorno Microsoft Office y Microsoft Project.

Esta metodología incluye :

• Descripción de la metodología en fases, sub-fases y actividades.
• Guía Rápida para herramienta de control en los proyectos, incluyendo gestión de calidad y riesgos.
• Más de 100 formularios como herramienta unificada con Guía rápida para gestionar proyectos.

permitiendo una fácil y rápida implementación, así como adaptación a las necesidades de cada empresa, colaboración eficaz entre las diferentes unidades/grupos.

La importancia de controlling financiero en TI

Estamos otra vez en la época del año que hay que empezar a preparar los presupuestos e inversiones del 2011 y algunos años más. A la vez estamos analizando como llegamos a final del año con el presupuesto y "reserva" que tiene la compañía. Todo un reto importante, cual reserva la atención del CIO durante los próximos meses.

Aunque Presupuestos e Inversiones son 2 cosas diferentes desde punto de vista financiero, en caso de TI hay que tratarlos muchas veces simultaneamente. Las partidas que antes iban a las inversiones y posteriormente a amortizaciones, ahora se imputan como costes en los presupuestos. Esto viene dado principalmente por 2 razones:

• primero por las nueves normas contables y financieras atrás de Sarbanes-Oxley Act (o Basilea II), cual prohibe capitalizar ciertos inmateriales, como coste de proyectos TI, servicios TI o consultoría TI.
• segundo por el fuerte crecimiento de subcontratación / outsourcing de servicios y proyectos TI, donde además la formula de financiación incluye todo en una cuota mensual, procedente de HW, SW, consultoría, etc. El hecho de no poder capitalizar grandes proyectos, y que los tiempos de amortización de equipamiento de TI se acortó drasticamente entre 3 a 6 años, hace que la cuota mensual de los proveedores de servicios es mucho más atractiva que la capitalización.

? Que poner en los Presupuesto y que en los inversiones ?

Como concepto general es claro que en los gastos debería ir los elementos de costes diarios y habituales, y en los inversiones los gastos de proyectos a futuro, donde el disfrute de sus beneficios sale en los próximos X años.  Pero la competencia entre TI y áreas de negocio - como ventas, producción, logística - de los recursos financieros de la compañía es feroz y no siempre bajo mismas condiciones. Parece que es más fácil conseguir nuevas lineas de producción o camiones de reparto, que servidores centrales para la compañía. 
Muchas veces se nos han criticado a los CIOs que no sabemos defendernos financieramente, ni hacemos los Business Case como nuestras colegas de negocio, ni estamos consientes de las cuotas de amortización de nuestra área.  
Si ahora todo lo que TI pueda aportar en nuevos proyectos para la compañía se carga contra los Presupuestos Generales de la compañía, aunque sea contra Departamento de TI, nuestra posicionamiento como área cual aporta a los beneficios de la compañía se empeora. Los costes suben en servicios desproporcionalmente a lo que bajan en las amortizaciones. La bajada de amortizaciones se empieza observar pasados unos 3 años,  y mientras tanto, parece que tenemos doble coste de operación. Nuestra fama como "caro e ineficiente" aumenta.  

?Como llegar a corregir la balanza entre presupuestos e inversiones ?

Primero de todo es buscar un buen Controller para TI, primordial. Para preparar las cuentas de la compañía a defender los inversiones y gastos de TI, hay que trabajar en los detalles contables. Un controller que entiende de contabilidad, control de costes, activos fijos y amortizaciones. Cada Director de Producción tiene uno, ?porque no un CIO? Además hay que cerrar alianzas de colaboración con Director Financiero, y los responsables de Contabilidad, Costes y Tesorería. Esto requiere reuniones periódicas entre todos, para preparar conjuntamente da estrategia de presentación de inversiones TI.

Ahora  el Controller de TI debe cambiar la imputación de gastos TI en la manera que sea posteriormente posible controlarlos, clasificarlos y medirlos.
Lamentablemente en muchas compañías se encuentra que los inversiones y/o gastos TI se han imputado contablemente en grupos sumarizados, y no hay nadie que sepa que elementos de inventario TI, o que costes hayan dentro. En nuestros presupuestos sigamos contando con ese coste de amortización, sin saber si toca o no. En peores de los casos, la amortización no se calcula hasta 0, sino prevee un reemplazo y resrva fondos para ello.  El controller debe hacer una investigación profunda de las cuotas de amortización, eliminar los que pueda y limpiar el resto ligándolo al inventario de TI. Necestitamos una proyección de amortizaciones a 3/5 años.

Segundo trabajo es la creación correcta de nuestros centros de coste, y la consideración si TI debería ser un Centro de Beneficio (aunque a 0) para la compañía. Como mínimo seria adecuado separar la área de operación y explotación de TI, del área de Proyectos/Innovación/Laboratorio.

En la contabilidad general hay que clasificar los tipos de costes de TI, siguiendo un parecido con la área de producción de la compañía, pero propio. Para que posteriormente podamos medir los costes de Hardware e infraestructuras, debe haber una clasificación propia para ello en la contabilidad y no sean aprovechados los habituales en la compañía como "maquinaria producción", "inmuebles", "mobiliario oficinas", "mantenimiento", "innovación", etc. Si nuestras cifras se suman a los generales de otras áreas, como jamas seamos capaces de demostrar el valor o el ahorro conseguido.

Si existen propias categorías de costes para TI, ya no es importante en que Centro de Coste (CeCO) se imputa un proyecto TI, así que se acabo de luchar que los proyectos informáticos deben estar en el CeCo de TI. Es más, nos conviene que los proyectos estén en los CeCo's quienes serán receptores del beneficio/costes del mismo, sus responsables nos apoyan en la definición del Business Case, se compromenten con los resultados, y participen en la implementación - rinden cuentas también. Teniendo las clasificaciones e imputaciones correctamente, somos capaces de presentar los costes totales, e inversiones totales mediante la contabilidad analítica.

Además una vez utilizamos categorías y subcategorias de costes, conseguiremos un árbol jerárquico para Presupuestos e Inversiones, con cual es muy fácil y rápido presupuestar o hacer cálculos de simulación para proyectos de inversión. Tenemos nuestros datos de costes y beneficios en los sistemas informáticos de la compañía, accesibles y medibles. Ahora si podemos calcular adecuadamente el Business Case y los impactos en las cuentas de la compañía.
Cuando tenemos los costes totales de TI para el nuevo año, tambien seremos capaces de mensualizarlos, elaborando conjuntamente con responsables de Tesoreria y Contabilidad, el flujo de caja mensual. A partir de ahora podemos controlar mensualmente nuestro prespuesto de TI, sabemos donde está cada coste y a que elemento de inventario corresponde.

Así que de repente el Director de Sistemas o CIO, se pasa de gestionar sus CeCo's a gestionar múltiples en diferentes áreas / sociedades y balancear las cuentas con el Director Financiero. Una posición mucho más estrategica, con mayor información y mayor capacidad de ejecución.

¿ Como impacta a los "precios internos" de TI ?

Si hemos conseguido subir las inversiones en TI, nuestros costes bajan, porque ya no hace falta la financiación externa cual siempre es más caro (aprox 8- 12%). Como los inversiones se imputan en los CeCo?s receptores, primeramente no hace aumentar los costes del TI hasta que empieza a dar soporte y mantenimiento a la nueva infraestructura o aplicación. Quiere decir también que el "precio" que TI le imputa a los departamentos de negocio, será también más bajo, como la "creación del producto" ya lo están pagando vía amortizaciones y no en una cuota mensual fija para empresas de renting o proveedores de TI.
Si ahora alguien le interesaría hacer un benchmarking de nuestros costes de servicio contra los proveedores de TI en el mercado, seguro que ganamos. Ya simplemente porque no trabajamos con margenes de 30%, ni tenemos estructura como ellos.


Deseo a todos una buena planificación de prespuestos e inversiones !