De la necesidad al proyecto
Por qué nace un proyecto, cómo se pide (RFP), cómo se justifica (business case), cómo se autoriza (Project Charter) y cómo se acota (objetivos SMART, alcance, supuestos y restricciones).
- Reconocer el motivo que dispara un proyecto (petición del cliente, ley, oportunidad…).
- Distinguir RFP, business case, SOW, Project Charter y enunciado del alcance: quién los hace, cuándo y para qué.
- Reescribir un objetivo vago como objetivo SMART.
- Escribir un alcance con in scope / out of scope y separar supuestos de restricciones.
- Responder a una RFP sin caer en "proponer la solución antes de entender el problema".
Es el primer bloque de "etapas del proyecto" del Tema 1 (diap. 15-22) y uno de los más aplicables: "¿este objetivo es SMART?", "¿esto es un supuesto o una restricción?", "¿qué documento autoriza el proyecto?". Las prácticas P1 tocan justo esto.
1. El camino completo
Las diapositivas lo resumen así:Tema 1, diap. 15.
Esta lección cubre los dos primeros pasos y el principio del tercero (la definición). La viabilidad tiene su propia lección (6).
2. ¿Por qué nace un proyecto?
Ningún proyecto nace porque sí. Detrás hay siempre un motivo, y conocerlo es lo primero que hace el JP, porque determina qué es "éxito". El PMI clasifica los motivos habituales:Ampliación. PMBOK 6, §1.2.6.4, "factores que conducen a la creación de proyectos". Salió como pregunta de emparejar en un examen anterior.
| Motivo | Ejemplo software |
|---|---|
| Oportunidad de negocio / demanda del mercado | Detectamos un nicho sin cubrir y creamos un producto para él |
| Petición de un cliente | Los usuarios de nuestro plugin piden funciones nuevas y sacamos una versión |
| Requisito legal o normativo | Adaptar la app al RGPD o a la ley de accesibilidad |
| Necesidad organizativa | Unificar procesos internos para reducir costes |
| Avance tecnológico | Un portátil más rápido con componentes de última generación; migrar a una nueva plataforma |
| Necesidad social o ambiental | Una app pública para reducir emisiones del transporte |
TusBus nace de una mezcla: necesidad del ciudadano (saber cuándo llega el bus) y oportunidad política (la feria de agosto). Que haya una fecha ligada a un evento te dice ya que el plazo será una restricción dura, y eso condicionará todo lo demás.
3. La RFP: pedir propuestas
Una RFP (Request for Proposals, solicitud de propuestas; en la administración española, el "pliego de condiciones") es el documento con el que una organización solicita propuestas a posibles proveedores. Describe la necesidad, los objetivos, el alcance esperado y las condiciones, y permite comparar alternativas.Tema 1, diap. 16.
Contenido habitual:Tema 1, diap. 17.
- Contexto y problema
- Objetivos y alcance esperado
- Requisitos
- Entregables
- Plazos e hitos
- Criterios de evaluación (cómo se elegirá la mejor propuesta: precio, solvencia técnica, plazo…)
- Presupuesto / condiciones contractuales
RFI (Request for Information): "cuéntame qué soluciones existen"; se usa antes, cuando el cliente aún no sabe bien qué pedir. RFQ (Request for Quotation): "dame precio de esto exacto"; cuando lo que se compra está totalmente definido. RFP: "propónme cómo resolverías esto y a qué coste"; cuando el problema está claro pero la solución no. Un software a medida casi siempre es RFP.
Fíjate en quién hace qué: la RFP la escribe el cliente (el ayuntamiento). Para el cliente, redactar la RFP es una actividad de gestión de adquisiciones (lección 2): está comprando fuera. Para el proveedor (tu consultora), la RFP es la entrada de su proceso comercial.
Responder a una RFP
Las diapositivas dan cuatro reglas:Tema 1, diap. 18.
- Entender el problema antes de proponer la solución. El error típico del ingeniero es leer "app de tiempos de llegada" y ponerse a pensar en Flutter vs. nativo. Primero: ¿qué problema tiene el ayuntamiento? ¿Colas? ¿Quejas? ¿Imagen ante la feria?
- Identificar supuestos (asunciones) y ambigüedades. "Los autobuses ya llevan GPS": ¿con qué frecuencia envían la posición? ¿Quién da acceso a los datos? "Antes de la feria": ¿publicada en las tiendas o con 10.000 usuarios?
- Proponer alcance, solución, plan, equipo y costes.
- Explicitar riesgos y exclusiones. Lo que no digas que no haces, el cliente supondrá que lo haces.
El punto 4 es el que más se olvida y el que más problemas da. Una propuesta para TusBus debe decir, por ejemplo: "No incluye la venta de billetes. No incluye la integración con el sistema de pago municipal. Supone que el ayuntamiento entrega una API con las posiciones GPS antes del 1 de marzo; si no, el plazo se revisará". Eso no es desconfianza: es gestión de expectativas, y te protege en la negociación de cambios.
4. De la RFP a la definición del proyecto
La RFP describe una necesidad. El proyecto debe convertirla en un marco gestionable: objetivos verificables, alcance, requisitos, stakeholders y criterios de éxito.Tema 1, diap. 19. Para eso se usan varios documentos que conviene no confundir.
| Documento | Pregunta que responde | Quién lo origina | Cuándo |
|---|---|---|---|
| Business case (caso de negocio) | ¿Merece la pena hacerlo? Problema, opciones (incluida "no hacer nada"), costes, beneficios, riesgos, recomendación | El negocio / sponsor | Antes del proyecto (y se revisa durante: "justificación continua" de PRINCE2) |
| SOW (Statement of Work, enunciado del trabajo) | ¿Qué trabajo hay que hacer? Descripción narrativa de la necesidad y del producto o servicio a entregar | El cliente (o se pacta en el contrato) | Antes del charter; en proyectos externos va con la RFP o el contrato |
| Contrato | ¿Qué nos obliga legalmente? | Cliente y proveedor | Tras elegir propuesta |
| Project Charter (acta de constitución) | ¿Está el proyecto autorizado? Propósito, objetivos, alcance inicial, stakeholders, responsabilidades | El sponsor lo firma (el JP suele redactarlo) | Al inicio, primer documento del proyecto |
| Enunciado del alcance (scope statement) | ¿Qué entra y qué no, con detalle? Entregables, criterios de aceptación, exclusiones, supuestos, restricciones | El equipo del proyecto | Planificación |
Ampliación. En el PMBOK 6, el business case y los acuerdos (que incluyen el SOW) son entradas del proceso "Desarrollar el acta de constitución".
Ojo a una sutileza de exámenes antiguos: el business case, el SOW y el charter son documentos del proyecto o de su origen; los proveedores, el cliente, el sponsor y la organización donde se ejecuta son entidades relacionadas con el proyecto. Si una pregunta pide "entidades externas", los documentos no lo son.
5. El Project Charter
El Project Charter o acta de constitución es el documento que autoriza formalmente el proyecto. Define propósito, objetivos, alcance inicial, stakeholders y responsabilidades, y sirve como referencia para decisiones posteriores.Tema 1, diap. 20.
Tres ideas que hay que entender, no memorizar:
- Autoriza. Sin charter, el proyecto no existe oficialmente: nadie puede gastar dinero ni pedir personas para él. Por eso lo firma el sponsor (quien pone los recursos), no el JP.
- Nombra al JP y le da autoridad para usar los recursos de la organización.
- Es la referencia de decisiones. Cuando a mitad de proyecto alguien propone algo, la pregunta es: "¿encaja con el propósito y los objetivos del charter?". Si no encaja, o se rechaza o se cambia formalmente el charter.
Contenido típico (ampliación, PMBOK 6 §4.1): propósito; objetivos medibles y criterios de éxito; requisitos de alto nivel; descripción y límites de alto nivel; entregables clave; riesgo general; hitos principales; presupuesto preaprobado; lista de interesados clave; requisitos de aprobación (quién dice que hemos terminado); JP asignado y su autoridad; sponsor.
Un charter es corto (1-3 páginas). Si tiene 40 páginas de requisitos, no es un charter: es un documento de requisitos mal ubicado.
6. Elementos de una buena definición
Una buena definición contiene:Tema 1, diap. 21.
- Problema / oportunidad
- Objetivos SMART cuando sea apropiado
- Alcance y exclusiones
- Entregables
- Supuestos y restricciones
- Criterios de éxito
Objetivos SMART
| Letra | Significa | Pregunta de comprobación |
|---|---|---|
| Specific | Específico | ¿Se entiende exactamente qué se quiere lograr, sin interpretaciones? |
| Measurable | Medible | ¿Hay una cifra o criterio que diga si se ha logrado? |
| Achievable | Alcanzable | ¿Se puede lograr con los recursos y capacidades que tenemos? |
| Realistic (o Relevant) | Realista / relevante | ¿Tiene sentido en este contexto y contribuye al propósito? |
| Time-bound | De duración limitada | ¿Tiene fecha? |
Las diapositivas usan la versión "Realistas"; en la literatura también aparece "Relevantes". Si te piden las letras, cualquiera de las dos es defendible; sigue la de clase.
Transformemos objetivos de TusBus:
| Vago | SMART | Qué le faltaba |
|---|---|---|
| "Mejorar la movilidad" | "Que el 20 % de los viajeros habituales use la app semanalmente a 30 de septiembre" | S, M, T |
| "Que la app sea rápida" | "Mostrar el tiempo de llegada en menos de 2 s en el 95 % de las consultas" | M (y es un requisito no funcional, más que un objetivo) |
| "Lanzar antes de la feria" | "App publicada en Android e iOS el 15 de julio, con las 30 líneas urbanas" | S (qué es "lanzar"), M (qué líneas) |
| "Que la usen todos los ciudadanos en un mes" | "Alcanzar 15.000 descargas en el primer mes" | A y R: "todos" no es alcanzable |
"Cuando sea apropiado": no todo se puede expresar en SMART desde el día uno (en un proyecto exploratorio aún no sabes qué cifra es razonable). Pero un objetivo que nunca llega a ser medible no permite saber si el proyecto ha tenido éxito, y "objetivos ambiguos" era la primera causa de fracaso (lección 1).
En exámenes antiguos aparecía: "¿cuáles NO son acciones sino objetivos?". Un objetivo es un resultado a conseguir ("conseguir sólo un 10 % de casos de uso con errores", "resolver el 80 % de los errores en menos de 2 h", "conseguir 10 clientes nuevos"). Una acción es algo que haces para lograrlo ("convocar una reunión", "poner en marcha un curso", "hacer un listado de 100 clientes potenciales"). Pista: los objetivos llevan cifra de resultado; las acciones llevan un verbo de hacer.
7. El alcance: qué sí y qué no
In scope: funcionalidades y entregables comprometidos. Out of scope: elementos explícitamente excluidos. Y la frase clave: el alcance no definido es una fuente frecuente de conflictos.Tema 1, diap. 22.
¿Por qué escribir lo que no haces? Porque lo que no se excluye queda en zona gris, y en la zona gris cada parte entiende lo que le conviene. El cliente pensaba que "app" incluía la versión web; tú que no. Sin exclusión escrita, ganará la discusión quien tenga más poder, no quien tenga razón.
| TusBus · In scope | TusBus · Out of scope |
|---|---|
| App Android e iOS · tiempo estimado de llegada por parada · mapa de paradas · favoritos · panel web de administración para incidencias de líneas | Venta de billetes · versión web pública · pantallas en paradas · rutas multimodales · soporte 24/7 tras el cierre (se contratará aparte como mantenimiento) |
Dos enfermedades del alcance
- Scope creep (deslizamiento del alcance): el alcance crece poco a poco, sin control, petición a petición, sin revisar plazo ni coste. "Ya que estáis, añadid…". Remedio: control de cambios (cada cambio se analiza y se decide de forma explícita: lección 11) y priorización (lección 5).
- Gold plating (chapado en oro): el equipo añade cosas que nadie ha pedido porque "quedan bien". Parece generosidad, pero consume tiempo, añade riesgo y deuda, y crea expectativas. Es tan mal alcance como el que falta.
Ampliación: scope creep y gold plating son términos estándar del PMBOK (gestión del alcance).
8. Supuestos y restricciones
Se confunden mucho y en un examen de aplicar es fácil que te pidan clasificarlos.
| Supuesto (asunción) | Restricción | |
|---|---|---|
| Qué es | Algo que damos por cierto sin haberlo comprobado, para poder planificar | Un límite conocido que condiciona las opciones |
| Ejemplo TusBus | "El GPS envía la posición cada 15 s" · "El ayuntamiento nos dará acceso a la API en marzo" · "Habrá dos desarrolladores móviles disponibles" | "Publicación antes del 15 de julio" · "Presupuesto máximo 60.000 €" · "Debe cumplir el RGPD" · "Hosting en servidores municipales" |
| Qué hacer con él | Verificarlo lo antes posible. Un supuesto falso es un riesgo que se materializa | Respetarla y diseñar dentro de ella; si es imposible, negociarla explícitamente |
La conexión con riesgos es directa: cada supuesto es un riesgo potencial. "Suponemos que el GPS envía cada 15 s" se convierte en el riesgo "Causa: no conocemos la frecuencia real → Evento: el GPS envía cada 2 min → Consecuencia: los tiempos estimados no son fiables". Lo verás en la lección 12. Por eso las diapositivas insisten en identificar supuestos al responder la RFP.
9. Criterios de éxito
Cerramos el círculo con la lección 1: el charter debe decir cómo sabremos que el proyecto ha tenido éxito, más allá de plazo y presupuesto. Para TusBus: app publicada antes de la feria (plazo), 15.000 descargas el primer mes y valoración media ≥ 4 en las tiendas (valor), error medio de la estimación < 1 minuto (calidad), sin incidencias de protección de datos (cumplimiento). Fíjate en que los criterios de éxito son los objetivos SMART vistos desde el final.
Antes de planificar nada, hay que convertir una necesidad difusa en un marco explícito y autorizado: objetivos medibles, qué entra y qué no, qué damos por supuesto y qué nos limita."El alcance debe ser explícito" es una de las ideas clave del Tema 1, diap. 71.
Práctica
¿Qué motivo dispara cada uno de estos proyectos?
- Los usuarios de nuestro plugin piden nuevas funciones y sacamos otra versión
- Un portátil más rápido y barato gracias a componentes de última generación
- Añadimos funciones a la app para cumplir el nuevo reglamento europeo
- Fusionar las funciones administrativas con la recepción de pedidos para ahorrar
- Detectamos un nicho de mercado y creamos un producto software para él
¿Qué documento autoriza formalmente el proyecto y da al JP autoridad para usar recursos?
- El business case, porque demuestra que el proyecto es rentable
- El enunciado del alcance, porque fija qué entra en el proyecto
- La RFP, porque es el documento con el que el cliente pide el trabajo
- El Project Charter, firmado por el sponsor al inicio del proyecto
¿Cuáles de estas acciones deben hacerse al inicio del proyecto?
- Identificar a los interesados (stakeholders)
- Elaborar la EDT con todas las tareas del trabajo
- Desarrollar y firmar el Project Charter
- Controlar la calidad de los entregables generados
- Efectuar las compras y adquisiciones necesarias
Clasifica cada frase de la definición de TusBus.
- El ayuntamiento entregará el acceso a los datos GPS en marzo
- La app debe estar publicada antes del 15 de julio
- No se incluye la venta de billetes desde la app
- Los autobuses envían su posición cada 15 segundos
- El presupuesto máximo es de 60.000 euros
- Mostrar el tiempo estimado de llegada en cada parada
¿Cuál de estos objetivos es SMART?
- Conseguir que la nueva app de citas del hospital sea mucho más usable
- Reducir a 3 minutos la media de pedir cita por la app antes de diciembre
- Lograr que todos los pacientes usen la app de citas lo antes posible
- Hacer la mejor app de citas sanitarias que haya en todo el mercado
¿Cuáles son objetivos y no acciones de un plan para mejorar la calidad del software?
- Convocar una reunión para analizar las causas de la baja calidad
- Conseguir que sólo el 10 % de los casos de uso fallen en pruebas
- Organizar un curso de formación para los analistas de la empresa
- Resolver el 80 % de los errores encontrados en menos de dos horas
- Identificar las tecnologías en las que cometemos más errores
Tu consultora recibe la RFP de TusBus. El equipo técnico ya está debatiendo entre Flutter y Kotlin. Según las pautas para responder una RFP, ¿qué debería hacerse primero?
- Decidir la tecnología cuanto antes, porque condiciona el coste de la oferta
- Copiar los requisitos de la RFP y presupuestarlos tal y como vienen escritos
- Entender el problema del cliente e identificar supuestos y ambigüedades
- Ofrecer el precio más bajo posible, porque es el criterio que más pesa
A mitad del proyecto, un programador añade por iniciativa propia un modo oscuro animado que nadie pidió "porque queda genial". ¿Cómo se llama este problema?
- Scope creep, porque el cliente amplía el alcance sin control
- Gold plating, porque el equipo añade lo que nadie ha pedido
- Deuda técnica, porque el código se escribe con prisa y atajos
- Supuesto falso, porque se creía que el cliente lo necesitaba
Escribe para TusBus un supuesto, conviértelo en riesgo (causa → evento → consecuencia) y di qué harías con él.
¿Por qué es importante incluir en la propuesta una lista explícita de exclusiones (out of scope)? Responde en dos frases.
Repaso espaciado · lecciones 1-2
El ayuntamiento agrupa TusBus, las pantallas de las paradas y el billete móvil para reducir el uso del coche, algo que ningún proyecto lograría solo. ¿Qué es esa agrupación?
- Un portfolio, porque agrupa varias iniciativas del ayuntamiento
- Una operación, porque se mantendrá durante muchos años seguidos
- Un programa, porque coordina proyectos para un beneficio común
- Un proyecto grande, porque todos tienen el mismo cliente final
¿Por qué el temario dice que la gestión debe "reducir la incertidumbre cuanto antes"?
- Porque el mismo error es mucho más caro de corregir cuanto más tarde
- Porque la incertidumbre impide firmar el contrato con el cliente final
- Porque el PMBOK obliga a eliminar toda incertidumbre antes de empezar
- Porque los clientes no aceptan proyectos con ninguna incertidumbre
Para profundizar
Relee las diapositivas 15-22 del Tema 1 y, si haces la P1, compara tu charter con la lista de contenidos de la sección 5. Complemento: el capítulo "Project Initiation" del libro abierto Saylor, Project Management: From Simple to Complex.
Si algo no te queda claro, pega el párrafo en un asistente (Claude en el móvil sirve) y pídele otro ejemplo o que te ponga a prueba. Para dudas de interpretación del profesor, la tutoría.
Resumen imprimible: Referencia · Fundamentos.