Dicen que lo que quieren es una resolución
Este artículo forma parte de nuestra colección "From the Trenches". Describe algunos desafíos comunes a los que puede enfrentarse al programar proyectos. Describe el mejor enfoque al intentar determinar cuánto tiempo deben ser las tareas y cuántas tareas debe haber para optimizar una programación de proyecto. Describe cómo los distintos sectores suelen requerir diferentes tipos de programaciones (por ejemplo, desarrollo de software, EPM (ingeniería, adquisiciones y construcción) y apagado de la planta. También se describen varios factores a la hora de elegir la resolución del proyecto (por ejemplo, la longitud del proyecto, los recursos implicados, la administración o división de recursos, la velocidad y el esfuerzo necesarios para recopilar datos y la programación de actualización de datos).
Para descargar la versión de Word de este artículo, consulte They say they want a resolution: white paper (Project Server 2010).
Para ver más artículos, consulte las notas del producto "Desde las trincheras".
Dicen que lo que quieren es una resolución
Con disculpas a los Beatles por el título, el tema de hoy es la resolución de su proyecto.
Hay una gran cantidad de materiales disponibles sobre cómo hacer una programación, pero una de las lecciones más críticas es muy difícil de obtener: ¿cuántas tareas debe tener en la programación del proyecto y cuánto tiempo debe tener cada tarea?
Regularmente me enfrento a programaciones de proyectos que parecen impostablemente complejas o con administradores de proyectos que parecen indefensos para identificar problemas en su programación porque la programación está en un nivel de resumen. He visto un proyecto de más de cien años de duración (sí, en realidad) que era perfectamente adecuado en longitud y en el que había algunas tareas que eran décadas de duración. También he visto programaciones de proyectos que duraron solo una hora o menos que eran perfectamente adecuadas y en las que algunas tareas duraban solo un minuto. He visto proyectos con solo unas cuantas tareas y otras con más de 100 000 tareas.
El software que usamos hoy en día puede controlar miles de tareas y una amplia gama de duraciones.
¿Cuál es el enfoque correcto?
¿Cuánto tiempo deben ser las tareas y cuántas debemos tener para optimizar la programación del proyecto? Llamaré a esto la resolución del proyecto.
Diferentes trazos para diferentes personas
Dado que el requisito puede ser diferente para diferentes sectores, diferentes tipos de proyectos y diferentes situaciones, veamos cómo decidir cuántas tareas se deben incluir en la programación y cuánto tiempo deben ser las tareas.
Los diferentes tipos de proyectos naturalmente exigen diferentes tipos de programaciones. Vamos a pensar en tres ejemplos diferentes:
Desarrollo de software. Muchos proyectos de software tienen características comunes. Aunque cada proyecto de software es único, normalmente hay una fase de diseño, una fase de programación, una fase de control de calidad, una fase de documento y una fase de implementación. Los proyectos de software se suelen medir en semanas o meses, y se prestan a tareas que son un día a un par de semanas. La asignación de recursos aquí se asigna a menudo al nivel individual.
Aquellos que han adoptado el proceso agile para desarrollar software buscan "sprints" cortos de una o dos semanas y dentro de ese sprint colocan tareas que son de breve duración, pero la duración general del proyecto todavía se mide en semanas. Hablaremos más sobre el desarrollo de Agile un poco más adelante.
EPC: Ingeniería, Adquisiciones y Construcción. Los proyectos de EPC son los lugares en los que se inició la metodología de programación de rutas críticas. En este tipo de proyecto, se está desarrollando algo muy grande. Podría ser un gran proyecto de defensa, como el proyecto de misiles Polaris, que dio a pert diagramas su inicio, o podría ser una plataforma petrolera offshore, un nuevo barco o una planta eléctrica. En este tipo de proyectos hay una fase de ingeniería en la que se concibe el proyecto terminado. La fase de ingeniería suele tener algún aspecto que nunca se ha diseñado antes. La fase de contratación examina la localización, contratación y gestión de la entrega de suministros o subconsultas para elementos del proyecto. En la fase de construcción, el producto final se construye y, a continuación, se encarga para su uso. Por lo general, pensamos en programaciones de proyectos de EPC en muchos meses o varios años con duraciones de actividad que duran desde un par de semanas hasta un par de meses. No es en absoluto inusual tener entre 5000 y 20 000 tareas en un proyecto de este tipo. La programación de recursos aquí casi siempre se asigna al nivel de aptitud en lugar del individual, y (solo para agregar a la diversión) puede haber muchos subproyectos realizados en un programa o proyecto maestro para facilitar la administración.
Apagado de la planta. Cuando se realiza una programación de proyecto para el apagado y el cambio de mantenimiento de una planta, se trabaja en uno de los entornos de programación más desafiantes posibles. Un apagado de la planta para hacer mantenimiento viene en dos tipos: planeado y de emergencia. Dejemos el tipo de emergencia a un lado por un momento; es un mundo para sí mismo. La duración de un apagado planeado de la planta depende en gran medida del tipo de planta. Por ejemplo, una unidad de planta nuclear podría hacer un cierre y un cambio "rápido" de la planta en 12 meses. Una refinadora de petróleo podría durar entre 4 y 6 semanas. Pero el tipo de programa de proyecto de planta que me parece más interesante es un molino de fabricación como un molino de acero, un molino de papel, o algo similar. Hay miles o decenas de miles de plantas de este tipo en todo el mundo, y deben someterse a mantenimiento regular cada año o así.
El costo del apagado para estas situaciones se mide normalmente en el costo de oportunidad; el costo del producto que no se producirá mientras la planta esté inactiva y en mantenimiento. Este costo se mide en horas, y el costo puede ser superior a $150,000 a $250,000 por hora! Así que la presión es de minuto a minuto para hacer el trabajo. En este tipo de situación, el apagado suele durar entre 5 y 8 días y el retraso de un solo día se calcula en millones. Si solo está acostumbrado a programaciones más largas y tradicionales, podría pensar que, en unos pocos días, "¿cuántas tareas podrían haber?" pero no es en absoluto inusual que un cierre de este tipo tenga entre 2000 y 4000 tareas, cada una de las cuales dura entre 15 minutos y un par de horas. Las asignaciones de recursos aquí se realizan por aptitud, pero la redistribución de recursos rara vez se realiza en el personal. Con el costo por hora tan intenso, no importa si pones más personas en el proyecto, simplemente hacerlo con prisa. La redistribución de recursos en esta situación a menudo se realiza para cuellos de botella altamente restringidos. Por ejemplo, "solo podemos caber dos personas en la sala eléctrica, por lo que eso tiene que administrarse discretamente".
Ok, ahora tenemos tres tipos de ejemplos, y hay muchos más, pero estos tres servirán para los propósitos de la discusión bien. En el tipo uno (desarrollo de software), se obtienen tareas que suelen ser de un día o de dos días a dos semanas. En el tipo dos (EPC), se obtienen tareas de semanas o meses. En el tipo tres (apagado de la planta), obtenemos tareas que se miden en unidades de 6 minutos (1/10 de una hora), 10 minutos, 15 minutos (1/4 de una hora), hasta un par de horas. Es obvio que, en algunos casos, las tareas cortas tienen sentido y, en otras, las tareas largas son más adecuadas. Siguiendo la misma lógica, a veces tiene sentido tener un gran número de tareas y, a veces, simplemente no.
Factores para elegir la resolución del proyecto
Con estas tres distinciones, es fácil ver que la tarea de proyecto de EPC de dos meses parecería ridícula en una programación de apagado de seis días y que una tarea de 15 minutos estaría fuera de lugar en el proyecto EPC o Software. Pero aparte de referirse a este artículo y decir: "Vandersluis dice que es un proyecto de software, por lo que las tareas solo pueden durar entre 1 y 10 días", (y por favor, no hagas eso) ¿qué características del proyecto nos indican qué nivel de resolución elegir? Echemos un vistazo a algunas obvias:
¿Cuánto tiempo dura el proyecto?
Comencemos con lo más obvio. Si se espera que el proyecto dure unos días, como en nuestro ejemplo de apagado, no tiene sentido tener tareas de varios días de duración. A menudo, empezar con un enfoque descendente es productivo cuando se piensa en dividir el ámbito. Use el pensamiento de estructura de descomposición del trabajo. Comience con los componentes principales. Piense en tener no menos de 4 y no más de 20 elementos.
¿Es una regla? No, claro que no.
Es sentido común. Menos de 4 hace que se pregunte por qué dividió el trabajo en absoluto y más de 20 es demasiado difícil de mantener en la mente de uno a la vez. Personalmente voy con no más de 8 elementos por elemento WBS y eso es debido a algún artículo que leí hace años que sugería que un octágono era la forma simple más compleja que la mente podía reconocer inmediatamente.
Piénselo por un momento. Puede identificar un círculo, un triángulo, un cuadrado, un pentágono, un hexágono que tiene 6 lados, un heptagón que tiene 7 lados (ok, que uno es difícil de visualizar) y un octágono.
¿Puede identificar una forma de 9 lados sin contar? No puedo. Se llama "nonagon" para los aficionados a las trivias.
Por lo tanto, personalmente, me esfuerzo por el límite de 8 elementos, pero mi regla general es 4-20.
Para cada elemento que haya visto, piense en cómo debe dividir el trabajo. Una vez más, piense en la regla 4-20. Pero saber cuándo detener es el secreto. Los administradores de proyectos más recientes dividirán y dividirán y dividirán hasta que cada paso por la obra lineal sea una tarea administrada. Algunas buenas preguntas sobre la cuenca hidrográfica que puede plantearse sobre la duración de una tarea podrían ser:
¿Qué acción realizaría si esta tarea llegara tarde? Si la respuesta es "nada", es una buena indicación de que la tarea en la que está pensando es demasiado pequeña para que valga la pena administrarla. Si ese es el caso, estás mirando con demasiado detalle. Realice una copia de seguridad de un nivel, retroceda un paso y compruebe si ha terminado.
¿La recopilación de los datos de la actualización de esta tarea tardará más tiempo que la propia tarea? No siempre pensamos en qué tipo de esfuerzo se va a llevar a cabo para administrar una tarea programada, pero vale la pena pensar en ello aunque sea por un momento. Si va a tardar más esfuerzo en administrar la tarea de lo que tardará en completarse, eso es una buena indicación de que la tarea se está definiendo con demasiado detalle.
¿Cuánto tiempo dura esta tarea? Cuando estamos dividiendo el trabajo, a veces perdemos de vista lo minúscula que es una tarea. Las grandes fases en el nivel superior fueron quizás semanas largas, pero a medida que bajamos un par de niveles de granularidad, podemos caer fácilmente en la trampa de definir una tarea que se va a administrar y que solo tiene unos minutos de duración. Cuando llegamos a tareas diminutas, tenemos que preguntar cuál sería la ventaja de administrarlas.
Vamos a aplicar una comprobación de realidad a lo que acabo de hablar. En un proyecto de EPC de dos años, si una tarea de una semana es un día tarde, es casi seguro que no merece la pena tomar medidas. En un proyecto de software de seis meses, una tarea de una semana con un día de retraso probablemente no valga la pena tomar medidas. En un proyecto de cierre de seis días, una tarea de una semana con un día de retraso es una emergencia masiva. En otras palabras, una tarea de una semana en el proyecto EPC puede ser demasiado fina para un nivel de detalle; en el proyecto de software, probablemente sea justo; y en el proyecto Shutdown, es casi seguro que debe dividirse en más detalles.
¿Cuántos recursos están implicados?
Sé que solo estamos trabajando en el ámbito, pero cuando examinamos qué tipo de resolución necesitamos, merece la pena pensar en cuántas personas trabajarán en una tarea. En un proyecto de EPC grande, por ejemplo, es posible que tengamos docenas de trabajadores de una aptitud implicadas en una fase de trabajo. Pero cuando terminamos con muchas habilidades diferentes en la misma tarea, administrar esa tarea se vuelve muy difícil, si no imposible. Por lo tanto, en esa situación, las tareas que requieren muchas aptitudes diferentes probablemente deberán dividirse.
En un proyecto de software, tendemos a pensar en casi todos los individuos como un recurso altamente técnico con capacidades únicas. Además, en los proyectos de software es habitual tener muchas tareas que se pueden volver a asignar dentro de un departamento, pero solo una tarea asignada a una persona. Por lo tanto, cuando tenemos tareas que se asignan a un nivel de una sola persona de un grupo de recursos o departamento determinado (por ejemplo, programación de interfaces), estamos lo suficientemente cerca como para decir que no necesitamos más detalles.
¿Cómo se administran o dividen los recursos?
El modo en que se administran los recursos es un gran determinante en cómo dividir subparte las tareas. En grandes proyectos de EPC, por ejemplo, los proyectos a menudo se dividen en subproyectos que se empaquetaban a grandes subcontratistas. En esta situación tenemos que hacer un par de cosas:
Defina el trabajo de una manera que permita a un jefe de proyecto supervisar al subcontratista con la confianza de que el progreso que se está realizando es un gran factor.
Defina las tareas de forma que el personal de ingeniería y administración de proyectos del subcontratista entienda lo que significan sin ambigüedades.
Asegúrese de que el subcontratista comprenda y acepte el nivel de resolución que ha adoptado como estándar.
Cuando examinamos proyectos de cuello blanco como software, investigación biológica o ingeniería, es más probable que encuentremos una estructura de administración de matrices en la que los administradores de proyectos no poseen ninguno de los recursos y debemos trabajar entre administradores de departamentos que asignan esos recursos en muchos proyectos diferentes. En este caso, las preguntas clave serían:
¿En cuántos proyectos es probable que un recurso funcione en un solo día?
¿Cuánto tiempo tarda un empleado en cambiar de un proyecto a otro?
¿Se define el trabajo de forma que tanto los empleados como los administradores del departamento de recursos entiendan cómo asignar la aptitud adecuada?
Cuando examinamos un proyecto de apagado o construcción, tiendemos a trabajar entre equipos que están diseñados específicamente. En estas situaciones, un jefe del equipo de recursos podría estar administrando el equipo eléctrico (incluso si ese equipo incluye carpinteros y montadores de tuberías), un equipo de plomería o un equipo de renovación de unidades de calderas. El trabajo tiene que organizarse de tal manera que la tripulación pueda mantenerse ocupada durante todo el turno y que no lleguen encima de otra tripulación que ya trabaja en algo en esa área. Dada la intensa presión de completar un proyecto de apagado, el trabajo suele organizarse por trabajo primero, programado y, a continuación, reagrupado y dividido por un jefe de equipo de recursos para que cada líder de equipo pueda caminar solo con sus tareas en un documento y con todo el proyecto en contexto en otro. Por lo tanto, las tareas deben definirse de una manera que sea comprensible para el empleado y para el líder del equipo de recursos. Las tareas aquí se definen probablemente hasta la hora o con más granularidad hasta el décimo o cuarto de hora.
¿Con qué rapidez puede recopilar datos y cuánto esfuerzo se requiere?
Parece una pregunta tonta cuando está acostumbrado a ver que los datos del proyecto están bien alineados al final de la semana para revisarlos, pero cuando intenta determinar el nivel de resolución del proyecto, esta puede ser una pregunta clave. Por ejemplo, cuando trabaja con numerosos subcontratistas, es probable que obtenga algún tipo de actualización semanal o mensual. De hecho, es esencial compilar la cláusula de actualización de administración de proyectos en el contrato. En esta situación, debe integrar los datos de estas diferentes empresas en su propia empresa, validar que los datos de progreso tienen sentido y, a continuación, realizar su propio análisis e informes. En un modo EPC, probablemente se trate de una aparición mensual.
En un proyecto de apagado, deberá actualizar el proyecto cada turno, actualizarlo rápidamente y obtener las actualizaciones de los líderes del equipo de recursos en medio del siguiente turno. En esta situación, el personal del proyecto enjambre por toda la planta durante el turno, recopilando datos tan cerca como puedan y haciendo que los líderes del equipo de recursos y los foremen usen hojas "take-down" para "quitar" el progreso de sus asignaciones. En un proyecto de software o investigación, es probable que esté trabajando en una programación semanal o algo parecido con personas que informan de su propio progreso y pasan por aprobaciones durante un día o dos.
Este es un punto importante que se debe tener en cuenta cuando se examina el número de tareas que se deben tener en el proyecto, ya que hay un costo para recopilar los datos.
Por lo tanto, pensar en la rapidez con la que puede recopilar, aprobar, integrar, analizar e informar de los datos de forma periódica es clave, así como la consideración del costo de recopilar los datos y la rentabilidad de la inversión de esos datos que se recopilan.
¿Con qué frecuencia actualizaremos?
Estas son dos claves para determinar la cantidad de datos que puede recopilar e incluir:
Piense en cómo recopilará los datos.
Piense en la frecuencia con la que puede actualizar razonablemente el proyecto y proporcionar a la administración las herramientas de toma de decisiones necesarias para guiar el proyecto y los recursos en la dirección correcta.
He visto que algunos directores de proyectos insisten en que quieren pasar a la gestión de proyectos en "tiempo real" y a la colección de proyectos y, aunque esto puede ser posible en teoría, es terriblemente difícil darse cuenta en la práctica.
Cuando examinamos los datos de administración de proyectos, hacemos algunas suposiciones. Se supone que:
Los datos están todos allí. No esperamos ver algunas tareas que se actualizan y otras que no.
Todos los datos se actualizaron en un momento similar. No esperamos que la mitad de las tareas se actualizaron hace unos minutos, pero la otra mitad no se han actualizado durante dos semanas.
Todos los datos han tenido algún nivel de aprobación. Esperamos que el administrador del proyecto esté detrás de los datos que se presentan y que pueda decir "Esta es una representación justa y precisa del proyecto".
Los datos pertenecen juntos. No esperamos que el riesgo se desenfoque con los costos y con los recursos a menos que hayamos diseñado específicamente nuestros informes y análisis de esa manera.
A menudo pregunto a los ejecutivos que están entusiasmados con el concepto de administración de proyectos en tiempo real lo que harán si pudiéramos superar los puntos que acabo de plantear. "¿Está preparado para tomar decisiones de administración durante toda la semana?" Se lo pediré. La respuesta debe depender del nivel de resolución. En un proyecto de apagado, la respuesta debe ser "Sí". En un proyecto de software, la respuesta es probablemente "No, lo haremos semanalmente". Y en un proyecto EPC la respuesta sería, "Mensual".
En algún momento, la ley de disminución de los rendimientos comienza a decir: "Entregar informes de proyectos más rápido no nos dará ningún aumento en la eficiencia".
Revisión de su trabajo
Ahora ha tenido algo de comida para pensar, ha usado el método de desglose del trabajo para dividir los datos y ha observado algunas de las señales de advertencia de que los datos están demasiado definidos. Ahora es el momento de inclinar la programación contra la pared, retroceder y mirar el proyecto con alguna perspectiva. Sorprendentemente, muchos administradores de proyectos nunca hacen esto. Se ven tan atrapados en la definición de los últimos detalles y están tan ocupados dividiendo tareas una y otra vez que se empujan a sí mismos hasta la fecha límite de puesta en marcha y nunca buscan para ver si lo que han hecho será una pesadilla para administrar.
En algunos casos, los ejecutivos están seguros de toda esa formación de MBA de que "más detalles son mejores" y están presionando para esas tareas de 5 minutos o 15 minutos en proyectos de seis meses de duración.
Cambiar el proyecto antes de que se inicie siempre es más fácil que en cualquier momento posterior, por lo que el tiempo de compilación en la actividad de creación de programación para volver a trabajar la programación si es necesario.
¿Es demasiado?
A veces, los administradores de proyectos examinan el ámbito de lo que han creado y se dan cuenta de que están demasiado bien en un nivel de detalle. Si ese es el caso, la corrección es obvia. Puede ser un montón de trabajo, pero te agradecerás más adelante para que la programación sea más sencilla al subir de nivel.
A veces la imagen no es tan fácil. En algunos casos, es solo una vez que se ensambla toda la programación que el administrador de proyectos puede ver lo compleja que es. Los proyectos complejos son, por su propia naturaleza, más arriesgados y el riesgo en la economía actual es un factor de selección clave para los proyectos. Algunas preguntas que merece la pena tener en cuenta antes de que se ponga en marcha un proyecto tan complejo podrían ser:
¿Podemos hacerlo en pedazos? Algunos proyectos de riesgo se pueden dividir en porciones más pequeñas y, a medida que los proyectos más pequeños, su riesgo disminuye. Sin embargo, si usa esta estrategia, cada proyecto discreto debe tener su propio valor cuando se complete.
¿Debemos repensar el ámbito? A veces, las acciones más sencillas son volver a los diseñadores de la obra en primer lugar, explicar la complejidad que parece evidente en la programación y ver si el trabajo se puede volver a colocar. Esto a menudo conduce a un pensamiento innovador que nunca habría tenido la oportunidad de ocurrir.
¿Deberíamos hacerlo?
Algunos proyectos nunca fueron diseñados para ser, y el tiempo más barato para cancelarlos es el día antes de que comiencen. Si el riesgo del proyecto solo es evidente ahora, mejor darse cuenta ahora que más tarde. Al tejer los resultados de volver a realizar su programación en el proceso de administración de cartera de proyectos (PPM), es posible que el riesgo del proyecto más complejo empeore la puntuación de trabajo en una escala de retorno a la inversión.
Un ágil... No, un proyecto agile
Prometí decir algunas cosas sobre la administración de proyectos de Agile y si eres un fan de Agile y has leído hasta aquí, aprecio tu paciencia. La administración de proyectos de software a través del método Agile es algo de una filosofía, pero es una filosofía cada vez más popular con aquellos que han sido quemados en proyectos de desarrollo de software masivos que fallaron.
En un mundo de desarrollo de software agile, intentamos dividir nuestro proyecto en "sprints" de una a tres semanas de tamaño mordido y el objetivo de cada miniproyecto es acabar con código utilizable. En este caso, estamos trabajando dentro de algunas restricciones bastante conocidas para que nuestro nivel de resolución sea bastante seleccionado para nosotros.
Tenemos un período de una a tres semanas, los recursos están disponibles para nosotros y vamos a asignar trabajo a cada recurso. El número de posibles tareas que podemos definir en esa estructura es finito y esto se presta a mantener un nivel adecuado de resolución. Sí, puede entrar en problemas en Agile mediante la definición de tareas que son demasiado cortas. "Define Field1: 10 minutes, Define Field2: 10 minutes, Define Field3: 10 minutes" etc. pero es mucho menos común.
Agile se diseñó para un entorno de desarrollo corporativo donde estamos creando software para su uso interno, y su uso a menudo se extiende al desarrollo de software comercial. (Usamos el método aquí en HMS para nuestro propio desarrollo de TimeControl). El método Agile da como resultado un departamento de desarrollo más ágil y ágil, pero no va a ser aplicable a todos los sectores o incluso a todas las empresas de software. Si está realizando la administración de proyectos en un entorno de software, mi recomendación es leer en Agile, aprender de él y, a continuación, adoptar esos elementos (todos, algunos o ninguno) que le harán más eficaz.
Envolver
Al igual que con la mayoría de los aspectos de la administración de proyectos, no hay ninguna respuesta fija a las preguntas que al principio parecen ser tan obvias. El número de tareas que tiene en el proyecto y cuánto tiempo debe tener cada una de ellas es algo que necesita buscar para decidir... pero decides que debes.
Elegir el nivel de resolución del proyecto es una responsabilidad de administración de proyectos que puede ser un factor clave de éxito en la administración de la programación del proyecto.
Autor
Chris Vandersluis es el presidente y fundador de Montreal, HMS Software, un asociado certificado de Microsoft con sede en Canadá. Tiene una licenciatura en economía de la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es un miembro de larga data del Project Management Institute (PMI) y ayudó a encontrar los capítulos de Montreal, Toronto y Quebec del Grupo de Usuarios de Microsoft Project (MPUG). Entre las publicaciones para las que Chris ha escrito se incluyen Fortune, Heavy Construction News, la revista Computing Canada y PMNetwork de PMI, y es columnista regular de Project Times. Enseña administración avanzada de proyectos en la Universidad McGill y a menudo habla en las funciones de asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de mantenimiento de tiempo orientado al proyecto TimeControl y ha sido asociado de soluciones de Microsoft Project desde 1995.
Chris Vandersluis puede ser contactado por correo electrónico en: chris.vandersluis@hms.ca
Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación de EPM de HMS (https://www.epmguidance.com/?page_id=39).