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.

The start of a project

It would be pretty obvious to most working project managers: a project starts with a business need; or a 'mission' if you like that kinda language.

The impluse of some is to rush to a scheduling package and start making up dates for actions that they think will progress the project to an end result.

Not so fast: a lot hangs of the mission that needs to be developed before one can understand the components of the project to achieve the mission and deliver a business benefit.

The most important item that develops from the mission is the description of the technical performance required (what will the project's deliverable do) and the criteria by which one would know that the required performance has been achieved. Only then can one develop the project components, create a work breakdown structure, analyse that into activities and produce a schedule.

But there's something prior to these details.

For a project manager to deliver a project he needs to establish the capabilities needed to create the deliverables. This goes hand in hand with developing the WBS and possibly comes before the budget. Development of the budget comes from an interplay between capability, technical performance it can produce, schedule and business benefits. The PM has to have a bright eye to trade-offs and how value can be created and delivered by the project.

The Sensible 12: No. 9

9. Project processes must be effective and efficient.
There are two types of processes: those that add value and facilitate repeatability and reliability of a series of tasks, and those that only get in the way and waste time. Projects that are successful must embrace and continually improve those processes that add value, and get rid of those that waste time.

Its right, but I just find the phrase 'add value' to be cliched. I was once asked to give a referral for a contractor I'd used and the prospective project manager asked me if the contractor had done what was required. They had. Then I was asked if the 'added value'. The implication was that they'd done something extra for free. So I had to explain the economics of production to the dill on the phone: yes they added value because they did as they were contracted for their $100k fee. That's the value they added! There's no magic in commerce.

ASAP

A favourite abbreviation in the business world is ASAP: as soon as possible.

I hope that this doesn't become a favourite in the world of projects that I am familiar with as its a recipe for disaster.

If you think you've got schedule risk now, then it will amplify when everyone starts talking the unparametrised language of "ASAP".

For me 'as soon as possible' means 'when it fits into your schedule'! Not what the sage head that sets the empty target is thinking, I'm sure.

If you have a delivery date, give it. Set a deadline, and I can work out the resource and production implications of your request; absent those, the request has no temporal parameter, and I'll do it as soon is it is MY possible; not yours! And that does not equate to 'quickly', 'urgently' or lets play the 'we're the fire brigade now' game.

The Sensible 12: No. 8

8. Communication both internal and external to the project must be clear and frequent.
Almost every aspect of project management is facilitated by the written and spoken word. It is critical that team members communicate often with each other as they work to fulfill the vision of the project. The project manager must communicate progress that the team is making toward their deliverables as well as surfacing issues and risks that arise along the way. It is important that all communication inside and out of the project clearly conveys the appropriate message to the intended audience.

Information is the lifeblood of project success. Much of the discourse on projects is about delivery or schedule; doing things. This is right as far as it goes, but the right things must be done rightly. People need information to do this and need to provide information while they are doing it.

Everyone on the project team must feel free to get any project information they need, and contribute to the project as they see is necessary. That is, no conversations (about the project or its performance) are prohibited. Once freedom of project information and communication is reduced, the  project manager is cut off from knowledge and there's nothing that stands in the way of failure.