¿Cómo puedo producir estimaciones más confiables para proyectos de actualización de tecnología?

Después de ejecutar algunos proyectos que actualizan la tecnología en lugar de agregar funcionalidad, noté algunos temas recurrentes:

  • Es más probable que los proyectos de actualización de tecnología excedan el presupuesto o el cronograma; es menos probable que los proyectos que brindan nuevas características incrementales excedan las estimaciones de presupuesto y cronograma.
  • Es más probable que los equipos de desarrollo subestimen los proyectos de actualización de tecnología.
    • La nueva funcionalidad tiende a tener requisitos bien definidos.
    • La funcionalidad antigua siempre es un viaje de descubrimiento, especialmente en productos ampliamente implementados con un historial de correcciones y mejoras impulsadas por el cliente.
    • Una gran parte de este legado oculto solo sale a la luz después de que el equipo tiene la oportunidad de avanzar seriamente con la refactorización.

Todo eso hace que la evaluación de factibilidad temprana y el análisis de ROI en dichos proyectos sean un desafío.

He intentado dos técnicas para abordar esto. Una técnica es agregar un impuesto constante sobre las estimaciones del equipo, pero eso puede ser crudo e impreciso, ya que los proyectos de refactorización no nacen iguales. Otra es retrasar la estimación y programar las proyecciones hasta que el equipo haya realizado un esfuerzo razonable para eliminar los costos ocultos. Sin embargo, esto no siempre funciona, ya que a veces un esfuerzo tan razonable en sí mismo es costoso y/o el negocio requiere una priorización temprana.

Me interesaría la sabiduría colectiva de las personas que han llevado a cabo este tipo de proyectos. ¿Cómo puedo obtener una previsibilidad razonable al planificar una actualización de tecnología?

Su pregunta se ha editado ligeramente, principalmente para eliminar la encuesta de opinión que genera la lista. PMSE requiere preguntas que al menos admitan la posibilidad de una respuesta canónica, en lugar de listas de listas. Una pregunta debe buscar resolver un problema, no explorar una constelación de posibilidades.

Respuestas (2)

No tengo suficiente experiencia para confirmar o refutar esta hipótesis. Dicho esto, si estuviera en el puesto, propondría el proyecto de refactorización mínimo posible (algo así como mis colegas académicos solían tener la "unidad menos publicable"). Si entiendo correctamente, trabajar a partir de los requisitos existentes implica descubrir (a través de pruebas y error) un conjunto de lo que podría llamarse requisitos culturales latentes, no declarados (estrechamente relacionados con el "conocimiento tribal" y los "Activos del proceso organizacional").

Entonces, organicemos un proyecto para hacer la actualización de tecnología menos imaginable. Eso establece un equipo (y más importante en las comunicaciones) con las partes interesadas que de repente revelarán esos nuevos requisitos. Si contratamos un proyecto de 1 mes para hacer una actualización de tecnología trivial. ("Todos obtienen un mouse nuevo"), que debería proporcionarnos un parámetro que podamos usar para mejorar la precisión de los proyectos de actualización de tecnología más grandes.

No creo que la precisión vaya a mejorar en un orden de magnitud. En el mejor de los casos, creo que esto haría un mejor trabajo al descubrir a las partes interesadas ocultas (y o partes interesadas zombis, ya sabes, no puedes cambiar esto porque Bob, que se jubiló hace 10 años y murió hace 3 años... Bob lo arregló para que solo pueda hacer este flujo de trabajo desde su escritorio y no un viernes....)

Entonces, ¿esencialmente un pico para descubrir el MVP para el estatuto del proyecto?
Creo que sí, pero estaba tratando de evitar el uso de palabras que no estoy certificado para usar.
Esto definitivamente está en el estadio de béisbol: el conocimiento tribal y las partes interesadas zombis son muy buenos términos exclusivos de este problema. Mi experiencia es que generalmente descubrimos trampas técnicas que las personas construyeron y enmascararon a lo largo de los años. Tener una tarea de punta es una forma de lidiar con ella. Aceptaré la respuesta, ya que está cerca y la pregunta estuvo abierta por un tiempo.

En mis observaciones de trabajo en esta industria a lo largo de los años, no opino que los proyectos de TI sufran nada diferente a cualquier otro proyecto en otros dominios. Lo que veo es una presión específica de la industria sobre los proyectos de TI que otros dominios han resuelto. Existe una presión significativa para que el precio del proyecto sea bajo solo para que se seleccione el proyecto. Esto comienza mucho antes de que cualquier tipo de solicitud de propuesta llegue a la calle para los proveedores de TI, y luego comienza la siguiente presión por un precio de bola bajo.

En el espacio federal aquí en los EE. UU., hay un impulso para obtener todo a un precio fijo fijo, incluso para proyectos en los que el cliente federal ni siquiera sabe lo que quiere y será "descubierto" durante el proyecto. Ningún otro proveedor de ventas de la industria firmaría un contrato como ese, pero los proveedores de TI lo hacen todo el tiempo. ¿Alguien puede imaginarse a un contratista de obras que se inscriba en una construcción de precio fijo para construir una "casa en algún lugar por aquí"?

La subestimación ocurre en todos los proyectos porque es un sesgo humano llamado sesgo de optimismo. Pero los otros métodos de estimación ayudan a controlar eso, por ejemplo, usando datos históricos, paramétricos, Técnica Delphi, etc. Sin embargo, antes de usar estos métodos probados, esta presión por la ilusión de precios necesita ser resuelta.

Gracias por la respuesta, pero mi pregunta no era sobre proyectos de TI en general, sino sobre reemplazo/refactorización de tecnología específicamente.
Mi respuesta no cambiaría, sin importar qué tan específico quiera ser dentro de TI. Creo que las presiones son las mismas. Pero tampoco hay una respuesta específica para una pregunta como esta. Estas son solo mis observaciones en este dominio.
firmando para construir una casa con un número indeterminado de habitaciones adecuadas para un clima indeterminado y adhiriéndose a un conjunto indeterminado de regulaciones y apelando a un gusto desconocido. Ese es el gobierno federal, transformando "Tráeme una piedra" en "Constrúyeme algo y te diré que no me gusta cuando hayas terminado. Ah, y tiene que ajustarse a la arquitectura empresarial que nos negamos a permiso para ser escrito, y debe ser Agile".
¡Eso es hilarante y demasiado preciso!
Exactamente, estaba buscando experiencia de personas que ejecutan proyectos de refactorización. Según mi publicación, no todos los tipos de proyectos de TI son iguales, y utilizaría una técnica de estimación diferente para refactorizar un módulo del kernel en comparación con la creación de un portal de servicios del gobierno. De todos modos, obtuve una idea de los proyectos federales en el camino; lo tendré en cuenta si alguno va en mi dirección.
David, generalmente estoy de acuerdo con tu publicación y quiero votar a favor, pero si bien esto explica el problema , no recomienda una solución. ¿Qué controles sugeriría específicamente para controlar el sesgo de confirmación o la falta de especificaciones en un proyecto de reemplazo de tecnología?
@CodeGnome, si pudiera responder esa pregunta, ya sería rico y estaría jubilado. En mi empresa, tenemos controles que se supone que ayudan con esto, pero los equipos de propuestas aprenden a sortearlos y esos controles también ejercen presión para no hacer aquello para lo que fueron diseñados; en su lugar, aparenta hacer lo que se supone que debe hacer. no se la solucion
@DavidEspina Es esta última oración: "Pero los otros métodos de estimación ayudan a controlar eso. También funcionaría en TI, si realmente los usáramos". Para mí, eso implicaba que pensabas que había una solución concreta. ¿Quizás si lo editaste? Acepto que actualmente no hay una solución conocida; solo mitigaciones, de las cuales las prácticas ágiles (entre otras) ofrecen algunas opciones.
La solución no son las técnicas de estimación (método Delphi, 3 puntos, datos históricos, etc.) porque ese no es el problema que afecta a TI. El problema es más sobre la presión de crear una ilusión de precios. La solución tiene que estar en torno a esa presión a la que nos enfrentamos. Espero que tenga sentido.
¿Puede actualizar la respuesta para abordar los problemas discutidos en estos comentarios? Creo que "la presión de la ilusión de precios" es demasiado valiosa como para perderla.
@DavidEspina, ciertamente no te equivocas, pero no veo cómo responde esto a la pregunta. Tal vez edite algunos de sus comentarios en la respuesta.
Creo que este es un tema complejo en el dominio de TI. A través de mis limitadas observaciones, induje la hipótesis de que la presión para hacer que las cosas parezcan económicas en TI es la causa raíz de estos puntos de precios poco realistas que tendemos a usar. No puedo probar la hipótesis en este momento ni puedo idear una solución. Creo que este es uno de esos problemas que todavía necesita una solución donde todavía no se puede dar una respuesta a esta pregunta. Al menos, así es como lo estoy viendo. No puedo llevar más lejos esta respuesta.
¿Cómo puedo producir estimaciones más confiables para proyectos de actualización de tecnología?
RespuestasAquíPolítica de privacidad1y, 0v