Es común que la mayoría de los procesos de desarrollo de software comiencen con un plan de ataque, en el que puede encontrar los siguientes temas:
Actualmente estoy haciendo mi plan de ataque. Me pregunto si la información anterior es suficiente o si es mejor incluir más información en este plan.
Mi pregunta para todos ustedes es, ¿qué piensan de la mención de los temas anteriores en el plan de ataque, qué información describirían y cuáles son las expectativas que tendrían si estuvieran en el rol de un cliente o de un miembro del proyecto?
Estoy de acuerdo con Mark en el artefacto del estatuto del proyecto. Esencialmente establece un proyecto. Sin embargo, con respecto a los planes en general, si puede responder quién, qué, dónde, cuándo, por qué y cómo, tiene un plan. No importa si todavía se encuentra en la fase de estrategia o avanzando hacia la táctica, esas preguntas deben responderse y responderse de manera que otra persona pueda agarrarlas e irse. Cualquier otra cosa que añadir (que no sea un tema descompuesto de estas preguntas básicas) es la guinda del pastel.
Está inventando sus propios términos para los artefactos comunes de gestión de proyectos. Lo que está describiendo se conoce comúnmente como Carta del proyecto o Mandato del proyecto, aunque algunas metodologías pueden usar otros términos para este tipo de resultado de la inicialización del proyecto.
Si su organización aún no define un proceso para esto, pregunte a sus partes interesadas qué nivel de detalle necesitan. Nadie fuera de la organización puede tomar esa determinación por usted.
Una fuente describe dos de los métodos formales para documentar el inicio del proyecto, citando ejemplos del PMBOK y PRINCE2. Incluso incluye plantillas de Project Charter y Project Mandate .
Estas plantillas no son necesariamente canónicas, pero ciertamente brindan ejemplos útiles. Puede usar su propia lista de verificación y formato si satisfacen mejor sus necesidades.
Independientemente de su metodología, un documento de inicio de proyecto debe cubrir los siguientes elementos esenciales:
Otros elementos como el presupuesto, los recursos, el alcance, etc., son realmente niveles adicionales de detalle que profundizan en lo anterior. Depende de la organización y del director del proyecto determinar qué nivel de detalle se requiere para definir el proyecto.
Y antes del Primer Día no había Nada.
Luego, el Equipo Ejecutivo miró a la Nada y dijo: "Mira, esto no es bueno ya que nuestra competitividad está en riesgo".
Y así, en el Primer Día, el Patrocinador desarrolló su Mandato y se lo entregó a su Campeón y Gerente de Proyecto para que lo hiciera bien.
Y en el Segundo Día, el Campeón y el Gerente del Proyecto trabajaron con el Equipo Ejecutivo para identificar a las Partes Interesadas Clave que deben ser consultadas. Y miraron esta lista y dijeron: "Esto servirá en esta etapa".
Y con el cierre del Tercer Día, el Campeón y el Gerente del Proyecto facilitaron una discusión entre las Partes Interesadas Clave para identificar la Visión, que dio lugar a la identificación de Deseos y Necesidades. Y los Deseos fueron criticados sumariamente como demasiado costosos, pero las Necesidades se mantuvieron como necesarias.
En el cuarto día, las necesidades se desarrollaron en una descripción del producto del proyecto, de modo que todos pudieran ponerse de acuerdo sobre lo que se iba a construir y un enfoque general del proyecto y pudieran estimar los costos, los recursos y el cronograma a un nivel muy alto en un caso de negocios resumido entregado a el Equipo Ejecutivo en el Quinto Día.
Y el Equipo Ejecutivo dijo: "Podríamos tener algo aquí"
Y con esta aprobación al Sexto Día se inició una investigación más detallada de los Productos del Proyecto, sus Costos y Beneficios, a tal punto que la planificación del proyecto, incluyendo definición de Alcance, Presupuesto, Recursos, Cronograma, Riesgo, Contratación, Beneficios, Comunicaciones , Gobernanza y Calidad podría iniciarse.
Y luego, en el Séptimo Día, comenzó el verdadero trabajo...
Todd A. Jacobs
usuario1169526
MCW