El post de hoy! después de unos días de descanso… Control de tareas! Directos al meollo!
En la lista que a continuación se muestra, se identifican ciertas tareas que forman parte de la gestión más técnica, dejando de banda la económica aunque el éxito de estas vaya totalmente ligadas con el éxito del proyecto. Cualquier tarea de la lista adoptada por el desarrollador o técnico se ha de valorar como un aporte extra al trabajo del Project manager, ya que suelen ser responsabilidad de este.
- Identificar las tareas.
- Determinar las habilidades necesarias para realizar cada tarea, utilizando, por ejemplo, una matriz de responsabilidad.
- Identificar el personal disponible, tras negociar con los responsables departamentales.
- Garantizar la competencia personal, es muy probable que sea imposible casar las habilidades requeridas con los técnicos disponibles.
- Establecer la formación imprescindible para complementar la deficiencia en habilidades indispensables.
- Asegurar que los puestos físicos, maquinaria y stock de material para el personal seleccionado estén disponibles.
- Consideración lógica de subcontratación.
Aunque parezca una aberración tener que subcontratar personal o servicios a empresas externas teniendo una plantilla de ingenieros, material y herramientas. En el mundo empresarial y de desarrollo de proyectos es una cosa habitual. Por este motivo remarcaré algunas razones por las cuales la consideración de subcontratación se hacen necesarias en según qué situaciones.
- Lamina las puntas de trabajo que pueden producirse temporalmente.
- Utiliza recursos humanos ocasionales para un proyecto en concreto, sin la necesidad de incorporarlos permanentemente en la empresa.
- Reduce costes al tener la empresa subcontratada, al menos teóricamente, una mayor productividad en su especialidad o bien menores gastos generales.
- Aporta la experiencia y los conocimientos de empresas o profesionales externos, cuando la empresa no dispone de expertos en la materia.
- Minimiza parcialmente, los riesgos empresariales al trasladárselos al subcontratista.
Una vez comenzado el proyecto, es estrictamente necesario un control de este con un máximo rigor, ya que de ello depende el éxito del proyecto, y no se le puede responsabilizar a “los recursos”, el control de éste, puesto que es una responsabilidad ajena a su trabajo.
El control de proyecto se basa en unos ítems básicos que a continuación se detallan.
- Obtención de datos que posibilitan medir el progreso realizado.
- Comparación respecto al indicador planificado para detectar desviaciones.
- Evaluación de las causas que motivan los imprevistos.
- Corrección que reconduzca la desviación, si es negativa, o que saque partido de la misma si es positiva.
Una vez identificada la desviación es importante reaccionar ante esta, y no aspirar a que a pocos días, meses o horas antes de la entrega, se actúe sobre este último desviamiento (la entrega), haciendo imposible la recuperación sin repercutir en la calidad. Es de vital importancia el seguimiento de los proyectos durante la vida de estos y no cerca de la fecha de finalización.
- Paralizar la tarea
- Revisar la situación y analizar las causas
- Proponer soluciones y seleccionar la más idónea
- Conseguir el apoyo de todas las partes implicadas, incluso del cliente
- Actuar o implantar la solución propuesta
- Continuar el seguimiento y la medición.
Desde mi punto de vista, considero que si se tienen en cuenta estos factores en la gestión de los proyectos ya sea por su ausencia, o no, en el momento de evaluar si el proyecto ha sido exitoso o no, se ha de observar por quien y de qué modo se han llevado a cabo estas tareas. Considero que es importante atribuir al valor del proyecto un alto porcentaje de responsabilidad de su éxito o fracaso a su gestión.
El éxito del proyecto está muy ligado a una buena gestión, y no se puede atribuir toda la gestión interna de un proyecto a un ingeniero de desarrollo (ámbito R+D), técnico o recurso, o si, pero se ha de tener en cuenta, que el aporte que pueda realizar a la gestión es extra a su trabajo y que el prisma por el que ve un “recurso” no es el mismo que el de un gestor.
