Primavera is a great Project Portfolio Management tool, it is highly powerful though it might be pretty confusing for a typical Microsoft EPM user. If the customer works with Primavera it does not mean that he is literate about Project Management best practices. Today, on a project, a long time planner, presently using P3 solution, sent me a 4 levels depth WBS for me to analyze and convert it into an EPM project. Suprisingly we have on one hand tasks grouped in phases or control accounts, but none of them are sequenced using standard Finish-to-Start, Start-to-Start or other typical dependency relationships nor they are resource driven, programming tasks and activities through a hardcoded start and finish dates. Migrating such a project plan to MS EPM is almost impossible if you would like to take advantage of the real power of MS PPS: Earned Value reporting (SV, CV, etc.). This is a challenge so we shall continue working on this issue. More info coming soon

En la empresa los proyectos generan entregables o documentación que debe ser archivada de una forma específica y uniforme a fin de que el personal familiarizado con la estructura pueda recuperar datos precisos en un momento dado con sencillez. Si la empresa tiene un certificado ISO 9001:2000 o CMMI entonces sus procedimientos ya contemplan la ubicación centralizada, segura y correctamente gestionada, donde se almacenan los entregables, sean documentos de proyectos, planes, blueprints, código fuente, logs de conversaciones etc. Aunque los proyectos pueden ser bastante diferentes, si hablamos de una empresa IT o de desarrollo de software, entonces debe ser capaz de unificar la estructura de datos y metadatos de sus registros de proyectos. A continuación propongo una forma de organizar y clasificar los registros que debería satisfacer los requerimientos de un rango amplio de empresas de software:

• Registros Producto
  • Base de Datos
    • Esquema
    • Scripts iniciales
    • Scripts actualización
  • Manuales
  • Fuentes
    • Código fuente genérico
    • Paquete instalación binario
    • Instrucciones
  • Informes de Pruebas
  • Modelado UML
  • User Interface
    • Wireframe
    • Screenshots
    • Prototipos
• Registros Proyecto
  • Análisis funcional
  • Documentación requerimientos
    • Casos de Uso
    • Arquitectura
  • - Contratos
    • Propuestas
    • Presupuestos
    • Pedidos
    • Aceptaciones
    • SOW’s
  • Planes de Proyecto
  • Riesgos
  • Actas
  • Informes

Lógicamente cada empresa debe personalizar esta lista a fin de ajustarla a sus necesidades.

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.

El periodo de garantía en proyectos de software es una parte integral del ciclo de vida del proyecto, por lo tanto a la hora de realizar estimaciones de esfuerzo – presupuestos, el hecho de tener disponible una determinada cantidad de recursos supone costes y gastos que en su mayor parte obviamos, dejándonos llevar por la ilusión de una nueva iniciativa. El soporte y mantenimiento fuera de garantía también son parte del ciclo de vida como bien indica Joe en su comentario, pero no del proyecto sino del producto. En estos casos las cuentas de cargo deben ser diferentes ya que no se trata de alcanzar los objetivos del proyecto en sí (ya lo hemos conseguido anteriormente, hurraaaa!), sino tomar las fases de soporte de la aplicación como un proyecto nuevo… con objetivos definidos, criterios y SLA’s establecidos y sobre todo con alguna rentabilidad, aunque eso es ya una decisión comercial. Si trabajamos con empresas de desarrollo de software, nos estarán eternamente agradecidos si tratamos el proyecto en sí, soporte dentro de garantía y también soporte posterior fuera de garantía como 3 proyectos independientes. Estos proyectos pueden llevarse acabo por diferentes grupos de trabajo, lo que evitará que el mismo grupo de programadores que inicialmente montaron la aplicación se quemen finalmente con la garantía o con el soporte posterior. La garantía es una obligación conjunta de todas las empresas que participan en el proyecto hacía el cliente. Por otro lado el mantenimiento y soporte fuera de garantía – no. El cliente tiene libertad de mantener la aplicación usando medios propios o subcontratar a la misma o una nueva empresa – un nuevo acuerdo. Para concluir, a veces algunos clientes una vez entregado el producto, se dan cuenta que para mantener el software a la par con sus crecientes demandas, debe existir un mantenimiento considerable, otros simplemente solicitan ampliaciones del alcance original del proyecto…

Agradecimientos a Joe por llamar mi atención sobre el tema de garantía y mantenimiento.

Al entregar un proyecto de software aunque tengamos muy presente las enseñanzas de Philip Crosby siempre existirán fallos, incidencias e incluso defectos que deberán ser tratados. Proyectos comerciales de desarrollo de software suelen llevar de 3 a 6 meses de garantía después de la entrega del proyecto. El cliente debe instalar el software y validarlo lo antes posible y siempre dentro de este periodo de tiempo. Aunque pueden existir periodos de garantía más amplios, son acuerdos comerciales puntuales entre cliente y proveedor. Durante el periodo de garantía las incidencias encontradas deben ser reportadas formalmente y arregladas por parte del proveedor sin cargo alguno – mantenimiento correctivo del producto en garantía. Cualquier cambio – Change Request – introducido durante la garantía y aprobado por CCB debe ser facturado ya que se encuentra fuera del alcance inicial de los trabajos. Al finalizar la garantía, a fin de mantener el proyecto vivo, es responsabilidad del proveedor de sugerir la formalización de un acuerdo de mantenimiento. Estos acuerdos suelen ser anuales, dónde para mantenimiento correctivo se establece una bolsa de horas mensual, que si no se llega a utilizar puede ser acumulada y usada durante la validez del contrato (un año). Al renovar el acuerdo las horas no consumidas se restablecen a favor del proveedor ya que éste reserva horas de recursos para ello. Para mantenimiento perfectivo igual que adaptivo - Change Requests – no se reserva una bolsa de horas dentro del acuerdo, sólo se define el precio hora.

A continuación incluyo algunas alternativas a MS Project Server. Gradualmente iré estudiándolas e incluiré datos adicionales e comparativas. Si alguien tiene experiencia trabajando con estas aplicaciones no duden en añadir comentarios.

• @Task – http://www.attask.com/
• Vertabase Pro – http://www.vertabase.com/
• Copper Project – http://www.copperproject.com/
• Creativa Manager Pro – http://www.creative-manager.com/
• Tracker Suite – http://www.trackersuite.net/
• ProjectTrack 2007 – http://www.ilore.com/
• ValleySpeak Project Server – http://www.valleyspeak.com/
• Project Planner – http://www.smartworks.us/
• B-Kin Project Monitor – http://www.b-kin.com/