Entradas

Una vez se ha tomado la decisión de que un proyecto debe ralentizarse, pausarse o detenerse, hay varias actividades a llevar a cabo. Algunas actividades aplican en todos los casos, pero otras solo aplican en función de la decisión específica que se haya tomado. Comencemos con las que aplican a todo:

  • Validación de decisiones. Todos los responsables de la toma de decisiones del proyecto deben ser consultados e, idealmente, estar de acuerdo con la decisión. Siempre vale la pena verificarlo dos veces.
  • Claridad en próximos pasos. A medida que comience a comunicarse tanto con los que han tomado las decisiones como con el público en general, habrá preguntas y desafíos sobre la decisión. Hay que prepararse, de antemano, tanto como sea posible. Hay que ser claro sobre la justificación de la decisión y los pasos específicos que se tomarán para desacelerar, pausar o detener el proyecto. Es clave comprender las dependencias y anticipar preguntas sobre el impacto en la organización, las personas, las empresas externas o los proveedores.
  • Comunicación. Cada organización es diferente, pero un orden lógico es comunicárselo primero al equipo del proyecto y a los comités ejecutivos (Comité Directivo, Junta de Programa, etc.), seguido por el personal afectado y las áreas comerciales, seguidos por proveedores o empresas externas que tengan alguna dependencia del proyecto. La comunicación debe ser rápida para que, idealmente, todos los que necesitan saberlo se enteren el mismo día. Es importante comunicar también los motivos de la decisión y los próximos pasos, no solo la decisión en sí.
  • Sensibilidad. Las personas pueden sentir una sensación de decepción o pérdida si un proyecto se interrumpe o se detiene, ya sean miembros del personal, contratistas o proveedores. Para algunos, esto también puede ser una pérdida de función o una pérdida de ingresos. Hay que tener esto en cuenta al comunicar las noticias.

 

Luego están las actividades que dependen de la decisión que haya tomado.

Ralentizar

En este contexto, nos referimos a donde un proyecto va a continuar, pero necesita acomodarse a una reducción de fondos y/o recursos. Si el proyecto necesita ralentizarse rápidamente, es poco probable que sea posible hacer un análisis detallado y una planificación completa. El gerente y el equipo de proyecto deben realizar algunas evaluaciones rápidas centradas en la productividad de los recursos, la importancia de los plazos, el alcance y la calidad. Disminuir la velocidad puede no significar retrasar los entregables. Si es posible lograr los mismos resultados a corto y medio plazo con menos recursos, esto permitirá que el proyecto continúe con el mismo alcance, plazos y calidad. En la mayoría de los casos, eso no es posible, por lo que las 3 palancas de gestión de proyectos son:

 

  1. Plazos: ampliar el proyecto para suavizar la carga de trabajo
  2. Alcance: reducir el alcance para centrar los recursos/ fondos en áreas clave
  3. Calidad: no entregar “entregables de oro” cuando un producto viable mínimo puede ser suficiente

 

La extensión de la fecha límite suele ser la solución más simple. Si los plazos no pueden extenderse, entonces se puede disminuir el alcance; si no se puede disminuir el alcance, se puede enfocar en un producto mínimo viable. Si se eliminan elementos de alcance especificos, o incluso flujos de trabajo discretos, esto ayudará a reducir la necesidad de una planificación detallada. Sin embargo, cualquier cambio acordado requerirá una revisión de la documentación del proyecto sobre recursos, plazos y alcance. Todo esto debe hacerse teniendo en cuenta las dependencias internas y externas del proyecto.

Interrumpir o detener un proyecto

Un proyecto «en pausa» se reiniciará en el corto a medio plazo; un proyecto «detenido» no se reiniciará. Cuando interrumpamos o detengamos un proyecto, hay que realizar los siguientes pasos:

  • Acordar la decisión formalmente con los órganos de gobierno apropiados
  • Pagar las facturas finales, cancelar las órdenes de compra, etc.
  • Actualizar toda la documentación, en particular el plan del proyecto, los informes de estado, los registros RAID, la matriz RACI y los datos de contacto de los miembros del equipo del proyecto (incluidos los proveedores externos)
  • Compartir todos los documentos, incluidos los correos electrónicos relevantes, que pueden ser específicos para un individuo, en una única ubicación común que sea accesible para todas las partes relevantes y asegurarse de que la ubicación sea conocida por todos
  • Realizar un análisis de «lecciones aprendidas», si el tiempo lo permite, para alimentar al proyecto o marco de gobierno

 

Algunas de estas acciones pueden parecer irrelevantes para un proyecto que se está deteniendo, pero a menudo sucede que los proyectos resurgen de una forma diferente y puede ser útil tener información histórica del proyecto disponible.

Además, para un proyecto en pausa es conveniente:

  • Crear un «registro de inicio» que identifique las acciones iniciales que deberán realizarse para reiniciar el proyecto.
  • Programar un recordatorio quincenal / mensual para verificar el estado del proyecto en preparación para el reinicio

Nuestro próximo artículo se centra en el reinicio rápido y ampliaremos más sobre el «registro de inicio» y los contenidos.

We recently posted a link to a news article about the rate of IT project failures. There have been some very high profile, and some less high profile, IT project failures and outages in the past couple of years.

IT projects and programmes, large and small, are often both complex and complicated. Particularly when they involve the migration of data from existing systems to new systems. If you have worked on this type of project, then we aren’t telling you anything new.

We thought it might be useful to talk about why these projects can be difficult and how you might increase the likelihood of success.

The Challenges

The level of difficulty in these projects is driven by the:

  • Number of existing systems, the connectivity between systems, and external interfaces;
  • Functionality of the new system(s), any customisation, and the regulatory requirements;
  • Amount of data to be migrated, the structure of the data (clients, accounts, funds, stocks, etc.), and the data quality;
  • Number of system users, internal subject matter expertise, and internal project experience.

And that is only part of the delivery challenge. There will usually be an overlay of cost constraints, time constraints, and, sometimes, political constraints. It may be a multi-national project, it may span different divisions or businesses, and it can be across time zones. All of which increase the time, cost, and complexity.

Changes to any one of the things in the list above can, and will, affect everything else.

So, what can you do about it?

The core aspects of project management – governance, plans, risk logs, dependency tracking, etc. – are all important for a successful project but we would like to be more specific than that. These are our top tips based on experience:

  • Look before you leap. Everyone wants to get in to the action, but you must not skip detailed planning. We know it is laborious, uses lots of resources, and it can feel as if you are getting nowhere, but if you look at every component in detail you are much less likely to come a cropper later.
  • Mobilise properly. If you start the project with the wrong mix of skills and experience, it is difficult to recover, and you will lose both time and momentum. In your planning, make sure you understand who you need and when.
  • Map it out. Whether it is the system components, interfaces, or data migration, map it out. The more you understand about how everything is connected, the easier it will be to manage the project, keep it joined up, and assess the impact of any changes.
  • Never stop testing. It can be the easiest corner to cut, often backed by the implicit assumptions that “everything will be fine” or “we can fix it afterwards”. As recent press coverage shows, these assumptions are not necessarily correct. Test the functionality, interfaces, migrated data, systems access, volume, overnight processes, and everything else. You need to be confident.
  • Reconcile everything. It is one of the hardest things to do but it is critical. Reconcile your existing systems before your start, reconcile at every stage of the project, reconcile when you are testing migration, reconcile when you go live, reconcile across new systems and interfaces. Reconcile clients and accounts, reconcile financial amounts, reconcile static data. You need to know that everything is right.
  • Make good decisions. At each stage of the project making good decisions is key. Everyone will have worked hard to determine scope, timescales, and budgets. There may be good reason to change something but don’t do it without considering the evidence and expertise available to you. Quick decisions, sometimes forced by political pressure, almost always cause future problems.

This is a wide-ranging and multi-faceted subject to cover in a very short article. Every one of these projects have complexities and nuances that you could never conceive of at the outset but will be expected to manage when they arise, against a backdrop of time, cost and political pressure.

There is no magic solution but if you focus on detailing and mapping everything up front, making sure you test and reconcile everything as thoroughly as you can, and making open and honest decisions as you go through, you will increase your chances of success.

You can probably tell that we enjoy this stuff. If we can help, or you just want to pick our brains, feel free to get in touch.