Risk Management on programs

Tolerate uncertainty and live with it, understand complexity, ambiguity and live with it, manage all these tensions about what can happen is the main goal of risk management.

Projects managing risks in an isolated way is a big risk for the organizations. By this reason the use of a clear risk management framework at program or portfolio level is used.

Risk management strategy, should reflect the organization’s risk policies and processes. In this way the program will inherit same principles and risk appetite of the organization. It also facilitates the organization to define the limits of delegation of authority they want to delegate.

The definition of tolerance thresholds is key as it translate risk appetite into a guideline that steers program and project behavior. Thresholds define the exposure to risks on one level that, if exceeded, requires escalation and reaction from level above.

The uncertainty associated to a risk is expressed within the relationship of the likelihood and the impact it has (preferably expressed in $$). In a program the complexity increases as the combination of risks of different projects can generate a complicated net of exposure, which typically is represented on a risk matrix diagram. Sometimes what is negative for a project is an opportunity for other.

The use of healthy checks during the definition of the programs or the attendance of a bid is key to review the business case or the opportunity from risk management perspective. They oblige you to think about key questions you should think about. I find them useful, not as a controlling tool.

Project aggregation; sometimes a project under execution is added to a program. This requires to the program team to asses the impact of this addition at risk level, review the business case and review the budget.

Risk-Matrix

Amazon QuickSight

QuickSight is the Business Intelligence solution offered in AWS. Today, I assisted to a presentation webinar where a demo of the solution was done (as usual this was the useful side of the event).

A no-brainier solution for all users that requires a BI tool. You can also use data from your own databases.

Spice is the component that makes all this possible, questions related to the time response provided by Spice is the key to see how useful is and if users accept it.

AWS-QuickSight

Planning and controlling transition

The sample below comes in the managing successful programmes book. The diagram describes a simple example showing outputs, transition management and benefits realization.

MSP-planning-and-controlling-transition

  1. Benefit baseline measurement, done during the development of the blueprint to understand how we go from the situation “as-is” to the desired state “to-be”.
  2. Output, the project has been delivered.
  3. which is received by the business unit as Enabler,
  4. to take into its operations (Sustained business operations).
  5. Business change management, changes may be required for this single enabler to embed it into operations.
  6. Operational outcome, is the achievement itself at operational/business level.
  7. Benefits realization, must be tracked by the Business Change Manager (BCM).
  8. Embedded change, a change that sticks.

The cycle is simple, and so much times is not understood by people around a program. I recently have seen how the role of Business Change Manager was lost after a program concluded, and there were no follow-up of the business benefits after that: a completely waste of time/money/effort for an organization who invested a lot on such program.

Program Control

A Program is controlled from different axis and these controls are required by different stakeholders. To attend all of them in a efficient way requires understanding of all this.

Program control is a process composed by activities where corporate group ask about the evolution of the program in one area (Finance, legal, quality assurance…). This process has to be established since the program inception.

The aim of a program and project are different. The aim of the program is the realization of expected benefits, through the achievement of desired outcomes. The aim of the project is the delivery of the outcomes and capability. The difference may lead to tensions between project and program control processes. So much people know this and if the program has detractors, they will try to use this tensions to add more pressure.

Re-use communication channels. The communication flow between the program, its projects and the business operations should be based on the governance standards. In this way, when control activities are required, if documentation and communication channels are well established, the addition of these stakeholders is easier.

Manage a program does not mean micro-management of its projects. Projects should be empowered but need tolerances and limits, in order to ensure that they do not  exceed their delegated authority. Allowing the project managers to manage their projects within the tolerances set by the program is a essential part of good program management. It will also give a clear view to the “controllers” about the situation of the program.

Ask Delivery Assurance. Big corporations have DA groups or QA teams that execute audits on programs and projects. Even if you have go through these processes, it is good to ask during the definition of the program, when the QA audits will be performed, what type of information they are going to require, and if there are extra requirements.

Keep your map of dependencies. You will have 1) internal dependencies to the project, 2) intra-dependencies on other programs and 3) external dependencies. When something fails in a program and you are reporting to a control audit you will be asked about “why” this is affecting you and what is the impact. To have a dependency map, looking into the projects as back boxes with inputs/outputs, will provide a crucial control tool for the program manager. Project assumptions is a source of information for program dependencies: use them, and ensure they are coordinated and understand the program dependencies that could affect to them.

DevOps y el camino de baldosas amarillas

Este libro llegó a mis manos mientras buscaba un libro que hablara de DevOps de una forma sencilla y práctica. Así que lo compré y lo leí en un par de días. El libro se lee muy rápido y es porque Juan José escribe como habla, y no añade ningún giro que complica entender los conceptos y seguir el hilo conductor.

Juan José Mora hace una buena revisión de conceptos básicos y tendencias que hoy en día están llevándose a cabo en el mundo del IT y si no eres muy tecnófilo te vendrá bien, a mi esta parte me sobraba un poco, pero bueno.

Una vez que el libro fue al grano sobre DevOps, se describen muy bien las problemáticas, las presiones y como identificar que es y que no es DevOps. Desmitifica muchos conceptos que son incorrectos y aclara de que trata realmente DevOps. Este ejercicio también ayuda a como DevOps se relaciona con el resto del sistema.

A mi me parece que es un libro muy válido para:

  • Personas que están en el mundo de los negocios y que necesitan refrescar ideas y aclarar conceptos sobre metodologías y entender como funciona un departamento de IT.
  • Personas que trabajan relacionándose con IT y que les vendrá bien para entender un poco de las presiones que sufre un departamento de IT.
  • Juan José, si algún día lees esto, imprime el libro y llena los aeropuertos con copias, muchos de los que viajan de lunes a viernes en avión deberían leer tu libro.

Portada_DevOpsLos tres principios básicos de DevOps son:

  1. Mirar el sistema como un todo.
    1. No trabajar en modo frontera.
    2. Quitar barreras (no significa que las responsabilidades desaparezcan).
    3. Mantener alineados el binomio negocio-tecnología.
  2. Incrementar el feedback.
    1. De los sistemas y de las personas.
    2. Mejorar los canales de comunicación.
    3. Los sistemas de IT son cada vez más complejos, hay que ganar conocimiento de ellos, de como se comportan. No permitir que existan cajas negras que nadie sabe que hacen.
    4. Es importante diseñar los canales de feedback con los que queremos contar, y revisarlos.
  3. Experimentación y aprendizaje continuo.
    1. Quitarse de la cabeza el “si funciona, no lo toques”.
    2. Luchar contra la obsolescencia.
    3. “Si funciona, mejóralo”: sino vendrá otro y será más competitivo que tu.

Herramientas DevOps:

  • Automatizar, automatizar, automatizar.
  • Gestión de la configuración.
  • Despliegue automático.
  • Gestión de logs.
  • Gestión del rendimiento.
  • Gestión de la capacidad.
  • Escuchar, hablar, compartir.

Que es DevOps, que no es DevOps:

  1. DevOps no pretende solucionar un problema de IT, pretende solucionar un problema de negocio.
  2. IT es ahora un proceso clave para todas las empresas, desde IT hay que ser proactivo y mirar hacia los objetivos de la empresa, y como IT puede contribuir a esos objetivos.
  3. DevOps es un cambio cultural que hay que hacer desde dentro, no se puede subcontratar, o enseñar con cursos.
  4. Devops se propaga por el convencimiento de las personas que participan, no por imposición.
  5. Compartir es una apuesta ganadora para comenzar a construir una cultura DevOps dentro de una organización.
  6. No debes montar un equipo DevOps, eso crea barreras, que es lo que pretende eliminar DevOps.
  7. Debes construir tu propia cultura DevOps en tu organización; no siempre lo que funciona en un sitio funciona en el otro.
  8. DevOps no es un proceso, no es una metodología.
  9. DevOps no sustituye a metodologías ágiles.
  10. Al intentar poner en marcha DevOps habrá resistencia al cambio. Hay que evangelizar estos principios, promoverlos, y hacer piña con aquellas personas que creen que poniéndolos en práctica mejoran la organización.
  11. DevOps puede ayudar a las organizaciones a vencer su rigidez, gracias a promover un IT más elástico que se ajuste mejor a la estrategia de la compañía.
  12. DevOps promueve la práctica de la transparencia.
  13. Con DevOps no tienes que cambiar tu estructura, debes cambiar la forma en que se relacionan las personas de tu estructura.
  14. DevOps no debe construir silos, debe ayudar a generar una red de tuberías que mantengan los silos conectados y actualizados.
  15. DevOps es válido para todo tipo de organizaciones (pequeñas y grandes).

Metamind, deep learning for enterprise

This session organized by data driven NYC shows some use cases related to deep learning, focusing on uses you can give for enterprises:

  • Find the number of times your logo is shown on TV in a sport event you are sponsoring.
  • Identify car brands.
  • Relatedness of Sentences.
  • Identify locations in a text.
  • and more applications you can find here: https://www.metamind.io/

https://www.metamind.io/

The Goal

I just finished to read this novel written by Eliyahu Goldratt and Jeff Cox.the-goal

Independently if you work on Manufacturing industry or not, this book reviews fundamental basis related to theory of constraints, methods to manage a supply chain.

I specially like the way the team started to think about the process of making themselves questions to look for different perspectives and find solutions to do not fall in the “common practice”.

The first question that came to my mind at the end of the book was:

how is it possible that I was not aware about the existence of this book before?

 I need to change the way I find books and explore other sources.

Theory-of-constraints-5-phasesAbility of a director:
  • What do we have to change?
  • To which direction do we have to change?
  • How?

Enterprise Applications on AWS: SAP

I can access to the Amazon Partner Network and some of the interesting stuff you can find there is training and product information.

I did the one related to SAP, and there are some topics very interesting:

  • SAP invites to use the BYOL (Bring your own License) model for creating environments into AWS. You can also use pay per use payment, but is limited. This has been, is and will be the hottest topic in the relationship between the 2 organizations since years.
  • SAP controls the way to implement their systems on AWS with SAP Notes communications and guidance documents through their own channels.
  • They make difference between certified and non-certified implementations. This is a tricky thing for me.
  • The recommended way to migrate to AWS platform is to export/import the database on a new installation.
  • Before to implement it, they recommend to read a bunch of SAP Notes.
  • They recommend your own SAP installation better than the pre-build solutions you can find in the AWS marketplace.
  • For calculate the right size of your environment, they recommend to do it with SAP Quick Sizer tool. This is an interesting topic that I’m willing to know: how is the real performance?
  • For the implementation you can use AWS instances: Standard instances, EBS-optimized instances or cluster compute instances. For sure the last one is the best one, but if you are supposed to move to AWS to save money, you really want to take the right one without losing performance.

SAP-on-AWS

MSP, Benefits management

Programs are primary driven to deliver benefits, this is done by projects that create outputs, which builds capabilities, which transition into outcomes that serve the purpose of realizing benefits.

Benefits-Realization-GovernanceI created this template based on the principles mentioned on the Managing successful Programs, so I can use for guidance during the execution of the programs:  MSP-Benefits-realization.

To take into account that the communication plan of the program contains a lot of the aspects related to benefits.

MSP-Training-benefits-management

“bi-modal” model constraints

Gartner is advertising “bi-modal”; a “new” way to drive operations and new activities of a corporation. I was reading the idea and the concepts around it and I found it “old” idea, with some propositions that are so nice to have, and that they can be defended on the paper, but that in the reality of the companies (where there are real people and real egos) I find difficult to implement.

Gartner-bimodalReview the basis of organizations behavior before to accept the “bi-modal” proposition. On this topic Simon Wardley defines here three attitudes, cultures and type of people: pioneers, settlers and town planners (the main “modes”), which impacts the way the organization mainly behaves.

  • Pioneers develop novel concepts.
  • Settlers → create great products.
  • Town Planners → create highly industrialized commodity and utility services.

3-type-culturesNot all combinations are possible, and that in some cases you have to give up some of the “modes” to do not be in the “middle of everything”:

  • DON’T try and break into Pioneers and Town Planners. These two groups are far apart. You’ll create a them vs us culture. None of the novel concepts will ever be industrialized because the Pioneers won’t develop them enough and the Town Planners will refuse to accept them for being underdeveloped. Both groups feel they are the most important and both ridicules the other.
  • DON’T bury your Settlers into one of these groups. They won’t feel welcome, they will be in conflict with the group becoming second class citizens. Put them in the Pioneer group and they’ll be denigrated to documenting the “glorious” inventions of others and fighting a losing battle over user needs. Stick them with Town Planners and they’ll be seen as ‘lightweights’, the people whose job it is to deal with those annoying Pioneers and document what they’ve done etc.

Then, what is new in bi-modal model?

My notes:

  • IT industry is full of marketing concepts, which need to be evaluated and understood.
  • Ideas are easy to defend on the paper, but it’s different to put in place with people. When talking about organizational transformations and changes, the risk are high.