Hi, Leonardo.

I liked the article, and said so.

"My only point is the following: the article is meant to be an overview of the importance of taking the proper actions in closing the project (using the proper prince2 process) and not letting it drag on."

And that's what I felt was good.

"(note that prince2 does not recommend which technique to be used),"

And that's one of my issues with many of these "standards" -- the failure to specify a process or a menu of specific processes suited to alternative scenarios. 

"If you have a complex project you will certainly run critical path analysis and evaluate the abcp at the end,. But what if you are running a "1 day project"? Would you do it?"

If it is really a very simple "1 day project", perhaps not. But then it's equally legitimate to ask: would I worry about closeout? Perhaps? Under what circumstances?

And of course, the length of the project should often not be the determining factor --it should be the expected value (i.e., importance) of time on the project (a topic that, alas, neither standards organizations nor PM software packages really address). There may absolutely be "1 day projects", or even shorter, where things like WBS template use, critical path analysis (including critical path drag and drag cost computation, resource bottleneck identificationand resolution, as well as ABCP analysis) would be of utmost value! As an example, I offer an emergency response to a major disaster such as an earthquake. The initial project in the program is to secure the area and set up life-saving and disaster mitigation processes. While that project will, we hope, take only a few hours, how well and how quickly it is performed is of utmost importance. All of the above project management techniques should be used, including ABCP analysis to optimize the process for the next similar disaster.

I recommend this chapter,"Time Is A Murderer" from CRC Press's Emergency Response Handbook for more on applying these techniques on such a project. 

"The reason why prince2 does not recommend which techniques to be used is that these must be chosen based upon the context. An important prince2 principle states that the method must be tailored to fit the project environment and it takes into account just this point"

In many of life's endeavors, and particularly on programs and projects, both the devils AND the gods are in the details. And standards that fail to address those details fail to provide the necessary guidance. As a result, project managers routinely omit techniques like estimates of the value/cost of time (vital, IMHO, on any and all projects!), critical path analysis (valuable on the vast majority), and expected value tracking (valuable on all but the simplest).

The current state of project management is woeful, and people die every day whose lives might have been saved by better-performed projects. Organizations that have long been presenting themselves as arbiters of "good practice" should surely be doing some serious soul-searching about the sad state of their discipline despite their virtual sovereignty. Perhaps being more explicit in mandating a specific agenda of techniques might help.

Fraternally in project management,   

Steve the Bajan

www.TotalProjectControl.com

Good article, Leonardo! Thank you.

The only thing I'd like to see added in any discussion of project closure and lessons learned is the explicit callout of as-built critical path (ABCP) analysis, with specific items (scope changes, rework, resource insufficiencies or increases, etc.) highlighted in the process of going from the planned critical path to the as-built critical path. (I know it's suggested in the article -- I'd just like to see it in bold, underlined and italicized!)

Fraternally inproject management,

Steve the Bajan