The problem with most project management books, treatises and discussions is that they are immensely practical but ultimately boring.

Never have I read a less noteworthy body of work since the IRS decided to print the tax code.

My preference for identifying problem areas in a technical project is to look for weak links.

Weak links aren’t (ever) individuals, even if they are under-performing or lack the skill-set to complete the task.

Weak links are where two or more people interface with each other in their work.

Weak links are where there needs to be a hand-off of one piece of work from one individual contributor (or completely separate team) to another individual contributor (or completely separate team).

Identifying the weak links early, and being vigilant for new weak links appearing, are hugely beneficial to cutting off potential problems long before they become actual problems.

Individual contributors get bogged down in their own detailed areas of work almost to the exclusion of paying attention to anything else.

As project managers we feel compelled to hold status meetings where we can brief everyone on the state of the project and what is going on.

Much more effective, especially for passive communication of project status, is printing out screens of each section being worked on, and highlighting what’s new, what changed.

And documenting the why of the decision for the change.

And that last step is incredibly important.

It is a powerful tool that takes very little time for one person (the project manager) to convey a large amount of change (the project) to a large audience (the team) without calling a meeting that pulls the team out of their flow with a weekly or monthly “all hands” status meeting.

If you have suddenly found yourself to be an accidental project management (without training or experience), my recommendation is you read a good book or two on the subject, and then find yourself a mentor, either in the same company (if it is large enough) or at a local project managers association.

What distresses me most about modern project management in an agile context is our complete disregard for visualization.

We create a few pretty graphs and bar charts from various data points in the tracking system, hoping that some random red, green and yellow lines will cross at some arbitrary point, and call it good if they do and bad if they don’t.

Visualization of critical data points is… well… critical to being able to reason about a project in a meaningful way that doesn’t require us to interpret numbers and clouds of data points.

On almost every project where I do nothing but project management I dedicate about 5% of my daily work to creating and updating graphical representations of our project.

How many tasks done.

How many known tasks to go.

How many bugs are open.

How many we closed yesterday.

How many new bugs we opened yesterday.

People who are “in” (the office) that week.

People who are “out” (on vacation) that week.

Any data points that I can convey visually.

And then I post them prominently for others to see.

Projects aren’t always late on delivery.

Quite frequently, projects were late before they started.

Projects with an over-optimistic time frame, or as bad project managers like to call it “an aggressive schedule” AKA “we set the deadline with no heed to what needs to be done.”

You cannot fix a project that is late before it starts simply be decreeing that we need to catch up.

I hold a belief that if you lack quantifiable data you should immediately start gathering any data rather than sitting around discussing what data should be gathered.

As a general principle of project management, when I work directly with stakeholders, I rarely, if ever, ask them what they want from the product or service.

Good end user use-case research should never start with “what do you want?”

I wrote about this very problem many, many, many years ago.

What did you need again?

Wanting what you got

Be in the habit of discussing your data after you have gathered it, not before.

When it comes to project management…

Knowledge is power.

Quantifiable knowledge is ultimate power.

Unlike great software developers I have yet to meet a project manager that leaves the office at the end of the day and goes home to work on a tricky project management problem “just because.”

We will go home and work on wrangling our project because we feel the pressure to meet a deadline.

But our ability to be great project managers never comes from a spreadsheet, wrangling a bunch of open tickets or grooming the backlog.

There is a fine line between “just enough sticky notes to remind me of something” and “this is my project management system.”

We’ve all been there.

As experienced project managers we can recognise that line in other people.

But sometimes we don’t see it in ourselves.

Projects suffer from ennui as much as people.

We identify project ennui as a lack of focus, a lack of progress, a lack of “shit getting done and done right.”

Project ennui is pervasive. But it is not continual.

Every project will have it at some point, it comes and goes in irregular cycles.

Project ennui becomes a problem when it is ongoing, when there is something actively blocking forward progress.

Identifying those factors, whether it be individual members of staff (rarely), direction, focus, clear goals or identifiable, actionable day-by-day tasks and then actively mitigating their effect can put an otherwise recalcitrant project back on the path.

It is when we try to identify a single source of project ennui is when the real problems start.

Ongoing ennui, that we cannot resolve, becomes project depression.

And from that, we get a failed project.

Every problem project I have ever run in too was because of a lack of communication.

It wasn’t technical.

It wasn’t budget,

It wasn’t execution.

It wasn’t idea.

All of those things had an impact.

But the primary problem was always, always, ALWAYS communication.

“We don’t have enough staff.”

“Joe said that feature would be two months later than estimated.”

“We don’t have the skill-set to pull that off.”

“The technology isn’t mature enough to deploy.”

“We’re going be over budget if we don’t figure out a solution to that.”

Every single time, someone, somewhere, didn’t say what was on their mind.

Speak up.

Frequently.

As a project manager, when communicating with your team, if what you just said does not end in a question mark, you’re doing it wrong.

You want to always have more questions than you have answers.

Even when you have the answer.

Developing a realistic plan is one of the hardest parts of initial project planning I have ever faced.

The realistic part is where the metaphorical rubber meets the metaphorical road.

You might be faster at something, you might be better at something, but as a project manager, realise you are fighting against the project equivalent of entropy.

You cannot do it all. It is time to delegate.