Ascendente o descendente: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". Aquí se explica la administración de proyectos, la administración de carteras y la administración de tareas, y se comparan las prácticas de administración ascendentes y descendentes relacionadas con ellas.

Para descargar la versión de Word de estas notas del producto, vea Administración descendente o ascendente: notas del producto (Project Server 2010).

Para ver más notas del producto, vea las notas del producto de la colección "Desde las trincheras".

¿Administración descendente o ascendente?

"Necesitamos administración de proyectos... mmm, quise decir administración de carteras... mmm, en realidad, administración de tareas… bueno, necesitamos todo", es un grito de batalla que escucho a menudo. No es la falta de definiciones de estos tres conceptos lo que crea confusión, sino su similitud.

Aquellos de nosotros que han trabajado en TI durante muchos años tendemos a ver las cosas desde una perspectiva técnica y a veces no es muy útil. Si analizamos los datos de administración de carteras, administración de proyectos y administración de tareas, es posible que tengan un aspecto muy similar. Tengo un campo de identificador, un campo de descripción y una fecha de inicio y de finalización en las tres. Vincular las tres administraciones debería ser natural entonces.

Tal vez no.

Veamos estos tres conceptos uno a la vez. Es fácil ver sus similitudes, pero hay diferencias fundamentales en las tres perspectivas.

Administración de carteras: un enfoque vertical

Los usuarios pueden entender diversas cosas diferentes por "administración de carteras", pero el significado más común es probablemente la selección de proyectos y la clasificación por prioridades. Los principios finalmente afectan a todos los usuarios de la organización, pero el proceso es de gran interés para los altos ejecutivos. La administración empieza con determinadas restricciones, como un presupuesto total disponible y la necesidad de responder a la pregunta "¿Qué podemos y qué debemos lograr con esta cantidad de dinero?". Si el proceso de administración de carteras es lo suficientemente maduro, este análisis podría incluir no solo nuevas ideas sino también proyectos existentes.

Panel que muestra el estado de varios proyectos

Para crear un proceso de selección de carteras y de asignación de prioridades, la administración debe enfrentarse a los criterios empresariales que impulsan la compañía y acordar de antemano las métricas que se tendrán en cuenta al buscar proyectos nuevos y existentes. ¿El retorno de la inversión debería ser una métrica clave? Quizá deberíamos considerar los efectos en la satisfacción del cliente o la retención del personal o la alineación con objetivos estratégicos. Sin importar cuáles son las métricas clave, la administración tiene que sopesar cada iniciativa de proyecto desde la perspectiva de cómo ese proyecto puede lograr dichos objetivos y la forma en que cada proyecto se compara con iniciativas alternativas en las que se podría utilizar el dinero.

Se trata de un proceso altamente analítico incluso si se realiza mentalmente. Sin duda es muy analítico cuando está utilizando software de administración de carteras de proyectos. Incluso una vez que se recibe el análisis desde el software en un informe o una vista, prácticamente siempre hay alguna supervisión en el nivel de la administración donde se logra una decisión definitiva acerca de las prioridades. Cuando eso se ha completado, los resultados finales deben transmitirse a aquellas personas que tendrán que realizar la administración de proyectos de cada uno de los proyectos. Los efectos de estas decisiones serán fundar algunos proyectos y no fundar otros, para que estén disponibles los recursos con una mayor prioridad para algunos proyectos y no para otros, y para avanzar la programación de algunos proyectos y para retrasar los demás.

Administración de proyectos: descendente y ascendente

Una vez que se aprueba un proyecto, se mueve a un territorio totalmente diferente. Ahora la vista más clásica de la programación del proyecto entra en foco. Ahora tenemos que construir lo que hemos descrito en nuestra justificación empresarial antes de que la aprueben.

Un jefe de proyecto comienza a pensar en términos de ámbito del proyecto y las entregas. El jefe de proyecto conoce el producto final que se debe crear, ya sea una herramienta de software o un edificio listo para ocupar. Es posible que piense en las fases principales de ese proyecto y cree una estructura de descomposición del trabajo.

Principales fases de un proyecto representadas en un gráfico

Se diseña una ruta crítica de los pasos lógicos necesarios para completar el proyecto. El jefe de proyecto también sabe que él o ella se tendrá que dar cuenta de la programación que se produce, por lo que consulta diversos expertos en el proyecto. El jefe de proyecto crea una vista ascendente del proyecto al mirar tarea por tarea y resumir esas tareas en las fases del proyecto y, finalmente, en el propio proyecto. En este momento el jefe de proyecto también puede iniciar la asignación de recursos por aptitudes, por departamento o incluso por nombre. Es posible que estos recursos tengan costes asociados a ellos. El resultado de calcular la duración de las tareas, los recursos necesarios y sus tasas nos brindan un presupuesto ascendente del proyecto.

Hasta el momento, vamos bien.

Vista de gráfico de Gantt de un proyecto

Pero cuando analizamos el enfoque descendente del proceso de selección de carteras de proyectos, había un coste también. De hecho, el coste calculado del proyecto formaba parte de la justificación empresarial que la administración había considerado al aprobar el proyecto. Si estamos simplemente obteniendo el presupuesto ascendente del proyecto de experiencia combinada de los expertos en el tema ahora, ¿qué se usó en la selección de proyectos en grupo de ejecutivos?

Es una buena pregunta. En algunas organizaciones, al proyecto se le asignará un cálculo aproximado del departamento de proyectos a fin de crear una justificación del negocio para el proyecto. En otras organizaciones, se crea un presupuesto ascendente completo antes de considerar el proyecto en el proceso de cartera. El problema con ambos métodos es que demandan esfuerzo. Un presupuesto completo puede demandar una gran cantidad de esfuerzo y, sin embargo, el proyecto aún no ha recibido la aprobación de financiar cualquier esfuerzo. Por lo tanto, en muchas organizaciones, un miembro de la administración simplemente hace un cálculo aproximado en torno a los costes de este proyecto.

Entonces el proceso parece todo integrado pero puede haber una especie de circulo vicioso aquí. ¿Qué ocupa el primer lugar, el trabajo dedicado a realizar el presupuesto o la selección del proyecto para poder dedicar mucho tiempo en el proyecto?

Además, ¿qué ocurre si el presupuesto ascendente no coincide con el presupuesto del proceso de selección de carteras? Si el presupuesto es menor, entonces probablemente no hay ningún problema, pero si el trabajo no se puede completar en el tiempo o el presupuesto estimado por el personal de selección de carteras, existe un conflicto.

Puede pensar que lo natural sería convocar a los directivos y solo debatir sobre el problema, pero hay muchas situaciones en las que no es tan fácil como parece.

En primer lugar, el comité de selección de carteras rara vez está conformado por el personal de administración de proyectos. Los miembros del personal ejecutivo de administración de proyectos están casi siempre incluidos en el comité de selección de carteras, pero el propio grupo suele estar conformado por directivos muy altos a los que les resulta un desafío coordinar el tiempo para estar todos juntos. En segundo lugar, el comité de selección puede reunirse de forma irregular, por lo que reunirlos para examinar todas las ramificaciones de un coste que no coincide para un proyecto frente al presupuesto podría ser un gran desafío. Por último, hay algunas culturas corporativas donde no representa un avance para la carrera tener que entregar las noticias al ejecutivo cuya estimación es completamente errónea con respecto al programa adecuado y al presupuesto para el proyecto.

Tareas de administración: un enfoque ascendente

Cuando nos referimos a tareas de administración, tendemos a pensar muy operativamente, y eso la mayoría de las veces nos lleva a nuestra agenda diaria y a un producto como Outlook.

Vista de una lista de tareas

Ahora estamos trabajando en el nivel de individuo o de miembro de un equipo pequeño. No vemos las tareas en contexto. Vemos las cosas a las que nos hemos comprometido o quizá aquellos elementos que le hemos pedido a un miembro del equipo. Esto no es una vista analítica en absoluto. Hay tareas por realizar y una persona que se ha comprometido a llevarlas a cabo.

En esencia, la administración de tareas es muy sencilla. Realiza la tarea y una vez que la completó le informa a la persona que se la asignó que la tarea está completa. Toda la funcionalidad para esto ya está presente en Outlook.

El engaño de datos similares

Hay un dicho: "Si es similar a un pato y grazna como un pato, debe ser un pato". Esto es cierto para los patos, pero no es siempre verdadero para los datos basados en tareas.

Veamos estos tres niveles de datos orientados al proyecto:

  • En el nivel de cartera, tenemos un proyecto y, quizás, fases debajo de ese proyecto. La información de la fase puede incluir un número de código, una descripción, una duración, una fecha de inicio y una fecha de finalización.

  • En el nivel de proyecto, tenemos un proyecto y tareas debajo el proyecto. La información de la tarea puede tener un número de código, una descripción, una duración, una fecha de inicio y una fecha de finalización.

  • En ese nivel de administración de tareas, tenemos una tarea y la información de la tarea puede tener un número de código, una descripción, una duración, una fecha de inicio y una fecha de finalización.

Seguramente tengan la misma apariencia, pero de hecho, la perspectiva de los datos hace que cada uno de estos registros comunes sirvan para un propósito muy distinto.

A menudo me preguntan: "¿puedo mover los datos de la vista de la cartera a la vista del proyecto para Outlook y al revés?".

La respuesta directa a esa pregunta es "sí".

Pero en nuestra firma tenemos un mantra que recordamos cuando ofrecemos asesoramiento técnico: "No me diga cómo hacerlo, dígame por qué debería hacerlo".

  1. Para ser más claros, imagine este ejemplo. Realizamos un entorno totalmente integrado. En el extremo superior de la escala tenemos una lista de proyectos organizados por cartera. No solo seleccionamos estos proyectos, sino que los integramos aún más, y los seguimos después de que se activan en proyectos activos desde el sistema EPM. Para ello, usamos la funcionalidad que ya está disponible para mover el proyecto y la fase de definiciones desde la cartera de nuestro sistema integrado hasta los proyectos del sistema. Los datos parecen idénticos.

  2. En nuestro sistema de administración de proyectos empresariales ahora realizamos una definición más detallada, usando las fases originales de la definición de carteras que se insertó de forma descendente. Al hacerlo, es posible actualizar el resumen en el sistema de carteras cuando actualizamos nuestros proyectos. Realizamos muchas tareas y asignamos muchos recursos. Ahora realizamos un análisis de nivelación de recursos para determinar nuestra capacidad en muchos proyectos.

  3. Usamos nuestras asignaciones de recursos para insertar los datos de las tareas y las asignaciones a cada usuario como un evento de calendario o una tarea de Outlook. Los usuarios ya no necesitan ir a un "sistema de administración de proyectos". Ahora pueden ver sus datos en su agenda diaria. Los datos se ven tal como en la lista de proyectos y se vinculan de manera más ascendente para la vista de cartera.

  4. El progreso de estas tareas y la disponibilidad en Outlook se devuelven desde el individuo hasta el sistema de administración de proyectos junto con los cálculos de cuándo se completará este trabajo. Los datos se ven igual que en los otros dos sistemas, de modo que mover los datos es relativamente fácil.

La creación de este tipo de sistema es técnicamente muy sencilla mediante las herramientas disponibles actualmente junto con un poco de configuración y desarrollo. Y eso se demostraría de maravilla.

Nos plantean exactamente este tipo de estructura de forma periódica. Sin embargo, aunque podemos hacerlo, ¿deberíamos hacerlo?

Imagine que en el nivel de tarea, un individuo se toma la mañana por una visita de emergencia al odontólogo y actualiza su Outlook para indicar que no estará disponible esa mañana. Es una mala noticia pero los efectos de propagación para el proyecto podrían ser masivos. Ahora, el sistema del proyecto calcula que la tarea que estaba programada para hacerse esta mañana no se completará hoy; se completará únicamente al medio día del día de mañana. Obedientemente analiza la ruta crítica y todas las tareas que dependen de esta y las pospone por cuatro horas. Tal vez cientos de tareas se ven afectadas. El resultado podría ser posponer la fecha de finalización del proyecto medio día más tarde. Otros proyectos también se ven afectados ya que otras personas que trabajan en este proyecto deben reorganizar sus tareas y la vista de cartera en sí se desliza hacia delante unos pocos píxeles.

Si imaginamos esto en tiempo real, el problema se agranda. Cientos o miles de personas deben realizar cambios a lo largo del día, y la vista de EPM, la vista de redistribución de recursos y la vista de cartera se animan constantemente con los efectos.

En realidad, esto no es así. Primero, el desventurado paciente dental volverá a su cargo al mediodía y puede trabajar unas cuantas horas más tarde esa noche para asegurarse de poner al día la ruta crítica y todo volverá a su curso en la mañana.

Además, aunque los datos parecen ser los mismos, nunca se integran de este modo debido exactamente a ese efecto.

Contexto de datos: la perspectiva importa

Cuando se analizan los datos, el contexto de los datos es fundamental. Los datos que tienen el mismo aspecto en el esquema de registro a registro se usan para fines muy diferentes en función de la perspectiva de la aplicación.

En una vista de cartera descendente, se toman decisiones estratégicas de dónde colocar nuestros recursos para maximizar el retorno de la inversión. Es posible que tomemos decisiones que un jefe de proyecto no tomaría. En mi propia organización, a veces elegimos proyectos que están totalmente fuera de nuestro conjunto de aptitudes existentes, sabiendo que obtendremos un resultado terriblemente ineficaz, pero lo hacemos porque queremos mejorar esas aptitudes. El retorno de la inversión no era una instalación efectiva, sino entrenar a los instaladores. Esta es una vista analítica.

En una vista táctica del proyecto, se toman decisiones operativas sobre dónde obtener el mejor rendimiento de nuestro personal y cómo obtener nuestros proyectos finalizados de la manera más rápida y eficiente posible. El ojo de un jefe de proyecto está siempre puesto en el futuro. Qué ha ocurrido en el pasado es solo de interés del jefe de proyecto en cuanto a que mejora su perspectiva del futuro. Esta es también una vista altamente analítica.

En una vista de administración de tareas, como una agenda, no somos analíticos. La agenda es un sistema de compromiso. Nos comprometemos nosotros mismos o comprometemos a los demás a realizar una determinada tarea en un momento determinado. Es posible que esto se adecue a la vista analítica. Y es posible que no.

Mezclar estas perspectivas y contextos sin comprender el impacto puede provocar un verdadero caos.

¿Administración descendente o ascendente?

Como de costumbre, no hay una respuesta correcta. Algunos aspectos del sistema de administración de proyectos realmente necesitan una administración ascendente. Después de todo, al final, son las personas las que van a crear las bases del proyecto. Pero algunas decisiones se toman, o deberían tomarse, en el nivel superior y son, por necesidad, descendentes.

Al mantener la distinción de para qué es cada nivel del paradigma de administración de proyectos, queda más claro si algunos de estos sistemas deben integrarse realmente o no. Si el proceso y el concepto de un nivel no tienen un beneficio directo por estar plenamente integrados desde otro nivel, entonces la integración no es la mejor opción. Es importante experimentar cómo funcionaría esa integración en un contexto del mundo real y si la frecuencia y el detalle de un nivel ofrece cualquier valor a los demás.

Diagrama que muestra un flujo de trabajo

Si, por ejemplo, un comité de dirección solo se reúne una vez por trimestre para tomar decisiones importantes sobre qué proyectos avanzarán y cuáles no, ¿cuál es el beneficio de actualizar sus vistas cada día, cada semana o incluso cada mes?

¿El algoritmo de redistribución de recursos de la administración de proyectos empresariales necesita realmente ver la cita con el odontólogo o es suficiente con conocer la disponibilidad aproximada de esa persona?

Incluso, si pudiéramos enviar una asignación a la agenda o la planilla de horas trabajadas de un individuo directamente, ¿eso permitiría ahorrar unos minutos cada día al tener que ir a un sistema diferente y realizar interfaz para ver los mismos datos?

Por lo tanto, la administración descendente es correcta en algunas circunstancias y la administración ascendente es adecuada en otras. Debe analizar su propia situación para ver en qué casos la integración de estas herramientas y conceptos puede devolver los dividendos correctos antes de vincularlos.

Acerca del autor

Chris Vandersluis es el presidente y fundador de HMS Software, con base en Montreal, Canadá, un asociado certificado de Microsoft. 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 miembro desde hace muchos años del Project Management Institute (PMI) y ayudó a fundar 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 encuentran Fortune, Heavy Construction News, la revista Computing Canada y PMI’s PMNetwork. Además, es columnista estable de Project Times. Dicta Administración avanzada de proyectos en la Universidad McGill y realiza disertaciones sobre las funciones de la asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de planillas de horas trabajadas TimeControl orientada a proyectos y ha sido un asociado de Microsoft Project desde 1995.

Puede ponerse en contacto con Chris Vandersluis al siguiente correo electrónico: chris.vandersluis@hms.ca.

Si quiere leer más artículos relacionados con EPM de Chris Vandersluis, vea el sitio de información de EPM de HMS (http://www.epmguidance.com/?page_id=39).

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Únase a los participantes de Office Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×