Got the Yellow Belt on Lean Six Sigma

Got the Yellow Belt certification on Lean Six Sigma.

For those of you who do not know what this is but you are interested, you can find some info here

PMI-SP certification added to my CV

Yesterday, 8th Aug, I took the exam for the PMI-SP (Scheduling Professional) certification issued by PMI and I passed :)

Information of the exam that may be of your interest.

• 170 questions, 3,5 hours.
• There was one question with two answers exactly the same. It makes it easier because on can discard those immediately but it is the first time something like that comes across.
• There were many questions regarding Performance Reporting and some (more than I wanted/expected) were not specifically mentioned in the preparation material.
• I found some (3 or 4) mistakenly phrased questions. One was asking for techniques while all the possible answers were processes and other one was stating "project management plan" when it was actually meaning "project schedule".
• Earn Value Management and Network scheduling questions were not too complicated. Easy calculations, doable only understanding the concepts. Abbreviations BCWS, BCWP and ACWP were key in a couple of questions
• One always finds surprising questions like asking for the "typical" monthly meetings ... well, the only monthly even I have managed in my projects was the payroll / invoicing, everything else was weekly, at least.

About preparation, I took the "Preparation Course PMI-SP Exam", the archived version of it and it was fine. I even recommend the recorded version as it makes easier to follow the course, you can schedule :) breaks and sessions at your own pace. The written material, which includes "Practice Standard for Scheduling" was also sufficient.

The natural next step would be to go ahead with preparations for the PMI-RMP (Risk Management Professional) exam. But it will have to wait as I am focussed on my social media business and Bachbill. Maybe I will try to give some Project Management training.

Mis impresiones sobre la charla en el Master de Empresas Multinacionales

El 25 de Marzo de 2011 tuve la oportunidad de dar una charla para los alumnos del Máster de Empresas Multinacionales  que organiza el Centro Carlos V de la Universidad Autónoma de Madrid ... uufff, tomad aire :)
   Lo cierto es que iba preparado para una sesión, más en la línea de lo que se entiende por "ponencia", en tono formal, casi académico. Pues bien, el tono fue muy relajado, desde el principio, cuando Fernando Úbeda - Dirección del Centro de Formación Continua de la UAM y buen amigo mío - me presentó como una persona "rara" por vivir en Alemania y por estar al tanto de los últimos avances en las áreas de internet y tecnología en general. Por supuesto, lo tomé como un piropo, como lo que era.


   Tenía preparado material sobre cómo las diferencias culturales pueden afectar a la gestión de proyectos internacionales y cómo uno debe aprender a detectarlas, asimilarlas y evitar que afecten al proyecto en sí. Tuve la suerte de que todos los alumnos ya están viviendo la experiencia internacional, ya que ninguno era de nacionalidad española, con lo que lo que podía haber sido una ponencia, se transformó en una auténtica y enriquecedora charla de intercambio de experiencias. Las mías como español trabajando con personas de otros países europeos y ellos, como iberoamericanos que estudian y trabajan en España. Lo dicho, muy entretenido y enriquecedor.


   Luego pasamos a la parte de Social Media que comenzó con un repaso a las redes sociales más conocidas (Facebook, Twitter, Linkedin, Blogs ...), algunos comentarios sobre Google y luego seguir con una descripción de lo que es Marketing Online y su aplicación práctica.
Ahí tengo que decir que los alumnos del Máster tienen cierto margen de mejora, por ejemplo sólo un par de ellos (de unos 25) tenían blog, no todos tienen su perfil profesional en Linkedin y su uso de twitter es muy marginal. Animo chicos, seguro que lo encontráis útil, sobre todo si os enfocáis en entorno internacional.


Las referencias que utilicé son las siguientes:
-- "Making cultural intelligence one of your signature skills" de Bill Richardson. Desafortunadamente no puedo compartir el contenido con vosotros, ya que es un artículo de pago y no tengo derecho a la distribución. De cualquier modo, buscando "cultural intelligence" y "cultural differences" seguro que encontráis buen material sobre este tema.


-- Las estadísticas sobre idiomas en Europa las saqué de Eurostat, en concreto de este informe "Europeans and their languages"


Os dejo aquí los enlaces a las presentaciones


Gestión de Proyectos Internacionales: http://www.slideshare.net/mblaya/uam-25-032011
y Social Media: http://www.slideshare.net/mblaya/social-media-25-032011


Lo dicho, fue un placer que no me importaría que se repitiese.

Gestión de Proyectos Internacionales

Ya tengo casi terminada la presentación de Gestión de Proyectos Internacionales y éste es el índice:

• Indice de Gestión de proyectos internacionales:
• Internacionalización
• Diferencias culturales
• Diferencias Idiomáticas
• Equipos virtuales

Utilizaré este presentación por primera vez en una ponencia para el Master de Empresas Multinacionales de la Universidad Autónoma de Madrid el 25 de Marzo.

Y aquí podéis ver el índice en formato transparencia.

Indice gestión proyectos internacionales 1 1

View more presentations from Mariano Blaya.

Ponencia para la U. Autonoma de Madrid / Lecture for www.uam.es

Estoy preparando una ponencia para el Master en Dirección de Empresas Multinacionales que imparte de la Universidad Autónoma de Madrid con el siguiente contenido:
- Gestión de proyectos internacionales
- Social media marketing

Ya os iré contanto.

--------------------------------

I am preparing a lecture to be given as part of Master on International Business Management organized by Universidad Autonoma de Madrid.
Contents:
- International project management
- Social media marketing

I will keep you posted over here.

Improving Project Management in Internet Services organizations

There is a number of opportunities of improving the way projects are managed in (some) Internet Services organizations.
- Scheduling approach
- Risk Management
- Reporting cycles
- Initiation phase
- Organization structure
- Agile software development integration
a work in progress slide deck is shared in the GDoc

PRINCE2

  Prince2 is a process driven and clearly defined project management method which became the de-facto-standard for the UK public sector.
It defines seven processes, each of them consists of a number of activities.
  Processes are: Starting up a project, Initiating a project, Directing a project, Controlling a stage, Managing stage boundaries, Manage product delivery and Closing a project.
  It looks to me very oriented to managing outsourced projects and, to do so, it describes a sound framework to interact to the supplier: control their progress, initiate and close the project.

Notes from http://en.wikipedia.org/wiki/PRINCE2

Extreme Programming

While Scrum is seen more as a Project Management framework, the Extreme Programming (aka XP) is more detailed and rather in the area of a methodology.


Its main goal is to improve software quality and responsiveness to customer requirement changes - which are expected as time passes and the problem is better understood.


In the traditional project management approach, customer requirements are intended to be agreed and frozen when project starts and any further change has to go through a change management process to get impact assessment, formal approval and project re-scoping which might lead to delays, re-engineering efforts and poor stakeholder satisfaction.


XP defines the methodology through a number of activities, values, rules and practices and for the sake of this post's length, I will go only through the Values as the foundation of the whole approach.


Values of XP must be shared and implemented by all team and stakeholders and are as follows:
-- Communication must be continous, preferably verbal, shared across the team and with frequent feedback.
-- Simplicity must drive every design effort in order to implement always the simplest solution that works for today's customer requirements and not for tomorrow's or next week's. We can put it in this way, implement as late as possible and assume the risks which this approach involves.
-- Feedback can come from three sources:
.- from the system when unit tests are run
.- from the the customer when acceptance tests are run
.- and from the team when a new customer requirement is estimated in effort.
-- Courage to design and code only for today's requirements, courage to refactoring when the needs comes, courage to persist on solving a complex problem. Courage is the value that empowers the team to take critical decisions because they are the best positioned to take them.
-- Respect for your own work and for other's work


Taking the above mentioned four values into account for every aspect of the project, provides benefits like flexibility, motivation amongst others.


These notes are based on http://en.wikipedia.org/wiki/Extreme_Programming article and are not intending to amend or correct it

Scrum: agile project management framework

Scrum is one of the agile project management frameworks, focussed on product development and, in particular, becoming relevant in software development, bringing flexibility and speed to the process.


--- The framework describes three roles with direct involvement, also called Pigs: Product Owner, Facilitator and Team.
:- The Product Owner is the link between the team and the business/customer. He/she sets priorities and writes requirements.
:- The Facilitator or ScrumMaster removes impediments that hinder team to deliver goals.
:- The Team develops and delivers the Product.
There is also Stakeholders, who justify the production, and Managers, who set up the environment. Both roles are known as Chickens.
It looks easy, doesn't it? And also it makes perfect sense.


--- Regarding the process, Scrum defines the meetings that should take place.
:- Daily Scrum meeting is held every day at the same time and same place, starts precisely on time and is timeboxed to 15 minutes. During the meeting, every team member covers three topics: progress since last meeting, job to do today and impediments preventing them from meeting their goals.
:- Post Scrum meeting is also held every day after the daily scrum, only one person per team attends and goes through issues on overlapping and integration areas. Meeting agenda is almost same as Daily Scrum's.
:- A key meeting of the process is the Sprint Planning Meeting, held at the beginning of the Sprint to define and plan the work to be done during the Sprint (typically a 7 to 30 working days period)
:- At the end of the Sprint, a Sprint Review and Sprint Retrospective Meetings are held to review the work done and raise process improvements.


--- As means of documentation, communication and reporting, three artifacts are used:
:- Product backlog: high level document with the requirements for the entire project and rough effort estimates. It is owned by the Product Owner.
:- Sprint backlog: gathers detailed information on the next Sprint, consisting of four to sixteen work hours effort tasks. It is owned by the Team.
:- Burn down: shows the remaining work of the current Sprint.


These notes are based on http://en.wikipedia.org/wiki/Scrum_(development) article and are not intending to amend or correct it.

Definition of Manager according to Scrum

Manager: People who will set up the environment for the product development organizations.


From http://en.wikipedia.org/wiki/Scrum_(development)#.E2.80.9CChicken.E2.80.9D_roles

¿Por qué se necesita formación específica en Gestión de Proyectos?

• La Gestion de Proyectos es una disciplina que en ocasiones se deja de lado en las titulaciones universitarias por considerar que, únicamente aplicando el sentido común, será suficiente.
• La formación se debe centrar en marcos de trabajo o frameworks que permitan definir los conceptos básicos.

• Unicamente aplicando el sentido común, distintos Jefes de Proyecto, entenderán de forma distinta un mismo concepto

[seguir leyendo en la presentación de GDocs]

Perform quantitative risk analysis

As it is described in a previous post, when risk management is applied to the whole project plan in a quantitative manner, phase duration becomes a statistical distribution rather than a deterministic figure. It also allows having an overall impact estimation for individual risk or for the combined occurrence of more than one risk.

This approach makes the project plan more realistic but also more complex and difficult to report and understand. Which of the two approaches should we use? Well, again, it depends on the specific project.

Some of the results of such analysis might be: probability of finishing the project on time and / or within budget and contingency reserve estimated to ensure the required level of confidence
One of the most known tools for this process is the Monte Carlo simulation and decision tree analysis.


Notes taken during my study of "Practice standard for Project Risk Management" from PMI

Perform qualitative risk analysis

The purpose of this process is to assess identified project risks in order to prioritize them. Such assessment consists of evaluating the probability that each risk will occur and the impact of each individual risk on the project objectives. Other factors can be: urgency or proximity, (un)manageability and external impact.


As part of this qualitative analysis, the risks must be classified by their root cause as well as by the common effects. Looking at the most important root causes and common effects will help to drive mitigation efforts.
Each risk must be assessed according to probability of occurrence.

This qualitative analysis should be done on periodical basis throughout the project as the information to analyse risks will be more and different as the project moves forward.

The deliverable of this process is a contribution to the risk register document; it adds information like impact, probability and priority to every identified risk. Typically, the high priority risks will be analysed in detail and monitored frequently while the low priority ones will placed in a watched list and reviewed less often.

Notes taken during my study of "Practice standard for Project Risk Management" from PMI

Identify risks

As PMI's Practice Standard for Project Risk Management precisely states, "a risk cannot be managed unless it is first identifed" and that means this must be the first to be executed. This risk identification activity will go on during the whole project and the risk register has to be considered a live document.

The risk identification tries to detect risks as early as possible but, at the same time, it must be implemented as an iterative process which allows the incorporation of additional risks at any point of the project.

A risk can have either a positive or a negative impact in the project, the first is called opportunity while the latter, a threat. Goal of risk management is to maximize the impact and likelihood of opportunities while the threats impact must be mitigated.

To avoid misunderstandings and misinterpretations on the identified risks, it is recommended to assign a risk owner since the time the risk is initially registered.

Notes taken during my study of "Practice standard for Project Risk Management" from PMI

Project risk management processes

Projects take place in real life and, as we all know, uncertainty is the only constant in life.

Project management is a try to control the uncertainty around the project, note that control does not mean avoid risks and uncertainty, which is not possible, the only chance is to understand, assess and manage them through Project Risk Management discipline.

This approach is something (almost) all project managers already apply to their projects, adding buffer to schedule, cost and resources as well as being cautious when reporting to senior management.

The Project Risk Management is an approach to structure to above explained while improving results and making it more predictable.

According to PMI's Practice Standard for Project Risk Management, there are six processes involved:

- Plan risk management
- Identify risks
- Perform qualitative risk analysis
- Perform quantitative risk analysis
- Plan risk responses
- Monitor and control risks
which will be covered in this blog shortly

Notes taken during my study of "Practice standard for Project Risk Management" from PMI

Projectized vs. Functional organization structure

PMBok from PMI defines a projectized organization as any organizational structure in which the project manager has full authority to assign priorities, apply resources, and direct the work of persons assigned to the project. While functional organization is defined as a hierarchical organization where each employee has one clear superior, and staff are grouped by areas of specialization and managed by a person with expertise in that area.

Which of the two should be used depends heavily on the organization's type activity and also will influence importantly the performance and deliverables.
A project oriented business managed by a functional organization structure will be slow, heavy and not flexible.
A functional oriented business managed by a projectized organization structure will be confusing, over managed and unclear.

Matrix organization is the most usual with its three flavours: weak, balanced and strong, depending on where the project coordination takes place.

In principle, there is none better than other but it is critical that the organization structure matches the business activity.

Creating internal project management communities: experiences from government and private sectors.

The experience from the European Commission was very interesting, the management does not fund the project management community although agree and support that some volunteers organize meetings, presentations and conferences to spread and discuss the PM subject.

They arrange the conferences and debates for lunch time and the European Commission project managers, most of them located in Brussels and only a few in Luxembourg, listen to the speaker while eat their sandwich. With such weak support, the community is growing and maintaining their activity, actually, it is really a community as it is always optional for the members to join or not every event. If at some point, there is not enough attendees, the community will be discontinued but, from Robert Maclaren's words it is far from happening as their colleagues are contributing more and more to the community of practice

The second speaker, Michael Söderberg, told us how Siemens in USA has created a community, PM@Siemens with a completely different approach. In this case, as the company is project oriented, being part of the community is not an option for the project managers, they have to. On the other hand, they are geographically distributed and meeting all of them together is almost impossible. They created a website, using sharepoint to share best practices, methodologies, share experiences and so on. They also have periodic video and audio conferences. So far, they are also doing well.


Notes from the PMI Global Congress EMEA Milano - 2010.
Presentation given by Robert Maclaren and Michael Söderberg

PMI Global Congress EMEA - Milano May 2010

I attended the PMI Global Congress EMEA in Milano, 10th, 11th and 12th of May.

Here it is the list of conferences I selected from the program:
- Benefits of Risk Analysis. Speaker: Wesley Gillette. My post on it.
- Creating internal project management communities: experiences from government and private sectors. Speakers: Robert Maclaren, Michael Söderberg. My post on it.
- Managing virtual project teams by using technology. Speaker: Thomas J. Mattus
- Too many cookd spoil the broth, or maybe not ? Speakers: Konstantinous A. Kirytopoulos, Dimitra Voulgaridou
- The PMO as a centre of excellence: virtual community or physical unit ? Speakers: Maria Cristina Barbero, Giuseppina Copetti.
- Project complexity: the stakholders' world. Speakers: Walter Ginevri, Maria Moresco
- Extreme project management in Telco industry. Speakers: Francesco Ludovico, Francesco Petrarca
- Pros and cons of Agile project management methods, from an experienced project manager's viewpoint. Speakers: Mattias Georgson Petren, Bjorn Granvik
- Project modular risk-based closure process. Speaker: Olivier Lazar.

More than 800 people from 57 countries attended the congress and the countries with higher participation were Italy, USA, Germany, Switzerland and France.

I also participated for two days in the Translation Verification of some PMI questionnaires from English to Spanish.

Fuzzy project schedule ... but realistic

Risk Management is one of the main process of the Project Management discipline and consists of a number of activities, Risk Planning, Risk Identification, Risk Analysis, Risk Response and Risk Monitoring amongst others.

In a usual or deterministic schedule, each activity starts and finishes on specifics dates, for instance, design activity starts on 3rd June and finishes 30 of June.

What happens in the real world? The contractors might have monthly contracts and they might be available on 1st June and the design can start earlier than schedule or, the project manager only get resources starting on Mondays so that means the team will start either on 31st May or 7th June. With regards to the design completion, other stuff might happen that makes it to be completed earlier or later than scheduled.

What all that means is that whenever project milestones are set to a specific date it means that the project manager states that date as the most likely to happen and it will happen, in reality, some days before or after that date. Actually, it is more realistic to plan in terms of optimistic, pessimistic and most likely date of every milestone and calculating those in terms of the risks related to each one.

When risk management is applied to project schedule preparation, the usual deterministic schedule becomes fuzzy but more realistic at the same time.

One interesting side effects of this fuzzy project schedule is that the critical path happens to be multiple and depending on which risks finally occurs. The activities to watch are not the ones on the critical path any more but those that are most often in the critical path and that is detected running simulations of the occurrence of the various risks identified.

This post consists of a few takeaways from the presentation of Wesley Gillette at the PMI Global Congress – EMEA in Milano on 10^th May … awesome presenter, by the way.

Vertical, horizontal or mixed organization ?

There is a number of ways to organize a team and, from my point of view, there is none better or worse than the others, it simply depends on the goals, focus and priorities of the team.

What I call a vertical organization consists of a project focussed structure where the team is built up when the project starts and disbanded when the project is closed. There is as many teams as projects and first - and often exclusive - priority is delivering the project on time, cost, scope and quality.
This structure team is especially effective for critical projects and short term efforts but do not necessarily delivers long term and high quality products.

On the other hand, we can organize a team in a horizontal fashion, with specialized resources for specifics domains and not transient teams but stable in the mid term. In this way, deliverables quality increases as same people are doing very similar work for some time so they become experts in their technical and functional domain.
Horizontal organization is the most usual for operations departments and those where the stability weights more than the agility.

Is anyone better than the other? Yes, the balanced one is the best. Depending on the maturity of the company, department, systems, and professionals, depending on the business priorities, timeframe for meeting objectives and which one of the triple constraint (quality, cost and time) weights more, there is balance on vertical and horizontal functions.

There is always room for horizontal functions such as Technical Office, Quality Assurance, Program Office, Operations, Business as Usual projects, Architecture among many others, as well as some others must be driven as vertical functions, such us, first implementation of a new architecture or system, complex projects with many dependencies and so on.

Finding the balance is, as always, the challenge...