Enhorabuena, ya tienes asignado un proyecto y el orgullo de ser un Jefe de Proyecto no te quita nadie. Celébralo ahora y prepárate justo después que viene una ola de hostias de campeonato. Una pastilla de aspirinas y buena preparación puede que eviten que tu estado anímico recaiga con la misma rapidez de un bipolar.

Una de las primeras cosas es hacer que el cliente ya no hablo de tu propia empresa entiendan cuál es tu rol en el proyecto. Algunos, no especialmente familiarizados con el concepto de gestión pueden erróneamente atribuirte tareas que no te corresponden, generando así expectativas que seguro que no podrás cumplir.

Una llamada al Cliente, sus contactos técnicos y/o de gestión, claro está si no tienes un project manager al otro lado puede evitar muchas decepciones.

Una buena agenda para esta llamada podría ser:

• Explicar tu Rol en el proyecto
• Habla sobre tu propio background y experiencia en la Gestión de Proyectos
• Habla sobre la función de jefe de Proyecto (9 Áreas de Gestión de proyecto)
  • Integración – Cumplimiento de Metodología e integración del resto de áreas de conocimientos.
  • Alcance - Planificación de proyecto desde perspectiva de alcance (lo que se va a hacer y lo que no se va a hacer en el proyecto)
  • Tiempo - Control de línea de tiempo, entregas, entregables y plazos.
  • Coste - Control de línea de costes, valor acumulado, etc.
  • Calidad - Control y aseguramiento de calidad en todo el proceso interno y externo del proyecto.
  • Recursos Humanos - Organización y distribución de trabajo para todo el equipo de desarrollo (menciona el número de personas involucradas).
  • Comunicación – Gestión de expectativas, reporting, vamos el 90% de tu tiempo.
  • Riesgos – Gestión de los riesgos, calificación y diseño de planes de contingencia y estrategias de mitigación.
  • Aprovisionamiento y adquisiciones - Aprovisionamiento y gestión de infraestructura necesaria para el proyecto. Compras y Gestión de contratos, etc.

Toda la charla es difícil de tragar y asimilar, así pues para terminar resume tus objetivos. Por ejemplo: Mi propósito es asegurarme de que el proyecto se entrega según el alcance definido, dentro de las limitaciones de coste y en plazo.

A continuación sería conveniente ofrecerle al cliente la oportunidad de preguntar por si tiene alguna duda que puedes aprovechar para reforzar tu mensaje inicial.

Luego si lo/la ves receptivo deja claro los siguientes puntos:

• Todo lo que tiene que ver con la gestión del proyecto (tiempo, alcance, coste, recursos, logística) es necesario tratar con el PM ya que si cualquiera de los aspectos de esta triple restricción (alcance, tiempos y coste) cambia afecta a las demás.
• Si cualquiera de los aspectos de esta triple restricción (alcance, tiempos y coste) cambia yo debo estar informado y autorizar y controlarlo.

Espero que la llamada vaya bien y que el cliente cuelgue con una clara idea de lo que un PM es, qué puede hacer y para qué sirve.

El “poder duro” y el “poder blando” son caras de la misma moneda, atributos o tipologías de un fenómeno sociológico a las órdenes de líderes, políticos, empresarios, jefes de proyecto, ciudadanos corrientes que diariamente, sin darse cuenta de ello, intentan alterar la realidad que les rodea a su favor.

El “poder duro”, asociado normalmente con la agresividad, a través de medidas de coerción, ejercicio de fuerza y amenaza de castigo, es un término clave en muchas de las teorías de realismo político y estrategias de negociación en proyectos. Teorías históricamente relevantes al concepto de poder ya que enfatizan la codicia de algunos negociadores de conseguir la situación de ganancia, dominación, sin considerar siquiera la posibilidad de llegar a un win-win. Esta vía de lograr los objetivos requiere fuerza física, acceso a recursos y a medida de que los interlocutores evolucionan en su conocimiento y experiencia, rara vez resulta eficaz a largo plazo y puede suscitar una respuesta inesperada (e.g.: rotura de negociaciones y situaciones lose-lose). Sin embargo, existen situaciones cuando el uso de “poder duro” es la única vía para alcanzar el objetivo.

Mientras que el “poder blando”, un instrumento igualmente afilado en manos de un project manager apto, sirve para conseguir los mismos objetivos pero mediante diálogo, convencimiento, negociación e incluso manipulación. El empleo provechoso de poder blando depende de otras restricciones, tales como capacidad de comunicación, carisma personal, credibilidad y autoridad aunque a veces puede confundirse con debilidad. El “poder blando” difícil de utilizar per se, a diferencia del “poder duro” muy pocas veces resulta suficiente, salvo excepciones. Una forma efectiva de conseguir nuestros objetivos políticos en el proyecto es combinar las características comunes y las diferencias de ambas técnicas coactivas vistiendo "la mano de hierro” con “un guante de terciopelo”.

El reto de los managers de hoy es saber medir la cantidad de ambos ingredientes y combinarlos para conseguir el “poder inteligente”, menos invasivo, menos dependiente de recursos y más diplomático. Para concluir, los dos tipos de poder son simples medios para conseguir un fin, los dos pueden ser igualmente poco humanitarios y utilizados de forma independiente su eficacia a veces es limitada. Cada uno de los poderes tiene sus propias características únicas y limitaciones: el “poder duro” es intensivo en uso de recursos, perseverancia, requiere fuerza física y se materializa a través de agresión; el “poder blando”, a su vez más difícil de usar, precisa dones de comunicación, carisma personal, credibilidad y diplomacia entre otras cualidades.

Referencias:

• Joseph S. Nye Jr., 2008, “El próximo líder estadounidense” (PDF), Project Syndicate.
• Jack Donnelly, 2000, “Realism and International Relations”, Cambridge University Press.
• Joseph S. Nye Jr., 2004, “Misuses of Power: Causes and Corrections”, Compass: A Journal of Leadership.
• Alexander Moseley, 2006, “Political Realism – The Internet Encyclopedia of Philosophy”, URL.
• Joseph S. Nye Jr., 2006, “Soft Power Is Cultural Power”, Foreign Policy, 1 March 2006.

1. Insertar el medio o montar la imagen para iniciar la instalación.
2. Al realizar el paso anterior el sistema abrirá una ventana.
3. Seleccionamos la opción “Server components, tools, Books Online, and samples”.
4. Aceptamos el contrato de licencia y continuamos con la instalación.
5. En este paso el proceso instalará los ficheros de soporte y el cliente nativo de SQL.
6. A continuación se iniciará la parte clave de la instalación de la aplicación que tras comprobar los requisitos de instalación nos permitirá proseguir.
7. Introducir datos de registro y el número de licencia aparecerá automáticamente (por lo menos en la versión que tengo yo).
8. Seleccionamos los siguientes componentes:
   • “SQL Server Database Services”
   • “Analysis Services”
   • “Reporting Services”
   • “Notification Services”
   • “Integration Services”
   • “Workstation components, etc…”
   • Seleccionamos el botón de opciones avanzadas para configurar la instalación.
   • Continuamos sin modificar ningún ajuste.
9. Seleccionamos “Default instance” y continuamos.
10. Marcamos “Use the built-in System account” y elegimos la cuenta “Local System”, continuamos dejando los ajustes en este pantalla por defecto.
11. Seleccionamos “Windows Authentication Mode”.
12. Definimos intercalación del servidor:
    • Collation: “Latin1_General”.
    • Marcamos las opciones:
      • “Accent – Sensitive”
      • “Kana – Sensitive”
      • “Width – Sensitive”
    • Continuamos.
13. Seleccionamos “Install the default configuration” y continuamos.
14. En la pantalla de feedback no marcamos ninguna opción y continuamos con la instalación.

1. Añadir Roles
   1. Acceder al componente Manage Your Server.
   2. Activar el enlace Add or remove a role.
   3. Seleccionar Custom configuration para continuar.
   4. Elegir opción Application Server para continuar.
   5. Habilitar uso de ASP.NET. El sistema procederá con la instalación del rol.
2. Instalar .Net Framework 3.0
   1. Descargar el instalador de la web de Microsoft.
   2. Ejecutarlo para efectuar la instalación en el equipo.
   3. Acceder a Internet Information Services (IIS) Manager y comprobar que ASP.NET v2.0.50727 está habilitado.
   4. Acceder a Windows Update y asegurarse que la máquina tiene las actualizaciones más críticas.
      • .Net Framework 3.0 Service Pack 1.
      • Tras concluir el proceso de actualización reiniciar.

Configuración del Sistema Operativo

1. Después del reinicio acceder al sistema con las credenciales facilitadas.
2. Configurar resolución pantalla 800×600 a 16 bits.
3. Desde Virtual PC 2007 instalar Virtual PC Addons y reiniciar.
4. Configurar adaptadores de red:
   • Renombrar Local Area Connection 1 a Bucle Invertido.
   • Renombrar Local Area Connection 2 a LAN.
   • Configurar adaptador Bucle Invertido:
     • Número IP: 192.168.0.1
     • Máscara de red: 255.255.255.0
     • Deshabilitar el servicio firewall en esta interfaz de red.
   • Configurar adaptador LAN:
     • Ajustes automáticos por DHCP.
5. Desinstalar componente Windows Internet Explorer Enhanced Security Configuration.
6. Configurar Internet Explorer:
   • Usar página de inicio en blanco.
   • Marcar que no se utilice proxy para conexiones locales.
7. Actualizar el sistema:
   • Descargar e instalar el Windows Server 2003 Service Pack 2 (32-bit x86). Reiniciar.
   • Acceder a Windows Update y asegurarse que la máquina tiene las actualizaciones más críticas. Reiniciar.
8. Acceder a System Properties – Advanced – Performance y seleccionar la opción Adjust for best performance.

Continuará…

Creación y Configuración Máquina Virtual

• Nombre archivo: Windows 2003 Server EPM 2007
• Memoria RAM: 1.024 Mb. (1 Gb.)
• Disco duro 1: 20.480 Mb. (20 Gb.)
• Discos para deshacer: Habilitado
• Adaptadores de red: 2
• Adaptador de bucle invertido de Microsoft (Instalado en Máquina Host)
• Controladora Ethernet (Instalada en Máquina Host)
• Sonido: Deshabilitado

Instalación Windows 2003 Standard (EN)

Instalación del Sistema Operativo

1. Arrancar el equipo virtual recién creado con el CD o imagen de Microsoft Windows 2003 Server Standard Edition (EN).
2. Cuando se pida pulsar “Intro” a continuación aceptar el acuerdo de Licencia pulsando “F8”.
3. En la pantalla de particionamiento pulsar “Intro”, habiendo seleccionado el espacio no particionado.
4. Seleccionar formato de partición NTFS (Rápido).
5. El sistema continuará con la instalación, reiniciando posteriormente el equipo.
6. En configuración Regional pulsar acceder a “Customize”.
7. Seleccionar formato “Spanish (Spain)”. Seleccionar ubicación “Spain”.
8. En la pestaña “Advanced” seleccionar “Spanish (Spain)”.
9. “Aceptar”
10. En la misma pantalla acceder a “Details”.
11. Seleccionar “Spanish (International Sort)” del desplegable.
12. “Aceptar” y continuar con la instalación.
13. Introducir Nombre y Organización.
14. Introducir el número licencia VLK para R2.
15. Seleccionar opción licenciamiento “Per server” 5 conexiones.
16. Introducir nombre servidor (LEICA).
17. Definir contraseña.
18. Fijar fecha y hora correcta y la zona horaria a GMT+1 Madrid, con opción de ajuste de hora automático. Continuar.
19. Seleccionar opción “Custom settings” en la pantalla de configuración de red: Aceptar opción por defecto para 1ª tarjeta de red. Aceptar opción por defecto para 2ª tarjeta de red.
20. Definir workgroup. Continuar con la instalación.
21. Después del reinicio acceder al sistema con credenciales facilitadas e insertar el CD 2 o la imagen del 2º disco de instalación Windows 2003 Standard Edition para actualizar e instalar componentes R2 del sistema operativo.
22. Introducir el mismo código de licencia utilizado en el paso
23. Continuar con la instalación.

Continuará…

Quería dedicar este post al contenido genérico del SOW. Cierto es que según industria el documento se formula de diferentes formas sin embargo creo que existen unos ciertos criterios comunes para crear un documento SOW bien atado. Está claro que no pretendemos hacer un documento blindado desde el punto de vista legal, en eso os podrían ayudar los servicios jurídicos de vuestra empresa. Es preferible si usamos MS Word prepararnos una plantilla genérica dónde usaremos campos para que en el caso de tener que reutilizar el documento podamos fácilmente localizar aquellos puntos importantes rápidamente para cambiarlos. Por ejemplo en la documentación uso campos para atributos Nombre Cliente, Razón Social, CIF, Dirección, Número de Horas Neto, etc. Cada SOW igual que otros documentos de proyectos deberían llevar una tabla de gestión de cambios, dónde cada vez que se modifique se incluyera una nueva versión y el nombre de la persona encargada del cambio.

• Términos Generales – Sumario de participantes cliente(s)/proveedor(es) y referencias al acuerdo marco (si existe).
  • Fechas inicio/fin y validez documento.
  • Sumario de alcance
• Contactos - Definición de stakeholders más importantes del proyecto.
  • Contactos del Cliente – PM Cliente(s) y Sponsor.
  • Contactos del Proveedor – PM Proveedor(es) y Sponsor.
• Ubicación - Definición exacta del lugar de prestación de servicio (onsite, offshore, etc.).
• Sumario Términos Comerciales - Definición del término y plazo de pago.
• Firmas - Firmas de los respectivos firmantes autorizados.
• Anexo - En esta parte del documento se detallarán la mayoría de los puntos anteriores.
  • Objetivos del Proyecto – Detalle de objetivos proyecto desde principales a secundarios.
  • Hitos ó Milestones por Fase – Cada fase debe definir la fecha del milestone junto con la descripción del producto a entregar en esta fecha.
  • Entregables – Detalle de entregables por cada milestone (ficheros, documentación, cd’s, planos, instrucciones, etc.).
    • Diccionario de entregables – Explicar que significa cada uno de los entregables.
  • Recursos - Listado de personal/perfiles y su número junto con la descripción del perfil de personas participantes en el proyecto.
  • Horas y Duración – Detalle de horas por cada fase y duración de las mismas.
  • Cláusulas especiales – En algunos casos es imprescindible definir clausulas particulares para proyectos.
    • Colaboración - Si dependemos del cliente o cualquier otro stakeholder deberemos limitar nuestra responsabilidad.
    • Gestión de cambios – Política de gestión de cambios.
    • Mantenimiento posterior – Delimitaremos el ciclo de vida del producto y separaremos su desarrollo del mantenimiento, dejando claro que el mantenimiento post-garantía es un proyecto distinto.
    • Otras.
  • Garantía - Periodo de garantía para el producto y los cambios realizados
  • Inversión - Costos por hora, hora extra, fines de semana, costes totales y por fase.
  • Reembolso y Gastos – Acuerdo sobre términos de autorización y reembolso de gastos.
  • Calendario y Pagos – Porcentajes e importes según fechas/hitos/entregables.

Comentarios:

• Los SOW’s deben hacer referencia a la documentación de fondo.
• Es buena idea incluir o acompañar el SOW con un Project Plan detallado cuyos datos coinciden con los incluidos en el sow.
• El SOW debe ser revisado por servicios jurídicos de la empresa y por el PMO en todo caso.

El documento Statement of Work (Orden de Trabajo) normalmente se prepara por los clientes enviándolo al proveedor para que éste tenga en un solo documento definido el alcance del trabajo, sin embargo puede que este acercamiento no sea el más adecuado para la mayoría de ocasiones, con grandes e incluso medianas empresas. La preparación de documentación todavía no se considera como parte integral del proceso sino un "mal" con el que hay que lidiar. Pedirles a clientes que ya te han hecho un "favor" de considerarte posible proveedor que prepare un documento administrativo puede ser a veces mucho pedir es por ello ellos – los clientes buscan proveedores que les quiten los problemas no añadan nuevas. Por eso, si el proveedor tiene una mayor madurez de proceso que el cliente será necesario contemplar que la preparación de documentos debe ser llevada acabo por los propios consultores o project managers, de esta forma nos aseguraremos de que el cliente no se quema, ni tampoco se le olvida algo importante a la hora de formular el SOW o cualquier otro documento de proyecto.

Continuará…

Trabajando con distintos proveedores y clientes a veces nos llegan muchas iniciativas que podrían convertirse proyectos sin embargo un gran volumen de los mismos no llega a prosperar por distintas razones. Para evitar quemarse y agotar a nuestros proveedores el Project Manager selecciona los proyectos que más interesan a la empresa y también se encarga de elaborar la documentación inicial para que los proveedores sean internos o externos (desarrolladores) puedan estimar. Si cada vez les pedimos que inviertan un tiempo considerable en la estimación definitiva nos vamos a encontrar de que se invierten muchas horas para esfuerzos que quizás no compensen. Por ejemplo proveedores pueden quemarse de tanto estimar y no ganar proyectos. La solución podría ser en aplicar la técnica de rolling wave (moving window) en la estimación, elaborar primero un ROM estimate o Budget Estimate y mostrarlo al cliente. Si no se "asusta" y da el visto bueno preliminar proceder con Definitive Estimate en formato MS Project. Al tenerlo se lo proporcionamos con esperanza de que lo aprueben. Al aprobarlo procederemos a preparar un documentos SOW correspondientes.

Continuará…

De repente nos comunican que el proyecto actualmente en curso debe ser cancelado anticipadamente. ¿Qué exactamente debemos hacer? Hay varias salidas lógicas que muchos de los PM’s podrían plantear, por ejemplo a) Reunirnos con el sponsor del proyecto para intentar que cambie de opinión, b) Empezar a identificar hasta que punto se ha realizado el trabajo, c) Evaluar el impacto de la decisión en los stakeholders involucrados en el proyecto o la opción d) Proceder a enviar avisos a los involucrados informándoles de lo sucedido. PMI busca que los PMP’s sean responsables, piensen antes de actuar y evalúen las consecuencias antes de llevar acabo las acciones. Quizás sea útil conversar con el Sponsor sobre la razón de cierre, sin embargo el PM no decide si el proyecto va adelante o no sólo puede influenciar la decisión. Directamente proceder a evaluar hasta que punto hemos concluido el trabajo, puede ser una opción bastante válida pero precipitada. Según el criterio de prudencia primero evaluaremos el impacto de cancelación del proyecto y luego actuaremos, lo que hace que la opción C sea la más válida. Y para no dejar la D sin comentar, creo que es irresponsable directamente enviar avisos de lo sucedido a los involucrados ya que posiblemente desconocemos el impacto de esta comunicación.