A long time ago…

Project Manager: “We are having difficulty managing our offshore team, would you be willing to help us out and get them back on track?”

Me: “The 15-person offshore team you hired to replace me at a higher cost than what I charge?”

Project Manager: “The very same. We were hoping you could come by the office and give us some advice on how to fix this.”

Me: “I charge $3,000 a day to show up in-person and do that. It will be at least a 15 day continuous engagement with a further five days of follow-up.”

PM: “We could hire someone a lot cheaper than that to fix the problem.”

Me: “You let me know how that works out for you.”

*click*

There are two types of time that you need to recognise.

There is fragmented time.

And there is focused time.

Project managers have fragmented time.

Their world revolves around meetings and dealing with small blocks of time; fifteen minute meeting here, five minute conversation there, and so on.

Software developers, engineers, artists all require focused time.

For them to be productive their schedule requires that they have large blocks of time to set aside to make the things they make.

Team leads often need to straddle those two worlds and it is never an easy job for them.

There is a fine balance between holding too few meetings and too many meetings.

Most of the time I find that it isn’t too few meetings or too many meetings, but too few meetings with the right people involved and too many meetings involving the wrong people.

All project managers need to fragment their time in to minute little packets.

Good project managers do this to their own time.

Bad project managers do this to their team’s time.

I would say any fool can put together a project plan that carefully tracks every detail but remains steadfastly unrealistic and unworkable.

But I believe strongly that it takes real talent to actually pull that off and still remain ignorant that the plan is not feasible.

A long time ago…

Project Manager: “You don’t chime in with advice and solutions when we ask direct questions via email any more. This shows a real lack of communication on your part.”

Me: “You stopped paying me and said my services were no longer required when you off-shored the project at 10% of what I charge, remember?”

Project Manager: “You could still chime in every now and then to make sure our team is on the right track.”

You cannot inherently understand how to manage a project without studying many projects; ones that went right and especially ones that failed.

We get better at managing projects through experience, but studying (really studying, not just reading about) another project, how it was put together, the decisions that were made, the conclusions that were drawn, and finally the ship or did not ship status of the project are all valuable to our understanding.

“In my head” is neither a project plan nor a measurable objective.

A fondness for a singular tool is the downfall of every project manager, marketer, software developer or carpenter you will ever meet.

There are individuals who are constantly seeking the new, shiny bullet with which to slay their project demons.

And then there are other individuals who cling desperately to the one tool they know works for project management.

One of the better techniques I know of for project management is to understand how different project management systems, software and methods work, even if they directly compete with each other.

Then you can make an informed choice when deciding on which technique to use for a particular situation.

But if all you have is a single tool, then everything you see looks like you can use that tool on it.

The worst project meetings I have ever sat through are the ones where nothing is ever written down.

Endless talking.

No notes taken.

If your team, your reports, your managers, and yourself have an aversion to capturing the details of a meeting that can be referred back to then I would suggest you immediately correct that behaviour.

Beware the meeting that has nobody present authorised to make a decision.

The greatest contributor to communications lag in a distributed team is when a question is asked that goes unanswered for days at a time.

As a project manager working with distributed teams, strive to acknowledge you have received the question as quickly as you can, schedule time to answer it as soon as you can — you may need to have a local meeting or undertake research or due diligence — and once you have the information you need, reply to the original question.

The greatest tool you have to reducing communications lag in distributed teams is to never leave a question unanswered at the end of your work day.

Many tasks that you will delegate, especially if you are good at undertaking the tasks to be delegated, will necessarily not be done “the way I would have done it.”

The best strategy I have found is to decide on requirements for the parts that matter “that need to be done the way I want them done” and to let the parts that don’t matter be done however the other contributors decide to do the tasks.

Attempting to make all tasks in a project “matter” Is the project management equivalent of making all tasks in a project all have top priority.

It’s also micro-management.

The best project management methodology I’ve ever encountered is the one we call “common sense.”