ASAP 2

In a previous post on this noxious abbreviation that pollutes business conversations, I decried the imprecision of its use.

I had another encounter with it today. The rational explanation for the fool hardiness didn't work, so I replied:

"OK, my 'possible'. I'll let you know when."

Kind of like the so-called 'reverse brief'; the document you give to a client when they don't know what they want (all quite legitimate in the world of the unknown). My rejoinder drove home the point that in a project where schedule sets the tempo of activity, dates have real meaning, measured in $ of value produced in NPV terms. Muck up my dates unpredictably and that will muck up your project returns unpredictably.

So, as a good PM, I'll let you know the date that is possible while maintaining the project tempo to produce the value you've hired me to produce.

The Sensible 12: No. 11

11. Issues and risks must be addressed quickly and openly.
Every project has risks that are associated with the venture, and every project will have issues that surface along the way. The fact that they occur is not unique, however, how they are addressed is unique to a successful project. It is critical to identify risks at the initiation as well as throughout the project. Immediately upon identification of a risk, develop a plan how you will manage that risk. As issues occur, address them quickly and provide the appropriate visibility to shareholders. Providing
transparency of risks and issues is an important principle of managing a successful project.

This along with communication is the meat of project management. But let's be sensible and approach risk management particularly with an understanding of the probability of risks, from analogous cases, and how to meet the potential cost on a 'diversity' basis. But fundamental is that the project is designed to eliminate as many risks as possible; and that shows up in the schedule!

The Sensible 12: No. 10

10. A change management plan must be in place in preparation for the inevitability of change.
Change is nothing to be afraid of; in fact if it wasn’t for change, there wouldn’t be a need for project management. The key is to have a change management plan in place which describes how a request is submitted to the project and how you will manage that change request. If this plan is documented and understood by all shareholders, change will be managed without disrupting the project.

I don't know what 'in place' adds to the content here. Yes, you must have a change management plan and the sponsor must participate in the development of the plan. He/she must also promptly give (or not) the authorisation of any changes (along with any investment and schedule changes) in cognizance of the benefit/value they will provide to the project.
The plan should include change proposal evaluation criteria to prevent the inclusion in the project of whims that do not go to the mission, but absorb time and resources nonetheless, depleting the project out turn value.