Abreviaturas utilizadas:
AP: Administrador de Proyecto o Administración de Proyectos.
GP: Grupo de Procesos.
KB: Knowledge Base.
Desde que estudiaba los principios de la Informática, he tenido la convicción de que la centralización de la información de una compañía es siempre la mejor opción en cuanto al manejo de sistemas informáticos automatizados. Aunque ya en la práctica, esa no es la realidad con la que nos enfrentamos en la pequeña y mediana empresa, incluso en las grandes empresas pecan como el dicho: “en casa de herrero cuchillo de palo” a la hora de aplicar las mejores prácticas según su propia experiencia; y tienen gran cantidad de sistemas descentralizados en lugar de tener un equipo de desarrollo de software encargándose de unificar su KB.
El PMBOK hace referencia a la Base Corporativa del Conocimiento (KB) desde una perspectiva de Administración de Proyectos, por ejemplo: bases de datos para la medición de procesos, archivos de proyectos como cronogramas, lecciones aprendidas de proyectos anteriores, gestión de problemas e incidentes, etc.
Al respecto, me llamó la atención en el siguiente video:
Como el autor habla de la Evolución de los Sistemas de Información (específicamente KB):
“Are focused on providing a central repository of highly controlled content used by staff, partners and customers to help themselves, and by support staff, to be used across all self-service and assistance support channels.”
Mi traducción de la definición de los KB son: “Sistemas automatizados enfocados en proveer un repositorio central de información utilizado por el staff, socios y clientes para que se ayuden a ellos mismos, y por el staff de soporte, que utilizarán el software en todos los canales de auto-servicio y soporte técnico”, desde lo que llama un “Closed-loop information flow” (flujo de información de ciclos cerrados), lo que el PMBOK, 2008 (Cap. 10.5) llama “Informar el Desempeño” aplicado al desarrollo del software. Si aplicamos las mejoras continuas que resultan de lo que el PMBOK denomina el GP de “Seguimiento y Control” que brindan la retroalimentación en el GP de “Ejecución”, el software y la capacidad del mismo va a proveer un medio visual de reportes de manera que es esperado que la cantidad de usuarios crezca, hasta el “New Generation KB”, que involucre múltiples recursos de alto conocimiento técnico y Administradores de Proyectos para liderar y dirigir proyectos de alto volumen de “stakeholders”.
Necesitaba definir lo que para mí es el principal objetivo de negocio al que deben estar enfocadas las organizaciones a nivel de gestión de su información; por lo que en mi carrera profesional aplico esta visión, en la medida de lo posible, en la empresa a la que contribuyo. Ahora entiendo que esta visión la debo de comunicar por escrito a la hora de laborar en proyectos que contengan este objetivo definido, ya que al no existir un documento de objetivos algunos stakeholders importantes no van a conocer la dirección que lleva el departamento.
Cuando me contrataron en la compañía en la que trabajo actualmente, lo hicieron pues tenían la problemática del manejo de la información en muchos sistemas distintos sin interfaz común entre los mismos. Lo cual es común en empresas pequeñas y medianas, pero cuando las compañías crecen (como en este caso) se ven obligadas a tener un excelente manejo de su información, o si no lo hacen, esto puede ser un obstáculo en el futuro, a corto o mediano plazo. Con mi experiencia trabajando en una empresa orientada a proyectos como lo es IBM, se aprenden muchas pautas y mejores prácticas que utilizan; pero aplicar esta metodología a una empresa con organigrama 100% funcional es una odisea que debe ser muy bien planificada y estructurada.
Después de un análisis de la naturaleza del negocio y los procesos internos del manejo de información nos dimos cuenta de esta necesidad, y la mala experiencia con contrataciones de out-sourcing nos llevó a conformar un equipo de lo que éramos 4 programadores para lo que se tenía como visión el desarrollar un ERP (sistema centralizado de información) realizado a la medida para la empresa. La planificación la efectué con colaboración de mi jefe, el gerente de IT (Irving Amador) y muchos miembros de la gerencia y operación de la empresa. Expusimos el diseño conceptual del proyecto en la junta directiva y se aprobó.
En ese momento nos veíamos en el escenario de querer desarrollar un proyecto de centralización de toda la información de la empresa a partir de un nuevo sistema automatizado desarrollado internamente, con su fase inicial para el primer entregable con una duración de 1 año.
Con el conocimiento adquirido en el transcurso de esta maestría en AP puedo ver que hasta ese punto del proyecto ya faltaban varios aspectos importantes como lo son: redactar un chárter bien definido, con el alcance del proyecto e identificación de stakeholders.
Se duraron alrededor de 2 mes y ½ para la contratación e introducción del equipo a los objetivos de la empresa y en la planificación inicial de lo que se iba a desarrollar, y dimos por iniciada la fase de ejecución de un proyecto estimado en 1 año.
En la Guía APP (Yamal Chamoun, 2002) me llamó la atención el uso atinado del término “comisionar” para expresar en una palabra el rol del AP en el ciclo de vida de la fase de ejecución, o desarrollo en este caso, del proyecto. Este rol implica procurar la cohesión de uno o varios equipos de trabajo desde sus inicios, y mantener esta retroalimentación durante todo el desarrollo y cierre de cada proyecto. Pero lo más importante, es mantener unido al grupo de trabajo para que quieran seguir trabajando en otros proyectos con el mismo equipo; además como otro factor importante, saber delegar las tareas que puedan explotar las habilidades y metodologías de trabajo de cada miembro del equipo.
Después de cumplido ese año y 2 meses de proyecto, se realiza, a cuestas, la primera implementación en la operación de una sucursal de la empresa. Durante 1 mes estuvimos dedicados a dejar el sistema estable en producción, y se inicia la planificación y ejecución de otros proyectos de expansión y creación de módulos de software. Actualmente llevamos 4 años de desarrollar sistemas de software para TouchScreen, dispositivos móviles, Web y Windows operando en 10 sucursales de la compañía; todos son una interfaz interactuando con la misma Base de Datos como punto centralizado de información.
Ahora observo, con el conocimiento adquirido en este curso de IAP (UCI), que la transición de la finalización de un proyecto a otro conlleva la definición clara de fases del proyecto, y la definición clara del fin de un proyecto y el inicio de otro. Si no se realiza este proceso con pautas y controles, esto resulta en desorden en los objetivos de la empresa en relación reciproca con lo que se está desarrollando por medio de los canales de comunicación de la gerencia, al AP y al equipo de trabajo.
Además, que una clara definición y comunicación de la visión del grupo de trabajo de un proyecto es de suma importancia para la alineación de los objetivos recíprocamente desde el equipo de trabajo hacia los objetivos de la empresa.
Por ejemplo, algo que hubiera hecho diferente, y cambiaré de ahora en adelante, es que al inicio no se pautaron claramente los requerimientos de operación y mantenimiento de un sistema ya entregado a nivel de Recurso Humano calificado. En el caso de un sistema de software, como en este, se necesita definir en los supuestos (antes de iniciar la ejecución del proyecto) que el producto final va a requerir de un Administrador de Base de Datos, al menos 1 Administrador del Sistema, una persona encargada de realizar los reportes que solicitan los usuarios, involucrar de llenos al personal de soporte técnico y un canal definido de soporte a la nueva aplicación, entre otros.
Todos estos supuestos aplican a casi cualquier sistema de software nuevo, por lo tanto nosotros lo dábamos como algo obvio, pero no lo pusimos por escrito en la planificación de este proyecto, lo que nos perjudicó a la hora de implementar el software. Ya que el equipo de trabajo que se tenía que dedicar a las nuevas fases del proyecto y más adelante a otros nuevos proyectos tuvimos que involucrarnos en alrededor de un 40% en estas tareas operativas del software. Lo que originó un traslape fuerte y complicado de las tareas del proyecto con las tareas de operación que se han ido alivianando con el tiempo solo con la ayuda y colaboración del gerente de IT y el equipo de soporte técnico; pero que hasta la actualidad nos está afectando.
Otro de los aspectos de oportunidad de mejora que nos ha afectado en estos proyectos, ha sido el de definir la envergadura del alcance del proyecto; es decir, todo lo que íbamos a incluir en el proyecto estaba bien definido, pero no definimos lo que no íbamos a realizar en cada fase. De manera que las expectativas de muchos stakeholders de importancia fueron muy altas con respecto al verdadero alcance. Por ejemplo el Gerente de Finanzas esperaba que en la primera fase toda la parte de Finanzas y Contabilidad se encuentre lista, cuando en realidad la primera fase del proyecto era enfocada a la operación como tal y no a la parte financiera, que teníamos planeada en siguientes fases.
Lo que origina el no tener las limitaciones bien definidas en el alcance por escrito, es descontento por parte de algunos stakeholders clave, además de desaprovechamiento del tiempo en reuniones para comunicar y explicar estos asuntos que se obviaron en un principio; ya que esto afecta futuros proyectos. O sea, se toma más tiempo al intentar comunicar y explicar el alcance una vez finalizado un proyecto, que en el principio como debería de ser y se define así en el PMBOK.
En síntesis, aunque los proyectos anteriores en los que he estado involucrado tienen un alto grado de éxito con respecto a la tríada, la gestión de calidad y satisfacción de los usuarios, sponsor y otros stakeholders; pudieron haber sido mucho más exitosos (satisfacción de mas stakeholders) con el conocimiento de mejores prácticas en AP como son las del PMI y ampliadas por otros profesionales en el área. Esto debido a que la debilidad en este aspecto, principalmente nos ha perjudicado en nuestro potencial de desarrollar nuevos proyectos con el status quo actual del equipo de desarrollo de software.
Anexo:
