MARKETING
COMUNICACIÓN
INTERNET
FORMACIÓN
DIRECTORIO
Noticias de Bufetes
Operaciones
Decía el General Patton que "un buen plan ejecutado hoy es mejor que un plan perfecto ejecutado en algún momento indefinido en el futuro". De alguna forma y sin sospecharlo, estaba elaborando uno de los primeros manifiestos ágiles de la historia para la gestión de proyectos. Con mucha más consciencia, en marzo de 2001, 17 especialistas en metodologías de desarrollo de software, se reunieron en Salt Lake City para reflexionar sobre cómo innovar y dotar de más eficacia las soluciones que querían ofrecer a sus clientes. La forma tradicional de construcción de software se basaba, y sigue basándose en varios casos, en el ciclo de vida secuencial conocido normalmente como “desarrollo en cascada”. Se trata de un enfoque histórico, aplicado en otras áreas profesionales (la construcción, la industria militar, la ingeniería aeronáutica, etc.), basado en una planificación rigurosa que tiene como premisa el análisis detallado del trabajo que se quiere realizar, su descomposición en tareas y la asignación de recursos (temporales, económicos y humanos), la ejecución conforme al plan y el posterior seguimiento y control de dicha ejecución para detectar posibles desviaciones y tomar eventualmente las medidas adecuadas que reconduzcan al plan original. Si es cierto que los proyectos existen desde siempre, a partir de los años 50 las industrias militares y automovilística advirtieron la exigencia de aplicar una práctica que permitiese reducir las disfunciones que más frecuentemente afectaban al resultado del proyecto: demora de tiempo, descontrol de costes y baja calidad / utilidad del servicio o producto realizado. El elemento clave de la nueva gestión era la capacidad de prever (gestión predictiva) tiempos, costes y recursos necesarios en función de la información conseguida y del plan elaborado, con garantía de que el servicio o producto final se obtuviese en los tiempos y costes estimados. El enfoque predictivo permitió conseguir resultados muy positivos, con reducción significativa de la desviaciones principales. Rápidamente se adoptó en otros sectores, incluido el de desarrollo de software. Sin embargo, en una realidad que evoluciona imprevisiblemente a ritmos acelerados, bajo un entorno como es el desarrollo de software caracterizado por la velocidad del escenario tecnológico y de negocio, las metodologías clásicas dan los resultados esperados únicamente en menos de la mitad de los proyectos creados. En estos mercados tremendamente rápidos, el producto adquiere tanto más valor cuanto más se apuesta por la flexibilidad, la innovación y la inmediatez de la solución. Ya desde los años noventa se estaban experimentando enfoques agiles que permitiesen crear productos y servicios conformes a las característica de los mercados y a las exigencias del cliente. Como resultado de esta continua investigación y experimentación, en Salt Lake City se elaboró el Manifiesto Ágil, en el que se valoraba: • A los individuos y su interacción, por encima de los procesos y las herramientas. • El software que funciona, por encima de la documentación exhaustiva. • La colaboración con el cliente, por encima de la negociación contractual. • La respuesta al cambio, por encima del seguimiento de un plan. Si las metodologías clásicas habían apostado por el concepto de predicción y anticipación (requisitos, diseño, planificación, ejecución y seguimiento), la gestión ágil de proyectos premiaba el concepto de anticipación y los ciclos de vidas incrementales e iterativos. En la fase de concepto se crea la visión del producto o servicio que se desea obtener. Sobre esta visión el equipo investiga (especulación) y desarrolla el producto o el servicio en un proceso de incremento continuo a partir de la versión beta. Durante el desarrollo se confronta la realidad de lo que va obteniendo. Esta perspectiva más investigativa permite desarrollar soluciones creativas y dinámicas. Las desviaciones del plan original no son una amenaza sino un descubrimiento de algo más útil, disponiendo cada vez más de mayor información. Más de que producto final, hablamos de producto en evolución. ¿Os suenan de algo las “versiones” de Windows, por ejemplo? Para decirlo con las palabras de Patton, "un buen software desarrollado hoy es mejor que un software perfecto desarrollado en algún momento indefinido en el futuro". En este escenario, se configuran dos factores estratégicos: la participación del cliente y la autogestión del equipo. ¿Cómo interesa este debate a los despachos de abogados y a los departamentos jurídicos de empresa? En el momento en que un despacho quiera gestionar sus casos como si fuesen proyectos debe plantearse qué tipo de metodología, estilo o enfoque es más correcto por este mismo proyecto. A pesar de que en mucho casos haya una diatriba entre sostenedores del clásico y sostenedores del ágil, en mi opinión no se trata de ver cuál enfoque es mejor (los dos tienen ventajas y desventajas) sino cuál es más adapto a la cultura y a la estructura de la organización, a la naturaleza del proyecto y a las exigencias del cliente. Si aplicamos un enfoque clásico, que bien puede ser representado por el cuerpo de conocimientos elaborado por el Project Management Institute (PMBOK – Project Management Body of Knowledge) o por PRINCE 2, centraremos nuestra atención en las fases del proyecto, los procesos, las áreas del conocimiento. Nuestro objetivo será planificar y seguir este plan, introduciendo posibilidad de cambio solo cuando estrictamente necesario. Utilizaremos herramientas como Gantt Chart, RACI, PERT, Matrices de Riesgos, etc.. El project manager se encargará de elaborar el plan y de seleccionar su equipo para que ejecute dicho plan. Si adoptamos un enfoque ágil, estaremos premiando las personas sobre los procesos, el proceso iterativo e incremental sobre el proceso secuencial o a cascada, la mitigación del riesgo mediante iteraciones fijas, la priorización de requerimientos de acuerdo a su valor, la creatividad y la espontaneidad de equipos dedicados y auto-gestionados, la incorporación de cambios frente a la flexibilidad del plan (el cambio se percibe como ventaja competitiva), la retro-información continua durante el desarrollo y la colaboración interactiva con el cliente. Si es cierto que las grandes firmas y los despachos medianos de abogados normalmente cuentan con una estructura jerarquizada en la que podría ser más realista (aunque siempre complicado) la adopción de un enfoque clásico, en despachos pequeños los métodos ágiles podrían funcionar perfectamente, siempre y cuando no desorienten al equipo. Sin embargo, en ambas estructuras se pueden adoptar las dos prácticas con éxito, dependiendo de estrategia y objetivos organizativos (no es un caso que el PMI haya incluido entre sus certificaciones la de PMI Certified Agile Pratictioner, PMI-ACP). Actualmente, los despachos excelentes que están aplicando el legal project management han optado por un enfoque más clásico, sin embargo el debate queda abierto (como testimonia la excelente series de artículos de Steve Denning publicados en la Revista Forbes sobre el enfoque ágil y el radical management, entre estos The Case Against Agile: Ten Perennial Management Objections). ¿A qué se debe esta preferencia? Concuerdo con la reflexión propuesta por Anthony Smith en su blog sobre Legal Project Management (Agile legal services: overcome objections and become a more productive and innovative law firm): entre otros factores, que me reservo de comentar en los próximos posts, incide principalmente el desconocimiento de las prácticas ágiles y de sus ventajas. Normalmente un abogado que se acerque al legal project management, tiene su primer contacto con la metodología más clásica, y principalmente con el cuerpo de conocimientos elaborados por el PMI. Ahora, este primer “encuentro” ya en si mismo requiere superar una histórica resistencia hacía la visión del abogado como gestor y supone enfrentarse con una cultura organizativa del trabajo que en algunos caso puede ser perturbadora. Pues, pedir a este abogado que haga un ulterior esfuerzo y que ponga en duda cuánto aprendido para introducir una visión más creativa y espontanea que se retroalimenta con la fortalezas técnicas y emocionales de su equipo requiere casi un acto de fe. Invitarle a adquirir capacidad crítica para saber elegir entre los dos enfoques para aplicar el más adecuado es desafiante. ¡Cuánta verdad en las palabras de John Dewey, probablemente el filósofo estadounidense más importante de la primera mitad del siglo XX: “The path of least resistance and least trouble is a mental rut already made. It requires troublesome work to undertake the alternation of old beliefs”. Si realmente queremos aprovechar del project management, necesitamos conocerlos en todos sus aspectos y elegir las técnicas y las herramientas que más dan valor a nuestro trabajo y a nuestros clientes. Diversamente, solo estamos añadiendo una complicación a nuestro oficio.
comparte ésta información::
Tweet
Publicar un Comentarioio
Lawyerpress publicará su comentario solo con su alias, sin el eMail, ni nombre y apellido.
Nombre y Apellidos
e Mail de contacto
alias
comentario
Comentario
copyright, 2012 - Strong Element, S.L. - Peña Sacra 18 - E-28260 Galapagar - Madrid - Spain - Tel.: + 34 91 858 75 55 - Fax: + 34 91 858 56 97 - info@lawyerpress.com - www.lawyerpress.com - Aviso legal
