I’ve yet to meet a project manager who was both effective AND had a “Do not disturb” sign on their door.

I’ve yet to meet a project manager that has not managed the art of effective and succinct written communication.

A lot of us got in to project management, not because we wanted to, but because someone else didn’t want to.

Follow-through denotes effectiveness vs ineffectiveness.

Like throwing a punch, you need to envision your target as being six inches further back than it really is.

That extra distance sets your mind to know that the fist has to punch through to get at the desired target.

It’s pretty simple, if you don’t (can’t) follow-through on something, you’re going to be ineffective at whatever you attempt.

Part of your job, as a project manager, is to take care of your team.

Sure, the stakeholders are important, but without proper care and tending of your team, you don’t have a project.

Project management is difficult for individual contributors when it comes to delegating tasks to others that the project manager is good at.

Part of growing in to the role of project management is understanding that you would do it one particular way, but that you have delegated because you cannot do it your way.

Project management should never be viewed as a cost centre.

Or overhead.

Or a necessary evil.

Did you ever meet a project manager that wasn’t trustworthy?

What you met was an ineffective project manager who held neither the trust of their stakeholders nor their team.

No single system or process exists for creating accurate estimates on a technical project.

Never have.

Never will.

If you look in the metaphorical toolbox of any seasoned project managed worth their job title you would find a variety of methods that will let them zero in on an as accurate an estimate as can be established for that series of tasks, given the data at hand.

There’s no shortage of people selling silver bullets either from the latest fad method to software costing a significant portion (per year) of a decent project manager’s salary.

There are four keys to bear in mind when estimating on a technical project.

The first is to not rely on a single system of estimation.

The second is understand there are no silver bullets for estimation.

The third is to re-estimate as the data and metrics change and new information comes to light.

And the fourth is to apply the proper estimation method for the current phase of the project.

That latter point is the hardest to teach and the hardest to learn unfortunately from top-down (and also bottom-up) estimation to phased estimation to simulation estimation and parametrics.

Bad project managers that I’ve worked with have taught me more about project management than even the best project managers.

We often have to practice our art for years to make the same kind of gaffs and goofs that a single bad project manager can make in a month.

If we are patient, and pay attention to what they are doing, we get to a ringside seat to their mistakes and valuable lessons in to precisely what not to do.

Individual contributors that move in to project management are usually “accidental project managers” through necessity than through desire or deliberate training.

Unfortunately, accidental project managers are usually there because they are highly effective individual contributors, and the mistaken belief of other people, usually management with no experience in project management, is that an untrained engineer or untrained artist will be able to fill a needs gap.

Good project management is never a cost centre.

Bottom-up estimation is probably the hardest and most intensive estimation any technical project manager will ever undertake.

And unfortunately it is invariably and frequently wrong the moment the estimate is handed over to the stakeholders.

You have to spend an inordinate amount of time going over every task and every detail with rarely all of the tasks specced out well enough to estimate them, the people who will do the work unavailable or not even hired, and valuable budget being burned on a phase of the project that management will rarely see much value in.

And yet, bottom-up is still the best we’ve got to get anywhere close to what we need in terms of estimation.

Where it all goes really wrong is at the point when we cling to our rapidly becoming wrong project estimate because we spent so long making the estimate in the first place.

Thank you for calling that two-hour all hands meeting that imparted no more information than we already had and involved only one person talking.

That entire meeting could have easily been summarized in a two paragraph email.

“Here’s where we are at.” and “Here’s where we are going.”

I have never met a courageous project manager I didn’t respect.

Courageous project managers know that tasks need to be cut.

Courageous project managers push back against stakeholders demanding too much.

Courageous project managers, before they start pouring, realise you cannot get a quart in to a pint pot (1 liter in to a deciliter jug).

It takes a huge amount of courage to say “No.”

Far more courage actually than it takes to say “Yes.”

Good project managers are full of optimism.

Great project managers make their teams full of optimism.

Beyond a project of two people, i.e. three or more people, I have learnt that assigning significant portions of a project to myself is a recipe for instant disaster.

I only get paid for one job and I see no reason to give myself two.

If you ask any one of your team what it is you do they will almost invariably tell you “project management.”

And then, in so many words, describe what you do on a daily basis in terms of the tasks you undertake, the processes you go through, and maybe some snide comments about “buggered if I know. Answer emails? Right?”

If you want to really get your team to understand what it is you do, tell them you’re in “risk management.”

Because after all, what is project management but the clever managing of risks, some known, many unknown.

Good project management is like insurance against catastrophe.

There’s a few reasons that estimates go wrong.

When we have the wrong people making the estimates.

No good trying to have someone who doesn’t do software development state how long it will take to do something.

Better still, it’s preferable to have the person who will perform the work making the work estimate.

When we have the right people giving us answers we want to hear.

Guilty as charged.

We’ve all done this.

We hedge our bets.

We say things we hope will make the other person happy.

And finally (though not the final reason), our estimates are based not on faulty assumptions but on the best data we have available at this time.

Simple things require little time to manage.

Simplified processes are easy to execute.

Simple reporting structures are easy to manage.

Simple communications methods make it easy to engage with. Simple requirements make it easy to share them, develop them and test them.

Desiring simplicity in a project isn’t a failure on your part.

Making your project management process simple enough that you can explain it to a non-project manager, e.g. your boss, is highly commendable because it means you understand it and other more importantly, other people can understand it too.

Complex hierarchies, complex reporting structures, complex project tracking processes, complex derived metrics make it difficult to hand off management to others.

Complexity in a project management process makes it difficult for you to step back and not drive.

But above all it makes it difficult for your best autonomous actors to fully commit if they don’t know what the next set of dance steps are going to be because nothing is simple.