Auditorías de Calidad de Subcontratas

 Eres un jefe de proyecto de una empresa de ingeniería. Tu empresa consiguió ganar un concurso público para instalar radares en vías de acceso a la autopista A6.

Decidiste subcontratar una parte del trabajo a una empresa.  El trabajo del proveedor implica instalación de cajas de aluminio donde se engancharían la electrónica del sistema.

Después de un par de ciclos observas que el reporting de estado que proporciona el proveedor no refleja correctamente la situación actual del esfuerzo.

¿Cuándo podemos lanzar una auditoría independiente para confirmar nuestra sospecha? ¿Cómo debemos abordar esta situación?

En el proceso de Administración de Contrato primero se debió haber definido como requisito la posibilidad de auditar sus procesos, a continuación detectada la sospecha de ineficiencia durante el proceso de Realizar Aseguramiento de Calidad solicitamos en una reunión la petición de auditoría.

Habitualmente habrá que negociar la métrica de rendimiento, un benchmark. Si la auditoría independiente muestra que el rendimiento es peor que el benchmark el coste correría a  cuenta del proveedor, asimismo abriría la puerta a posibles penalizaciones si se incurre en retrasos. Por el contrario si el benchmark es superado, nosotros deberíamos financiar la auditoría y realizar un ajuste en el sistema de medición de eficacia parte de nuestro proceso de Aseguramiento de Calidad. 

Creación de Plan de Recursos

Todos tenemos jefes. Algunos, los más afortunados sólo uno, aunque lo normal son dos si nuestra empresa tiene organización matricial. Los Jefes de Proyecto no son una excepción, pero sus líneas de reporte y dependencias suelen ser algo más complejas ya que deben rendir cuentas de sus acciones no sólo a su jefe inmediato sino también a los responsables de la Oficina de Proyecto (PMO), Patrocinadores u comités de dirección y seguimiento.

Al concedércele un nuevo proyecto al Project Manager, éste se encuentra con un dilema - ¿a quién pedir recursos para el proyecto? 

La resolución de este dilema tiene facetas burocráticas y políticas, es decir, por un lado preparar una Estructura de Descomposición de Recursos (RBS) y Plan de Recursos y por el otro negociar su disponibilidad e involucración con sus line managers y otros Jefes de Proyecto, respetando el complejo entramado de dependencias políticas que puedan existir.

La RBS principalmente sirve para hacernos una idea clara de qué tipo de recursos necesitamos y qué departamentos nos los pueden facilitar, mientras que el Plan de Recursos nos dará todos los datos reales de recursos para que podamos asignar por cada tarea a personas específicas encargadas de llevarla a cabo. 

Teniendo claro el alcance del proyecto y cuales son los paquetes de trabajo (EDT), podemos ir creando una lista de recursos genéricos (Analistas, Consultores, DBA, etc) que agruparemos por departamentos (Programación, Consultoría, Tratamiento de Datos, etc.). Dentro del plan de proyecto a cada tarea le asignamos uno o varios recursos genéricos lo que ofrecerá una visión inicial del esfuerzo, plazos, así como nos da una idea aproximada sobre el número de recursos por perfil que podamos necesitar (en función de sobreasignación).

Con el RBS y el Plan de Proyecto se conciertan entrevistas con Line Managers para llegar a compromisos de dedicación.

Alcanzados estos compromisos, tenemos nombres de recursos, fechas de disponibilidad, sus horarios, ubicaciones, costes asociados (desplazamientos, costos por uso, etc.) y también conocemos su número. Al sustituir los recursos genéricos por reales obtenemos un plan de proyecto real, con su camino crítico, recurso tambor en función del cual nos deberemos organizar y fechas. 

Proyectos grandes requieren que cada uno de estos pasos genere documentos formales, sin embargo en caso de esfuerzos medianos tener un Microsoft Project Plan con asignación de recursos y revisado con Line Managers sería suficiente.

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.

 

A veces cuando hablamos de aplicaciones OpenSource muchos suelen asociarlo con el mundo Linux, técnico y difícil de tratar especialmente para aquellos no técnicos que se dedican a la gestión.
 
En la mayoría de los casos suele ser verdad sin embargo en recientes años han surgido iniciativas que han llevado al surgimiento de nuevas generaciones de programas OpenSource pensadas y empaquetadas de manera que el enfoque se centre en el aspecto pragmático.
 
Por ejemplo las mismas distribuciones de Linux, tan ajenas a escritorios de trabajo y casas ahora están más cerca que nunca del usuario doméstico gracias a la simplificación y diseño inteligente de interfaces de usuario.
 
Lo mismo ha sucedido con robustas herramientas de gestión documental, versiones y de configuración OpenSource. Hace pocos años han aparecido startups, empresas que al ver las dificultades inherentes al modelo clásico OpenSource han encontrado un nicho, ofreciendo las soluciones OpenSource paquetizadas de forma tan tremendamente sencilla que no requiere apenas conocimientos técnicos.
 
Así un jefe de proyecto cuando necesita un sistema documental puede aprovechar la potencia, seguridad y accesibilidad de Subversion para almacenar registros documentales de proyectos y códigos fuente sin preocuparse demasiado. La empresa VisualSVN, asumiendo que usamos Windows, ha conseguido empaquetar el servidor Subversion para ahorrar tiempo y preocupaciones.
 
En Servidor:
  1. Bajamos VisualSVN Server.
  2. Instalamos el programa en una máquina Windows.
  3. Configuramos que escuche el puerto 443 (SSL) y habilitamos el soporte HTTPS por seguridad.
  4. Creamos repositorios y usuarios.
  5. Listo (Screenshot). En la consola podremos acceder por navegador al repositorio. Pero si queremos operar tendremos que instalar en maquinas clientes TortoiseSVN.
En Cliente:
  1. Bajamos TortoiseSVN, cliente con la que accederemos a la solución.
  2. Instalamos el programa.
  3. Definimos donde queremos que se almacene la copia local de los ficheros que vayamos a bajar de Subversión.
  4. El programa se integra con el entorno de Windows y nos permite, situándose en cualquier fichero de Windows,  con el botón derecha añadirlo al sistema de gestión de configuración (Screenshots).
Ahora que ya tenemos el entorno montado, cada jefe de proyecto o leader de equipo puede adaptar su propio sistema de organización de información para beneficiarse de las ventajas del sistema.
 

 

Entorno mínimo de Gestión de Proyectos

Hace algún tiempo tuve la oportunidad de empezar un nuevo proyecto en un entorno sin formales herramientas de Project Management. 
 
Concretamente siempre busco que toda la solución MS Office Enterprise Project Management (EPM 2007) estuviera disponible para poder planificar con tranquilidad, monitorizar y controlar costes y fechas del proyecto comparando esfuerzo planificado con trabajo real y almacenar documentos en un repositorio centralizado, donde estuvieran disponibles para acceso remoto a través de SharePoint.
 
Los programas diseñados por Critical Tools tales como WBS Chart Pro y Pert Chart Expert resultan tremendamente útiles, aunque no son imprescindibles. El primer programa se integra a la perfección con MS Project Professional y permite construir de forma gráfica una WBS (Estructura de Descomposición de Trabajo). 
 
A continuación, exportando el resultado a Pert Chart Expert, los paquetes de trabajo se secuencian estableciendo dependencias y se organizan de manera gráfica para facilitar una vista sencilla de la planificación en base a una línea temporal. El resultado es parecido al diagrama de red de MS Project Professional aunque resulta más claro y sobre todo útil. Toda la planificación realizada se puede almacenar como un solo fichero MPP a partir del cual los dos diagramas pueden ser accedidos con un clic.
 
De todas estas herramientas como mínimo es necesario tener una solución para planificar, basta con MS Project Professional, una solución para gestión de versiones y configuración similar a Subversión (OpenSource) o Surround SCM (comercial).
 

En uno de los proyectos en los que estoy ahora inmerso nos encontramos con la situación que había que diseñar flujos personalizados para librerías de SharePoint, utilizando componentes Windows Workflow Foundation. Los flujos estándar no servían por la rigidez y flujos diseñados con SharePoint designer tampoco ofrecían suficiente flexibilidad. Las especificaciones de requisitos de software de Microsoft requieren que tengas los siguientes componentes instalados en máquinas de desarrollo para poder diseñar correctamente flujos de MOSS con Visual Studio 2005:

  1. Microsoft Office SharePoint 2007 o WSS 3.0
  2. VisualStudio 2008
  3. Extensiones Workflow Foundation para Visual Studio 2008
  4. SDK SharePoint 2007 con ECM Starter Kit

Sin embargo si tenemos múltiples desarrolladores, no es lógico que cada uno tuviera un MOSS dedicado, por lo que podemos simular la existencia de MOSS realizando los siguientes pasos, que permitirán finalmente crear flujos sequenciales y de estado de SharePoint con VS 2005.

  1. Añadimos clave de registro en HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions12.0 y creamos valor alfanumérico Sharepoint="Installed".
  2. Copiamos de un servidor SharePoint 2007 las siguientes librerías a la carpeta ISAPI del Hive 12 de las máquinas de desarrollo y las registramos como ensamblados:
  • Microsoft.SharePoint.dll
  • Microsoft.SharePoint.Library.dll
  • Microsoft.SharePoint.Security.dll
  • Microsoft.SharePoint.WorkflowActions.dll
  • Microsoft.SharePoint.WorkflowActions.intl.dll
  • Microsoft.SharePoint.WorkflowActions.intl.resources.dll
  • Microsoft.office.workflow.tasks.dll
  • Microsoft.Web.Design.Server.dll
  • Microsoft.Web.Design.Server.intl.dll
  • Microsoft.Web.Design.Server.resources.dll

Una vez estas referencias estén correctamente registradas en el sistema arrancamos el VisualStudio 2005 y observamos que tanto el flujo sequencial como de estado muestran correctamente la barra de herramientas de flujos. Referencias y agradecimientos:

  1. En el panel de navegación superior de la Central Administration seleccionamos la pestaña Operations.
  2. En la sección Topology and Services hacemos click en el enlace Services on server.
  3. Dentro de la sección: Select server role to display services you will need to start in the table below, seleccionamos Project Application, una vez que aparece el servicio en la tabla de la parte inferior, hacemos clic en Start en la columna Action para arrancar el servicio.
  4. Seleccionamos Services on server de nuevo marcamos la opción Single Server or Web Server for small server farms. Y arrancamos los siguientes servicios:
  5. Office SharePoint Server Search
    1. Marcar opción “Use this server for indexing content”.
    2. Marcar opción “Use this server for serving search queries”.
    3. Introducir cuenta correo electrónico: nombre@dominio.com
    4. Farm Search Service Account:
      1. LEICA\Administrator
      2. (contraseña de la cuenta)
    5. Opción de rendimiento: Reduced

 

Instalación de SharePoint Server 2007 SP1 Enterprise Edition

  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. Introducimos el siguiente código de licencia que viene en el certificado (Enterprise Edition) y continuamos.
  4. Aceptamos los términos de la licencia y hacemos clic en Continue.
  5. Seleccionamos opción Advanced.
  6. En la pestaña Server Type seleccionamos Complete.
  7. En la pestaña Feedback seleccionamos No, thank you.
  8. Pulsamos Install Now.
  9. Al terminar desmarcamos la opción Run the SharePoint Products and Technologies. Configuration Wizard Now y pulsamos el botón Close.

Instalación de Project Server 2007 SP

  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. Introducimos el siguiente código de licencia que aparece en el certificado y continuamos.
  4. Aceptamos los términos de la licencia y hacemos clic en Continue.
  5. En este momento el instalador detectará el SharePoint server instalado y continuará con la instalación sin solicitar información adicional al usuario.
  6. Pulsamos Install now.
  7. Al terminar marcamos la opción Run the SharePoint Products and Technologies Configuration Wizard Now y pulsamos el botón Close.
  8. Se abre la ventana inicial de configuración, seguimos.
  9. Aceptamos que se reinicien varios servicios durante la configuración.
  10. Seleccionamos opción No, I want to create a new server farm, seguimos.
  11. Introducimos los siguientes datos y continuamos:
    1. a. Database server: LEICA
    2. b. Database name: SharePoint_Config
    3. c. Username: LEICAAdministrator
    4. d. Password: (la contraseña de la cuenta de windows)
  12. Seleccionamos la opción de autentificación NTLM y continuamos. 
  13. En este paso revisamos la configuración y si es correcta continuamos.
  14. Al terminar recibimos una pantalla con sumario y al pulsar Finish se nos abrirá la ventana de Internet Explorer mostrando SharePoint Server Central Administration para que podamos añadirlo a la lista de sitios de confianza.

Plan de Despliegue de EPM 2007

Desplegar el EPM 2007 es una decisión que implica un gran impacto sobre la empresa. Requiere que ciertos criterios estén bien contemplados antes de empezar. Uno de los principales es la madurez de la empresa en general, de sus procesos y por último de los jefes de proyecto. Simplificando el asunto, una empresa que no haya utilizado con anterioridad de forma activa Microsoft Project 2007 estándar o professional para gestionar los proyectos a diario, y cuyos Project Managers no están habituados a realizar su trabajo según procedimientos estrictos, no debería contemplar la implantación de EPM 2007. La razón es el alto nivel de riesgo y fracaso del proyecto por resistencia a cambio, tanto desde el punto de vista operativo como desde la perespectiva de impacto sobre la cultura empresarial. Si por el contrario la empresa está habituada a la gestión por proyectos, dispone de PM’s certificados o con cierta experiencia, tiene unos procedimientos que se siguen tiene muchas más probabilidades de éxito. El proceso es distinto para cada situación pero en terminos generales el EDT de 1-2º nivel es el siguiente:

  • 1. Gestión de Proyecto
    • 1.1 Formalización de alcance
    • 1.2 Revisión y validación requerimientos
    • 1.3 Seguimiento y contro.
    • 1.4 etc.
  • 2. Análisis
    • 2.1 Análisis procesos actuales
      • 2.1.1 Toma de Requerimientos
      • 2.1.2 etc.
    • 2.2 Análisis técnico entornos
      • 2.2.1 Planificación hardware
      • 2.2.2 Planificación software
      • 2.2.3 etc.
  • 3. Desarrollo
    • 3.1 Desarrollo Metodología y Procedimientos
    • 3.2 Definición plantillas EDT.
    • 3.3 Revisión Metodología y EDT con Cli.
    • 3.4 Hito. Primera aprobación cliente.
    • 4.5 Alineación procedimientos y EPM.
    • 4.6 Identificación desarrollos GAP.
    • 4.7 Identificar integraciones.
    • 4.8 Definir interfaz otros sistemas.
  • 4. Despliegue
    • 4.1 Implantación de procedimientos
    • 4.2 Despliegue desarrollos requeridos por metodología
    • 4.3 Hito. Segunda aprobación cliente.
  • 5. Pruebas
    • 5.1 Funcionales
    • 5.2 Revisión y correcciones
    • 5.3 Revisión con cliente y correcciones
    • 5.4 Revisión final y aceptación
    • 5.5. Hito. Listo para Pre
  • 6. Paso a Producción
    • 6.1 Paramentrización entorno pre
    • 6.2 Volcado y despliegue en pre
    • 6.3 Parametrización entorno pro
    • 6.4 Volcado y despliegue en pro
  • 7.Formación y Training
    • 7.1 Preparación de Material por Roles
    • 7.2 Desarrollo escenario prácticas
    • 7.3 Sessiones training.
  • 8. Mantenimiento
    • 8.1 Correctivo
    • 8.2 Perfectivo

Hay que tener en cuenta que la plantilla debe ser personalizada para cada empresa y proyecto. No todos instalan todos los componentes disponibles ni todos tienen los mismos requerimientos. El hecho es si no has realizado una implantación de EPM antes deberías trabajar con alguien que sí lo ha hecho pero si ya tienes experiencia no te costará nada ampliar y personalizar la plantilla.

  1. Descargar “SQL Server 2005 Service Pack 2” desde la web de Microsoft.
    • Aceptamos términos de acuerdo de licencia.
    • Seleccionamos todos los componentes actualizables.Seleccionamos “Apply selection to all instances” habiendo seleccionado la opción “Windows authentication”.
    • Opcionalmente podemos pulsar el botón “Test” para verificar la conectividad.
    • Continuamos con la instalación.
    • No marcamos ninguna opción de envío de datos anónimos a Microsoft.
    • A continuación el instalador comprobará si existen ficheros bloqueados. Encontrados los ficheros nos informará de que se debe reiniciar el sistema después de la instalación del Service Pack. Continuamos con la instalación.
    • El programa nos volverá a informa que existen operaciones pendientes y si deseamos continuar. Marcamos la opción “OK” y luego “Next”.
    • Desmarcamos la opción "Launch the User Provisioning Tool for Windows Vista after SP2 installation completes" y finalizamos.
    • Reinicio de la máquina.
  2. Accedemos a Windows Update e instalamos las últimas actualizaciones críticas del sistema y reiniciamos la máquina.

Tareas Post-Instalación

  1. Ejecutamos el programa SQL Server Surface Area Configuration desde el menú Microsoft SQL Server 2005 – Configuration Tools.
  2. Seleccionamos el enlace: Surface Area Configurations for Services and Connections.
  3. Expandimos nuestra instancia de SQL Server y a continuación el nodo Database Engine, hacemos clic en Remote Connections y seleccionamos la opción Using both TCP/IP and named pipes, pulsamos Ok.

QuoteClickInsure.com - Free car insurance quotes and consumer auto insurance information