Office
Iniciar sesión

Dicen que quieren una resolución: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". Aquí se describen algunos desafíos comunes con los que se puede enfrentar al programar proyectos. También se describe cómo lograr el mejor método al intentar determinar cuánto tiempo deberían durar las tareas y cuántas tareas debería haber para optimizar una programación del proyecto. Además, se analiza cómo los diferentes sectores normalmente requieren distintos tipos de programas (por ejemplo, desarrollo de software, EPM [ingeniería, compras y construcción] y cierre de fábrica). Se detallan varios factores que influyen en la elección de la resolución de proyectos (por ejemplo, la duración del proyecto, los recursos involucrados, 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 estas notas del producto, vea Dicen que quieren una resolución: 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".

Dicen que quieren una resolución

Con perdón de los Beatles por el título, el tema de hoy es la resolución de su proyecto.

Hay mucho material disponible sobre cómo realizar una programación, pero una de las lecciones más críticas es terriblemente difícil de conseguir: ¿cuántas tareas debería haber en la programación del proyecto y cuánto tiempo debería durar cada tarea?

Con frecuencia, me encuentro con programaciones de proyectos que parecen imposibles por su complejidad o con jefes de proyecto que parecen incapaces de identificar problemas en su programación porque la programación se encuentra muy resumida. He visto un proyecto que tenía más de cien años de antigüedad (sí, realmente) que era perfectamente adecuado en longitud y en el que había algunas tareas que tenían una duración de décadas. He visto también programaciones de proyectos que duraban solo una hora o menos que eran perfectamente apropiadas y en las que algunas tareas duraban solo un minuto. He visto proyectos con unas pocas tareas y otros con más de 100.000 tareas.

El software que usamos hoy puede controlar miles de tareas y una amplia gama de duraciones.

Por lo tanto, ¿cuál es el enfoque correcto?

¿Cuánto tiempo deberían durar las tareas y cuántas deberíamos tener para optimizar nuestra programación del proyecto? A esto lo denominaré la resolución del proyecto.

Trazos diferentes para diferentes personas

Debido a que el requisito puede ser diferente para los distintos sectores, diversos tipos de proyectos y diferentes situaciones, veamos cómo decidir cuántas tareas debemos colocar en la programación y cuánto tiempo deben durar esas tareas.

Los diferentes tipos de proyectos exigen naturalmente distintos tipos de programaciones. Pensemos en tres ejemplos diferentes:

  1. Desarrollo de software   . Muchos proyectos de software tienen características en común. Si bien cada proyecto de software es único, por lo general, hay una fase de diseño, una fase de programación, una fase de control de calidad, una fase de documentación y una fase de implementación. Los proyectos de software se miden habitualmente en semanas o meses, y eso se aplica a las tareas que pueden durar de un día a un par de semanas. Aquí la asignación de recursos se realiza a menudo de forma individual.

    Aquellos que han adoptado el proceso ágil para desarrollar software buscan acortar "sprints" de una o dos semanas y dentro de ese sprint colocar tareas que sean de corta duración, pero la duración general del proyecto se sigue midiendo en semanas. Hablaremos más sobre el desarrollo ágil un poco más adelante.

    Vista de gráfico de Gantt de sprints Agile
  2. EPC: ingeniería, compra y construcción   . Los proyectos de EPC han sido el punto de partida de la metodología de programación de rutas críticas. En este tipo de proyecto, se desarrolla algo muy grande. Podría ser un gran proyecto de defensa como el proyecto del misil Polaris que dio inicio a los diagramas PERT, o bien, podría ser una plataforma petrolífera marina, una nueva embarcación o una central eléctrica. En estos tipos de proyectos hay una fase de ingeniería donde se idea el proyecto terminado. La fase de ingeniería generalmente incluye algún aspecto que no se ha diseñado nunca antes. La fase de compra se enfoca en localizar, contratar y administrar la entrega de suministros o subcontratos de elementos del proyecto. En la fase de construcción, se construye el producto final y, luego, se comisiona para su uso. Por lo general, imaginamos las programaciones de proyectos de EPC en muchos meses o varios años con actividades que duran desde un par de semanas a un par de meses. No es raro tener de 5.000 a 20.000 tareas en un proyecto de este tipo. La programación de recursos aquí se asigna casi siempre en el nivel de aptitudes en lugar de forma individual, y (para agregarle un poco de condimento) puede haber muchos subproyectos incluidos en un programa o proyecto maestro para facilitar la administración.

    Vista de diagrama de Gantt de varios proyectos y subproyectos
  3. Cierre de la planta   . Cuando realiza una programación de proyecto para el cierre y la reestructuración de una planta para mantenimiento está trabajando en uno de los entornos de programación que más desafíos supone. El cierre de una planta para realizar mantenimiento puede darse de dos maneras: planeada y de emergencia. Dejemos el caso de emergencia a un lado por un momento; es todo un tema. La duración de un cierre de planta planeado depende profundamente del tipo de planta. Una central eléctrica nuclear, por ejemplo, puede realizar un cierre de planta "rápido" y volver a estar en ejecución en 12 meses. Una refinería de petróleo puede tardar entre 4 y 6 semanas. Sin embargo, el tipo de programación de proyectos de planta que encuentro más interesante es un molino de fabricación como una planta siderúrgica, una fábrica de papel o algo similar. Hay miles o cientos de miles de estos tipos de plantas en todo el mundo y deben llevar a cabo un mantenimiento periódico cada año.

    El costo del cierre para estas situaciones se suele medir en 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 de más de 150.000 USD a 250.000 USD por hora. Por lo tanto, la presión para finalizar el trabajo es minuto a minuto. En este tipo de situación, el cierre normalmente dura entre cinco y ocho días y la demora de un solo día se calcula en millones. Si solo está acostumbrado a programaciones más largas y tradicionales, puede imaginarlo en pocos días, "¿cuántas tareas podrían haber normalmente?" pero no es para nada raro que para un cierre de este tipo haya de 2.000 a 4.000 tareas, las cuales pueden durar cada una entre 15 minutos y un par de horas. Las asignaciones de recursos aquí se realizan por aptitudes, pero la redistribución de recursos rara vez se realiza sobre el personal. Con un coste por hora tan intenso, no importa si coloca más personas en el proyecto, lo que importa es llevarlo a cabo con rapidez. La redistribución de recursos en esta situación a menudo se realiza por cuellos de botella muy limitados. Por ejemplo, "solo caben dos personas en la sala eléctrica, por lo que debe administrarse discretamente".

    Vista de gráfico de Gantt de las tareas secuenciales

Bueno, ahora tenemos tres tipos de ejemplos, existen muchos más, pero estos tres serán útiles para los fines de debate. En el primer tipo (desarrollo de software), tenemos tareas que duran normalmente de uno o dos días a dos semanas como máximo. En el segundo tipo (EPC), tenemos tareas que duran semanas o meses. En el tipo tres (cierre de la planta), tenemos tareas que se miden en unidades de 6 minutos (1/10 de una hora), 10 minutos, 15 minutos (1/4 de hora) hasta un par de horas. Es obvio que en algunos casos, las tareas breves tienen sentido y en otros las tareas más largas resultan más adecuadas. Siguiendo la misma lógica, a veces tiene sentido tener un gran número de tareas y en otros casos no.

Factores que influyen al elegir la resolución del proyecto

Con estas tres distinciones, es fácil observar que la tarea del proyecto de EPC de dos meses sería ridícula en una programación de cierre de seis días y que la tarea de 15 minutos estaría fuera de lugar en el proyecto de EPC o el proyecto de software. Pero más allá de hacer referencia a este artículo y decir: "Vandersluis dijo que es un proyecto de software, por lo que las tareas solo pueden tener de 1 a 10 días de duración" (por favor, no lo haga), ¿qué características del proyecto nos indican qué nivel de resolución debemos elegir? Echemos un vistazo a algunos ejemplos obvios:

¿Cuánto tiempo dura el proyecto?

Empecemos con el más evidente. Si se espera que su proyecto dure unos cuantos días, como en nuestro ejemplo del cierre, entonces tener tareas que duren varios días no tiene ningún sentido. Empezar con un enfoque vertical es a menudo productivo cuando pensamos en subdividir el ámbito. Emplee un concepto de estructura de descomposición del trabajo. Comience con los componentes principales. Piense en no tener menos de 4 y no más de 20 elementos.

¿Es una regla? No, por supuesto que no.

Es sentido común. Con menos de 4 se plantea por qué se divide el trabajo y es muy difícil retener más de 20 en la mente a la vez. Personalmente, uso no más de 8 elementos por elemento de WBS y esto se debe a que hace algunos años leí un artículo en el que se sugería que un octágono es la figura simple más compleja que la mente puede reconocer inmediatamente.

Piense en eso un momento. Puede identificar un círculo, un triángulo, un cuadrado, un pentágono, un hexágono (que tiene 6 caras), un heptágono (que tiene 7 caras) —bueno, ese es difícil de visualizar— y un octágono.

¿Puede identificar una figura de nueve lados sin contar? Yo no. Solo para que sepa y haga alarde de ello, a esa figura se la denomina nonágono.

Por lo tanto, personalmente, estoy a favor del límite de ocho elementos pero mi regla general es 4-20.

Para cada elemento que ha analizado, piense cómo dividiría el trabajo. Nuevamente, piense en la regla 4-20. Saber cuándo detenerse es el secreto. Los jefes de proyecto con menos experiencia subdividirán, subdividirán y subdividirán hasta que cada paso sea una tarea administrada. Algunas buenas preguntas que se puede plantear sobre la longitud de una tarea podrían ser las siguientes:

  • ¿Qué acción debería llevar a cabo si se retrasa la tarea?    Si la respuesta es "ninguna", entonces es un buen indicador 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á teniendo en cuenta demasiados detalles. Retroceda un nivel, de un paso hacia atrás y vea si está listo.

  • ¿La recopilación de datos en la actualización de esta tarea llevará más tiempo que la tarea en sí?    No siempre pensamos en qué tipo de esfuerzo requerirá administrar una tarea programada, pero vale la pena pensarlo un momento. Si demandará más esfuerzo administrar la tarea que completarla, entonces es un buen indicio de que se está definiendo la tarea en un nivel de detalle muy fino.

  • ¿Cuánto tiempo dura la tarea?     Cuando subdividimos el trabajo, muchas veces perdemos de vista en cuán minúscula se convierte una tarea. Las grandes fases de nivel superior quizás llevaban semanas, pero a medida que descendemos algunos niveles de granularidad, podemos caer fácilmente en la trampa de definir una tarea para administración que solo demande unos pocos minutos. Cuando estamos frente a pequeñas tareas, nos tenemos que preguntar cuál es el beneficio de administrarlas.

Vamos a aplicar una comprobación de la realidad a lo que acabamos de mencionar. En un proyecto de EPC de dos años, si una tarea que demanda una semana se retrasa un día, seguramente no valga la pena iniciar ninguna acción al respecto. En un proyecto de software de seis meses, si una tarea que demanda una semana se retrasa un día, probablemente no valga la pena iniciar ninguna acción al respecto. En un proyecto de cierre de seis días, una tarea que demanda una semana y tiene un día de retraso representa una emergencia masiva. En otras palabras, una tarea de una semana en un proyecto de EPC puede ser un nivel de detalle demasiado fino; en el proyecto de software, probablemente esté bien y, en el proyecto de cierre, seguramente deba descomponerse en más detalle.

¿Cuántos recursos participan?

Sé que estamos trabajando en el ámbito, pero cuando hablamos de qué tipo de resolución se requiere, vale la pena pensar en cuántas personas trabajarán en una tarea. Por ejemplo, en un gran proyecto de EPC puede haber decenas de trabajadores con una determinada aptitud que intervienen en una fase de trabajo. Pero cuando nos encontramos con muchas aptitudes diferentes en la misma tarea, administrar dicha tarea es muy difícil, si no es imposible. Por lo tanto, en esa situación, las tareas que requieren muchas aptitudes diferentes probablemente deban dividirse.

En un proyecto de software, tendemos a pensar en casi todos los individuos como recursos altamente técnicos con capacidades únicas. Además, en los proyectos de software es habitual tener muchas tareas que se pueden reasignar dentro de un departamento pero solo una tarea asignada por persona. Por lo tanto, cuando tenemos tareas que se asignan a una sola persona de un departamento o un grupo de recursos determinado (por ejemplo, la programación de la interfaz) es suficiente para decir que no necesitamos más detalle.

¿Cómo se administran o subdividen los recursos?

La forma en la que se administran los recursos es un gran determinante al momento de subdividir las tareas. En los grandes proyectos de EPC, por ejemplo, los proyectos a menudo se recortan en subproyectos que se dividen entre grandes subcontratistas. En esta situación tenemos que hacer un par de cosas:

  • Defina el trabajo de manera que permita a un jefe de proyecto supervisar al subcontratista con confianza de que los progresos alcanzados son un factor importante.

  • Defina las tareas de manera que el personal de ingeniería y administración de proyectos del subcontratista comprendan lo que significan sin ambigüedad.

  • Asegúrese de que el nivel de resolución que ha adoptado como estándar el subcontratista lo comprende y lo acepta.

Si analizamos proyectos ejecutivos como software, investigaciones biológicas o de ingeniería, es muy probable que nos encontremos con una estructura de administración matriz en la que los jefes de proyecto no poseen ninguno de los recursos y debemos trabajar con los jefes de departamento quienes asignan esos recursos en muchos proyectos diferentes. En este caso, las preguntas clave serían:

  • ¿En cuántos proyectos es probable que se use un recurso en un solo día?

  • ¿Cuánto tarda un empleado en cambiar de un proyecto a otro?

  • ¿El trabajo se encuentra definido de manera tal que tanto los empleados como los directores de departamentos de recursos comprenden cómo asignar la aptitud adecuada al trabajo?

Cuando analizamos un proyecto de construcción o de cierre, tendemos a trabajar con equipos que se crean para determinados objetivos. En estas situaciones, un líder del equipo de recursos podría administrar el equipo de electricidad (aunque ese equipo incluya carpinteros e instaladores de tuberías), un grupo de plomería o un equipo de restauración de calderas. El trabajo tiene que estar organizado de tal manera que el equipo se pueda mantener ocupado a lo largo del turno y que no llegue encima de otro equipo que ya está trabajando en algo en dicha área. Dada la intensa presión de tener que completar un proyecto de cierre, el trabajo a menudo se organiza por trabajo en primer lugar, se programa y, a continuación, el líder del equipo de recursos lo reagrupa y subdivide de modo que cada encargado del equipo pueda caminar únicamente con sus tareas en un documento y con el proyecto completo en contexto en otro. Las tareas tienen que definirse de manera que sean claras para el empleado y el líder del equipo de recursos. Las tareas aquí probablemente se definan en la hora o incluso con más granularidad a los diez minutos o el cuarto de hora.

¿Con qué rapidez puede recopilar datos y cuánto esfuerzo le demanda?

Suena una pregunta tonta cuando está acostumbrado a ver los datos de su proyecto muy bien alineados al final de la semana para su revisión, pero cuando intenta determinar el nivel de resolución del proyecto, esto puede ser una pregunta clave. Por ejemplo, cuando se trabaja con numerosos subcontratistas, es probable que obtenga algún tipo de actualización semanal o mensual. De hecho, incluir la cláusula de actualización de administración del proyecto en el contrato es esencial. En esta situación, debe integrar los datos de distintas empresas usted mismo, validar que los datos de progreso tengan sentido y, a continuación, realizar su propio análisis y elaboración de informes. En un modo de EPC, probablemente, esto deba realizarse mensualmente.

En un proyecto de cierre, deberá actualizar el proyecto en cada turno, actualizarlo rápidamente e informar las actualizaciones a los jefes de equipo de recursos en el medio del siguiente turno. En esta situación, el personal del proyecto se dispersa por toda la planta durante el turno y recopila datos en tiempo real a medida que pueden. Los jefes de equipo de recursos y los encargados usan hojas para tomar notas sobre el progreso de sus asignaciones. En un proyecto de software o de investigación, probablemente trabaje en un programa semanal o algo similar con individuos que informan su propio progreso y tienen que pasar por autorizaciones cada uno o dos días.

Este es un punto importante para tener en cuenta cuando analiza cuántas tareas tiene en su proyecto, porque no hay un coste relacionado con la recopilación de datos.

Por lo tanto, considerar cuán rápido puede recopilar, aprobar, integrar, analizar e informar los datos de forma regular y cíclica es clave, como lo es la consideración del coste de la recopilación de datos y el retorno de la inversión de los datos recopilados.

¿Con qué frecuencia se realiza la actualización?

Estas son dos claves para determinar la cantidad de datos que puede recopilar e incluir:

  • Piense cómo recopilar los datos.

  • Con frecuencia, piense acerca de cómo actualizar su proyecto razonablemente y proporcione administración con las herramientas de toma de decisiones necesarias para guiar el proyecto y los recursos en la dirección correcta.

He visto algunos jefes de proyecto que insisten en que desean pasar a la recopilación de proyectos y administración de proyectos en tiempo real y, si bien esto puede ser posible en teoría, es muy difícil de realizar en la práctica.

Cuando hablamos de administración de proyectos hacemos algunos supuestos. Se supone que:

  • Los datos están todos allí   . No esperamos analizar algunas tareas que estén actualizadas y otras que no lo estén.

  • Los datos se actualizaron todos al mismo tiempo   . No esperamos que la mitad de las tareas se actualicen cada algunos minutos y la otra mitad se actualicen cada dos semanas.

  • Todos los datos tienen cierto nivel de aprobación   . Esperamos que el jefe de proyecto esté detrás de los datos que se están presentando y que puede decir "Esta es una representación justa y precisa del proyecto".

  • Los datos permanecen juntos   . No esperamos que los riesgos se esfumen con costes y con recursos a menos que hayamos diseñado específicamente nuestros informes y análisis de esa forma.

Frecuentemente les pregunto a los ejecutivos que están entusiasmados con el concepto de administración de proyectos en tiempo real lo que harán si logramos superar los puntos que acabo de plantear anteriormente. "¿Está preparado para tomar decisiones de administración durante toda la semana?". La respuesta debe depender del nivel de resolución. En un proyecto de cierre, la respuesta adecuada sería: "Sí". En un proyecto de software, la respuesta probablemente sería: "No, lo haremos de forma semanal". Y en un proyecto de EPC la respuesta sería: "Mensualmente".

En algún momento la ley de rendimientos decrecientes entra en vigor para decir "Ofrecer informes de proyecto con más rapidez no aumentará nuestra eficiencia".

Revisar su trabajo

Ahora ya ha tenido algunos elementos de reflexión, ha usado el método de descomposición del trabajo para subdividir los datos y ha visto algunas de las señales de advertencia que los datos están definidos de forma muy detallada. Ahora es el momento de poner la programación contra la pared, dar un paso hacia atrás y mirar el proyecto con cierta perspectiva. De manera sorprendente, muchos jefes de proyecto nunca hacen esto. Quedan tan atrapados en definir los últimos detalles y están tan ocupados en subdividir tareas una y otra vez que se presionan ellos mismos para llegar a la fecha límite y nunca miran si lo que han hecho será una pesadilla para administrar.

En algunos casos, los ejecutivos están seguros por todos los cursos de MBA que "más detalles es mejor" y ejercen presión para esas tareas de 5 minutos o 15 minutos en los proyectos que duran seis meses.

Cambiar el proyecto antes de que se inicie siempre es más fácil que hacerlo en cualquier momento posterior, por lo que debe establecer un tiempo en la actividad de rediseñar la programación si es necesario.

¿Es demasiado?

A veces los jefes de proyecto miran el ámbito de lo que han creado y se dan cuenta que el nivel de detalle empleado es demasiado fino. En ese caso, la solución es evidente. Puede ser una gran cantidad de trabajo, pero se lo agradecerá a usted mismo más tarde si realiza una programación más sencilla al subir un nivel.

A veces la imagen no es tan sencilla. En algunos casos, el jefe de proyecto solo puede ver la complejidad de toda la programación una vez que está montada. 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 vale la pena considerar antes de poner en marcha un proyecto complejo, por ejemplo, podrían ser:

  • ¿Podemos hacerlo en varias partes?    Algunos proyectos arriesgados pueden dividirse en partes más pequeñas y como proyectos más breves, el riesgo disminuye. No obstante, si usa esta estrategia, cada proyecto discreto debe tener su propio valor una vez que está completo.

  • ¿Debemos volver a pensar en el ámbito?    A menudo las acciones más simples son volver a los diseñadores del trabajo en primer lugar, explicarles la complejidad aparente en la programación y ver si el trabajo puede volver a establecerse. Esto muchas veces genera un pensamiento innovador que nunca hubiera surgido.

¿Debemos hacerlo todo?

Algunos proyectos nunca deberían haber llegado a ser proyectos y el mejor momento para cancelarlos es el día antes de que empiecen. Si el riesgo del proyecto es solo aparente por el momento, mejor darse cuenta ahora y no más tarde. Cuando se integran los resultados y se lleva a cabo la programación nuevamente en el proceso de administración de carteras de proyectos (PPM), es posible que descubra que el riesgo del proyecto más complejo tiene una puntuación de trabajo mucho peor en una escala de retorno de la inversión.

Un proyecto ágil

He prometido mencionar algunos aspectos sobre la administración de proyectos ágil y si es fanático de las cosas ágiles y ha leído hasta aquí, aprecio su paciencia. Administrar proyectos de software mediante el método ágil es algo así como una filosofía, pero es una filosofía más popular entre aquellos que se han quemado en proyectos de desarrollo de software masivos que no se realizaron correctamente.

En un mundo de desarrollo de software ágil, tratamos de dividir nuestro proyecto en pequeñas partes, en "sprints" de una a tres semanas y el objetivo para cada miniproyecto consiste en acabar con código utilizable. En este caso, estamos trabajando dentro de algunas restricciones bastante conocidas para que nuestro nivel de resolución sea casi igual al elegido.

Tenemos un espacio 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 este se presta a mantener un nivel adecuado de resolución. Sí, puede tener problemas en el método ágil si define tareas que son demasiado pequeñas. "Definir Campo1: 10 minutos, Definir Campo2: 10 minutos, Definir Campo3: 10 minutos", etc. pero es mucho menos común.

El proyecto ágil se diseñó para un entorno de desarrollo corporativo donde estamos creando software para uso interno y su uso se extiende a menudo al desarrollo de software comercial. (Usamos este método en HMS para nuestro propio desarrollo de TimeControl). El método ágil da como resultado un departamento de desarrollo más maniobrable y ágil pero no se va a poder aplicar a todos los sectores ni a cada empresa de software. Si está realizando administración de proyectos en un entorno de software, mi recomendación es que lea sobre el método ágil, aprenda sobre él y, a continuación, adopte los elementos (todos, algunos o ninguno) que lo harán más eficaz.

Conclusión

Al igual que sucede con la mayoría de los aspectos de la administración de proyectos, no hay ninguna respuesta establecida a las preguntas que a primera instancia parecen tan obvias. Cuántas tareas tiene en su proyecto y cuánto tiempo demandan cada una de ellas debe ser algo que necesita buscar por sí mismo para decidir, pero decidir es una obligación.

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.

Acerca del autor

Chris Vandersluis es presidente y fundador de la empresa HMS Software, establecida en Montreal, Canadá, un asociado certificado de Microsoft. Cuenta con unos estudios en Economía en la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es miembro del Project Management Institute (PMI) y participó en la creación de las secciones de Microsoft Project Users Group (MPUG) en Montreal, Toronto y Quebec. Entre las publicaciones en las que ha escrito Chris se encuentran Fortune, Heavy Construction News, Computing Canada Magazine y PMNetwork de PMI; también es columnista habitual en Project Times. Es profesor de Administración avanzada de proyectos en la Universidad McGill y a menudo es ponente en actos de asociaciones de administración de proyectos de Norteamérica y el resto del mundo. HMS Software es el proveedor del sistema de control para los proyectos de TimeControl y es asociado de la solución 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 de Office
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.

×