Thursday, December 20, 2012

If I had asked people what they wanted...they would have expressed a requirement

Henry Ford is supposed to have said once

“If I had asked people what they wanted, they would have said faster horses”.

It is not really important if he had said this sentence for true, as is not very important the context in which this sentence would have been said.


What really matters is that many project managers, from time to time,  feel like saying that about their stakeholders. Such a statement implies two things

  • A lack of trust in the stakeholders' insight and vision of the project.
  • A lack of trust in the stakeholders' capability to express solid requirements.

This attitude could potentially lead to grave consequences in the long run, like stakeholders disengagement and failure in managing stakeholders' expectations.

The funny thing is that many times it is true.

Stakeholders do have limited insight into the project and yes, sometimes, they are not able to express requirements efficiently.
This lack of clarity is because they look at particular aspects of the project and not to the project as a whole.

In fact, they rely on project managers for activities such as the gathering of requirements, the definition of the scope, integration...

It is a project manager duty to provide the right degree of expertise, insight, and vision on the project. It is a project manager obligation managing stakeholders expectations and distilling requirements from necessities.


As Michelangelo Buonarroti wrote


"Non ha l'ottimo artista alcun concetto 
ch'un marmo solo in sé non circoscriva

col suo soverchio, e solo a quello arriva

la man che ubbidisce all'intelletto."




That is to say that the statue lives inside the marble block; the artist just removes the excess.

The sentence “If I had asked people what they wanted, they would have said faster horses” is an expression of a necessity that hides an implicit requirement.
The requirement is the need for a faster and more reliable transport.

Understand the best way to satisfy this requirement, respectful of the project's constraints, is a part of our job.


Licenza Creative Commons

Wednesday, December 12, 2012

Change and people without choice


Projects are not static entities residing in a never changing environment. 
As a matter of fact, they are more similar to growing organisms that must adapt to a changing habitat to survive and thrive. So we do not have to fear changes.
Changes are right, changes are good, changes work. 
What we really have to be scared about are unnecessary and/or uncontrolled changes. These are real dangers, the agents that could doom your project transforming it from an honeymoon with your stakeholders to a never ending hellish journey. 
So it is mandatory that a sound and effective change management strategy be in place and be followed by project managers and project management team members throughout the project execution. 
An important aspect of change is obviously communication and I would like to focus on communication between the project manager, or the project management team members, and the people who will be passively affected by the change without being able to do anything about it. I am talking about the less important stakeholders of the project, those who can exercise just little influence on constraints or objective, those who haven't much power or simply are not much involved in the project. 
Probably in a perfect world this should not happen but I have witnessed some of this circumstances and I have learned what I think is an important lesson. 

You have to take good care in communicating changes to these stakeholders and never base your communication strategy on the assumption that they will agree with the change or that they will be prone to accept it just because they cannot avoid it. 



So it is important that you start with the right foot here and I think that the right foot to start with is explain WHY a change is necessary, followed by HOW you and your team will take care of the change and finally WHAT is the change. 



I suggest you not to do it the other way round. 
People are more prone to accept and listen your point of view if it is well motivated, moreover in this way you will be able to prove that a change is ineluctable before generating any kind of resistance in your audience. 
In this way you are not commanding your stakeholders but you are sharing your project insight with them, you are showing concern for their role in the project and you are managing their expectations. What a project manager should always do.
You are now proposing a solution, not a problem. 

I suggest you to view this presentation by Simon Sinek about starting communication with why. I found it extremely interesting and inspiring. It is a video more or less 20 minutes long but I think is worth to be viewed.

Another important wisdom is to show data that explain accurately the WHAT part of your communication. 


It is not enough to talk with people, you also have to sustain your point of view with facts and prove that everything is under control. People are usually more afraid of the unknown than they are of changes, I have found.






Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Tuesday, December 4, 2012

Meetings - crumbs to achieve (hopefully) better results

In many ways, a meeting is not different from a project. Both are unique and temporary events with stakeholders, scope, schedule...and both are subject to scope creep and gold plating. 
It is a well known truth that a great part of meetings are not so effective as they could and so fruitful as they should. There are many reasons for that.
In this post I will give some tips and summarize some best practices that I have learned on the field, suggestions that I had been given from far more experienced project managers than I am, advices that I have read about on books and so on.
Most are just common sense but I nonetheless hope that this post could help.
I know that there is no silver bullet for the perfect meeting and that this list is way far to be complete. I think that it could be nice if this post will start a discussion about best practices to achieve fruitful meetings. If you have some other tips, please share it and leave a comment. 
Eventually, If there will be a conspicuous number of comments, I could open an appendix to this post and obviously giving you credit for your help.





Why do you need this meeting ?
Ask yourself why this meeting should be called. If you cannot focalize on its purpose or if you find difficult to answer this question, probably there is no real need for this meeting at all.
Do not call meetings to discuss other meetings or to set a line for other meetings or to decide who will take part to another meeting,...
Likewise do not call meetings to inform people. Use reports instead.
An information sharing part is welcome and necessary but do not exaggerate with the extension and the quantity of information to convey. Meetings shouldn't be used to inform people, should be used to decide actions by well informed people.
Also avoid confusion between information sharing and decision making part. If you do not succeed I will swore to you that at the end of your meeting no one would have understood what is needed to be done and which actions have to be taken.
Finally do not use meetings to face day to day management issues or ongoing work. There are better communication channels for that.






Call the meeting
Send an invitation to all partecipants a week or so before the scheduled date. 
In the invitation clearly states
  • Meeting location
  • Meeting starting time
  • Meeting duration 
  • Meeting purpose 
  • Meeting agenda
  • Attending people and a brief description of their expected contributions
It is important that everyone knows in advance where the meeting would be kept, at what time and how long it will last, so that they can adjust their weekly schedule. 
Possibly keep the meeting short.
It is important that everyone understands the meeting purpose and knows the meeting agenda, so that they can document on the meeting's topics and prepare their contributions. 
Besides no one is eager to attend a meeting whose meaning is unaware of and ignore why other people are supposed to attend.
Remember also to give a memo to each attendees the day before or early the same morning.





Invite all the right people and just the right people
Always ask yourself "why should I need this guy to take part in this meeting ?".
There should be two kinds of people at meeting: contributors and decision makers. If one doesn't belong to one if this 2 categories, his presence at the meeting is probably useless.
There is no point in summon twenty people in a room if they have no direct interest in the meeting purpose. A lot of people generates confusion if not interested in the debate and will slow down the meeting schedule with useless intervention if interested. 
Don't have fear to upset someone not inviting him at a meeting. This could happen but it shouldn't be your concern. A meeting invitation is not a judgment nor a kind of social promotion or a benefit, it is the explicitation of a particular need at a given time for a given project.




Ask for a partecipation confirm
You have to know who will attend the meeting and who won't. There is no point in taking a meeting without the decision makers presence. The only result you will obtain will be to replicate the meeting some day later.





Set the room
Be sure to set the location at its best.
Number of seats, boards, printouts... take care of every organizational aspect.




Stick to the meeting agenda and schedule
Do not accept other topics except those included in the agenda. Keep everyone focused on it. If some topic worthy of discussion is raised but not in line with what is planned to be discussed, keep it for another meeting. If someone introduces an argument that is  planned to be discussed later on, politely but firmly ask him or her to hold is thought and assure him or her that this aspect will be discussed later.
Likewise do not exceed the planned meeting duration. Never. People tend to get nervous when asked more time than what that they have agreed to, because they feel as their time is not of any importance to you. So plan to discuss topics in order of importance. At worst least importance matters will find room in the next meeting. Remember also to leave some minute to recap and finalize the minutes.





Take minutes
Always collect meeting minutes and take notes of actions to be taken next, with resources and schedule informations. 
If you find difficult to find important concept that are worth of being collected or you can't list any action to be taken...well this is a sign that the meeting has been totally ineffective and probably useless.
Send the minutes to everyone that has attended the meeting and/or store them in a central repository where everyone who is interested in their content can access them.




Keep the audience focused
Pay attention to signals that reveal lack of attention or poor interest from the attendees, like playing with smartphones, messaging, side conversations, arriving late...
In this case politely but firmly and assertively recall the attention of everyone. It may be a good idea to ask people to turn off their devices. If the meeting last less than half an hour, there is no need in continuously checking e-mail with smartphones.
If someone shows up unprepared to the meeting politely point out to all the audience that you will expect in future a greater degree of involvment, without address the sinlge person. If this happen often...well... this is a leadership and human resource problem. Take care of it.



Lead the meeting
Reserve yourself the right to give or deny the floor, regardless of who the speakers is.
Do not let people talk too much, ask all the speakers to be brief, clear and concise in their contributes.
Refrain people from pointing out obvious things just to appear in the minutes, from use long and wordy introduction there is clearly no need of and from restate exactly what has just been said from other attendees just to add that they agree.















Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Tuesday, November 27, 2012

Project management resources from Tasmania


Tasmania is an archipelago comprising more than 300 islands situated about 250 Km south of the Australian continent, from which is separated by the Bass Strait. The main island is named Tasmania after Dutch explorer Abel Tasman, who reported its existence on 1642. 
It is a sovereign state and counts nowadays more or less half a million inhabitants.



These are all well known facts but there is something peculiar that maybe not everyone knows.
Tasmanian government on its own created a project management framework named Tasmanian Government Project Management Framework, comprised of the Tasmanian Government Project Management Guidelines and many supporting resources. I have come to know this attending an amazing presentation given by Sean Whitaker at the last Project Management Institute Global Congress in Vancouver.
This framework has been realized to be a guideline for every Tasmanian government agency and it is freely consultable from here, the official Tasmanian government web site.

Resources that can be found are
  • Mailing list. It was meant to be a way for sharing project management ideas between Tasmanian government employees. However to facilitate collaborations between public and private sectors subscription is not subjected to any restriction.
  • Framework documentation and generic project management tips.
  • Templates for generic project management activities related documents. 
  • Checklists to assess project characteristics or the degree best practices are being implemented.

All materials is organized in sections

Getting started in project management
This section provides informations and resources on basic project management topics, to help everyone get started in basic project management activities.

Project life
This section provides informations and resources to help managing projects, organized in a kind of project life cycle. We can find here tutorials and templates to organize the project, create Gantt charts, create WBS, report the project status,...

Project management guidelines
This section describes how to manage a project following the Tasmanian government framework, identifing and explaining all the included key processes. This document is realeased under the creativecommons Attribution 3.0 Australia license.

Supporting resources
This section contains resources to help project managers to set up and manage projects like fact sheets, templates toolkits...

Project Management advisory committee
This section contains the meaning and the pourpose of the tasmanian government project management advisort committee (PMAC for short).

Further information
This section mainly contains examples and presentations.

As I said all the material is freely consultable from the internet and I have proposed it in this post as a source of information and for self-learning pourpose. If anyone is interested in downloading part of the material here presented and using it to manage his/her own project, I recommend to ask for permission following one of the many information links provided by the Tasmanian government on its official web site.

These resources could be very useful for someone who is taking his/her first steps in the project management world, as it essentially covers basic project management principles and activities.
Nonetheless I think that even an experienced project manager could get some benefit. 
Who knows where the next good idea or tip will come from ?



Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Monday, November 19, 2012

Risk qualitative analysis. How much complicated ?


When it comes the time for risk qualitative analiysis, project manager and his team are required to express qualitative estimations of some risk attributes, tipically probability and impact, by means of subjective values or judgment.
These estimations are mainly based on project insight achieved by team members until that moment and some kind of a priori knowledge about the nature of the risks themselves.
Obviously the more these informations are reliable, the more this subjective qualitative analysis is trustworthy.


In the next of this post I will give some little tips that I think could ease this process.



Keep it simple

The objective is to have a simple and effective way to establish which risks worth a more specific quantitative analysis and which must be simply checked from time to time, rendering this information in a way that almost everyone can understand in a glimpse of an eye. 
So use simple indicators as numbers, letters or definitions. Don't use long wordy descriptions. These can find more suitable space in the risk description documents.

Figure 1. Simple is better...and understandable even after months.



Few Attributes

Two attributes are best. 
People normally find easy taking decisions based on two variables charts, conversely can be dismayed coping with multi-dimensional space. 
In figure 2 are represented a 2D scatterogram on the left  and a 4D scatterogram (colors are the fourth dimension) on the right. As we can see the scatterogram on the right is plenty of information but it is very difficult to understand. Conversely it is straightforward taking decisions based on the 2D graph.
I have seen indicator systems so complex and so difficult to read, that even the team who created them loosed the grip on their meaning after less than one month.
Probability and Impact are everything you need to know in this stage. 

Figure 2. On the left a 2D scatterogram. On the right a 4D scatterogram. The 4D graph is far richer of informations but it is difficult to understand.



Linearly spaced values
Logarithmic scales, Modified Fibonacci series, Repfigit numbers...well...are we still talking about project management or did we switch to astrophysics ? 
Methods mentioned above are surely useful in many ways but are also very difficult to familiarize with.
I think that for simple qualitative analysis nothing can be better than a plain old linear sequence.

Figure 3. Everyone can easily manage linearly spaced values.


Even integer numbers
Use even integer numbers every time you can. 
Decimal number are a useless complication. 1 to 10 in 0.1 step have the same meaning than 1 to 100 with step 1.
If you use odd numbers the mean is among possible values and this tend to polarize the estimation, you will end up using 3 more than the dued if you values are between 1 and 5. Guaranteed.
Take a look at Figure 4. 
I guess your attention has been dragged immediately to the middle, right ?
Now take a look at figure 5.
See how different is your perception ?
Using integer numbers you are every time compelled to make a choice. Under the mean or above the mean. No neutrality.

Figure 4. What are you looking at ? The one in the middle ? 
Figure 5. And now ? What are you looking at ? 


Few values
What is the point in having a scale that goes from 1 to 10 if people use 90% of the time values between 4 and 8 ? Too much values can be confusing. 
It is sometimes difficult to perceive and assess effectively an attribute value on a long scale based on subjective considerations only. Especially if the team is not accustomed to it or not extremely experienced.
In figure 6 we can see a 10 values bar chart on the left and a 4 values bar chart on the right. What is the difference between 7 and 8 or 8 and 9 ? Are you sure you can state it just basing your judgment on subjective data only ? Which graph is more intelligible ?
Two values are too little, four are best, six are even better if the team is experienced, eight are definitely too much. 
The only exception is if you intend to use values assigned to risk attributes during qualitative analysis to infer a suitable probability density function to be used in quantitative analysis, as I stated in my 12 November 2012 post A structured approach to qualitative risk analysis.
In this case you do need to use many values in your evaluation scale.

Figure 6. On the left a 10 values bar chart. On the right a 4 values bar chart. Which one is more intelligible ? What is the real difference between 7 and 8 and 9 ?


Standardize the values
2 is a number. It doesn't have a meaning by itself. You have to provide that meaning.
For example :
  1. Risk impact less than 200000 USD
  2. Risk impact between 200000 USD and 400000 USD
  3. Risk impact between 400000 USD and 600000 USD
  4. Risk impact above 600000 USD
Best is when the standardization is at a corporation level, so that every project manager and team member could immediately understand what is at stake.


Judgment or numbers ?
Sometimes number can intimidate people that could feel more at ease using judgment as Very low, Low, High, Very high. 
Still it is necessary  a standardization at a corporation level.


...In the end 
My point is that using a sequence like 1, 2, 3, 4 or 1, 2, 3, 4, 5, 6 should be best for risk qualitative analysis in most projects in most organizations and that you shouldn't consider more than two risk attributes at this stage. Any values you decide to use must be provided with a clear, unmistakable and standardized meaning at corporation level. 



Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Monday, November 12, 2012

A structured approach to qualitative risk analysis

Have you ever undergone the terrible experience of needing a plumber on Christmas day?
If your answer is "yes", you will have learned the hard way that the impact of a random event is a function of time. The same can be said about the probability.

So, when it comes the time for qualitative risk analysis, is rather a simplistic approach, assign constant values for risks' probability and impact, not considering the time dependency that these variables have.

Normally, qualitative risk analysis is a prelude to the quantitative one, in which a thorough risks review is carried out with appropriate statistical tools and methods.

Nevertheless, a structured approach for risks qualitative analysis could be helpful for projects which
  • Are too small to justify both qualitative and quantitative risk analysis.
  • Have so many risks, that performing a complete quantitative analysis could be too much time and resource consuming.

So, my suggestion is that every time a qualitative analysis is performed
  • Assess probability and impact values for all the project risks, for the entire project life cycle. Do not assign constant values that are meaningful just for the here and now. Try to forecast future values and reasses past ones, expressing them as a function of time, using all the information you can get.
  • Collect, analyze, and potentially correct all your previous estimations.

Please, take a look at the next two images.
The qualitative risk analysis of Risk #001 has been performed as a function of time and covers the expected project life cycle.

Figure 1 depicts the qualitative value assigned to the occurrence probability of the risk; figure 2 represents the qualitative value assigned to its impact.
Both values  are provided for the entire project time horizon and depicted as functions of time.

Figure 1: Probability as a function of time.

Figure 2: Impact as a function of time.

As we can see, a quantitative analysis of the current risk could be quite safely avoided until May. 
So, indications to perform quantitative risk analysis on risk #001 in Q2 can be added to the risk management plan. 
During project execution, if new evaluations would contradict the present data, risk #001 could immediately undergo the analysis process.

In figure 3 and figure 4 is shown the qualitative risk analysis temporal evolution for risk #001. 
Every 3 months the qualitative risk analysis results have been questioned in the light of new information, obtained during project execution, and the assessments of probability and impact corrected. 

The probability value has been set to zero for past months since the risk didn't occur.

The risk's impact value on the project has been instead reassessed also for past months. 
The reassessment process is useful for following reviews of the qualitative risk analysis effectiveness.

Figure 3: Probability as a function of time. Qualitative analysis performed each 3 months.

Figure 4: Impact a function of time. Qualitative analysis performed each 3 months.

In figure 5 it can be seen an estimation of the accuracy of the qualitative risk analysis performed on risk #001.
The horizontal lines represent the risk impact mean values of all the evaluations performed during the project life cycle (actual values can be seen in Figure 4) while the vertical lines depict the standard deviation values (mean +/- sigma). 

Figure 5: Impact. Means and standard deviations for each estimation as a function of time. 

The showed graphical representation can be very useful during project closure and lessons learned collection. Figure 5 shows how well (or how bad) we have performed qualitative risk analysis.
The presented approach helps project managers to understand how to refine estimations, and the degree of uncertainty it can be expected for similar projects.

Figure 6 and figure 7 depict the temporal evolution for the qualitative values of probability and impact for risk #001 (actual values can be seen in figure 3 and 4). 

Figure 6: Probability as a function of time for a single month estimation. Month is August. See also Figure 3. 


Figure 7: Impact as a function of time for a single month estimation. Month is September. See also Figure 4. 

It can be seen that for the selected months, the probability assessed value decays with a quadratic law while the impact value changes linearly.
Mathematical models and polynomial fitting techniques can be used to discover hidden patterns in the data, and the velocity of convergence of an estimation to an unbiased value. Results could also be correlated with previously conducted analysis and grouped by risks area.

The proposed approach could be useful in aiding project managers to refine their estimations for future projects, it could display the natural tendency to overestimate or underestimate particular categories of risk in particular moments of the project life cycle, and can be used to debias estimations, conducting to more reliable forecasts.

The bottom line is that having qualitative evaluations for each project risk in the form of time function can be helpful for

  • Determine when a particular risk deserves a quantitative analysis, plan the required actions and allocates the required resources well before the task can become critical.
  • Select a proper statistical probability distribution to be used in quantitative analysis and in statistical simulations. For example it could be estimated fitting a model over the curves presented in the first 2 figures.
  • Allocate contingencies in a more effective way.
  • Get debiased estimations and more reliable forecasts.
  • Assess the qualitative risk analysis effectiveness and correctness.
  • Estimate the natural tendency of a particular project manager in overestimating or overestimating particular categories of risk in particular moments of the project life cycle.


Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Tuesday, October 30, 2012

Is life a bad chartered project ?

Once a friend of mine told me "Life is strange. Usually when you have the necessary introspection capability to make a choice, you discover that it is too late. Either you have already taken the wrong decision years ago and the chips are down now, or you have to drastically reduce your expectations and targets. This happens many times and in many ways."
I totally agree.
For example you have to choose which degree apply for when you have little idea of what you would like to do in your life. You become a lawyer and maybe you would have been more happy as a doctor.You will discover it...that's sure...but it will be too late.
Maybe one day you wake up and say out of the blue "Here I am...I want absolutely learn how to play jazz guitar...I will play in a band...I will...". But then you realize that you are 40 years old, with a full time job and 2 kids to play with. You still can learn jazz guitar...but you probably will end up playing "Autumn Leaves" or "Blue Bossa" alone in your basement, late at night, without having any clue on how to play a decent solo.
Doesn't this ring you any bell? Isn't this the same situation you will find yourself stuck into when you are managing a badly chartered project? Isn't this what you get when you realize to have put too little an effort in writing a project charter, either because you couldn't or because just you wouldn't ?



In a badly chartered project you will come at a point where the product you deliver is not what it should have been, when there is no more way to satisfy requirements or hit objectives. You can be sure of this.
Or, if you are lucky enough, you will come at a point where you have to dramatically review objectives and savagely cut scope, time, costs, quality...or all of them.



The result doesn't change...a failure.
Maybe you will succeed in make the sponsors and the clients buy in your deliverables...but they won't be properly satisfied and at the bottom of your heart you will feel that you have failed in some way.
So when you are taking up a project be careful to understand what is in the charter and what it is not and that both things be understood by the sponsor and key stakeholders.
This is a good rule of thumb even you are helping chartering the project.
So what do we hope to find in a solid project charter?
Well...many things...there is no silver bullet in this game...but if I had to write a list I would recommend at least
  • A detailed project description, including high level objectives and requirements. Sometimes stating what it doesn't belong to the project is as valuable as writing what it is a part of it.
  • Solid and well explained business case. This automatically define your options when it is time for change and/or control. If you know what is at stake you can choose which project constraints optimize at expenses of others. Moreover if the business case expires it is right that the project dies.
  • Most important constraints (time, budget, quality, ...). Also these informations help you in revising your options when it comes the time to change. 
  • How project objectives contribute to company objectives. This shows the value of your project as perceived by your company and the strength and the effort you will be allowed to profuse in your quest for success.
  • High level project risks. 
  • High level stakeholders. If you don't know by now who will be most influenced by the outcomes of your project or can influence the results in a massive way you will be rushing headlong toward disaster.
  • High level deliverables. If you don't know what you will be asked to deliver how would you possibly deliver it ?
  • Project manager authority. What are you in charge of ? You must know what you are entitled to do, which actions, countermeasures and decisions you can take and which you cannot take.
  • Time horizon of the project. 
If you cannot states all these informations at least at a very high level...well...it probably means that you don't have the necessary insight  into the project to charter it in an effective way.
If you can't describe it you can't project it and if you can't project it...it simply means that you can't do it.
So take your time and try to analyze every aspect of your project before finalizing the project charter, because it is the foundations over which your project will be build and because once released, you and your team will be committed to it. 




Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Friday, October 26, 2012

Crumbs from Vancouver - 04

Here we are.


PMI® Global Congress 2012 - North America in Vancouver is ended.
What will remain with me of this terrific experience?
Well...a brand new insight in Project Management and new ways and methods to analyze old questions, to find functional answers to new and well known problems.
New questions? Yeah, why not! As your insight grows your curiosity spreads and you question what you know in more depth.
Links with valuable project managers from around the world, tons of material to study, books to read...
Well, all that project management is fascinating for.
Now the long journey home toward my beloved ones...I miss them much even if I consider a real privilege to have been here for a so long and engaging time.


Monday, October 22, 2012

Crumbs from Vancouver - 03

Today has been remarkable here at the PMI® Global Congress 2012 - North America in Vancouver.



Not just for the sessions, that are becoming every day more engaging but also because today, finally, the Vancouver sky has stopped pouring rain over us, poor project managers.
Today I have been through two truly amazing sessions. One about methods and good practices to write better projects requirements, the other about the never ending struggle of contingency reserves.
Theory is good but what happens when it meets the reality of companies that always want more with less ? That are always struggling to skinny their costs ?
That is where remain focused on good requirements and accurate estimates of contingency come into play and can truly make the difference.
The sessions were both highly interactive and the two speakers able in engaging the audience and in maintaining high the level of energy in the room.
Other two remarkable sessions I attended to were about leadership and the skills a project manager should have to succesfully create valuable teams. The socialization of power against the personalization of power, empathy and emotional intelligence can be a real breakthrough while bad management or negative attitudes can effectively spoil in few days all the good works that has been performed in months.
Other than for the sessions this meeting is truly amazing for the opportunity to meet people from every part of the world and to exchange ideas about project management and practices in a very multicultural environment.
An appointment that a passionate project manager shouldn't miss.

Sunday, October 21, 2012

Crumbs from Vancouver - 02

End of day one at the PMI® Global Congress 2012 - North America.


I participated to the RPWS (Research Program Working Session) focused on the definition, the role and the maturity evaluation of a PMO.
The questions on the table were "How can we define a PMO ?" and "How do we evaluate a PMO maturity level ?".
In this all day long session all participants has been divided in groups and encouraged to respond to these questions by mean of brainstorming and focusing group techniques. Each group then in turn exposed its answers to other participants and responded to questions about the provided answers.
At the end PMI's researchers and staff summarized the discussion focal point and showed statisitcs and case studies about PMO implementations and the relative evolving scenario.
It has been a great experience, highly interactive and engaging.
I met a lot of experienced project managers and I had the opportunity of sharing ideas and opinions with very qualified people from almost every part of the world.
An experience that I recommend to every project management practitioner or passionate.
Stay tuned.

Friday, October 19, 2012

Crumbs from Vancouver - 01

Just landed in Vancouver to attend the PMI® Global Congress 2012 - North America.


Four days to dive into project management matters, processes, tools and techniques.
I was looking forward this meeting since the summer and I hope to gather many new ideas, to collect new advices and gain a greater insight into this fascinating world.
Vancouver seems a very hospitable town and the congress center magnificent.
Too bad that it is raining now and so I cannot take a sightseeing tour as complete as I would have liked through the great Stanley Park. I will spend a couple of hours visiting downtown.
I hope to be able to share impressions on the blog at the and of each day sessions...that is...if I won't be too tired.
Stay tuned.

Tuesday, October 16, 2012

Project management is the art of the possible

"Politics is the art of the possible" is said to have declared Otto Von Bismarck in 1863 to an interviewer from the St. Petersburgische Zeitung.
I am nor an aphorisms fan neither a Bismarck admirer but in its apparent triviality this sentence hide two big truths.
  • A pragmatic and wise politician distinguish between realities and desires, between opportunities and treaths, between possibilities and obligations. He or She has to know the environment in which  he or she operates.
  • Planning and negotiations, if properly conducted under a correct knowledge and interpretation of the previous environmental factors, can always lead to success. Provided objectives are realistic.

In this respect I state that (also) project management is the art of the possible. 
A good project manager should be able tell a viable budget or schedule from what are just hopes. He or She should be able to tell reality from management desires and hopes and eventually reconcile the differences. Obviously he or she should absolutely not commit himself  or herself to what is a beyond belief schedule (or budget, scope, quality plan, ...). I think that in many cases, especially if a project manager has not been involved in the project chartering process, this could be one of the most tricky parts of project management. 
Opportunities and treaths are what we could call risks and they should be treated through appropriate project management techniques. They should be identified, evaluated, documented and periodically revised. Plans should be put in place to address them in case they happens, to mitigate or enhance their impact on the project.
Every wise project manager knows that penetrating and understanding the environment in which the project evolve is a basic step toward a successfull completion. Marketplace conditions, industry standards, competitors, processes, tools, management attitude, Sponsor support, budget constraints, knowledge bases,... are all factors that can help or  hamper the project manager's (and team's) efforts and options. So all this factors, all this possibilities and obligations has to be continuously kept in mind and mastered. 
Under these premises the project manager operates and leads the team, implementing valuable processes and applying techniques suitable for planning, negotiating, monitoring project status and controlling project flow.
Said that, I strongly believe that if there is even a remote possibility to conclude a project on time, on budget and with a certain degree of quality, proper project management combined with an insight into environmental factors and process assets can significantly exploit the possibilities of success.
Obviously no project manager can do magic. Some conditions (good chartering, strong business case, management commitment...) has to be put in place before project start. A good project manager knows how to make use of everything is around him but remember, project management is the art of the possible.




Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.