I have always found it difficult to take seriously “stakeholders” that don’t have the power to green light the project but insist on being the red light that prevents a project from starting.

I am a firm believer that large projects should often be smaller multi-part projects.

Nobody sat down one day and said “You know, we should build an enormous metropolis called Rome. Let’s set a budget, a time frame and figure out what resources we will need.”

P.S. this rule doesn’t apply if you work in city planning.

Anytime a project outcome is not objectively measurable (though I will grant you some fudge factor leeway) you will end up with a project that fails to deliver, an unfulfilled team, and an unhappy stakeholder.

Gantt charts are like horizontal infographics for your project.

They look pretty, you think you have deep insight when you look at them, but in essence they hide a wealth of sins about your project.

Projects are multi-dimensional and it is rare a spreadsheet or the resulting Gantt chart captures all the nuance you need to track and be aware of.

They are a good start, but if all you have is a Gantt chart, then everything looks like a resource to be managed.

If you believe that you have captured all of the interdependent events of a project that will last more than a few hours then I am afraid I will have to give you some bad news.

Beware the stakeholder that wants to direct project funds to non-deliverables.

It’s okay to break down a larger project in to smaller projects.

We do it all the time, we just don’t always admit to ourselves.

Time frame.

Interdependent events and resources.

Desired outcome (preferably objectively measurable).

Unique characteristics.

The essential elements of any project you will ever tackle.

If you don’t understand or lack detail  on any one of them, it’s pretty much a sure bet your project is going to run in to trouble until you do have that information.

“Holistic approach.”

“30,000 feet view.”

Code phrases we use to describe “I need to put some distance between myself and the individual trees just to figure out how big the forest actually is.”

Assign more meetings to those people who work in fragmented time (project managements, team leads, etc.).

Assign fewer meetings to those people who work in focused time (creative workers, engineers, software developers).

One of the issues I see repeatedly with inexperienced project managers is that they try to treat a software development project the same as making a sandwich.

You can make the sandwich almost any old how, and it will still be a sandwich (of a sorts).

And you can apply the ingredients haphazardly and not in any particular order and it will still be a sandwich (of a sorts).

If you are haphazard, apply the ingredients in a random order, and just slap ingredients together until you think you are done, your software development project doesn’t become a beautiful, edible sandwich.

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

That is no longer a meeting.

That is a committee with an opinion.

“But we have to have meetings.”

I hear this a lot. I know you do as well.

Meetings (the right kind) can often resolve conflicts we cannot resolve via email or other faceless communications means.

The art of calling an in-person meeting is knowing when to call an in-person meeting.

Too frequently an in-person meeting is called because of fear.

Because the person needing the meeting wants other people will make the decision for them.

As a project manager, if you do more talking in a meeting than listening, you’re doing it wrong.

As a software developer (or any kind of technical or creative contributor), if you do more listening in a meeting than talking, you’re doing it wrong.

P.S. To whatever you rebut, the answer is “You’re in the wrong meeting or you shouldn’t even be in that meeting.”

The one error I see again and again in software project management is the failure to track how long it takes to fix each defect.

The other major error I see is asking software developers to estimate how long it will take to fix a particular defect.

The bad project managers I’ve worked with insisted on perfection but didn’t plan for it.

The really bad project managers I’ve worked with insisted on perfection but didn’t know how to achieve it.

The terrible project managers I’ve worked with insisted on perfection but didn’t know what it looked like.

The greatest project managers I’ve worked with insisted on perfection and actually got it.

If you want perfection in your project, you have to plan for it, be able to attain it, and also be able to recognize it when you get it.

And without planning, attaining and recognizing the perfection you are striving for, you won’t be able to reach it.