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.

The Sensible 12: No. 7

7. The project manager must serve the team.
The project will be successful only if the team succeeds. The project team consists of individuals who are blessed with their own strengths and skills. It is important to get these individuals to work together as a team to deliver the service or product which will ultimately provide value to the customer. Team production increases as the project manager serves their team members by doing things like removing road blocks, facilitating resolution of issues, and in general supporting their every need.

Again, no. The project manager serves the project sponsor, his/her investors and their customers. To do this he or she does all the above, but let's not forget that individuals join a project team voluntarily (that is, they are not conscripted and can walk out the door at any time) and expect the project manager to perform his or her role while they perform theirs.

The Sensible 12: No. 6

6. The project manager must provide leadership for the team.
The project manager must provide leadership to the project team helping them evolve into a cohesive unit with a clear understand of the project vision. When successful, the team will be able to deliver greater value to the customer than what would be achieved by a leaderless group of individuals.

No. The project manager must manage the project. He or she will facilitate, provide resources, identify the work load, manage stakeholders, report, recommend action, provide information, or catalyse others to obtain information, and above all, will use thier position to move the project along.
Mature professional adults do not need 'leadership' as some exercise of moral superiority, they need coordination, common understanding of roles and responsibilities, and a focus for information and advice. If they are not performing, a conversation is required to identify the concern and resolve it.
Sheep and dogs have leaders, adults in a cooperative social endeavour (work) do not.

Project Management is an Information Game

Nice to see this reflected in one of Glen Alleman's recent blogs: The Value of Information.

In a way, its a commonplace: all we have in any intellectual or social endeavour is 'information'. That's not a special observation. However, what is special is how rarely this translates into common understandings of project management or how the related estimates of risk, cost, delivery performance are made.

A lot of discussion seems to refract PM as a time and/or cost (usually 'time' if the way PM is coupled with scheduling computer packages) game. Well, these are clearly part of it in the real world where both are limited, or constrained, but the project grows and lives (and succeeds) on the good management of information.

The Sensible 12: No. 5

5. A team that takes ownership in the project will deliver successfully. When a team takes ownership in the project with the enthusiasm to deliver increased value to the customer, that project will be successful. It takes soft skills and leadership by the project manager to foster a unified team, but when successful, great things happen. A team is most effective when they understand the project vision and can gain a passion for the solution and take ownership in delivering that solution.

All fluff. A team doesn't 'take ownership' unless they are investors; pretend 'ownership' is a bit of pop-management rhetoric.
The people who are engaged in delivery have to be committed to their promise to do their job.
The Project Manager has to provide resources, direction, and the organisational setting to facilitate this. We all need to behave honourably, politely and with respect. End of story, or its the end of the story.

Project dimensions

In Karl Wiegers' book "Practical Project Initiation" he includes an approach to developing a view of a project's constraints.

The starting point is to map the 'five project dimensions' on a kiviat diagram (radar chart) showing their degree of flexibility.

Wiegers sees that the 'iron triangle's' three project dimensions are inadequate, and if stated as 'time', 'cost' and 'quality' he's dead right. But he re-engineers these three into five (see the illustration from his book, below): features, quality, cost, schedule, staff. There was a question as to whether 'risk' was a project dimension. Of course, it isn't; it is a characterisation or qualification of any of the legitimate dimensions and doesn't have an independent existence or basis apart from the subject that is at risk.

But is five better than three? Does it help?

My first reaction is that 'quality' is a fake dimension, and 'features' perhaps as well; (although in software development, maybe its meaningful). These two attempt to split out the one parameter that has basic meaning for the project's mission: '[technical] performance'. If I need performance at 'n' for a project, then the only 'quality' I'm interested in is in 'n' being achieved. If there's an acceptable range, then it is the performance range, not a separate thing called quality range. So performance accepted is not just 'n', but anywhere between 'n-m' and 'n+p'.

'Quality' as an add-on extra to production is unhelpful and only serves to create an add-on industry of 'quality' advisors.

The two dimensions of 'schedule' and 'staff' are also related, and I question the split. However, I can see the sense operationally, with the use of the five dimensions is to establish the constraint envelope. If schedule (I think the term 'delivery' is better, it carries a reminder that the project is there to produce things, and not just to formulate an abstract schedule) is highly constrained, then staff flexibility might be nice to know, but possibly irrelevant; on the other hand if staff is a constraint, and delivery is flexible, then so what?

BTW, I'm glad Wiegers uses 'staff', not 'resources'. Staff are people, iron ore is a resource.

So, for me, the constraints to a project, or to a work package in a large project, come from the requirements for delivery, and this is probably related to interfaces with other work packages, the performance requirements and mission the project is to be used for, and the funds available to be invested for an expectation of return (I prefer to talk business, rather than accounting).