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:
6 comentarios:
Me parece muy interesante la conclusión de tu ensayo, algo que tal vez a mucho nos ha sucedido que es el hecho de realizar un esfuerzo generoso, conquistar muchos de los propósitos del proyecto, pero; si no cubrimos a todos los stakeholders, sobre todo los claves, siempre habrá desazón de algunos de ellos por no recibir lo que esperan en su completa expectativa, aún cuando en ocasiones ellos no han participado del kick off del proyecto donde se exponen los alcances.
Aquí el uso del charter y en especial la definición de los alcances, como mencionas, sobre todo lo que NO incluyen las etapas de desarrollo, deben quedar bien documentadas de una forma explícita.
Me parece debemos luchar por ser agentes de cambio en nuestra compañía -en la que ambos trabajamos- e iniciar las prácticas del PMBoK con la estandarización de un charter para marcar los alcances, stakeholders y responsabilidades, así como la calidad técnica de nuestros trabajos y definir las normas de calidad requeridas.
Mariano, muy buen ensayo, el tema de knowledge base es interesantísimo, yo tengo una maestría en gestión de conocimiento y se lo retador que es hacer lo que vos hiciste en tu empresa. Ahora la combinación del tema con la administración de proyectos te va a dar mucha fortaleza y relevancia internamente en la empresa.
Cualquier día podemos hablar sobre knowledge management, knowledge sharing, etc.
Agradezco tu comentario, decidí escribirlo así puesto que como humanos tenemos nuestra parte personal y profesional y somo "integros" como lo sugiere el Pmbook para el proyecto. Esta integridad como personas afecta positiva o negativamente en el desarrollo de los proyectos.
Saludos.
Al igual que menciona Alexander, me parece muy interesante la síntesis que realizas en tu ensayo, ya que muchas veces cometemos el error de considerar exitoso un proyecto porque cumplió en alcance, tiempo y costo y dejamos de lado la calidad del producto o servicio que le entregamos al cliente y su satisfacción, factores que son a mi parecer tan o más importantes que la famosa triada.
Buenas tardes Mariano… me parece muy acertado el enfoque de tu ensayo, respecto a la los procesos de iniciación que debemos de realizar en los proyectos, para evitar malos entendidos, re trabajos, o disgustos de parte del cliente. Como vimos durante el curso el 80% de los proyectos fracasan por un mal manejo en el proceso de planificación, por lo que debemos de prestar más atención a esto.
Mariano, comparto por completo la sugerencia que mencionas con respecto a la designación del recurso humano requerido para la operación y mantenimiento de los sistemas ya entregados, pues en el caso que mencionas, se partió de hecho de suponer algo que para ustedes, como desarrolladores de software era obvio, sin embargo, para los demás miembros de la compañía no lo fue, y esto repercutió en que se tuviera que destinar parcialmente el recurso humano destinados al desarrollo del software para el incorporarlo a la parte operativa, logrando atrasos en el desarrollo de los módulos siguientes y retrabajos por parte de los diseñadores.
Otro aspecto que me parece importante destacar es la definición del alcance del proyecto de forma completa, incluyendo lo que se incluye y lo que no se incluye, pues esto evita generar falsas expectativas por parte de todos los involucrados del proyecto y se evitan malos entendidos y explicaciones del por qué no se obtuvo algo que se creía era parte de los entregables del Proyecto.
La conclusión que mencionas me parece muy interesante, pues manifiesta que los proyectos aún siendo cumpliendo los objetivos en cuanto al alcance, tiempo y costo, siempre deben analizarse y visualizar cuales aspectos se pueden mejorar, de ahí la importancia de tener una base de conocimiento en la administración de Proyectos para poder implementar buenas prácticas y aumentar el grado de éxito obtenido.
Mariano, muy interesante tu ensayo, se ve que has logrado adaptar tus conocimientos adquiridos hasta ahora en el desarrollo de tu trabajo profesional. Pienso que la creación e implementación de un softwere es uno de los proyectos más complicados, el administrador del proyecto debe tener una gran capacidad y conocimiento de las mejores prácticas en AP, rodearse de un gran equipo, y como lo indicas en tu ensayo, aparte de establecer lo que incluye, es importante también dejar claro lo que no incluye. Particularmente, pienso que el tratamiento con los “Stakeholders” es de sumo cuidado en este tipo de proyectos y es de suma importancia la capacidad negociadora de AP.
Publicar un comentario