Feeds:
Entradas
Comentarios

cuadrante mágicoRecientemente Gartner ha presentado el cuadrante mágico para la Gestión de Proyectos y Portafolio de Proyectos del sector de las tecnologías de la información del 2007. Se trata de una representación gráfica donde se muestra el estado del mercado correspondiente en un período de tiempo, mediante la agrupación de las diversas empresas en cuatro categorías: líderes, aspirantes, visionarios y empresas con un nicho específico.

El informe pasa revista a cada una de las empresas reflejando sus puntos fuertes y sus debilidades, centrándose en el sector de las TI, aunque en muchos casos la gestión de proyectos y portafolio va más allá de este sector. Por otro lado, los analistas de Gartner se basan en el grado de soporte que ofrecen los distintos productos a las nueve áreas de conocimiento de la gestión de proyectos identificadas por el Project Management Institute en el PMBOK, para incluir o no en el cuadrante a una determinada empresa. El documento se encuentra disponible en inglés aquí.

Entre las tendencias que se comentan, por encima de nuevas fusiones y adquisiciones, y el papel en el mercado de las empresas visionarias que ofrezcan productos y servicios a precios ajustados, dos son las más significativas:

  • Está en marcha la integración entre la gestión del portafolio de proyectos, los servicios TI y las funciones de gestión del ciclo de vida de las aplicaciones, de forma que en un futuro (según los analistas de Gartner no antes del 2009), existirá una oferta de productos para la Planificación y Control de las Tecnologías de la Información (ITPC) de forma integral.
  • En el 2010, al menos una de las empresas que comercializan software de gestión de proyectos y portafolio de proyectos TI, emergerá con un enfoque hacia el mercado medio, utilizando en gran medida un software robusto desarrollado sobre un modelo de software como servicio (SaaS).

No sé cómo lo veis pero la primera de ellas (convergencia hacia soluciones ITPC), es un auténtico reto aunque parece lógico que se acabe apostando por una visión/solución homogénea. En cuando a los modelos de software como servicio, diría que más va más allá de una tendencia, y que los últimos movimientos del mercado como la aparición de Google Gears, van a dar un fuerte impulso a este modelo.

technorati tags:, ,
,

El presente post tiene como origen el magnífico artículo de Peter DruckerManaging Oneself“, que si bien no tiene como foco principal la gestión de proyectos, si que podemos aplicar algunas de las buenas ideas que se esbozan en él.

Los tres conceptos que fundamentan la exposición de Drucker son la responsabilidad, la comunicación y el análisis retrospectivo. Este último será el mecanismo que posibilitará identificar las fortalezas, la forma de trabajar, y los valores que uno posee.

Así pues, ¿cómo puedo/debo actuar en el camino hacia el éxito de los proyectos en los que participo y hacia la mejora continua en mis labores?

Desde el punto de vista de la responsabilidad, siempre la tendremos independientemente de nuestra función o cargo.

Si soy el Jefe de Proyecto, tendré la responsabilidad de asignar a los integrantes del equipo las tareas en las que sean más productivos. Es el nivel de responsabilidad que más fácilmente se percibe, y habría de partir de la premisa de que la organización también ha sido responsable en poner a disposición del Jefe de Proyecto los perfiles más apropiados. En realidad, son muchas las ocasiones en las que el equipo de trabajo ya viene dado, pero en cualquier caso es recomendable adaptar o diseñar los puestos de trabajo como comenta y explica Manolo Álvarez en su blog.

Si soy un integrante del equipo, tendré también la responsabilidad de dar a conocer mis destrezas y mis inquietudes en el ámbito del proyecto, para facilitar la convergencia función/persona adecuada.

En este momento ya estamos hablando de la comunicación, pues será la herramienta principal con la que el Jefe de Proyecto obtendrá toda la información necesaria para articular al equipo sobre las tareas a llevar a cabo. En el caso de ser uno de los integrantes del equipo me permitirá asegurarme de que estoy haciendo lo que realmente se espera que haga, así como para señalar con la máxima antelación posible las dificultades, riesgos y problemas que puedan surgir en mis tareas.

Por último, el análisis retrospectivo, que Drucker propone como técnica de análisis personal, también puede realizarse sobre los proyectos. Así pues, a nivel personal, este análisis permitirá encauzarnos como profesionales hacia las labores, proyectos, organizaciones en las que podamos aportar más, mientras que a nivel de proyecto, se tendrán en cuenta los informes de experiencias anteriores, los resultados obtenidos en la toma de decisiones críticas, etc. para aplicarlos en el contexto del proyecto en curso. Sólo de esta forma se podrá realmente hablar de organizaciones basadas en el conocimiento.

technorati tags:, ,
,

El libro del verano

Ya está aquí el verano y las vacaciones acechan a la vuelta de la esquina. ¿Y existe algún remedio mejor para paliar los calores que leerse un buen libro a la sombra, con una cervecita al alcance de la mano? Puede que sí, si realmente se trata de un blook instructivo y entretenido sobre gestión y desarrollo de proyectos de software. Si, si, ya sé que también están la playa, la montaña, las mariscadas, las copas, etc. pero hay tiempo para todo. Pues nada, el libro del verano ya está aquí, de hecho lleva unos meses entre nosotros. Se trata de “Mirando alrededor. El día a día en los proyectos de software“. Además su autor, Juan Palacio, permite su descarga gratuita en formato pdf en su blog Navegapolis.net , y nos proporciona una visión integral que incluye la gestión de recursos humanos, las organizaciones, PMI, CMMI, SCRUM ..

Imprescindible para ampliar nuestras perspectivas y reflexionar sobre algunos de los grandes tópicos de este mundillo.

technorati tags:, , , , ,

El Project Management Institute (PMI) es una asociación profesional sin ánimo de lucro dedicada recopilar el conocimiento y buenas prácticas en la gestión de proyectos, generar estándares sobre la misma y difundir la profesión a través de diversas certificaciones. El PMBOK (Project Management Book Of Knowledge) es la guía en la que se recogen los fundamentos y métodos contrastados. En la actualidad va por su tercera edición.

Conseguir que un proyecto tenga éxito, por encima de que simplemente sea ejecutado con corrección es una ardua labor para la que se necesita experiencia diversa. En concreto, el PMBOK identifica la necesidad de que la dirección del proyecto tenga conocimiento y habilidades en al menos cinco áreas de experiencia. Son las siguientes:

  1. La propia gestión o dirección de proyectos.
  2. El área de aplicación del proyecto, incluyendo normativas y regulaciones propias del área (en el supuesto de un proyecto de ingeniería industrial frente a uno de ingeniería informática, son campos distintos, no tienen porque seguir las mismas normativas).
  3. El entorno del proyecto, es decir, el contexto en el que se encuentra a todos los niveles: social, cultural, organizativo, económico.. Cual es la realidad que envuelve al proyecto y los factores que le influyen.
  4. El área de dirección en general, independientemente de que se trate de un proyecto. Comprende temas como la gestión financiera, la logística, la selección de personal..
  5. Las habilidades interpersonales, las que involucran más directamente a las personas, empezando por la comunicación, la negociación, el liderazgo, etc.

No es imprescindible, ni siquiera habitual que el peso del conocimiento en estas áreas de experiencia recaiga en una única persona. Todas son necesarias para que el proyecto consiga sus objetivos, y descuidar una de ellas puede dar el traste con el trabajo de muchos meses.

Imaginemos la carencia de cada una de ellas, tendríamos los siguientes 5 escenarios:

  1. Desconocimiento de la gestión/dirección de proyectos: parece claro que estaríamos dejando en manos de la suerte y de la inercia que un proyecto terminase bien. Pero contar con la suerte es una estrategia muy peligrosa.
  2. Desconocimiento del área de aplicación del proyecto: pensemos ahora en que se elabora un proyecto donde no se conoce ni el área de negocio ni la normativa o regulaciones vigentes. Se estaría ejecutando un proyecto por instinto, pensando que las cosas deben de ser de una manera cuando a lo mejor las leyes pueden estar marcando el camino contrario. ¿Qué ocurriría en una aplicación informática que tratase con datos personales y que no tuviese en cuenta las regulaciones de seguridad y privacidad de datos, (en España la LOPD)?
  3. Desconocimiento del entorno del proyecto: podríamos tener un proyecto que finaliza y es técnicamente correcto, pero el impacto en la organización a la que sirve no es el adecuado. Un proyecto de gran calado en la administración pública justo antes de unas elecciones podría ser considerado de electoralista y tener una repercusión negativa en la sociedad.
  4. Desconocimiento de temas genéricos de dirección: puede dejar cabos sueltos y generar muchas sorpresas. Supongamos que se ignora el proceso de compras de un material importante para el proyecto (a lo mejor creemos que la compra es inmediata y realmente se precisan meses de trámites administrativos)
  5. Carencia de habilidades interpersonales: es posiblemente el área cuyo conocimiento es más difícil de medir. Si tenemos en cuenta que un proyecto es algo único pero las personas, departamentos, organismos, etc. que lo sacan adelante también lo son, en seguida veremos su importancia. Por ejemplo un proyecto con un equipo desmotivado es un cheque en blanco para el fracaso.

technorati tags:, , , , ,

No me he resistido a compartir la traducción de este post original de Project. Los 10 errores principales del nuevo Director de la Oficina de Proyectos son los siguientes:

  • 10. Vender su casa para estar más cerca del nuevo trabajo.
  • 9. Comprar acciones de su nueva empresa para demostrar compromiso.
  • 8. No entender que OGP significa “Opuestos desde la Gerencia de Proyectos”. Aquí no se me ocurre una traducción mejor, en inglés sustituye PMO (Project Management Office) por “Project Manager are Opossed”, es decir en vez de Oficina de Gestión de Proyectos, “los Jefes de Proyecto se Oponen”.
  • 7. Creer lo comentado durante la entrevista de trabajo sobre responsabilidad en la gestión de proyectos.
  • 6. Creer lo comentado durante la entrevista de trabajo sobre las habilidades necesarias para formar parte de la Oficina de Proyectos.
  • 5. Pensar “no puede ser muy duro ayudar a la organización en algo que le interesa tanto“.
  • 4. Pensar “no puede ser muy duro ayudar a los Jefes de Proyecto en algo que les interesa tanto“.
  • 3. Pretender que una organización externa desarrolle los nuevos procedimientos.
  • 2. Decidir que lo que realmente se necesita es la mejor formación posible en gestión de proyectos

y finalmente, el error fatal …

  • 1. Aceptar el trabajo

Si has trabajado o trabajas en una Oficina de Proyectos, te tiene que hacer gracia. Sino .. tenlo en cuenta por lo que pueda pasar.

technorati tags:, , ,

No hay terreno por explorar que digamos …

Mapa mental de Gestión de Proyectos

Via adoption curve dot net descubro WikiMindMap, que genera mapas mentales en base a las entradas existentes en la Wikipedia sobre un determinado tema, como p.ej. Project management.

technorati tags:, , ,

Hace unos días, Fernando Trías de Bes publicaba un artículo titulado “El síndrome de las ventanas“, sobre la influencia que tiene en nuestro desempeño y en nuestra vida en general el tener muchos frentes abiertos a los que uno se dedica simultáneamente. Este problema también se conoce como “Multitasking Syndrome” o “Internet Multitasking Syndromey realmente su impacto sobre la sociedad todavía está por ver, aunque las perspectivas no son buenas.
Asimismo, existen organizaciones que sufren del mismo mal en la planificación y ejecución de sus proyectos, en muchos casos marcados por objetivos a corto plazo que acaban por convertirse en pan para hoy y hambre para mañana. ¿No habéis estado en un proyecto que sufriese dicha enfermedad? ¿No habéis visto cargar con demasiadas tareas a alguna de las personas del equipo de forma que acaba por dedicarse a las mismas superficialmente, lo justo para ir tirando?
¿Cómo se abordaría desde una perspectiva corporativa y de gestión de proyectos esta problemática? ¿Implementando una Oficina de Proyectos? ¿Con un sistema permanente de auditorias internas? ¿A través de modelos de madurez? ¿Gestionando el portafolio de proyectos sobre un sistema de cuadros de mando avanzado?
La respuesta a estas cuestiones se me antoja compleja, sobre todo cuando quienes toman las decisiones se fijan demasiado en los resultados y pierden de vista los síntomas de la enfermedad.
Sin embargo, antes o después el resultado de esa ligereza en la dedicación, acaba por salir a la luz. Como por ejemplo el caso de la nueva web del Congreso. No me extrañaría que detrás de este proyecto hubiese unos cuantos responsables de proyecto realmente buenos lidiando con los elementos. Cuando el síndrome afecta a una organización en general, quizás es más difícil de detectar, pero antes o después acabará pasando factura.

Las prisas no son buenas consejeras, la agilidad está bien pero cuando va más allá de una coletilla de marketing. Ya lo decía Fray Guillermo de Baskerville, cuando mencionaba que lo que más le aterraba de la pureza era la prisa.

technorati tags:, , , ,