¿Para qué tanto control y metodología?

Un día al término de la jornada laboral, antes de retirarme, un colaborador analista de testing, me pide una reunión, y entre diversos temas que conversamos resaltaron dos preocupaciones que tenía de los cambios que estabámos ejecutando.

La primera de ellas, "¿para qué tantos controles en el proceso?"

Para responder, recordé qué el colaborador tenía un negocio familiar, un restaurante.  Antes de responderle la pregunta, le formule una cuestión respecto a su negocio, "cuando tienes un cambio de turno de personal, y ellos salen con bolsas o maletines, ¿les revisan el contenido?", la respuesta fue afirmativa, entonces le hice una nueva pregunta, "¿por qué?", "porque en ocasiones se llevaban insumos, comidas o utensilios sin autorización".  Es decir, tuvo un problema y decidió aplicar un control para evitar que siga ocurriendo.   Adicionalmente los controles no siempre es por alguna ilegalidad que esté ocurriendo, sino simplemente para asegurar el cumplimiento de la actividad, así como, no se aplica en todos los casos sino a una muestra.   Y dependerá de la madurez del proceso y de las personas que la ejecutan, la necesidad de mantener el control.

La segunda pregunta, fue "¿para qué tanta metodología?", igualmente haciendo referencia a su negocio familiar, le pregunté, "¿cuál es el plato de bandera del restaurante?", "el lomo saltado", me respondió.  Adicionalmente le pregunté, "¿cuantos cheff tienen durante la semana? ", "tres cocineros", me respondió.  Le comenté que tenía mucha suerte, porque para tener tres cocineros, el sabor del lomo saltado era igual durante todos los días de la semana.  Y me comentó su secreto, "los platos tienen descrito un paso a paso que todos los cocineros lo deben seguir, para asegurar el sabor", entonces le dije, "esa es tu metodología".   La metodología te permite estandarizar la ejecución de las actividades, que permite en un primer momento asegurar el mismo producto en todo momento, con la misma calidad, característica, costos, etc., y adicionalmente te permite mejorar, optimizar y madurar el proceso y producto.

El temeroso y audaz colaborador que se atrevió (para bien...) a cuestionar los últimos cambios que veníamos aplicando, cambió en su perspectiva de cambios, logrando entender el propósito de las actividades.   Este cambio le permitió entender el resto de cambios, con lo que en el tiempo, asumió las responsabilidades de liderar el equipo de testing, luego la responsabilidad de calidad de los procesos, hasta el último reto asumido del equipo de desarrollo de software.

¿Pará qué tanto control y metodología?...

Organicémonos...

Muchas veces nos encontramos abrumados con la cantidad de requerimientos de sistemas que recibimos de nuestros usuarios, adicionales a la cantidad de problemas que nos reportan día a día, todo el equipo, toda el área de sistemas, esta abocada a atender las diferentes necesidades de nuestros usuarios, pero aún así, faltan manos para atenderlos todos. Finalmente, la situación conlleva a incumplimiento de fechas, postergación de la atención del requerimiento, insatisfacción del usuario, mala calidad del producto, estrés en el equipo de trabajo, etc.

En principio, debemos establecer una organización adecuada para la atención en el área de sistemas, si bien es obvio y la teoría lo dice, en la práctica, debido a nuestra desesperación, los roles en la organización no están definidos o no se cumplen. Tener claridad en cada uno de los servicios que el área de sistemas ofrece o es responsable, por ejemplo, soporte en la atención de incidentes tecnológicos de la compañía, atención de requerimientos de hardware y software, atención de requerimientos funcionales de las aplicaciones, desarrollo de proyectos tecnológicos, etc. Para cada uno de estos servicios tendremos definidos los procesos, perfiles, funciones y responsabilidades. Estos perfiles serán cubiertos por personas a quienes se les asignarán las funciones y responsabilidades para cumplir con la atención de los servicios del área. Debemos definir las responsabilidades para cada uno de los integrantes de nuestro equipo de trabajo, evitando que todos cubran todas las funciones o que todos realicen todas las tareas.

Ante la abrumadora cantidad de requerimientos, un punto muy importante, es establecer el procedimiento y las políticas de atención de cada uno de los servicios, donde se establece, quién debe solicitarlos, a través de que canal, como por ejemplo,

1. La atención de requerimientos, que corresponden a pedidos de nuevo hardware, software o funcionalidad adicional para las aplicaciones, en estos casos, debe ser solicitado o aprobado por el dueño del presupuesto del área solicitante, en vista que debe asumir el costo de la inversión o el gasto de la atención.
2. Para la atención de un requerimiento de funcionalidad adicional para una aplicación, deberá tener la aprobación del usuario dueño responsable de la aplicación, quien debe mantener el modelo conceptual definido para la aplicación, si no es así, cualquier persona solicitaría alguna funcionalidad sin los criterios del modelo conceptual.
3. Todos las solicitudes deben quedar registradas en una fuente de información o en todo caso a través de un solo canal de comunicación, o integrándolos, como Sistema de Mesa de Ayuda, a una cuenta de correo mesadeayuda@... o un número telefónico o anexo de la empresa que permita registrar la solicitud, eliminando cualquier pedido a través de un canal informal.
4. La solicitud debe ir acompañado de una prioridad o un orden de atención respecto a las solicitudes pendientes anteriormente ingresadas.
5. Toda atención completada debe tener la conformidad de la atención por parte del solicitante.

Para los servicios habrá un procedimiento de solicitud y atención que permitirá establecer el orden de los pasos a seguir, mientras que las políticas establecerán los principales requisitos para la atención.

Finalmente el registro centralizado permite no sólo tener la información en un sólo punto para hacer seguimiento a las atención, sino también permitirá explotar la información mediante estadísticas, para detectar y analizar los patrones de comportamiento, por ejemplo,

1. Incidentes por errores en las aplicaciones. Detectar patrones para priorizar la corrección del problema, en función al número de errores producidos y/o al impacto funcional del problema.
2. Requerimientos de hardware y software. Analizar compras periódicas para concentrarlos en compras por volumen.
3. Tiempos de atención de incidentes y requerimientos, que permitirá optimizar el número de personas para el área, así como definir el estándares de niveles de servicios para con el usuario cliente.
4. Estrategia de implementación de soluciones. La relación de los requerimientos de hardware y software priorizados, permitirá una adecuada planificación de la implementación y de inversión.

En resumen, organicémonos... de acuerdo a las funciones y responsabilidades por los servicios que brindamos, con ayuda de políticas y procedimientos, que son mejorados de acuerdo al análisis de estadísticas e indicadores, para identificar patrones y priorizar soluciones.

Un Momento para la Gestión...

En nuestros proyectos, somos buenos desarrolladores, conocemos diferentes técnicas de desarrollos, amplia base metodológica, estándares claros, estimaciones precisas, pero un defecto, muchas veces, nuestros planes de trabajo no consideran tiempos para la gestión, tiempo para controlar y hacer el seguimiento a los planes de trabajo, tiempo para administrar las actividades detalladas del plan de trabajo. Estos tiempos, también son parte del proyecto, son tareas del jefe de proyecto.

No tener estos tiempos considerados en el plan de trabajo, implica mayor esfuerzo para el jefe de proyecto para realizar sus tareas de desarrollo y las tareas de gestión (no considerados en el plan), con la finalidad de cumplir con las fechas comprometidas, o en todo caso, sinceraremos el plan de trabajo moviendo las fechas o ingresando un recurso adicional al proyecto.

Para evitarlo, es necesario e imprescindible, considerar los tiempos para la gestión, control y supervisión. A continuación un grupo de actividades que considero deben estar incluidos dentro de los tiempos de gestión, con estimados de tiempos, que dependen del tipo de proyecto, de las características de los perfiles del equipo de trabajo, y de las características del usuario:

1. Resolver dudas, consultas y/o coordinaciones diarias de cada uno de los participantes del equipo de trabajo. (0.50 horas por día por recurso)
2. Resolver dudas, consultas y/o coordinaciones diarias del cliente y/o usuarios. (1.00 hora por día)
3. Revisar los reportes de horas semanales de los participantes del equipo de trabajo.(0.10 horas por semana por recurso)
4. Actualizar semanalmente el plan de trabajo, registrar los avances, reestructurar las actividades y asignaciones de recursos. (0.40 horas por semana por recurso)
5. Elaborar reportes e informes de avances semanales, (0.50 hora por semana)
6. Reuniones semanales de reporte de avance con el cliente y/o usuarios. (1.00 horas por semana)
7. Reuniones semanales de reporte de avance con mi gerente supervisor. (1.00 horas por semana)

Para un ejemplo de proyecto con un equipo de cinco recursos podríamos necesitar 22.5 horas semanales del jefe de proyecto, insisto en que, de acuerdo a las características del proyecto, del equipo de trabajo y del usuario deben evaluarse las actividades de gestión, así como los estimados de tiempo de cada una de ellas. Pero en general, siempre necesitaremos de Un Momento para la Gestión...

Control y seguimiento del proyecto ... un problema cultural

"No hay tiempo para realizar el control y seguimiento del proyecto", "no hay tiempo para elaborar los informes y reportes de avance", "no hay tiempo para reuniones de avance", son expresiones típicas y comunes por la que muchos de nosotros hemos pasado, hasta que nos convencimos que las cosas funcionan mejor con la gestión de proyectos.

Siempre he pensando que este problema común, es un problema cultural (cultura en la forma de trabajo) al cual nos es difícil adaptarnos (en un comienzo), lo tomamos como un trabajo engorroso que no tiene un beneficio "directo" con el desarrollo del software, con la construcción de la aplicación, y que únicamente sirve para informar los avances a la gerencia.

A veces creo que sólo somos especialistas en desarrollo, especialmente cuando empezamos, porque nos gusta analizar, diseñar, programar, en general construir aplicaciones, hacer que la computadora realice lo que queremos. Entiendo que si nos hubiera gustado como especialidad, el controlar y hacer seguimiento, posiblemente estaríamos en otra carrera. Pero lo que tenemos que comprender es que en general cualquier especialización a la que nos dediquemos requiere una administración, control, seguimiento para que finalmente logremos el objetivo trazado.

En estos casos, no es solamente conocer una metodología de control y seguimiento, es necesario entenderlo, es necesario vivirlo. Para ello, necesitamos darnos una oportunidad, que nos permita vivir un proyecto con el control y seguimiento adecuado, para entenderlo y con ello, compararlo con situaciones anteriores (proyectos sin control ni seguimiento), para evaluar y comprender el impacto positivo que anteriormente no era posible medirlo (en vista que no se entendía).

Ejemplos de impacto positivo,

1. Acciones oportunas, con el seguimiento, se detectan los problemas en el momento, y no al final cuando es mucho mas difícil corregir.
2. Equipo sin estrés (en proyectos con problemas o sin problemas), desde el momento que se tiene conocimiento de la situación real con las acciones de corrección claramente definidas, la situación es mejor (no necesariamente bueno, en proyectos con problemas), pero mejor.
3. Confianza en el plan, creer en el plan, creer en la fecha de termino, al margen de problemas y correcciones, tener la versión real de la situación, que nos permitan tomar la mejor decisión. Sin un seguimiento, la fecha del plan es irreal, con lo cual no es posible tomar la decisión adecuada.
4. Preocupación individual de cada integrante, teniendo el plan actualizado, cada integrante tiene una guia por cumplir, para evitar que el plan general (creíble para todos los integrantes) no se vea afectado. Esta actividad no es únicamente del jefe de proyectos (como pareciera inicialmente), entendemos que la gestión es de todos los integrantes (cada uno en sus actividades), donde el jefe de proyectos los consolida.

Al tener el impacto positivo, valoraremos más el esfuerzo por realizar el control y seguimiento, entenderemos mejor sus beneficios y será difícil dejarlo en los siguientes proyectos, con ello habremos cultivado la cultura de control y seguimiento en los proyectos.

Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte III)

Primeros logros ...

En este proyecto fuimos reconocidos como el equipo que tenía la mejor gestión de proyectos. Además de reducir el promedio 35% de variación con respecto al esfuerzo estimado inicial los proyectos (promedio de la evaluación de proyectos de 1999) a sólo 2% por responsabilidad del equipo de trabajo, permitió sentir los primeros éxitos en un proyecto, recordando que, "Este proyecto no fracasará... " se estaba cumpliendo...

No sólo logramos cumplir con las expectativas del proyecto en cuanto a avances, fechas y resultados económicos, sino también se incrementó la confianza del equipo de trabajo respecto a su desempeño, se generaba expectativa positiva y motivación en el equipo sobre el plan de trabajo, la planificación de las vacaciones se cumplían....

Asimismo, teníamos la confianza de nuestro usuario, que además, realizaba una más exhaustiva evaluación de los requerimientos que solicitaba ... en vista que se tenía claramente registrado los requerimientos y/o incumplimientos por su responsabilidad.

Con la confianza y buenos resultados, empezábamos a generar una cultura positiva en el equipo respecto a la gestión de proyectos.

Difusión total ... Replicación masiva ...

Otros proyectos empezaron a buscarnos para utilizar la metodología de control operativo de proyectos (esquema de control y seguimiento) para mejorar su desempeño y cumplir con sus objetivos.

Empezamos a capacitar a los diferentes jefes de proyectos con los temas de gestión de proyectos y luego con la metodología de control operativo de proyectos, para seguidamente pasar a la implementación de la metodología en cada uno de sus proyectos. Esta implementación se realizaba en cinco semanas, donde al final el jefe de proyectos tomaba el control de la metodología y de su proyecto.

Cuando terminamos la implementación de la metodología de control de proyectos teníamos información suficiente para evaluar la variación del esfuerzo estimado de cada uno de los proyecto para esa fecha. El resultado, 15% como promedio de variación con respecto al esfuerzo estimado inicial de los proyectos.

Esta reducción a 15% del promedio de variación del esfuerzo estimado de los proyectos, indicaba que ibamos por la dirección correcta con el uso de la metodología.

Nueva meta ... nuevo objetivo ...

Consideraba que lo razonable en los proyectos de desarrollo de software, el promedio de la variación de los esfuerzos estimados debería estar por debajo del 10%, fijamos la meta de 5%.
Al cabo de varias semanas ... con el ingreso y salidas de proyectos fuimos ajustando el indicador hasta llegar al 5% y a partir de alli lo mantuvimos entre el 5% y 7%.

Al tener estandarizada la gestión de los proyectos con la metodología de control y seguimiento nos permitiría consolidar todos los proyectos en un plan consolidado, con lo cual tendríamos claramente, no sólo, las fechas de inicio y fin de cada proyecto, o las variaciones de los mismos, así como las responsabilidades identificadas para cada equipo de trabajo o para el usuario, sino también podíamos controlar los ingresos y salidas de los recursos de manera que optimizabamos los tiempos muertos entre proyectos, negociando los inicios de los nuevos proyectos, ajustando las vacaciones de los colaboradores a los periodos libres entre proyectos.

Una forma de asegurar el pan para mañana ...

El estandar de control y seguimiento de proyectos nos permite controlar los proyectos y optimizar el uso de los recursos, pero además, en el caso de las consultoras cuyo negocio es ejecutar proyectos, las cobranzas están relacionadas a los entregables de cada proyecto, es muy útil el estandar debido a que los entregables nos dan la referencia del flujo de caja positivo, mientras que los pagos a los colaboradores nos dan como referencia el flujo de caja negativo, teniendo por consiguiente el flujo de caja de cada proyecto y finalmente un flujo de caja del
consolidado de todos los proyectos de la consultora. Inclusive, podemos establecer metas sobre el flujo de caja del consolidado de los proyectos, incluyendo proyectos futuros aun no iniciados.

Finalmente, a cocachos aprendí ...

Para nosotros, desarrolladores de sistemas es importante conocer y saber utilizar la herramienta de desarrollo y las metodologías de desarrollo, también es importante el resultado tecnológico funcional del producto en elaboración, pero en algunos casos, no se le da la suficiente importancia a la gestión del proyecto.

Por tanto, podemos terminar con un producto tecnológica y funcionalmente fabuloso y espectacular, pero tal vez, no en la fecha esperada inicialmente, o no con los recursos económicos inicialmente presupuestados, o tal vez con un equipo de trabajo estresado y cansado, esperando no participar en otro proyecto similar.

Con el estandar de control y seguimiento de proyectos, lo importante es la tranquilidad y confianza en un equipo de trabajo durante la ejecución del proyecto, en base a una identificación real y oportuna de los imprevistos y variaciones en el proyecto, de manera que, se tomen las acciones correctivas rápidamente, cuyas soluciones son más faciles de implementar, en comparación a la acumulación de problemas por la falta gestión y seguimiento.

Finalmente, proyectos con calidad, terminados en tiempo y dentro de presupuesto, con los recursos productivos, eficientes y satisfechos, es realmente posible, en la medida que la gestión y seguimiento sea más importante para las empresas y los equipos de trabajo.

Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte II)

Microsoft Project... la herramienta

Tenía experiencia utilizando MS Project desde 1996, pensaba que sabía utilizar la herramienta, cuando en realidad sólo registraba las actividades para mostrar en un diagrama de gantt. Para mostrar los avances, registraba los porcentajes o construía un nuevo diagrama de gantt. Para el esquema de control del nuevo proyecto, pensé en definitiva utilizar el MS Project, pero esta herramienta debería tener una mayor utilidad, que simplemente mostrar un diagrama de gantt (en todo caso, podríamos utilizar el MS Excel para hacer lo mismo, sin gastar en licencias de otros productos).

Con el MS Project buscaba cerrar el ciclo completo de control y seguimiento de un plan de trabajo, es decir, que basándome en un plan de trabajo inicial con actividades y recursos definidos, debería periódicamente alimentarlo con las horas aplicadas (horas reales) por los recursos en las diferentes actividades, así como modificaciones en las actividades y/o sus estimados de esfuerzo o fechas de realización, de forma que con los ajustes necesarios, terminaba siendo en mi plan de trabajo inicial para el siguiente periodo.

Finalmente logré establecer el ciclo completo, para quienes conocen MS Project, dos funciones completaron (para mí) el complejo esquema de control y seguimiento de un plan de trabajo, "reprogramar trabajo restante" y "redistribuir recursos", ambos permiten "sincerar el proyecto" debido a las diferentes variaciones en las actividades durante el periodo.

Esquema de control y seguimiento ... su impacto y sorpresas ...

Inicialmente, mientras definía el esquema las revisiones y actualizaciones semanales del plan de trabajo me tomaban alrededor de 12 horas, para 4 recursos en el proyecto, incluía, registrar los reportes de hora de cada uno de los recursos, identificando las actividades de los reportes en el plan de trabajo, ingresar nuevas actividades no contempladas inicialmente, identificar y analizar las variaciones en el proyecto, buscar justificarlas, reajustar el proyecto para reducir o eliminar el atraso en el proyecto, para finalmente cerrar con el informe de avance semanal. Cuatro meses después la actualización semanal tomaba alrededor de 1.5 horas, para 10 recursos en el proyecto, ¿qué cambio?

1. Madurez del esquema de control y seguimiento. Metodología de Control Operativo de Proyectos.


2. Mayores herramientas de identificación de variaciones, como vistas, reportes, etc.


3. Mejora en el registro del reporte de horas de cada uno de los recursos. Más sincero.


4. Mayor compromiso de cada uno de los recursos en sus actividades, debido a la identificación de responsabilidades dentro del proyecto.


5. Mejora en el cumplimiento de los tiempos y estimados de esfuerzo en las actividades para cada uno de los recursos. Cada uno administraba su "plan de trabajo".


6. Reevaluación previa de las actividades futuras y sus estimados que permitan tomar acciones de corrección con anticipación.


7. La identificación anticipada y oportuna de los atrasos o incremento de los esfuerzos por reestimación, que permiten recuperar el tiempo con mayor holgura y tranquilidad. Evitando acumular los atrasos al final de cada fase, entregable o final del proyecto, donde no existe tanto margen de acción.


8. La actitud positiva del equipo de trabajo, creyendo en el objetivo del proyecto, creyendo en el equipo de trabajo y creyendo en el plan de trabajo.


9. Finalmente, la cultura de planificación, control y seguimiento en cada uno de los participantes en el proyecto, como herramienta imprescindible para el mejor desarrollo de los proyectos.
   

Con todos estos cambios, todos los recursos estaban alineados y comprometidos con sus actividades, veía en cada uno de ellos,

1. No habían atrasos que recuperar, o eran mínimos. Mínimas variaciones, justificadas por los recursos y fácilmente recuperables.


2. Rápido registro de horas de los recursos


3. Mínimo reajuste, en vista que no hay atrasos.


4. Mínima justificación por responsabilidad del equipo de trabajo.


5. Sin estrés en el proyecto, sin amanecidas u horas extras innecesarias.
   

Por ello, la actualización se redujo de 12 horas a sólo 1.5 horas en la semana. El proyecto mantenía sus fechas originales o sólo tenía alguna variación por requerimientos adicionales de los usuarios.

Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte I)

Sólo metodología de desarrollo poca gestión...

En 1996, iniciamos un proyecto de consultoría para la reingeniería de una área en una compañía financiera, con el análisis de los procesos logramos la reducción de tiempos, optimización de las actividades para lograr un área eficiente que permita a la compañía financiera estar preparada para incrementar su producción en los próximos años. Finalmente, este proyecto determinó la necesidad de desarrollar un nuevo software para el área que permita automatizar los procesos optimizados ya implementados.

Por ese entonces, mi experiencia en proyectos de desarrollo era alrededor de 7 años, habiendo participado en 10 proyectos aproximadamente, tanto como programador, analista programador y líder de proyecto. Mis conocimientos de desarrollo se basaban en las metodologías de desarrollo de software, tanto para análisis, diseño, programación, pruebas, gestión, etc.

Para el nuevo software para los procesos optimizados, se preparó un proyecto de desarrollo, donde tenía la responsabilidad del proyecto, era el líder del proyecto, participé en la definición y estimación del proyecto, calculado en 24 meses de duración. Finalmente, iniciamos el proyecto con un equipo estaba conformado inicialmente por 4 personas. Al cabo de 2 meses de proyecto, el analista principal (persona con mayor experiencia en el proyecto) comenta respecto a los resultados de la evaluación económica del proyecto (resultado positivo): "Con el resultado obtenido a la fecha, el proyecto fracasará económicamente...". Este comentario, que lógicamente no me gustó, me hizo pensar: "¿cómo es posible que en dos meses de avance de un proyecto de 24 meses, podamos señalar que el proyecto (en positivo) fracasará, teniendo todo el tiempo por delante para tomar las acciones correctivas necesarias para evitarlo?. Pero, el problema no era el comentario, al margen si era cierto o no, finalmente no sabía como controlarlo, para evitar a que fracasara.

A partir de esa fecha, me enfoqué a las metodologías de análisis, diseño y programación, para que el proyecto no fracasara, también teníamos planes de trabajo, pero no había el seguimiento correcto, tampoco lo entendía en ese momento. El proyecto terminó con los alcances solicitado, pero no en los plazos estimados, ni con los resultados económicos esperados, mi compañero tuvo razón, pero no porque sea un visionario, sino porque no hicimos las gestiones necesarias para evitarlo y corregirlo. Luego de esa experiencia pensamos en, darle énfasis a la supervisión de la aplicación adecuada de las metodologías de desarrollo, insuficiente claro, no lo entendía en ese momento, el tema de gestión era muy gaseoso ...

En los siguientes meses, nos dedicamos a la supervisión de proyectos bajo la metodología de desarrollo definida por la consultora, con planes de trabajo y seguimiento periódico a la metodología, pero algo faltaba...

Escalofriantes números ...

A finales de 1999, realizamos un análisis de los proyectos desarrollados durante el año, incluían aquellos iniciados antes de 1999 y aquellos que terminarán después de 1999. La evaluación debería determinar la variación del esfuerzo real total (horas hombre aplicadas más horas hombre pendientes por aplicar) con respecto al esfuerzo total original de la propuesta de cotización. El resultado fue, el esfuerzo real era un 35% adicional respecto al esfuerzo de la propuesta original, es decir, estábamos trabajando un 35% más del esfuerzo por el cual estamos cobrando. Este adicional que representaba un equivalente a 60 meses de sueldo de una persona promedio en la organización, o la planilla de sueldos de un mes.

Incluso se pensaban que no era 35% sino 50% ..., en realidad el 35% o 50% adicional no solo consideraba la responsabilidad del equipo de trabajo, por no controlar adecuadamente el proyecto, sino también incluía requerimientos adicionales del cliente, o modificaciones a las especificaciones iniciales que por motivos diferentes no eran presupuestados y por tanto, era asumido por el proyecto. ¿Motivos?, falta de control y seguimiento al proyecto, inexperiencia del equipo para identificar los adicionales o modificaciones, "rabo de paja" por los errores cometidos durante el proyecto, que no permite negociar con el cliente, falta de gestión comercial, etc.

Consideraba que con un mayor control y seguimiento al proyecto en lapsos de tiempos mas cortos podría reducirse el esfuerzo adicional, o podría rápida y fácilmente identificarse cualquier requerimiento adicional o modificación bajo la responsabilidad del cliente. El problema era ¿cómo identificar? ...

Un fracaso más, si importa ...

En el año 2000, iniciamos un proyecto cuyo contrato tenía muchas penalidades por incumplimientos de cláusulas, ya cansado de tantos proyectos estresantes por carga de trabajo, plazos sin cumplir, resultados económicos negativos, etc. Me propuse definir un esquema de planificación y control, que me permita identificar las diversas variaciones de esfuerzo y de fechas de las actividades, a lo largo de la ejecución del proyecto. Que, esta identificación de variaciones también me permita identificar al responsable de los mismos, de manera que se tenga claramente identificados las responsabilidades del contrato. Decía: "Este proyecto no fracasará, y menos por mi responsabilidad...".

Tenía los elementos suficientes para el éxito del proyecto, esquema de organización adecuada, buenos recursos, experiencia metodológica en el desarrollo de proyectos, pero faltaba el esquema de control...Es decir, tenía todos los elementos suficientes para sobrevivir en la selva, comida, agua, carpa, abrigo, herramientas, linternas, etc. pero, ¡¡¡no tenía el mapa ni una brújula!!!

Con mi copiloto al lado...

¿Cual es nuestro problema? es que para mantener el trabajo, pensamos en que debemos atornillamos a nuestros puestos, donde en lo posible, nadie más conozca como lo hacemos. Y con ello, no nos damos cuenta que, de esa manera, nosotros mismos cortamos nuestras oportunidades.

Desde hace varios años, al iniciar cualquier proyecto personal o profesional busco un Copiloto como apoyo. Con la Gerencia de Sistemas como responsabilidad busqué tener a una persona que conociera todas las actividades que yo realizaba, y principalmente que conociera los criterios con los cuales tomaba las decisiones. De esta manera, a parte de cubrirme ante cualquier ausencia mía, me apoyaba en momentos de mucha carga de trabajo. Y para mi Copiloto una oportunidad para crecer profesionalmente realizando actividades sobre nuevos roles.

Contar siempre con un segundo a tu lado, nos permitirá mejorar nuestras oportunidades, un Copiloto con potencial profesional para que te reemplace ante cualquier situación (cosa que, pocos son los que lo hacen, por temor a perder el puesto). Copiloto a quien le debes enseñar todo lo que haces tu. ¿Cuál es el fin?, que puedas salir de vacaciones, que te ayude en épocas pico, pero cual es el motivo principal (egoísta si quieres verlo), que finalmente en el momento en que estés preparado para tomar nuevas responsabilidades, tienes a alguien preparado en tu puesto para reemplazarte, con lo cual, tranquilamente vas a tomar tus nuevas responsabilidades.

Una manera de fomentar estos desarrollos personales y profesionales, es solicitando a mis colaboradores directos que busquen "ocupar mi escritorio", ocupar mi puesto, de manera que intenten hacer las cosas de la misma forma que yo o mejor aún. En estos casos, mis colaboradores preocupados por si esto sucedía, me preguntaban, "¿y luego que vas a hacer?", yo respondía ... "siempre hay nuevas oportunidades...".

Cuando tu jefe necesite asignar una nueva responsabilidad, preguntará, ¿quién lo puede tomar?, decidirá por ti ya que estas profesionalmente preparado, luego, la siguiente pregunta será, ¿y lo que haces, quien lo puede hacer?, en caso no haya nadie, la asignación en tu persona será muy difícil. En cambio, al tener tu Copiloto al lado fácilmente podrás acceder a esa nueva oportunidad.

Al final, todos ganamos, uno mismo al crecer con las oportunidades, el Copiloto quien recibe la enseñanza y también las oportunidades y la organización con una actitud al crecimiento y desarrollo, más no atornillarse en el trabajo.

Por fin me animé ...

Por fin me animé ... compartir mis anécdotas, experiencias profesionales y personales que recibí en el tiempo. Desde hace varios meses anduve pensando abrir un blog de este tipo, que aún no sé cómo elaborarlo... pero vamos a intentarlo...

Espero que estas anécdotas y experiencias puedan ser recibidas para el mejor provecho de cada uno de uds. en la forma como me ha servido a mí.

Tengo estudios de ingeniería industrial con experiencia en el área de tecnología, particularmente en desarrollo de software y gestión de proyectos.