La gestión de configuración (CM o SCM), una de las condiciones sinequanon para trabajo de una empresa orientada a proyectos, esté o no involucrada en desarrollo de software. La correcta gestión, distribución, almacenamiento y archivado de la documentación sin CM es prácticamente imposible. La falta de CM lleva a registros duplicados, confusión en versiones de ficheros, pérdida de información y datos cruciales del proyecto. El trabajo de PM esta vinculado muy estrechamente con el sistema de CM ya que éste, utilizando una estructura personalizada para cada empresa y proyecto, almacena los artefactos y registros del proyecto (Plan de Proyecto, Statements of Work, Contratos, Registros Históricos, etc.). En el mercado podemos encontrar una gran cantidad de sistemas de configuration management con funcionalidad integrada de gestión de versiones. He trabajado con las siguientes así que puedo opinar desde la perespectiva de un manager de proyecto sobre la facilidad, seguridad, y eficacia de cada uno.

• CVS - Sistema tradicional usado hace algunos años, todavía en uso. Se basa en línea de comandos aunque existen GUI’s. No recomendable para gestionar la documentación, aunque puede valer, teniendo presente sus desventajas, para equipos de desarrollo.
• Subversion - La evolución natural de CVS. Buena solución aunque también para línea de comandos. Hay que usar un GUI. Limitaciones, requiere instalación de componentes Apache.
• Borland StarTeam – Un software enterprise de gestión de configuración. Muy bueno, pero muy pesado. Tiene conceptos no demasiado fáciles de intuir por lo tanto si se usa se debe estudiar primero su funcionamiento exacto. Soporta opciones de línea de comandos y el cliente nativo.
• Microsoft SourceSafe (VSS) – Tradicionalmente el software SCM y gestión de versiones por excelencia… ahora bien, tiene tantas desventajas como ventajas, especialmente en la integridad de la información. No he probado todavía la versión más reciente, sin embargo la anterior era un desastre.
• Surround SCM – Software de SCM que uso en mi empresa. Cliente-Servidor, ligero, seguro, transaccional, require o no uso de base de datos. Desventajas, orientación a desarrolladores, puede ser lento cuando se hace check-in transaccional de gran volumen de datos y igual que otros CM no tiene búsqueda integrada por contexto. Recomendable aunque sea para probar.
• Perforce - Software usado hace un año en un proyecto de gestión de software. No esta mal, se le puede aplicar algunas de las ventajas de Surround SCM, pero le falta algo de lógica. Cuando lo probéis podréis sentir lo que quiero decir.

Como conclusión, definitivamente recomendaría el uso de Surround SCM para gestión documental y código fuente. Si incorporaran búsqueda u algunos cambios en el software, sería genial.

La orientación a proyectos dentro de PYMES, empieza cuando los trabajos o encargos llegan a considerarse proyectos con todas las consecuencias que esto supone. Las fases de iniciación, elaboración, desarrollo y cierre se marcan claramente y la empresa así como sus clientes saben diferenciar entre el ciclo de vida de proyecto y ciclo de vida de producto (mantenimiento posterior, etc). . En esta fase de madurez se gestionan los proyectos individuales por los project managers sin considerar las posibles sinergias que podrían obtenerse si éstos se gestionaran de forma conjunta, como un programa. En la siguiente fase aparece el PMO (Project Management Office) que según la estructura organizacional suele llamarse de diferentes maneras p. ej. Departamento de Proyectos, División de Ingeniería de Proyectos, etc. En realidad todas estas unidades tienen en común el hecho de que desempeñan por lo menos algunas funciones de la Oficina de Proyectos (PMO). La PMO dirigida por PMO Manager se encarga de gestionar de forma coordinada los proyectos, programas y portafolios, con el fin de optimizar el uso de recursos, reducir costes y obtener sinergias a través de uso de algunos de los conceptos de la teoría de cadena crítica de Goldratt.

Continuará…

¿En qué consiste una estimación del proyecto? Cada vez que un cliente solicita un presupuesto en esta acostumbrado o mejor dicho habituado a recibir un presupuesto según determinados criterios implícitamente claros para él. Para que el presupuesto no juegue con una desventaja innecesaria, preguntamos al cliente el formato en el que desea recibir el presupuesto. Tratándose del gobierno, nos lo indicarían en el pliego, pero si tratamos con empresas medianas o pequeñas debemos intentar de forma explicita solicitar esta información a fin de que el cliente tenga facilidades para leerlo. En aquellos casos cuando esta info adicional no esta disponible recomiendo facilitarle al cliente la estimación de forma escalonada, salvo que hayan instrucciones en contra. La estimación ocupa tiempo y recursos, para intentar asegurarse de que cuando lo preparemos y se lo enviaremos no se asusta, primero sería prudente facilitarle un orden de magnitud, como si avisáramos sobre el alcance. Si vemos que la reacción es favorable, pues a continuación tranquilamente podemos dedicarnos a realizar una estimación bottom-up. Este paso previo sirve como hemos visto para reducir un poco el riesgo. Para facilitarle un presupuesto al cliente sobre un proyecto, sería adecuado el formato de MS Project o cualquier otra alternativa que permita plasmar de forma gráfica las tareas, costes, duración, dependencias entre las tareas, etc. Un WBS con un diccionario WBS de alto nivel para explicar en que consiste cada una de las tareas. El último documento permite entender al cliente el contenido de paquetes de trabajo. Y cuando el cliente se pronuncie favorablemente sobre nuestra estimación en MS Project podemos concluir esta fase del proyecto formalizando un Statement of Work, dónde se definen claramente las condiciones comerciales, alcance, fechas, embediendo el presupuesto en MS Project original.