• Matemáticos reconocidos poco conocidos

    Karl Weierstraß
    (1815 - 1897)

    Maestro de Cantor, Runge,  Schwarz  y de toda una generación de matemáticos alemanes, Weierstrass es el responsable de uno de los métodos más efectivos en Cálculo: el método épsilon (nombrado así pues su notación utiliza la letra griega ε). Gracias a este método se pudieron probar varios teoremas fundamentales para el fundamento de la matemática infinitesimal lo que a la postre permitió varios de los desarrollos tecnológicos de la actualidad.

    Nacido en Ostenfelde, Westphalia (ahora parte de Alemania) , en 1828, al establecerse su familia en Paderborn, ingresó al Gimnasio Católico (institución equivalente a la educación media superior) y paso mucho de su tiempo leyendo el Journal of Pure and Applied Mathematics,  que era la revista matemática líder en Europa.  

    Mientras era profesor en el Instituto Industrial de Berlín, Weierstrass desarrollo una de las más grandes ideas matemáticas hasta el momento.  En su “Introducción al Análisis” druante los años 1859-1860, dio al mundo una rigurosa metodología para que los matemáticos trabajaran con la noción de secuencias infinitas o series que alcanzaban un límite. 

    Hasta ese momento, mucho del desarrollo del cálculo Newtoniano se basaba en ideas, nociones que se sabían verdad pero no se habían demostrado rigurosamente. El concepto de “límite infinito” aplicado a variables fijas, como en la expresión “n tiende a infinito” no se sabía realmente su significado formal.  El método épsilon resolvió esto.

    Weierstrass razonó: En lugar de que el límite estuviera definido para n como el proceso de alcanzar el infinito, por qué no definimos una secuencia infinita que tenga un límite si para cualquier épsilon  ε, siempre puedes encontrar un entero n tal que para todos los enteros m>=n, el emésimo término de la secuencia siempre estuviera a ε del límite.

    Entre los conceptos que gracias al método épsilon se pudieron formalizar se encuentran:
    + El concepto de continuidad , pieza clave para el desarrollo de la ciencia
    + El teorema de Weierstraß que trata sobre máximos y mínimos locales, y
    + Teorema de Bolzano-Weierstrass , otra pieza fundamental en la construcción de los ladrillos fundamentales del cálculo: los números Reales.

    Mucho le debe la humanidad a este gigante Alemán de las matemáticas.

  • ¿Por qué fracasan los proyectos de TI?



    Tiempo atrás Computer Weekly publicó un artículo de Tony Collins llamado: Las 5 causas por las que fracasan los proyectos de IT, desde el punto de vista del asegurador. Tony menciona una mesa de trabajo organizada en Londres por la publicación y una empresa aseguradora el pasado 24 de noviembre, en la que se discutieron las 5 causas de fracaso en proyectos de TI según los registros de la aseguradora Hiscox, especializada en reclamos por proyectos de TI fallidos. Al final del resumen me he permitido agregar algunas notas en base a mi propia experiencia. Los expertos concluyeron que las 5 causas más frecuentes de fracaso son:
    • Empezar a trabajar muy pronto. Iniciar el proyecto respondiendo a presiones y sin tomar todas las previsiones necesarias puede provocar problemas que extiendan la finalización del proyecto.
    • Un contrato ambiguo puede provocar problemas si no define adecuadamente el objetivo del proyecto, así como los roles y responsabilidades de los interesados.
    • No establecer en forma adecuada el alcance preliminar del proyecto. Frecuentemente las partes acuerdan iniciar el proyecto aun sin tener claro cuál es el producto final que se espera del proyecto, lo que puede provocar que no se determine adecuadamente su complejidad y no se asignen los recursos adecuados.
    • Administración inadecuada del proyecto y del contrato. El no dar seguimiento puntual al contrato durante la ejecución del proyecto (ignorar las clausulas del contrato) provoca que los reclamos sean difíciles de resolver. También se dificulta aplicar los procesos de control de cambios. Además, acordar el costo y tiempo de re trabajo en forma satisfactoria para las partes resultará más complicado.
    • No involucrar a la gente adecuada en el momento adecuado. Es usual que las partes no acerquen a los usuarios finales con el equipo de desarrollo desde las etapas iniciales del proyecto. También ocurre que las negociaciones las realicen el equipo gerencial del cliente y el equipo de ventas del proveedor, provocando que el cliente no solicite con precisión lo que requiere y que el proveedor ofrezca de más o confunda lo que el cliente solicita. Para el momento que se involucra al equipo adecuado ya se ha gastado grandes cantidades de recursos económicos y tiempo.

    Es muy interesante observar que los problemas mencionados no son exclusivos de un país o región, sino que parecieran ser globales. El escenario descrito de arranque rápido es frecuente, sobre todo en situaciones de crisis económica como la presente, ya que los vendedores y la gerencia del proveedor de servicios buscarán que se empiece a cobrar al cliente a la brevedad, sin haber completado las definiciones que conforman el enunciado de alcance preliminar. Y si el cliente no puede definir con claridad lo que espera del proyecto, si no es posible expresar claramente en qué condiciones el proyecto se considera concluido, el proyecto tendrá pocas oportunidades de terminar en forma exitosa. Finalmente, es recomendable acordar con el cliente y documentar los procesos para asignación de recursos en general, particularmente la administración de los recursos humanos, la administración de contratos, el manejo de expectativas de los interesados y un apropiado control de cambios.


    Las razones de Standish Group



    Un segundo artículo titulado “Why a project fails?” de Amit Sarkar refiere a un estudio de Standish Group cuyos resultados muestran que las diez razones más frecuentes por las que fallan los proyectos de TI son:

    1. Mala planeación. Los administradores tienden a pensar en la planeación como una pérdida de tiempo con el argumento erróneo de que es mejor ocupar el tiempo actuando que planeando.

    2. Objetivos y metas poco claras. Esta causa también aparece en el post anterior. En este caso la causa se atribuye a que muchos proyectos de TI se elaboran en forma progresiva y se planea por oleadas.

    Si al principio la toma de requerimientos es incompleta, el alcance del proyecto puede no ser claro y provocar que toda la evolución del proyecto (desde la elaboración del cronograma) este fundada en bases erróneas. Definir claramente los requerimientos del proyecto requiere de mucho tiempo y buena comunicación.

    Si los objetivos del proyecto se modifican se pueden producir cambios no controlados en el alcance del proyecto o en las características del producto final, impactando al proyecto en forma negativa.

    3. Manejo inadecuado de los intereses de los Stakeholders. Cuando hay interesados que no son identificados desde el principio del proyecto, es de esperarse que soliciten cambios que a su vez provoquen atrasos.

    Además, cualquier cambio tardío es más costoso y difícil de integrar pudiendo incluso provocar que todo el proyecto falle.

    4. Estimaciones de tiempo o recursos que son irreales. Es frecuente que los administradores cometan costosos errores cuando estiman recursos o tiempo.

    Un error común se comente durante la creación de la WBS, asumiendo que la duración de una tarea es el tiempo que tarda en completarse, sin considerar que se presentarán interrupciones.

    La duración de una tarea es el tiempo que tarda en completarse incluyendo las interrupciones.

    Otro problema común es usar aproximaciones lineales al estimar los tiempos. Por ejemplo, integrar el doble de programadores no va a reducir la duración del proyecto a la mitad.

    5. Asignación inapropiada de tareas y responsabilidades. Ocurre cuando el administrador no asigna tareas y responsabilidades en forma adecuada según las capacidades de los miembros del equipo, provocando confusión y (eventualmente) re trabajo.

    6. Falta de apoyo gerencial e involucramiento de los usuarios. Los administradores de proyectos de TI enfrentan muchas dificultades cuando controlan proyectos. Si el administrador trabaja coordinando y facilitando el avance del proyecto pero sin al apoyo de la gerencia entonces no podrá tomar decisiones propias o reforzar las decisiones del equipo.

    7. No comunicar en forma adecuada y no actuar como un equipo integrado. Los proyectos fallarán si la comunicación no es adecuada.

    8. Falta de una administración de riesgos apropiada. Otra potencial causa de falla es la falta de habilidad de los administradores para categorizar cuantitativa y cualitativamente los riesgos e implementar medidas correctivas.

    9. No contar con el equipo humano adecuado. Los rápidos cambios tecnológicos hacen difícil predecir las capacidades que se requerirán del equipo de TI, agregando dificultades al proyecto.

    10. Capacidades inadecuadas del administrador.

    Algunas recomendaciones que se extraen del artículo de Amit para enfrentar estas situaciones son:
    Involucrar a administradores de proyecto con la experiencia adecuada desde la etapa de planeación.

    Identificar a los interesados desde el principio del proyecto.

    Tratar de obtener (y entender) todos los requerimientos antes de iniciar el trabajo.

    Delimitar el alcance, preparar la WBS tomando en cuenta todos los requerimientos al elaborar la línea base del proyecto.

    Establecer un control de cambios de alcance efectivo, incluyendo los cambios en la línea base, analizando el impacto de cada cambio de alcance en términos de costo, calendarios, planeación de recursos, entregables, etc.

    El plan de administración de alcance debe incluir un proceso de control de cambios y este debe seguirse para identificar su origen y minimizar los efectos.

    Cuando se está preparando el detalle del enunciado de alcance del proyecto hay que trabajar en un ambiente colaborativo con el equipo, consultando con los interesados siempre que sea posible.

    Usar técnicas adecuadas para estimar la duración de cada tarea.

    Organizar al equipo de forma que cada quien trabaje en su área de especialización

    Identificar riesgos (pasados, presentes, potenciales), clasificarlos cuantitativa y cualitativamente e implementar acciones correctivas.

    Asignar el rol de "dueño o responsable de los riesgos" a una o dos personas deberán identificarlos, discutirlos con el equipo y sugerir e implementar soluciones.

    El administrador debe inspirar al equipo, compartir la visión y crear un ambiente que motive al equipo, por lo que se sugiere integrar al proyecto administradores que tengan capacidades de comunicación, planeación y organización adecuadas.

    Finalmente, algunas notas personales:

    La única sugerencia contra la mala planeación es… planificar. Tomando todo el tiempo que sea necesario, hacerlo en forma iterativa a lo largo de todo el proyecto, ajustando lo que se deba ajustar, etc. El plan de proyecto nos dice hacia dónde vamos, por lo que más vale que sea claro desde el principio.

    Se debe escuchar con cuidado a la gerencia y al patrocinador del proyecto para conocer sus puntos de vista sobre el proyecto. Por otro lado, para crear soluciones que sirvan a los usuarios, estos deben estar involucrados en todo el proceso de planeación.

    En artículos de mi blog personal he destacado ya la importancia de la comunicación (aquí y un poco aquí). Se debe comunicar a loa interesados en forma regular y efectiva: los hechos relevantes, los temas que puedan provocar preocupación, el progreso, los cambios y actualizaciones al plan de administración. Se deben considerar la forma en que cada uno de ellos puede afectar al proyecto.

    Por último, hay que prevenir los cambios fuera de control. Si un cambio es necesario, todos deben conocer su impacto en el proyecto y estar de acuerdo con ello.


    Iván Rivera
    http://ivanrivera-pmp.com
    Comments 2 Comments
    1. Regísima's Avatar
      Regísima -
      Bienvenido a este espacio, Iván.
      Un placer contar con tu colaboración.

      Saludos!
    1. rivera.ivan's Avatar
      rivera.ivan -
      Mil gracias por la oportunidad.Un saludo.
    Comments Leave Comment

    Click here to log in

    ¿Cuál es la quinta palabra de ésta pregunta? Escribe en minúsculas.