¿Qué es lo que se debe y no se debe hacer en la licitación de proyectos de TI empresariales?

Ambas respuestas anteriores indican experiencia por parte de los contribuyentes. Ambas partes hacen reclamos válidos, aunque hay más debajo de la superficie.
El Sr. Laughlin hace algunos puntos muy buenos. Para sus “hacer” no hay nada con lo que no esté de acuerdo. ¡Lo que falta es, en mi opinión, el primer paso, que es asegurar ABSOLUTAMENTE que el proyecto ha sido patrocinado al nivel apropiado en la organización Y financiado! He visto demasiadas horas de trabajo desperdiciadas en licitaciones, alcances, proyectos y planificación, en proyectos donde los fondos no se verificaron de antemano.
El otro elemento que agregaría es saber que el primer intento fallará. SIEMPRE. Si eres el primero en entrar, necesitas saber esto y prepararte para ello. Incluso puede recibir una oportunidad en la ronda 2, si está preparado para que la ronda 1 falle. Eso no significa que debas planear o fallar, pero solo debes saber que ese es el resultado más probable de la ronda 1.
Tengo el mismo sentimiento por los “no”. La lista es válida en todos los aspectos. Sin embargo, lo que falta aquí es el tiempo y la aceleración. No espere que su cliente esté preparado para comenzar, sin importar lo que diga. Cualquiera sea el plazo que hayan establecido, multiplíquelo por 3. 6 meses de inicio significa 18 meses. DE VERDAD
El otro elemento que falta es no pasar una hora hombre sin un conjunto de criterios de éxito revestidos de hierro, firmados MANUALMENTE, CON TINTA REAL, por las partes interesadas y los patrocinadores, ambos. Sin eso, fracasarás … cada vez.
El Sr. Polis también ha tenido su parte de experiencia, y también hace un argumento muy fuerte, con el que no puedo estar en desacuerdo. Sin embargo, lo que aclararía es que probablemente haya presenciado demasiados proyectos en los que el equipo de ventas o los equipos internos de implementación no estaban en la misma página, probablemente como resultado de no ser parte de las negociaciones de alto nivel, lo que significa que el proyecto tuvo un alcance en el vacío, como mínimo. Otra posibilidad es que un equipo u otro era “verde” y no realizó su diligencia debida antes de determinar el alcance o presentar su propuesta, luego obtenerla y tener que comer cualquier exceso o darse cuenta del problema antes de comenzar y tener Sacar.
Ambos caballeros proporcionan información valiosa. Cada uno ha experimentado claramente diferentes niveles de éxito o fracaso. Yo también. Y tú también. Al final, haz tu mejor esfuerzo para descubrir cualquier posible trampa, antes de entrar. No tengas miedo de hacer cientos de preguntas. Cuanto más pidas, más preparado estarás y, sinceramente, por mi parte, más confianza tendré en ti, como cliente, ya que eres tan minucioso desde el principio.
Buena suerte.

Asegúrese de tener algunos detalles sobre “quién” estará en el equipo de entrega del proyecto real del lado del cliente y quién exactamente del lado del vendedor / proveedor. Las personas “en la sala” cuando se contratan a menudo no son el equipo real de entrega del proyecto.

Además, es muy difícil hacer que un proyecto funcione sin un plan para hacerlo. Es similar a la cuestión de comprar software “listo para usar”, en lugar de “contratar resultados”. Los pasos de revisión, registro y verificación deben incorporarse y cuestan muchísimo. Por supuesto que no hacerlo cuesta como el infierno más tarde. Confiar pero verificar.

En tercer lugar, tampoco he visto un proyecto de TI empresarial que “cumpla exactamente lo acordado”, porque esto generalmente cambia durante el proyecto (no debería, pero lo hará). Los estilos de desarrollo en cascada / Lean tienen fortalezas y debilidades, pero asegúrese de saber cuál está contratando y cuál necesita. Esto es especialmente así cuando una gran parte del proyecto es “desconocido para ambas partes”, es decir, Nueva Tecnología / Nuevo Proceso = Alto Riesgo y no se puede codificar por completo.

Espero que algo de eso genere ideas para ti.

Como he ejecutado personalmente muchos proyectos empresariales de TI con éxito, no me pongo demasiado negativo al respecto.

El número uno para los grandes proyectos, implementaciones o cambios es un concepto desde dos perspectivas.

Primero el no. No intentes morder demasiado de una vez.

El hacer. Utilice múltiples fases, cada una de ellas separada de la otra y con hitos claramente definidos entre ellas. Asegure el éxito en cada iteración y su salida final funcionará.

Eso es lo más importante mientras se ejecuta un proyecto, pero antes de eso, ni siquiera comience nada sin un problema claro que resolver. Nunca implemente ninguna solución “solo porque”, incluso si parece dinero fácil. Ningún problema claramente definido significa que no hay requisitos comerciales significa que no hay solución significa que no hay éxito.

Hacer:
Asegúrese de que los requisitos sean herméticos. Evite el deslizamiento del alcance.
La cotización es inclusiva, incluye impuestos, entrega, varios.
Gastos únicos y anuales por separado. Lista de mantenimiento por separado.
Concéntrese en construir una relación a largo plazo.
Negociar. No pagues al por menor. El precio puede bajar un 50%.
Estar dispuesto a alejarse.

No:
Intenta competir en nickles y dimes. Es el paquete, el equipo, el software.
Apresura el trato.
Para ventas, olvide el trimestre de ventas. Para TI, este acuerdo podría costarle su trabajo.
Piensa que conoce o comprende al comprador.
Confíe en el proveedor para todas sus preguntas.
Traiga un gran equipo de ventas a las reuniones.

El principal no es NO LO HAGAS. Publicidad, por el contrario, nunca he visto (o incluso oído hablar) de un proyecto de TI empresarial exitoso. El concepto es fundamentalmente defectuoso y la única razón por la que los clientes afirman que los proyectos tuvieron éxito es porque han gastado tanto dinero que muchos gerentes serían despedidos si alguna vez admitieran la verdad. Este es un buen ejemplo de lo que probablemente sea la cosa más importante al tratar con cualquier tipo de proyecto: NECESITA SABER DE QUÉ PROYECTOS SE LEVANTARÁ.