effery, M. (2009). A&D High Tech (B) : gestión del cambio de alcance .

Recuperado
la de datos de Kellogg School of Management (KE L 158) (060255)

Gestión del cambio de alcance

Después con éxito la planificación y la organización de la A & D de alta tecnología en línea

almacenamiento de proyectos, proyecto encargado Chris Johnson fue ascendido a vice presidente
de e-business. Eric Robertson regresó de su licencia .y asume la posición que había dejado como el
proyecto gerente de la línea tienda.

A fines del verano de 2003, Jolmson comenzó a escuchar susurros : de sus colegas que el proyecto
estaba en problemas. El 20 de agosto , el CIO Matt Webb se acercó ficticiamente a Johnson en su
oficina. Él había simplemente despedido Robertson y querido Johnson para servir como el interino
proyecto gerente. Por más de tres meses, Robe1ison había dicho a Webb que el proyecto estaba
en pista, pero pronto se cambió curso y dijo a W flujo que él "adivinado" que podría ser al menos
un solo el mes tarde y que los costos haría horno de la ONU por más de 20 por ciento. Este fue
apenas aceptable, ya que era imperativo que el proyecto se completó en el tiempo para la fiesta de
compras temporada. El proyecto tuvo una importancia estratégica para la empresa y fue parte
integral de su estrategia de promoción de vacaciones .

Webb explicó a Johnson que no era un adicional desafío: el vice presidente de la comercialización
quería a crear "promocionales paquetes" para el día de fiesta temporada. Promocionales paquetes
son una colección de artículos agrupados juntos y vendidos en un menor costo que si los artículos
fueron comprados individualmente. ¡La tría de A&D ! promociones con SORNE minoristas habían
mostrado un aumento del 10 por ciento en las ventas con la adición de estos promocionales
paquetes, y la comercialización del plan de llamada de ellos para ser enrollada a cabo a nivel
nacional. Por lo tanto, en orden a mantener la coherencia en todas las ventas de los canales, los
paquetes también se necesitan para estar disponible en la línea tienda.

Una vez más, se le pidió a Johnson que solucionara rápidamente el proyecto. Necesitaba a analizar
el verdadero estado de la proyecto y recopilar bis proyecciones de costo y horario. Johnson también
necesaria para evaluar el posible impacto de la adición de promoción paquetes. Aunque detened
de su transición hacia su nuevo trabajo como vice presidente, Johnson fue , sin embargo, excita a
la vez poner de nuevo su proyecto de gestión de conocimientos para su uso.

Paquetes promocionales

Los promocionales paquetes y las tareas asociadas con la implementación de ellas representaban
la única funcional o alcance el cambio de la línea tienda como Johnson fijó a cabo para solucionar
el proyecto.

Los promocionales paquetes tenían no necesariamente presentan una técnica de diseño desafío
para el proyecto. El catálogo de productos de Microsoft Site Server tenía la flexibilidad de manejar
reglas complejas al tratar con diferentes esquemas de precios . Sin embargo, desde MS Sitio
servidor tenía que ser configurado y probado, un nuevo conjunto de tareas no originalmente
planificadas o , estimado necesarios para ser factorizado en el proyecto de plan.

Ventas Planificación llamados para un total de de doce promocionales paquetes. La técnica de plomo
en el equipo, Marc Sanders, estima que después de dos a de tres días de formación por persona,
de diez a doce "días-persona" que se necesita para su equipo a configme los precios de las reglas
en el sistema. La prueba de plomo estima veinte a veinticinco días-persona sería ser necesarios
para probar las nuevas características y a la regresión de la prueba los existentes producís en
conjunción con los promocionales paquetes. Sanders fue un poco woiTied sobre el tamaño ofhis el
desarrollo del equipo , ya que fue apenas mantiene hasta con sus funciones la gestión de los
existentes tareas en el proyecto.

A & D fue actualmente cargando el envío como un plano porcentaje dependiendo en orden de
tamaño. La línea tienda, sin embargo, fue a ser incorporado a manejar porcentajes y para especificar
el envío cargos en una por elemento base. En el proyecto de esquema, la línea de base estimación
de la Enviar Solicitar tareas de diseño y construcción incluyó el trabajo para el extra de envío
funcionalidad. Sanders estima que se podría reducir el 50 por ciento de la obra en los Someter
Solicitar tareas si el por artículo el envío de carga característica se retira . Haciendo así que sería
probable liberar un desarrollador que podrían potencialmente trabajar en el ERP interfaz.

Como ahora como Johnson sabía, la TI personal fue corriendo a su máxima capacidad , lo que
significaba que cualquier adicionales recursos para el proyecto se tienen a ser contratistas. A & D
no no tradicionalmente utilizar contratistas para la prueba. La tasa de mercado para un desarrollador
por contrato había aumentado a $ 175 por hom , con una tasa de horas extra del 150 por ciento. De
Johnson mejor suposición era que se iba a tomar un solo la semana para un nuevo desarrollador
para obtener aclimatados y entrenado en los procedimientos deEl proyecto.

Microsoft podría proporcionar consultores que estén completamente capacitados con la experiencia
para configurar el motor de fijación de precios para acomodar los paquetes promocionales . Sanders
tuvo la experiencia de trabajar con estos consultores , y se estima que se podrían hacer la
configuración de trabajo y formar a otro desarrollador para mantener las reglas en el sistema en
ningún más de dos a de tres días. Los Microsoft consultores pagan $ 500 por hora y requiere un
mínimum de dos semanas a organizar para la visita. Por lo tanto, para la planificación de los
propósitos, Microsoft consultores podrían ser contratados para dos a de tres días de trabajo , pero
requiere dos semanas de plomo tiempo de lo previsto.

Reunión de revisión

Después de la revisión de su nueva asignación con Webb, Johnson rápidamente se reunieron todas
las línea tienda de proyectos potenciales para conseguir su entrada en el estado de la proyecto. Él
Iearned que no había habido ninguna medida y , por tanto, ninguna evaluación - del proyecto de
gestión de métricas. Esto vino como una sorpresa para Johnson, ya que Robertson había sido
conocido a ser meticuloso en la medición de los proyectos cuantitativamente en el pasado.

Después de trabajar con los clientes potenciales de más de una semana, Johnson minuciosamente
reconstruido juntos los históricos de datos y consiguió el real tiempo dedicado a trabajar para todas
las pertinentes tareas como de Augnst 26. Ver Anexo 1 para los proyectos "reales". Él también tenía
el ganado valor de la plantilla de una anterior misión que podría ser utilizado para analizar el
proyecto de plan, si se podría imaginar fuera de cómo los eamed valor de datos podrían ser
extraídos fi · om el proyecto de software. Ver Anexo 2.

El proyecto fue originalmente programado para ser implementado por mediados de noviembre,
antes de la Acción de Gracias fin de semana. El vice presidente de la comercialización y Webb
acordó que se fue posible al retraso de la ejecución hasta que de diciembre de 1 y todavía cosechar
s o me de los beneficios de la fiesta temporada. Johnson se dio cuenta de que esto estaba lejos de
ser el escenario ideal , ya que el proyecto se perdería el fin de semana de compras de Acción de
Gracias . Sin embargo, se necesita para proporcionar Webb con una precisa evaluación de cómo y
cuando el proyecto podría ser completado .

Johnson se dio cuenta de que lo primero necesario para actualizar el original de Microsoft Proyecto
de documento. Él era no seguro de lo que, si los hay, problemas existían en el original de proyecto.
En adición, que era no estoy seguro exactamente cómo a incorporar los promocionales paquetes
en el proyecto de plan. Jolmson de experiencia dijo a él que algo iba a necesitar a ser fijo , y que la
última hora ámbito cambio se va a costar la empresa.

Ej : hibit 1: Informes estadísticos del proyecto

Línea de
Nombre de tarea base Diferen Real Restante Nombre del recurso
(días) cia
Proyecto general
Project Management
Gestionar proyecto 127 - 90 sesenta Chris Johnson ( Gerente de
2 y cinco proyecto )
Requerimientos del sistema o
- o
Reúna los requisitos 8 7 Ryan Neff ( líder funcional ), Stacy
comerciales 1
7 Lyle ( analista funcional )
Diseño de flujos de procesos 44 o 4 o Ryan Neff ( líder funcional ), Stacy
comerciales 4 Lyle ( analista funcional )
Finalizar requisitos técnicos 66 - 5 o Rick Burke ( líder de infraestructura
1 5 )
Requisitos operativos de Creale 15 o 15 o Ryan Neff ( Líder funcional ), Stacy
Lyle ( Analista funcional ), Rick
Burke ( líder de infraestructura )
Identificar las necesidades de 2 - 1 o Rick Burke ( líder de infraestructura
infraestructura técnica 1 )
Requerimientos de software
Crear requisitos funcionales
Capture el perfil del cliente 44 o 4 o Ryan Neff ( Líder Funcional )
4
Ver y buscar catálogo de 66 o 6 o Ryan Neff ( líder funcional )
productos 6
Actualizar y Cálculo Cesta de la 3 1 4 o Ryan Neff ( líder funcional )
compra 4
Tomando pagos 66 -1 5 o Stacy Lyle ( Analista Funcional )
5
Enviar orden 44 o 4 o Ryan Neff ( líder funcional )
4
Compruebe Orden de Historia y 3 o 3 o Ryan Neff ( líder funcional )
la Orden Estado
Crear requisitos de Dala 3 o 3 o Stacy Lyle ( Analista Funcional )
Crear requisitos de interfaz ERP 77 8 10 55 Stacy Lyle ( Analista Funcional )
Crear requisitos de interfaz de 44 o 4 o Stacy Lyle (Analista Funcional)
usuario 4
Diseño detallado
Diseño Capturar páginas de 13,5 o 13,5 o Marc Sanders ( Líder de desarrollo
perfil de cliente y ), Ryan Neff ( Líder funcional )
Componentes [50%]
Ver diseño y buscar catálogo de 13,5 o 13,5 o Desarrollador 1 (TBD), Ryan Neff (
productos Líder Funcional ) [50%]
Páginas y componentes

Anexo 1 (continuación)

Nombre de tarea Variación de

referencia Real Restante Nombre del recurso
(dias) o
66 Desarrollador 1 (TBD), Ryan Neff (
Diseño Actualizando y Cálculo Cesta de la compra Funclíonal Lead)
6o
Diseño Tomando Pagos Páginas y 6 o 66 o Marc Sanders ( Líder de Desarrollo ),
Componentes Stacy Lyle ( Analista Funcional )
Diseño Enviar orden Páginas y componentes 16 dieciséis o Marc Sanders ( Líder de desarrollo ),
o Ryan Neff ( Líder Funcional )
Verificación del diseño Historial de pedidos y 55 o Marc Sanders ( Líder de desarrollo ),
estado del pedido 4 1 Ryan Neff ( Líder funcional )
Páginas y componentes 12 o
Diseño Lógico y física de datos Modelo 18 - Sanjay Vohra (DBA), Stacy Lyle (
6 Analisis Funclional )
Diseño de interfaz ERP 20 10 20 10 Desarrollador 1 (TBD), Stacy Lyle (
Analista Funcional )
Planificación de prueba
Reúna los requisitos de prueba 14 14 o Kara Siposki ( Test Lead), Todd
o Eliason ( Tesler )
Crear plan de prueba del sistema y casos de 20 o Kara Siposl < i (Test Lead), Todd
prueba 20 o Eliason (Tester)
Scripts de prueba del sistema Wrile 22 20 2 Kara Siposki (Test Lead), Todd
o Eliason (Tester)
Infraestructura técnica
Crear entorno de desarrollo 20 o 20 o Rick Burke ( Líder de infraestructura )
Crear entorno de prueba 2 -4,2 10 20 Rick Burke ( Líder de infraestructura )
34. [90%]
Supporl Developmenl Environmenl 3.8 - 1,2 2,4 Rick Burke ( Líder de infraestructura )
0.2 [10%]
Entorno de prueba de soporte e implementación o 46 Rick Burke ( líder de infraestructura )
46 o
Base de datos de soporte 6o 0.1 4.5 4.5 Sanjay Vohra (DBA) [ 1 O%]
4.
Desarrollo y unidad de prueba
14 o Deveioper 2 (TBD)
Build Capture Páginas del perfil del cliente y 13
1
Componentes
Vista de compilación y búsqueda Producl Catálogo 14 o Desarrollador 3 (TBD)
Páginas 12 2
Y componentes
Construir Actualización y Cálculo 7 4 66 55 Desarrollador 3 (TBD)
Cesta de la compra
Páginas y componentes de Build 6 1 77 o Desarrollador 2 (TBD)
Taking Payments
Crear Enviar páginas de pedido y componentes 24 o 24 Desarrollador 2 (TBD), Desarrollador
o 3 (TBD}
6o o
Construir Comprobar Orden de 66 Marc Sanders ( Líder de desarrollo )
Historia y la Orden Estado
Páginas y componentes

Anexo 1 ( continuación)

Línea
Nombre de tarea de base Diferencia Real Restante Nombre del recurso
(días) o
Construir modelo de datos 10 5.5 Sanjay Vohra (DBA) [50%]
lógicos y físicos 15,5
Construir interfaz ERP 18 14 2 30 Desarrollador 1 (TBD)
años
Desarrollo de soporte y prueba 46 o 2 44 Ryan Neff ( líder funcional ), Stacy
de ensamblaje Lyle ( analista funcional )
Pruebas
Realizar pruebas de ensamblaje 32
Realizar pruebas de fase 1 12 Marc Sanders ( Líder de desarrollo )
Realizar pruebas de fase 2 20 Marc Sanders ( Líder de desarrollo
), Desarrollador 1 (TBD),
Desarrollador 2 (TBD),
Desarrollador 3 (TBD)
Realizar pruebas del sistema 160 Kara Siposki (Test Lead), Todd
Eliason (Tester), Marc Sanders
( Líder de desarrollo ), Desarrollador
1 (TBD), Desarrollador 2 (TBD),
Desarrollador 3 (TBD), Ryan Neff (
Líder funcional ), Stacy Lyle
( Analista Funcional )
Realizar pruebas de validación 80 Kara Siposki (Test Lead), Todd
Eliason (Tester), Marc Sanders
 ( Líder de desarrollo ), Desarrollador
1 (TBD), Desarrollador 2 (TBD),
Desarrollador 3 (TBD), Ryan Neff (
Líder funcional ), Stacy Lyle
( Analista funcional )
Despliegue
sistema de ejemplo 80 Kara Siposki (Test Lead), Todd
Eliason (Tester), M son Sanders
( Líder de desarrollo ), Desarrollador
1 (TBD), Desarrollador 2 (TBD),
Desarrollador 3 (TBD), Ryan Neff (
Líder funcional ), Stacy Lyle
( Analista funcional )
Implementar Para Producción 8 Kara Siposki (Test Lead), Todd
Eliason (Tester), Marc Sanders
( Líder de desarrollo ), Desarrollador
1 (TBD), Desarrollador 2 (TBD),
Desarrollador 3 (TBD), Ryan Neff (
Líder funcional ), Stacy Lyle
( Analista funcional )
Projecl Wrap-Up 90 Kara Siposki (Test Lead), Todd
Eliason (Tester), Marc Sanders
( Líder de desarrollo ), Desarrollador
1 (TBD), Desarrollador 2 (TBD),
Desarrollador 3 (TBD), Ryan Neff (
Funcionalidad principal), Stacy Lyle
(Análisis funcional ), Rick Burke (
Líder de infraestructura )

2 : Plantilla de análisis de valor ganado

La plantilla a continuación se puede utilizar para analizar el valor ganado para el plan del proyecto
A&D . El archivo electrónico que lo acompaña tiene fórmulas Excel integradas para ayudar a derivar
las proporciones de valor ganado .